An AI wallet security checklist is a launch gate
An AI wallet security checklist should answer one question before an agent can move value: what stops a valid-looking but unsafe transaction? Creating an address is easy. Launch readiness requires isolated secrets, limited authority, Co-Signer policy, bounded destinations and amounts, an emergency pause, and evidence finance can reconcile.
The enemy is unbounded autonomy. A model may produce transaction intent, but separate systems must hold secrets, approve, sign, and record the result.
Short answer
Before launch, keep private keys, API private keys, encryption material, and MPC shares outside the prompt. Give the agent a scoped identity, require idempotent signed requests, enforce amount and destination rules through a customer-controlled Co-Signer, connect WebSocket events and the operating ledger, and test an emergency pause. Release real funds only after rejected, duplicated, delayed, and interrupted transactions behave as designed.
The launch-control matrix
Use this matrix as an acceptance test.
| Control | Evidence required before launch | Failure it limits |
|---|---|---|
| Secret isolation | No private key, MPC share, encryption key, signed event URL, or long-lived credential appears in prompts, logs, or Git | Credential theft and irreversible key exposure |
| Scoped identity | Separate Ed25519 API keys for the Co-Signer and integration, each with minimum permissions | One compromised workload gaining broad authority |
| Co-Signer policy | A transaction outside local policy is rejected before signing | Model intent becoming unilateral signing authority |
| Destination rules | Approved address, network, asset, token standard, and memo requirements are checked | Funds sent to the wrong or unsupported destination |
| Amount and velocity limits | Per-transaction, daily, and burst limits are tested at their boundaries | Overspending and rapid automated loss |
| Emergency pause | A named operator can stop new sends without deleting evidence | Continued movement during an incident |
| Idempotency | A timed-out request retried with the same key creates no duplicate transaction | Duplicate payments during recovery |
| Event visibility | Created, rejected, signed, broadcast, confirmed, and failed states are observable | Silent failures and false customer balances |
| Ledger and audit | Every balance impact links to an actor, wallet, operation, policy outcome, and external reference | Unexplained movements during reconciliation |
1. Keep secrets outside model context
The model does not need wallet private keys, seed phrases, MPC shares, Co-Signer encryption material, or API private keys. It needs structured capabilities: create a wallet under an authorized account, read an approved balance, propose a transaction, or retrieve a status. The protected runtime performs the signed request.
OWASP's secrets management guidance recommends fine-grained access, least privilege, rotation, revocation, and keeping secrets out of logs. Apply that lifecycle to every agent identity.
Use separate secrets for development, testnet, and live flows. If a secret enters a prompt, transcript, issue, or repository, treat it as exposed and rotate it.
2. Split identities and enforce least privilege
The Co-Signer and application integration do different jobs, so they should not share one API identity. Each needs only the permissions required for its workflow.
If the integration is compromised, the team can disable it without replacing the Co-Signer's signing material. Network location alone is not authorization: authenticate the service, limit its scopes, validate request freshness, and check policy before value moves. Follow the current BroSettlement authentication guide for signed requests, timestamps, nonces, and replay protection.
3. Put the Co-Signer between intent and signing
An agent may decide that a supplier invoice should be paid. It should not decide alone that a cryptographic signature may happen. The customer-hosted Co-Signer is the control boundary between those two statements.
Threshold cryptography distributes trust across participants instead of relying on one complete signing key. NIST describes multi-party threshold schemes as applying secure multiparty computation to signatures and key generation. In BroSettlement's 2-of-3 architecture, normal signing requires cooperation without reconstructing the complete private key.
Cryptography does not define business policy. The Co-Signer still needs explicit rules for assets, networks, destinations, values, and manual-review thresholds. Read the Co-Signer guide and test rejection as carefully as approval.
4. Define transaction policy before automation
Write policy in a form that produces a deterministic answer. “Pay reasonable invoices” is not a control. “USDT on TRON, approved destinations only, within transaction and daily limits, with manual review above a threshold” is testable.
| Policy decision | Automatic result | Evidence to retain |
|---|---|---|
| Destination is not approved | Reject | Destination, network, policy version, rejection reason |
| Amount exceeds the transaction limit | Reject or require review | Requested amount, threshold, reviewer decision |
| Daily budget would be exceeded | Hold | Current total, proposed amount, budget period |
| Asset or network does not match the route | Reject | Requested and allowed route values |
| Memo or destination tag is required but missing | Reject | Validation result without exposing secrets |
| Risk or compliance status is unresolved | Hold | Case reference and responsible owner |
The agent should receive a bounded result: approved, rejected, or review required. It must not rewrite policy, raise its limit, or approve its own exception.
5. Make emergency pause operational
An emergency pause is a rehearsed procedure with a named owner, defined scope, and preserved evidence. It may combine application controls, API-key revocation, Co-Signer policy, and manual approval. It should stop new sends without erasing pending operations or ledger history. Run the drill on testnet, restore service, and reconcile every transition.
6. Make every transition observable
WebSocket events provide fast awareness, but they are not the accounting source of truth. Consumers must tolerate duplicates, reconnect safely, and fetch current state before changing a customer balance.
At minimum, operations should distinguish:
- the agent created an intent;
- authentication and policy checks ran;
- the Co-Signer approved or rejected it;
- MPC signing completed or failed;
- the transaction was sent to the blockchain network;
- the network confirmed, rejected, or replaced it;
- the operating ledger posted the resulting balance impact.
Use WebSocket events for visibility and the operating ledger for balance impact. Record the agent identity, policy version, idempotency key, wallet ID, operation ID, and external transaction reference.
7. Test retries and failure modes
Before launch, test the paths most likely to create financial ambiguity:
- the API accepts a request but the client times out;
- the same idempotency key is sent again;
- the Co-Signer is offline;
- the network fee changes or balance becomes insufficient;
- a destination fails the allowlist check;
- WebSocket delivery duplicates an event or reconnects after a gap;
- a transaction remains non-final longer than expected;
- the ledger and an internal product balance disagree.
A timeout is not permission to generate a new idempotency key. Retrieve the existing operation and continue from its current state. The testnet wallet guide shows how to prove the receive and send paths before real funds are involved.
8. Keep finance and compliance in the control loop
Finance needs more than a blockchain hash. Each movement should connect the agent, business purpose, source wallet, destination, asset, amount, fee, policy outcome, approver, ledger entries, and final network status. Reconciliation should compare product balances, BroSettlement ledger entries, and on-chain activity through stable identifiers.
MPC and Co-Signer controls do not replace KYC/KYB, AML decisions, Travel Rule processes, licensing analysis, sanctions screening, or jurisdiction-specific review. A held transaction needs an owner and resolution trail.
Export evidence according to your organization's retention policy. BroSettlement's Audit Logs API can filter organization-scoped activity by source, action, actor, object, IP, and time. API availability does not replace the customer's retention, review, and access-control obligations.
How BroSettlement supports the control boundary
BroSettlement connects embedded MPC wallets, a customer-hosted Co-Signer, signed API requests, events, an append-only operating ledger, and audit records. BroLabel AI Agents lets an agent use that infrastructure without holding raw signing secrets.
The practical next step is to install and inspect the BroSettlement Agent Skills, run the full checklist on testnet, and record evidence for every pass and failure. Do not move to real funds because wallet creation succeeded. Move only when policy, pause, event recovery, and reconciliation tests also succeed. Bro has your back!
Prelaunch verification checklist
- Secrets: no private key, MPC share, encryption material, or signed event URL enters model context.
- Identity: Co-Signer and integration identities are separate and minimally scoped.
- Policy: destination, asset, network, amount, velocity, and review rules are explicit.
- Separation: the agent cannot modify policy and approve its own exception.
- Pause: emergency controls have an owner, scope, restoration path, and test evidence.
- Retries: the same idempotency key cannot create duplicate payments.
- Events: reconnection and duplicate delivery are handled safely.
- Ledger: entries reconcile to product balances and on-chain references.
- Evidence: audit exports and retention have named owners.
- Obligations: KYC/KYB, AML, Travel Rule, licensing, and sanctions responsibilities are documented.
FAQ
Can an AI agent hold a wallet private key?
It should not. The agent can create transaction intent, while private keys, MPC shares, and API private keys stay in protected infrastructure outside model context.
Is MPC enough to secure an AI wallet?
No. Launch still needs scoped identities, Co-Signer policy, limits, destination rules, idempotency, monitoring, reconciliation, recovery, and incident procedures.
What should the emergency pause stop?
Define the scope: one agent, wallet, API identity, asset, route, or all outbound transactions. Preserve pending state and audit evidence.
How should duplicate transaction requests be handled?
Reuse the original idempotency key, retrieve the existing operation, and continue from its current state. Do not create a new key simply because the first response timed out.
When is an AI wallet ready for real funds?
Only after testnet evidence covers approvals, rejections, limits, pause, retries, event recovery, ledger postings, reconciliation, and incident ownership. A created address is not a readiness test.
