Agent Economy Wallet implements defense-in-depth security to ensure AI agents can manage funds autonomously without risk of drain, replay, or unauthorized access.
AES-256-GCM Keystore Isolation
Private keys are never exposed in plaintext to the LLM or application state.
- Encryption at rest: All keypairs encrypted using AES-256-GCM with a key derived via PBKDF2 (210,000 iterations, SHA-512).
- In-memory decryption: Keys are decrypted only when a discrete, authorized signing operation is triggered — never held in memory otherwise.
- Agent isolation: Agents receive public keys and signing references only. Raw seed phrases are never exposed to the LLM context.
- File-level protection: Keystores are saved to
~/.agent-economy-wallet/keys/ and are .gitignored from source control.
Spending Policy Engine
Every outbound transaction passes through the Policy Engine before reaching the network:
| Guardrail | Description |
|---|
| Per-Transaction Cap | Maximum SOL or token amount allowed in a single transfer |
| Daily Spending Limit | Rolling 24-hour cap on total outbound value |
| Rate Limiting | Maximum transactions per hour to prevent rapid drain |
| Whitelist Enforcement | Restrict interactions to known program addresses and trusted merchant keys |
| Human-in-the-Loop | High-value transfers above a configurable threshold require explicit operator approval via the CLI |
The Policy Engine runs before signing — rejected transactions never touch the network. There is no override mechanism available to the AI agent.
x402 Payment Security
The x402 protocol includes built-in protections against abuse:
- On-chain verification: Every payment signature is verified against the Solana ledger. The merchant confirms the USDC transfer amount, recipient address, and transaction finality before releasing data.
- Anti-replay cache: An LRU cache of recent transaction signatures prevents the same payment from being used twice.
- Stateless validation: No off-chain state is needed. Payment proofs are Solana transaction signatures — independently verifiable by any party.
On-Chain Registry Security
The decentralized registry has unique security properties:
- Immutable registrations: Once an SPL Memo transaction is confirmed, it cannot be altered or deleted.
- Wallet attribution: Every registration is signed by the merchant’s wallet — the blockchain provides cryptographic proof of authorship.
- Manifest verification: Buyer agents fetch the manifest from the URL in the memo and can verify the server is still live before transacting.
- No central authority: There is no admin key, no governance token, and no mechanism for any party to censor or remove a registration.
Audit Trail
Every action taken by every agent is recorded in the audit log:
- Transaction attempts (successful and failed)
- Policy engine evaluations
- x402 payment flows (probe, pay, receive)
- Wallet creation and closure events
- Gasless relay usage (Kora vs self-paid)
The audit log is queryable via MCP resources (audit://logs, audit://wallet-logs/{wallet_id}) and the CLI dashboard.
Wallet Closure
Wallet closure is a human-only operation:
- The
close_wallet function is deliberately excluded from MCP tool registration.
- Only human operators using the CLI TUI can close a wallet.
- On closure, remaining SOL is swept to the
OWNER_ADDRESS configured in .env.
- All associated keys are securely destroyed from the keystore.
Recommendations
For production deployments:
- Use
pnpm key:import to encrypt the master wallet key — never store base58 keys in .env.
- Set
WALLET_PASSPHRASE to a strong, unique passphrase (minimum 12 characters).
- Run the Kora relay on a separate machine from the MCP server.
- Review audit logs regularly via the CLI dashboard or
daily_report prompt.
- Set conservative daily spending limits and lower them as needed.
