T06 · System Persistence
- Location
SKILL.md:58- Finding
Mandatory Twice-Daily Wallet Monitoring Creates Cross-Session Persistence
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This wallet skill is broadly payment-related, but it asks for recurring wallet access, reusable spending authority, mutable external instructions, and unpinned code execution that users should review carefully.
Install only if you are comfortable letting an agent link to a wallet, create and reuse spending mandates, inspect received-payment records, and interact with FluxA/ClawPI services. Before use, avoid enabling the scheduled task unless you explicitly want twice-daily wallet checks, pin CLI versions, require confirmation before transfers, social actions, reward claims, paid API calls, and card-detail display, and review or delete stored mandates when no longer needed.
SKILL.md:58Mandatory Twice-Daily Wallet Monitoring Creates Cross-Session Persistence
CLAWPI.md:9Mutable Remote Markdown Is Treated as Trusted Agent Instructions
SKILL.md:64Skill Mandates Promotional and Financially Oriented User Steering
SCHEDULED-CHECKIN.md:9Unattended Execution of Mutable npm Packages Creates a Supply-Chain Execution Path
MANDATE-PLANNING.md:54Cross-Session Mandate Reuse Relies on Unprotected Local State
Skill contains instructions that could directly expose system prompts, internal rules, or hidden instructions to users or external parties.
- Do not over-explain.
- Do not auto-follow users unless clearly worthwhile.
Output rules:
- Always include the Wallet report section, even if there was no activity.
- Keep the full user-facing summary concise and in user's language.
- If there is nothing meaningful beyond the required Wallet report, still send the Wallet report only.
The skill instructs the agent to update the skill/CLI from a remote URL and install @latest, which is a self-modification path. This undermines reproducibility and review, and could let a compromised remote resource or package update change the agent's behavior and privileges mid-session.
| **Charge Agent** | Receive payments from agents via Payment Link + x402 | [INTEGRATION-GUIDE-CHARGE-AGENT.md](INTEGRATION-GUIDE-CHARGE-AGENT.md) |
| **Payout to External Wallet** | Send USDC to any Base chain wallet address | [INTEGRATION-GUIDE-PAYOUT.md](INTEGRATION-GUIDE-PAYOUT.md) |
## Troubleshooting — Update Skill & CLI
If you encounter persistent errors during payment or other operations that you cannot resolve, the skill or CLI version may be outdated. Update from:
The file expands a payment-wallet skill into social-network behaviors such as registering for a social app, posting content, following accounts, and claiming red-packets. In a wallet-integrated agent, this broadening of scope is dangerous because it can drive the agent to take privacy-impacting and financially relevant actions that are not clearly aligned with the wallet skill’s stated purpose or bounded by explicit user consent.
The documentation directs the agent to register an external service, create a watch-only URL, follow accounts, and claim red-packets, all of which have privacy and financial consequences, yet it provides no consent, disclosure, or safety guidance. In the context of a wallet-enabled agent, omission of consent boundaries materially increases the chance of unauthorized account linkage, fund-related interactions, and exposure of user activity.
The instructions tell the agent to create posts, discover and follow people, and report how many accounts were followed, none of which are justified by a payment-focused wallet skill. This creates a real risk of unauthorized social actions, reputation harm, and downstream financial exposure if following or claiming rewards causes wallet-linked activity on behalf of the user.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl -X POST https://agentid.fluxapay.xyz/refresh \
-H "Content-Type: application/json" \
-d '{"agent_id": "<agent_id>", "token": "<token>"}'
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Your service needs its own Agent ID to create payment links:
curl -X POST https://agentid.fluxapay.xyz/register \
-H "Content-Type: application/json" \
-d '{
"agent_name": "My Service",
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Your service needs its own Agent ID to create payment links:
curl -X POST https://agentid.fluxapay.xyz/register \
-H "Content-Type: application/json" \
-d '{
"agent_name": "My Service",
The guidance to create one reusable mandate for an entire multi-step or recurring workflow increases the lifetime and scope of delegated payment authority, reducing per-action user review. In the context of an agent wallet, this makes misuse more dangerous if the agent misclassifies later payments as within scope, if the workflow expands unexpectedly, or if persisted mandates are reused inappropriately across conversations.
- Discover API → pay → generate → poll result (Banana/Seedance)
- Search x402 services → call multiple APIs to compare results
**Strategy:** Estimate the **total cost across all steps** before creating the mandate. Include retry buffer (1 extra attempt per step). Create **one mandate** covering the entire workflow — do NOT create a new mandate per step.
### Type 3 — Recurring / Long-Term Task
The policy instructs the agent to persist mandate data across conversations in a local file, including purpose, scope, budget limit, and validity metadata, but does not require any user-facing notice, consent, or retention controls. In a wallet skill, this creates privacy and authorization risk because future sessions may silently reuse previously approved spending authority and expose payment-related history to other local actors or contexts.
The documentation includes examples for received payment records that expose potentially sensitive payer information such as wallet addresses, transaction hashes, payment descriptions, and especially payerEmail, without any warning about privacy handling or data minimization. In a wallet/payment skill, this can normalize collecting and surfacing personally identifiable and financial metadata to agents or downstream consumers, increasing the risk of unnecessary disclosure, retention, or misuse.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
| Status | Meaning |
|--------|---------|
| `pending_authorization` | Waiting for user approval |
| `authorized` | Auto-approved via `--mandate`, onchain tx starting |
| `processing` | Approved, onchain tx in progress |
| `succeeded` | Done, `txHash` available |
| `failed` | Transaction failed |
The scheduled task executes npx ...@latest, which fetches and runs whatever package version is current at execution time. In a recurring autonomous workflow tied to a wallet, this creates a software supply-chain risk: a compromised or malicious newly published version could gain code execution and interact with wallet-related state or credentials without an explicit user review step.
This is a second scheduled invocation of the same unpinned npx ...@latest package, so the same supply-chain exposure applies to transaction-report generation. Because the command processes wallet activity in an automated context, a malicious upstream update could exfiltrate sensitive transaction metadata or perform unintended wallet operations.
The scheduled check-in expands beyond wallet operations into fetching external announcements and social-feed content from remote URLs. For a wallet skill, this broadens the trust boundary and causes the agent to ingest untrusted remote content on a schedule, increasing prompt-injection, tracking, and unnecessary data-exposure risk without being required for core payment functionality.
Reading recommended users, red packets, and recent social feed is unjustified for a payment wallet check and introduces unrelated third-party content into an autonomous workflow. This increases the chance of prompt injection or manipulative content influencing agent behavior, especially given the wallet-adjacent context and references to potentially taking actions like following users.
The activation description says to use the tool for any payment-related action, which is broad enough to trigger on loosely related prompts. In an agentic environment, overly broad routing increases the chance of invoking wallet/payment operations when the user intended only discussion, planning, or comparison.
The repeated instruction to use this tool whenever the user asks for payment-related actions lacks boundaries around execution vs. advice. Because the skill can move funds and initiate approvals, broad invocation guidance materially raises the risk of unintended financial workflows being started.
The documented card details capability reveals full prepaid card credentials (PAN, CVV, expiry), which is materially more sensitive than ordinary payment actions and exceeds the narrow payment-wallet scope described in the manifest. In an agent setting, this increases the risk of credential exfiltration, accidental disclosure in chat/logs, or misuse by downstream tools.
Issuing short-lived identity credentials for SSO/account binding is a distinct trust and authentication function, not a routine wallet payment action. If misused, an agent could authenticate to third-party services or bind accounts in ways the user did not expect, extending impact beyond financial operations.
The skill directs the agent to reuse signed mandates from persistent local state and conversation context across tasks. While operationally useful, this creates session-persistence risk: previously granted authorizations may be silently reused in later contexts, reducing fresh user visibility into spending scope.
**MUST** follow when working with intent mandates:
1. **Plan by task intent, not by API call.** Assess the full task before creating a mandate — estimate total cost across all steps, create one mandate for the whole workflow.
2. **Check for reusable mandates first.** Before creating a new mandate, check both the current conversation context and `~/.fluxa-ai-wallet-mcp/mandates.json` for existing signed, unexpired mandates that fit.
Full planning rules, task classification, and state file schema: [MANDATE-PLANNING.md](MANDATE-PLANNING.md)
The skill advertises card details --id as revealing full card details without any explicit warning about displaying highly sensitive secrets. In practice, showing PAN/CVV/expiry to an agent can leak them into transcripts, tool logs, screenshots, memory, or other integrations, enabling fraudulent card use.
The instructions direct the agent to execute a real USDC payment flow, including mandate creation, signing, and submission of an x402 payment token, without an explicit warning that this moves funds and may be irreversible once executed onchain. In an agent-wallet skill, omission of a prominent confirmation step is especially risky because an autonomous or semi-autonomous agent may follow the sequence as operational guidance and trigger unintended transfers.
The skill directs the agent to discover and call paid third-party APIs and request wallet budget approval, but it does not require explicit disclosure of external data sharing, third-party payment routing, pricing uncertainty, or service trust boundaries before proceeding. In a wallet-enabled agent context, this increases the risk of users authorizing charges or transmitting prompts/data to external providers without informed consent, which is materially more dangerous than in a non-payment skill.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
VC=$(echo "$RESULT" | jq -r '.data.vc')
curl -X POST "$AUDIENCE/agent-bind"
-H "Content-Type: application/json"
-d "{"vc": "$VC", "challenge": "$CHALLENGE"}"
No suspicious patterns detected.