Imagine sending a new employee to New York for a two-day client trip, handing them the corporate card and saying, “Just put everything on the card.” You're picturing a hotel, some meals, an Uber from the airport, with a price tag of $2,000 tops. They come back having booked a suite at a five-star hotel on Central Park, hired a private chauffeur, and taken the client to a Michelin-starred dinner. Nobody gave the employee a $2,000 budget. They said, “Just put everything on the card,” and technically, that's what the employee did.
As I've detailed before, an agent can be given signing authority without being given unrestricted control over the assets it can reach (“AI agent custody: who controls an agent's assets?”). But securing that authority leaves a separate question: what should the agent actually be allowed to do with it?
Give an agent that same instruction, and the problem is identical. “Plan the trip” is the goal. It says nothing about how much economic authority the agent should have to accomplish it. A policy is the number you forgot to say out loud: $2,000, two days, this trip. A policy engine is what makes sure the agent stays inside those boundaries before a transaction is signed.
Custody determines who can sign. Policy determines what they are allowed to sign.
How policy engines became core infrastructure for crypto custody
This isn't a new problem invented by agents. It's a problem institutional crypto custody had to work through first, and the record of how it got solved is fairly traceable.
Back in 2020, when I was a Director in KPMG's Innovation & Enterprise Solutions practice, I co-authored a research paper, Cracking Crypto Custody, which framed the underlying issue: institutional investors wouldn't risk holding cryptoassets unless those assets could be safeguarded and governed the way traditional assets (cash, stocks, bonds) are. The report's four building blocks for institutional-grade custody, security and resilience, compliance, third-party trust, and value-added services, treat governance and policy controls as running through the whole list rather than sitting off to one side of it.
Fireblocks built its Transaction Authorization Policy, a rule engine that governs every outgoing transaction and decides whether to allow it, block it, or require additional approval, as a core layer of its custody platform. Metaco built a comparable policy-driven custody stack and was acquired by Ripple for $250 million in 2023, addressing what Ripple described as an institutional custody market heading toward a $10 trillion opportunity by 2030. Blockdaemon's current Institutional Vault carries the same idea further still, with policy enforcement cryptographically bound to the signing process itself, not applied afterward as a separate check.
The point is that policy enforcement became a defining component of institutional-grade custody because multiple teams, working independently, confronted the same underlying problem, recognizing that key security alone was never sufficient.
How an AI agent policy engine enforces spending and transaction rules
It helps to separate two things that get talked about as one. A policy is the rule itself, a spending cap, an approved list of destinations, a required sign-off above a certain size. A policy engine is the mechanism that takes a proposed action, checks it against those rules, and decides whether to let it through, block it, or kick it to a human, before anything gets signed. As laid out in “The missing infrastructure for AI agent payments,” permissions define the boundary in advance, while policy enforcement is what actually checks a specific request against that boundary in the moment. A policy engine is the infrastructure that makes that check real rather than aspirational.
Fireblocks' own documentation describes the flow this produces: a transaction is first evaluated against the relevant policies to determine whether it is authorized, and only then is an authorized transaction passed to the designated signer. If additional approval is required, that happens before signing as well. In short, the sequence looks like this: agent proposes action, policy engine evaluates the action, the engine authorizes, rejects, or routes it for additional approval, and only then does signing, and eventually execution, happen. What's worth underlining is how firmly the policy check happens before signing rather than after.
Blockdaemon's implementation shows the same idea enforced further down, at the cryptographic layer itself. Policy evaluation happens across three independent nodes for every operation, and approvals are bound to the specific details of a request so one approval can't be replayed or reinterpreted to authorize something else.
None of that logic is written to care whether the party making the request is a person or a model. That's the useful part, and also the reason it transfers.
Why AI agents raise the stakes for policy enforcement and security
A person requesting a large transfer at 2 a.m. on a Sunday is unusual enough to draw a second look. An agent operating continuously has no such natural rhythm to flag against. It can legitimately transact at any hour, and if something upstream goes wrong, it can generate plausible-looking requests at machine speed. Human activity has natural limits; agent activity doesn't. A policy engine therefore has to evaluate every request on its merits, regardless of when it arrives or how many came before it.
Gartner estimates that by 2028, a quarter of enterprise security breaches will trace back to AI agent abuse, from both external attackers and malicious insiders. The Grok and Bankr incident from May 2026 shows what that looks like in practice. An attacker manipulated Grok into repeating a Morse-code-encoded instruction publicly, and the connected Bankr trading agent treated that output as an authorized command, moving roughly $175,000 in tokens. Threshold signing alone would not have prevented that transaction. It protects signing authority from compromise, but without a separate mechanism evaluating whether the instruction itself deserved to be authorized, the signing nodes can still collectively produce a valid signature for a request that originated from manipulation rather than intent. What was missing is the kind of pre-signing authorization check a policy engine is designed to provide, not a specific guarantee that any one configuration would have caught this particular attack.
AI agent policy engines for payments and crypto are already being built
The institutional pattern is showing early signs of repeating for agents specifically, on a shorter timeline than the years it took custody providers to get there.
Fystack has built an open-source policy engine designed for agents on payment rails, checking every transaction against defined rules before the signing layer runs at all. A request that doesn't match an existing rule doesn't get an automatic pass, it routes back to standard human approval, and even adding a new address to an allowlist has to go through the same approval process as any other policy change.
Coinbase's Spend Permissions is a well-documented example of the same idea already live. A user can grant a spender the ability to move tokens from their smart account within limits defined in advance: a specific token, a maximum amount, and a time window. Once granted, the spender can act inside those bounds without requesting a fresh signature for every transaction, because the constraint is enforced onchain by a smart contract, eliminating the need for human review of each request. Coinbase names agentic payments and algorithmic trading as explicit use cases for the feature, with Spend Permissions specifically scoped to token spending within the limits the account has defined.
Neither is a finished answer, and neither on its own proves the pattern will hold. What they do show is that agent infrastructure has started reproducing the same separation between signing authority and transaction policy that institutional custody spent years arriving at.
Why AI agents need both custody and policy
Custody protects signing authority. Policy governs when that authority can be exercised. Institutional custody worked this out gradually, across more than one platform, more than one team, more than one path to the same governing insight. Agent commerce doesn't have the luxury of that timeline, and the earliest builders in the space already seem to recognize that custody and policy require separate solutions.
A policy engine evaluates whether a proposed action falls within the rules before it's ever signed. Paired with custody that keeps a single compromised device or manipulated instruction from becoming a total loss, that check turns delegated access from a leap of faith into something an owner can actually reason about. The point isn't to strip an agent of the autonomy that makes it useful, but to make that autonomy safe enough to extend in the first place. Giving an agent permission to act should never have to mean giving it permission to do anything; the infrastructure around it should preserve that distinction even when the agent itself gets the instruction wrong.
overview
