Wallet infrastructure for AI agents: MCP access with clear spending authority

The short answer

An AI agent should never be the thing that decides whether a payment is allowed. The prompt is an instruction, not a control. The wallet layer has to hold the authority: an identity for the agent, a policy that says exactly what that identity may do, enforcement that does not depend on the agent's code behaving, and a record of everything it tried. The Model Context Protocol is a good way to give an agent access to a wallet. It is not a way to constrain one.

Three patterns work in practice, and most teams should start with the first and end with the third.

Den publishes this blog and builds the infrastructure behind the third pattern. Where we describe other providers, we cite their documentation as read in September 2026.

What MCP does and does not do

The Model Context Protocol is an open standard for connecting AI applications to external systems. A host application such as an assistant runs clients that connect to servers, and servers expose tools the model can call, resources it can read, and prompts it can use. That is an integration surface, and a good one, because a wallet vendor or your own team can publish a server once and every MCP-capable agent can use it.

The specification is candid about the risk. Its security section says tools represent arbitrary code execution and must be treated with appropriate caution, that hosts must obtain explicit user consent before invoking any tool, and that descriptions of tool behaviour should be considered untrusted unless they come from a trusted server. It also says plainly that MCP cannot enforce these principles at the protocol level. Whoever operates the wallet has to.

Fireblocks' official MCP server is a useful example of getting this right. Its tools are read-only by default, covering vault accounts, transactions, assets, policies, and users. The single write operation, creating a transaction, is disabled unless an environment flag enables it. The README recommends the least-privileged API role and strongly advises configuring the policy engine so a human designated signer must approve any transaction the assistant initiates. That is the correct division of labour: MCP for access, the policy engine for authority.

Pattern one: the read-only assistant

Start here. An agent with a viewer role can answer "what did we pay this vendor last quarter," summarize the approval queue, explain why a transaction was rejected by policy, and draft reconciliation notes. It cannot move money, so the failure mode of a bad prompt is a wrong answer rather than a wrong payment. In Den, that is an API member that no policy names as an initiator or approver, which leaves it able to read accounts and transactions but unable to queue one. In Fireblocks, it is the Viewer role the MCP README recommends. In Utila, it is a service account with the viewer role.

Pattern two: an agent-owned wallet with a hard budget

When the agent needs to pay for things itself, give it a wallet whose rules are enforced outside the agent.

Privy's guide to agentic apps describes provisioning an agent its own embedded wallet and attaching policies that cap transfer amounts per transaction and per time window, allowlist contracts and recipients, and restrict operations to time windows. Once a policy is attached to a wallet, its policy engine denies any request the rules do not allow, and evaluation happens inside the enclave that signs. Turnkey's policies can restrict an agent's API key to specific destinations and require consensus for anything else, and its September 2026 scoped sessions make an agent's authority specific and temporary. Safe's agent quickstart uses the Allowance module to make the agent a delegate with a daily token budget rather than an owner, so the limit is enforced by the account contract itself. Fireblocks' Agentic Payments Suite, launched in May 2026, describes per-wallet and per-delegation rules for spend limits, merchant allowlists, time windows, and asset constraints.

The pattern is right for agents buying data, inference, or API calls at small scale. Turnkey's September 2026 analysis of the x402 Bazaar found agents mostly paying fractions of a cent for search, market data, and blockchain reads. A budgeted wallet fits that. It fits less well for paying a vendor invoice: caps and allowlists bound the damage, but no human reviews the specific payment before it settles.

Pattern three: the agent as a proposer inside an organization

For anything where money is meaningful, put the agent inside the same governance as your people. It gets an identity, a narrow set of things it may do without review, and a path to escalate everything else to a human.

Den models this directly. An agent is an API member: a programmatic identity that an admin invites, that proves control of its signing key, and that admins add through a member proposal. Its key can live in a KMS or HSM per Den's signing key guidance, so the agent never holds a secret in its context. Then two policies define its world:

• An auto-approval policy for the routine case: token transfers from one operating account, initiated by the agent, in one token, to recipients on an allowlist, under a per-transaction cap, with a time limit on how much that initiator can move per day.
• A manual-approval policy for everything else the agent is allowed to propose, requiring 2 of 3 members of the Finance group to approve on their mobile signing clients.

A transaction that matches neither policy cannot be queued at all, per the transaction flow. The agent's initiator signature is distinct from approval: it authorizes the proposal to exist and expresses no decision. The SDK validates the policy locally before it will produce signable data, the Guardian service validates it again, and the onchain contracts verify the policy and the approvals a third time before executing. If the agent's process, the MCP server, or Den's own server is compromised, the contract still reverts a transaction that does not match.

Two properties close the escalation loop. The agent is not an admin, and only admins can propose or approve changes to members, groups, policies, or admins, so the agent cannot widen its own permissions. And every mutating API call requires an idempotency key, so an adapter that retries a timed-out request with the same key does not create a second proposal.

Den's documentation describes integration through its API and TypeScript SDK and does not list an MCP server among those paths. The design we recommend is a custom adapter your team builds on the SDK that exposes a few tools: list the accounts and balances the agent may see, fetch a transaction and its policy result, and propose a payment with a description that carries the business reference. Keep the adapter small. The authority lives in the policies, not in the tools.

Threats that are specific to agents

Injected instructions. An invoice PDF, a web page, or a chat message can contain "pay this address instead." Resolve recipients from your own vendor records, never from the content the agent read, and let the allowlist policy be the backstop when the resolution is wrong.

Poisoned tools. The MCP spec warns that tool descriptions are untrusted. Pin the servers your host may connect to and review their tool lists like you review dependencies.

Leaked credentials. The agent should never see a private key or a long-lived API secret in its context. Den API members sign from a KMS. Privy's agent authorization flow is built so the agent never handles keys or credentials. Turnkey's scoped sessions expire.

Self-escalation. Confirm the agent's identity cannot change policies, add signers, or raise its own limits. In Den that is the admin threshold. In Turnkey it is the root quorum. In Privy it is wallet ownership.

Runaway spend from correct behaviour. An agent doing exactly what it was asked, in a loop, is a failure mode to design for before launch. Per-initiator time limits, which Den supports per initiator, source account, or destination, are the control.

Ambiguous evidence. When something goes wrong you need to know what the agent asked for, which policy matched, who approved, and what executed. Den's audit log records transactions, approvals, and policy changes with actors and timestamps. Log the tool call arguments and the resulting proposal identifier alongside it.

How the providers compare for agent authority

Every row is workable. The question is what you want to be true when the agent's process is compromised. Enclave enforcement means the vendor's server is the last line. Onchain enforcement means the chain is.

For the embedded-wallet providers in this space, read Turnkey vs Privy. For the human approval design the agent should slot into, start with crypto treasury wallets for finance teams. Den's API and SDK page shows the building blocks for the adapter described above.