TL;DR
Enterprise AI agent wallets need six controls, and no single vendor feature covers the architecture. Agent code never holds or reads a private key. MPC, HSM, or TEE infrastructure signs approved transactions. A policy engine enforces spend caps, allowlists, and approval workflows. Separate credentials bind each wallet to one agent and one tenant. Tamper-evident audit trails record signing activity and policy decisions. KYT and sanctions checks run before signing, not after. The comparison table below scores Openfort, Circle, Coinbase, Fireblocks, and Ledger on key isolation, agent controls, and compliance and audit evidence that public documentation actually supports.
An agent wallet fails compliance review in a different place than a user wallet does. The signing key can be perfectly protected and the deployment still fails, because nothing recorded which agent asked, under which policy, or what the screening service said before the signature went out.
This post sets out the six controls an enterprise agent wallet needs before it gets transaction authority, then scores Openfort, Circle, Coinbase, Fireblocks, and Ledger on the evidence public documentation supports. For the wider vendor landscape, see the best AI agent wallets for developers. For the permission model underneath it, see agent wallet identity, permissions, and compliance and the AI agents solution page.
Why AI agent wallets need a different compliance model than user wallets
Autonomous agents remove the human review step that many wallet controls assume. A user can inspect the amount and recipient before approving a transaction. An agent generates payment requests from model outputs, API events, or scheduled instructions, often while no person watches. Compliance programs therefore cannot treat a valid login or wallet session as approval for every transaction the agent submits.
Higher transaction frequency increases the effect of faulty instructions and compromised workflows. A user might make one mistaken payment, while an agent can repeat the same action across hundreds of requests. Transaction controls must evaluate each request against machine-readable rules for permitted assets, recipients, and amounts. They must also track cumulative spending over defined periods and route exceptions to a human approver.
Agent authorization must connect every payment to a specific identity and policy decision. A valid agent credential should identify the agent and tenant, while the transaction record should capture the applicable policy version, screening result, and approval path. Without that attribution, an auditor cannot determine whether the agent acted within its authority or whether another workload used the same credential.
Before granting transaction authority, you should require isolated signing, enforceable spending policies, per-agent credentials, complete audit records, and pre-transaction compliance screening. Engineering reviewers can then test how the wallet blocks prohibited actions. Compliance reviewers can verify who authorized each payment and which controls ran before execution.
Keep private keys outside agent code
An AI agent should create transaction requests without gaining access to the private key that authorizes them. The agent sends a structured request to a separate signing service, which authenticates the caller and decides whether to sign. If agent code can read or export the key, an attacker who compromises the model or its runtime can bypass every control around the approved signing path.
An MPC wallet distributes signing authority across multiple key shares held by separate services, devices, or operators. A required threshold of shares jointly produces a signature without reconstructing the full private key in one location. The agent can request a signature, but it cannot access the shares. MPC alone does not determine whether a wallet is custodial or self-custodial. The entities controlling the shares, recovery method, and transaction authority determine the custody model.
An HSM stores or generates the private key inside a dedicated hardware security module. The HSM performs signing internally after an authorized service submits a request, and the key remains inside the device. A TEE instead runs signing code inside a hardware-isolated area of a general-purpose processor. The surrounding application can call the isolated code, but it cannot directly inspect the protected memory where the key resides.
Key isolation makes the agent an untrusted requester rather than a custodian. A signing service can reject requests that fall outside the agent's assigned identity or permissions. Operators can also suspend the agent's access without moving the underlying key. A signer that approves every authenticated request still protects key material, but it does not control how funds are used. Spend limits, counterparty rules, and approval requirements must therefore sit in the signing path rather than inside the agent's prompt or application logic.
Policy-controlled execution: spend caps, allowlists, and approval workflows
A policy engine should evaluate every signing request before the isolated signing service approves it. Key isolation prevents an agent from accessing private keys, while policy evaluation restricts how the agent may use those keys. The signing service should reject requests that violate any applicable rule.
Per-transaction limits cap the value of one payment. Aggregate or session caps limit cumulative spending within a defined period, so an agent cannot evade the per-transaction limit by submitting several smaller payments. Counterparty allowlists restrict transfers to approved addresses or contract functions. Human-in-the-loop thresholds route higher-risk requests to an authorized reviewer before signing.
You can stack these controls to express narrower authority. For example, an agent might receive permission to spend no more than 20 USDC per transaction and 100 USDC per day. The same policy could restrict payments to approved vendors and require human approval for any new counterparty. The policy engine should count concurrent transactions against the same aggregate cap so parallel requests cannot exceed it.
Coinbase CDP provides a concrete example of server-side enforcement before signing. Its policy engine supports per-token allowances, transaction limits, session caps, and counterparty allowlists. A policy could authorize USDC on Base while blocking ETH, reject any payment above a specified amount, and stop further signatures after the session reaches its cumulative cap. The linked overview also describes scoped session keys with defined permissions and expiration. An operator can revoke a session key without replacing the master signer.
Identity binding: giving every agent and tenant its own credential
Each agent should receive a distinct wallet identity or scoped session credential. The signing service binds that identity to one agent, one tenant, and a defined policy set. A session credential can authorize limited signing requests without exposing the wallet's custody key to agent code.
Shared credentials weaken attribution because multiple agents can submit requests under the same identity. Audit records may show which wallet approved a transaction, but they cannot independently establish which agent initiated it unless the service also records and verifies agent identity. A compromised agent could also use permissions associated with the shared credential but intended for another agent.
Per-tenant issuance preserves customer boundaries in a multi-tenant deployment. The wallet service should reject any request when the authenticated tenant, agent identity, wallet, and assigned policy do not match. Logs should record those bindings alongside each policy decision and signing event.
Individual credentials also contain the effect of a compromise. You can revoke one agent's wallet authorization or session credential while other agents continue operating. You can then review transactions tied to that identity, rotate its access, and issue a replacement without changing credentials across the fleet.
Audit trails and pre-signing screening requirements
A tamper-evident audit trail should record every signing request, including rejected requests. Each entry should identify the agent and tenant, the signing key or session used, the policy decision, the counterparty, and the timestamp. The record should also preserve the transaction payload, network, asset, amount, approval actor when applicable, and final transaction identifier.
The audit store should prevent silent alteration and support export into the company's monitoring and record-retention tools. Write-once storage or cryptographic chaining can make later changes detectable. Consistent request identifiers should connect the agent's action, policy evaluation, signing event, and blockchain transaction. Access logs should also reveal who viewed or exported the records.
KYT and sanctions checks should run before the signing service authorizes a transaction. The screening service should evaluate destination addresses and contracts against applicable sanctions lists, supported threat-intelligence sources, and your company's documented risk rules. A blocked or unavailable screening result should prevent signing unless an approved exception workflow applies. The audit trail should preserve the screening provider, result, rule version, and any exception approval.
A third-party Coinbase Agentic Wallets overview reports that activity logs include the timestamp, signing key or session, counterparty, asset, amount, and policy result, with portal access and real-time webhooks. A MetaMask comparison of agentic wallets reports that Coinbase KYT screening blocks transactions involving sanctioned addresses and known scam contracts. Buyers should confirm both capabilities in current Coinbase documentation and procurement testing.
A vendor comparison should therefore score audit completeness, tamper resistance, export access, pre-signing screening, and documented handling of blocked transactions. A generic activity feed does not meet the same standard.
Comparing AI agent wallet platforms on custody and compliance controls
The table scores documented controls rather than general custody or regulatory claims. A score of 2 indicates support documented in the sources cited here, 1 indicates partial or indirectly documented support, and 0 indicates that those sources do not verify the control. A zero does not prove that a vendor lacks the capability.
| Vendor | Key isolation | Agent controls | Compliance and audit | Best fit |
|---|---|---|---|---|
| Openfort | 2. Self-custodial key management through the open-source, self-hostable OpenSigner stack | 2. Policy-based transaction controls and agent wallets | 1. Five independent security audits are reported, but the cited public material does not verify wallet-level KYT or tamper-evident transaction audit records | Applications that want self-custodial infrastructure and programmable controls |
| Circle Agent Wallets | 0. Public material does not specify MPC, HSM, TEE, or another isolation method | 1. Circle describes transactions within defined guardrails, but does not document specific spend caps, allowlists, or approval rules | 0. Circle documents its company regulatory posture, but not Agent Wallet audit trails or KYT controls | USDC-centered applications that can validate technical controls during procurement |
| Coinbase CDP Agentic Wallets | 2. MPC key shares and AWS Nitro Enclave signing keep keys away from agent code | 2. Per-token allowances, session caps, transaction limits, allowlists, and scoped session keys | 2. Activity logs, policy decisions, webhooks, and KYT blocking are documented | Agents making controlled payments on Base or other supported networks |
| Fireblocks agentic payments commentary | 0. Fireblocks uses MPC in its broader platform, but no agent-specific custody design is verified | 0. Published commentary discusses desired controls without documenting an implementation | 0. Available sources do not confirm agent-specific audit or screening capabilities, and one source describes the material as conceptual rather than a product launch | Existing Fireblocks buyers willing to confirm whether agent controls exist in their contracted product |
| Ledger Enterprise Wallet Infrastructure | 0. Supplied evidence does not verify an agent-specific key architecture | 0. No documented agent spend policies, allowlists, or approval workflows | 0. No agent-specific audit trail or KYT evidence was available | Ledger customers prepared to validate programmatic signing and compliance controls directly |
Security audits assess the design or implementation within their stated scope, while transaction audit trails preserve evidence about individual wallet actions. Openfort's five audits assess security, while an enterprise compliance review should separately confirm event retention, policy-decision logging, export options, and pre-signing sanctions screening.
Vendor questions for compliance and engineering review
Public documentation may not provide enough detail to approve these controls during procurement. Ask each vendor to answer these questions and provide supporting architecture diagrams, sample exports, or test results.
- Key custody. Can agent code ever access a private key, key share, recovery secret, or signing credential? Who controls the signing infrastructure, where does signing occur, and which party can recover or move assets without customer approval?
- Policy engine. Which controls run before signing, and can you set per-transaction limits, cumulative spend caps, counterparty allowlists, and approval thresholds? Ask whether administrators can prevent agents from changing their own policies and how quickly policy updates take effect.
- Identity binding. Does each agent and tenant receive a separate wallet, session key, or credential? Confirm that you can revoke one compromised identity without disabling unrelated agents or rotating a shared fleet credential.
- Audit export. Does each record connect the agent identity, signing credential, policy decision, counterparty, amount, and timestamp? Request a sample export and confirm retention periods, tamper protections, API access, and compatibility with your security monitoring tools.
- KYT integration. Can sanctions and transaction-risk screening block a request before signing? Ask which screening providers the platform supports, how administrators set risk thresholds, and how reviewers handle false positives or approved exceptions.
Include these answers in the contract and acceptance tests. Vendor demonstrations should prove that rejected transactions remain unsigned and that revocation, audit export, and screening controls work under realistic failure conditions.
Conclusion
Compliant agentic payments depend on architecture decisions made before an agent receives transaction authority. Key isolation and policy-controlled signing limit what an agent can authorize. Per-agent identity, immutable logs, and pre-signing screening make each transaction attributable and reviewable.
Predeployment controls preserve the records needed to investigate transactions and can block requests that exceed an agent's authority. You should verify custody boundaries, transaction policies, credential revocation, audit exports, and screening integrations before deployment.
If you are building this model, consider whether Openfort's self-custodial agent wallet infrastructure fits your custody and policy requirements. Our open-source signing stack and five reported independent security audits can support engineering and compliance review, but you should confirm the current reports, scope, audit logging, and screening integrations during procurement.
FAQ
What is an AI agent wallet?
An AI agent wallet lets software request and execute digital asset transactions under defined permissions. Openfort provides self-custodial agent wallets with policy-based transaction controls. Key isolation and spending policies let agents transact without receiving unrestricted signing authority.
How is an MPC wallet different from a custodial wallet?
An MPC wallet distributes signing authority across separate key shares, while a custodial wallet gives a provider control over the assets. Openfort offers self-custodial key management through its open-source OpenSigner stack. You retain control over signing infrastructure without exposing a complete private key to agent code.
Do AI agents need KYC and KYT screening?
KYC identifies the person or business controlling an agent, while KYT screens transactions and counterparties for financial crime risk. An Openfort deployment can combine wallet policies with an external KYT and sanctions-screening service. Pre-signing screening can block prohibited transactions before execution.
What happens if an agent credential is compromised?
A properly isolated agent uses a restricted credential rather than a master private key. Openfort policies can constrain the wallet's permitted transactions and spending. You can revoke the affected credential while preserving other agents and wallets.
How do SOC 2 reports and security audits apply to agentic payment infrastructure?
SOC 2 evaluates a service provider's controls, while financial audits depend on complete records and documented procedures. Openfort has completed five independent security audits, but buyers should request current reports and verify their scope. Tamper-evident transaction logs that include policy decisions and agent identities provide evidence for compliance reviews.
