Custody policy engines weren't built for agents

If you run a custodian, wallet infrastructure or digital asset bank, your clients are going to ask you to let an AI agent act on their assets.

A fund wants its research agent to rebalance. A treasury team wants an agent to sweep idle stablecoins into yield and pay vendors. A trading firm wants an agent on perps around the clock. Each asks the same thing of its custodian: let the agent act, but make sure it only does what we say.

That's a new job for a custodian. The client sets the mandate and the custodian enforces it, whichever AI the client brings and whichever service the agent touches.

Most custodians already have a policy engine, and the obvious answer is to point the agent at it. However, policy engines were designed to manage a different kind of risk.

Custody policy engines only stop bad transfers

Custody policy engines grew up around treasury operations. They answer a precise question well: should this transfer leave this wallet? They do it with:

• Approval quorums: two of three signers for anything over a threshold.
• Destination allowlists: funds only go to known addresses or counterparties.
• Velocity limits: no more than a set amount per day.
• Role-based permissions: who can initiate, who can approve.

That model fits the risk it was built for: a stolen key, a rogue employee or a phished approver trying to move funds out. The risky event is a transfer, and the policy sits in front of it.

Custodians have the building blocks, but no agentic access yet

A review of public documentation from large custodians and institutional wallet platforms this autumn found the same picture almost everywhere:

• The parts exist. Allowlists, approval quorums, scoped API keys and, in some cases, velocity limits.
• Almost no one has joined them up for agents. One platform had shipped an agent-specific product, and it was invite-only. Others offered a documentation search for AI tools, or nothing agent-specific at all.
• The default safety model is a person. Withdrawals wait for human approval, or for video verification. That works for a treasury team that moves money a few times a day. It doesn't work for an agent acting every few minutes.

There is now increasing pressure to change. Bank of England Deputy Governor Sarah Breeden put it plainly in June: "relying on a human in the loop for all agent actions is unlikely to be realistic. More sophisticated governance and accountability frameworks may be needed."

Agents fail through valid actions, not just bad transfers

An AI agent with trading access rarely needs to move funds out to do damage. It can do damage in place, through actions that are each valid on their own. The agent doesn't need to be malicious:

• It could simply make a mistake, like a misread decimal or the wrong ticker.
• The code around it could have bugs, like retry loops, or sizing that ignores balances.
• Its credentials could leak.
• It could be manipulated via prompt injection, since it bases decisions on external text and information.

None of this would look like a suspicious transfer to a policy engine. Here are four common agent failures and how they would look to a transfer-focused policy:

Each row passes a transfer policy. Each breaks the client's mandate.

The rules read transactions, not positions

The deeper problem is what the rules can see. Most policy engines evaluate the fields of a transaction: destination, amount, asset, who initiated it, which contract function it calls. Even platforms that enforce policy at signing, inside secure hardware, are matching on those raw fields.

An agent's risk doesn't just live in those fields. It lives in the account: leverage after the trade, over-exposure to one asset, collateral health, how much has been spent this week across every action. A rule that can only see "amount: 500 USDC, destination: approved venue" can't tell a harmless order from the one that tips the account over.

And agents don't stay in one lane. The same agent might trade, stake, lend and pay in a single day. If each of those runs through a different control mechanism (key permissions for trading, an allowlist for transfers, nothing for lending), the client's mandate is only as strong as the weakest one.

What an agent policy has to check

To cover how agents fail, a policy needs eight properties that treasury engines rarely have.

1. One mandate across every action and service. Trading, staking, lending and payments governed by the same set of rules the client approved, not a different control per product.
2. Independent of the AI. Clients will bring Claude, ChatGPT, open-source models and their own agents, and switch as models improve. The mandate has to hold whichever agent is acting, so it can't live in the agent's prompt or tools.
3. Rules that understand each action. Size, leverage and exposure for trades; collateral health for lending; payees and budgets for payments.
4. Checks against the account after the action, not just the action. A $500 buy is harmless, unless the account already holds $20,000 of the same asset at 4x.
5. Enforcement outside the agent, before signing. If the agent can see, change or retry around the rules, they are suggestions. Nothing that fails the mandate should ever get a signature.
6. Safe by default. Most agent tools start with no limits at all. A new agent should start from sensible defaults (small sizes, no leverage, no withdrawals), loosened only when the client decides to.
7. Refusals are final, and only the client can change the rules. No appeal or retry loop for a manipulated agent to work on.
8. Evidence. Clients, auditors and regulators will ask whether each agent action was within mandate. A log the custodian wrote is something they have to trust. A proof is something they can check.

Regulators are asking for this too. Singapore's industry framework for agentic finance, published by MAS, says: "An agent cannot extend the scope of a mandate through its own reasoning or inference." The FSB calls it "least agency".

How this works in practice

Pakt enforces client mandates this way today, for any MCP-compatible agent:

1. The client approves a set of rules (markets, trade size, leverage, concentration, price protection, an equity floor) with a signer only they hold. New accounts start from a conservative default: a small per-trade cap, no leverage, and no moving collateral out.
2. The agent proposes an action. It never holds a key that can sign on its own.
3. Inside secure hardware (a TEE), the action is checked against the rules and the account's projected state.
4. If every rule passes, it's signed, with a zero-knowledge proof that it satisfied the client's exact rules. Proofs take under two seconds and can cover up to 10 orders.
5. If any rule fails, no signature exists. The action never reaches the venue.

Funds never leave the client's account, and nothing about the custodian's existing model changes. The policy layer sits at the point of signing, next to the keys.

What a build looks like

Every custodian's stack is different, so each Pakt deployment is built to the use case. A typical engagement covers:

• Rule design: one policy covering the actions your clients' agents need, from trading rules (markets, leverage, concentration) to lending (collateral health) and payment rules (payees, budgets, time windows).
• Defaults: the starting mandate your clients get before they customize anything.
• Integration at signing: where the check sits relative to your existing MPC, HSM or policy engine, so it adds to what you have rather than replacing it.
• Receipts and reporting: what your clients, auditors and supervisors need to see, and in what form.

Sources

• Bank of England: Breeden, "Agents of change"
• MAS: Safeguards for Agentic Finance at Runtime
• FSB: Sound Practices for Responsible Adoption of AI
• ForkLog on HAPI's 3Commas analysis