Binding an agent to the intent you gave it works for typed transactions and nothing open-ended. The industry is selling that narrow case as if it were the whole problem.
At a glance
Agent identity is essentially solved with existing standards. Authorizing an agent's intent is not, and no token ever will. For open-ended work, contain the blast radius, measure judgment with evaluations, and keep a human on the actions that can't be undone.
Solved: agent identity and delegation — ratified standards and graduated infrastructure, inside your own trust domain.
Works where it fits: typed-intent binding for payments and fixed-shape workflows (RFC 9396).
Open: open-ended intent — a containment, evaluation, and human-supervision problem, not an authorization one.
Picture an agent that does everything right. It has its own identity, distinct from yours. When it acts for you it carries a short-lived token that names both of you and is scoped to exactly the operation it needs. Every call is authenticated, authorized, and logged against the correct principal. A security review passes it without a comment.
Then a support ticket it is reading contains a line an attacker planted, the agent treats that line as your instruction, and it issues a nine-thousand-dollar refund to an account you have never heard of. Every check was green. The refund was in scope. The token was valid.
Here is the part you do not expect. This exact failure is close to solved. The refund has a type, an amount, and a destination account, so you can pin the delegation to the specific transaction and reject anything that does not match, and any competent fraud system would have flagged a nine-thousand-dollar payout to a brand-new account regardless. The industry has an answer for the refund, the answer works, and that is precisely the problem, because your agents mostly do not issue refunds.
They “clean up the staging environment before the demo.” They “handle this customer’s issue.” They “triage the overnight alerts and escalate anything real.” Those are the intents an autonomous agent actually receives, and not one of them has an amount field. That is the boundary this piece is about, and the current wave of agent-authorization products walks right up to it and then sells you the payment.
Intent-based authorization: the answer that works, and why it fools people
There is a real and growing body of engineering around what vendors are calling intent-based or task-based authorization, usually under a slogan like “authorize the task, not the permission.” The core move is legitimate. A scope is a capability: a token scoped to refund:write authorizes every refund in the system and trusts the agent to issue only the right one, which is exactly the trust a prompt injection exploits. So instead of a coarse scope, you bind the grant to the specific transaction. The mechanism has been ratified since 2023, in RFC 9396, Rich Authorization Requests, and it is already in production in open-banking-style flows.
Now the grant does not say “may issue refunds.” It says “may issue a refund, for ticket 4821, up to two hundred dollars, on this one account.” Carry that object down the internal call chain in a transaction token, an emerging IETF draft, so no downstream service can widen it. Check every attempted action against it before the action executes, and the injected nine-thousand-dollar refund fails, because it was never in the grant. This is good work. If your agents transact, do it.
One condition makes or breaks it. The grant’s constraint values (the amount, the account, the ticket number) have to come from a trusted source, the original order or a human, and never be assembled by the agent out of the same untrusted ticket it is reading. Bind the grant to attacker-supplied values and you have bound nothing.
Now notice the shape of every example anyone gives you for this pattern. It is a payment. A transfer. A refund. A trade. It is always a typed transaction, because a typed transaction is the only kind of intent that fits inside a JSON object with fields. The demos are all payments because payments are the only place the technique fully works. The framing quietly assumes that an intent is a structured record you can write down in advance, and for the narrow world of financial transactions, and for structured, fixed-shape workflows like onboarding or provisioning that decompose into enumerable typed actions, that assumption holds. For the genuinely open-ended work you also hand agents, it collapses.
Open intent: when there are no fields to authorize
“Clean up the staging environment before the demo” does not reduce to a typed object. There is no amount, no counterparty, no enumerable type. You cannot write the authorization_details that would have bounded it, because the legitimate actions it authorizes are open-ended and only knowable in context: drop these test users, yes; truncate that log table, yes; drop the database holding the load-test fixtures the demo depends on, no, even though “drop a database” is exactly the kind of thing cleaning up staging involves.
And notice which failure actually hurts. It is not the loud one. A nine-thousand-dollar refund to a new account trips every anomaly control you already own. The dangerous action is the quiet, in-distribution one: dropping a database while cleaning up databases, sending an email while handling correspondence, closing a ticket while triaging tickets. It looks normal by every metric the system tracks, it sits comfortably inside any scope broad enough to let the agent do its job, and it was still not the thing you delegated. No token expresses the difference between “drop the staging junk” and “drop the one database that matters,” because that difference lives in whether the action serves the purpose, and purpose is not a field.
This is why intent is not an authorization problem. Authorization asks whether an action is in an allowed set, and it answers deterministically, which is its whole value. Deciding whether an open-ended action serves an open-ended intent is not a set-membership question. It is a question of comprehension, the same comprehension a prompt injection hijacks in the first place. Dressing it in OAuth vocabulary does not change what kind of problem it is. It just gives you a token that feels like a control and is not one.
Containment over authorization: how CaMeL and taint tracking attack it
So, the honest state of the art stops trying to solve intent and changes the question. Authorization asks whether an action is allowed, which means knowing in advance which actions are the right ones, and that is the intent you cannot codify. Containment asks nothing about intent. It assumes the model will be fooled, and it limits what any action can reach, so that a fooled agent still cannot touch anything that matters. The switch from permitting the right action to bounding the blast radius of the wrong one is the whole move, and it is what the most serious work in the field actually does.
The most serious attempt is CaMeL, short for capabilities for machine learning, from the 2025 paper “Defeating Prompt Injections by Design,” by researchers at Google DeepMind and ETH Zurich. The core idea is one a security engineer will recognize on sight: never let untrusted text act as instructions, and track where every value came from so tainted data cannot reach a dangerous operation. It is taint tracking, the classic data-flow discipline, pointed at an agent.
The setup has three parts. A privileged model sees your request but never the untrusted content, and its only job is to turn the request into a small program. A quarantined model is the one component allowed to read untrusted content, and it can return data but never take an action. A custom interpreter runs the program and tags every value with metadata recording where it came from and who is allowed to see it, and those tags are the capabilities the name refers to.
Make it concrete. You tell an agent to “send Bob the notes from our last meeting.” The privileged model, working only from that trusted request, writes a short program: fetch the notes, find Bob’s address, send the notes there. To get the address, the program hands the raw notes to the quarantined model, which extracts one and returns it tagged as untrusted. A policy can now fire before anything is sent: an address that came from untrusted content is not allowed to be a recipient unless it matches your contacts or you approve it. If the notes were poisoned to say Bob’s address is attacker@evil.com, the send is blocked, because the interpreter knows that value is tainted and the policy forbids it. The model was fooled. The action never happened, because the fooling was never allowed to reach it.
Sit with what CaMeL does and does not do, because it is the most instructive thing in this whole discussion. It does not understand your intent. It contains the blast radius of misunderstanding it. And its own authors are clear about the cost: someone still has to codify and maintain the security policies, and an agent that constantly asks the human to approve edge cases trains the human to click yes. Even the best work in the field reframes the problem from “understand the intent” to “constrain the consequences,” because the first problem is not solved and the second one is at least tractable.
Be precise about the scope of that guarantee. CaMeL guards the injection route, where untrusted data hijacks the agent. It does nothing for the other half of the problem, an agent that misjudges an open intent from a perfectly trusted request, with no poisoned input anywhere. That case is not what CaMeL’s taint tracking addresses, because there is no untrusted provenance to key on, and yet generic containment still bounds it: a backup, an irreversibility gate, a human on the actions that cannot be undone. What none of that closes is the comprehension gap underneath. Notice too what CaMeL is: authorization relocated to an action’s consequences rather than removed. Intent never becomes a token you check at the instant of action; it becomes a set of constraints on what any action is allowed to touch.
Two things follow, and both cut against what a token vendor will tell you. You cannot hand the judgment back to the agent’s own model, because that is the model the injection already owns. And you cannot escape by putting a second, smarter judge model in front of it. To decide whether an action serves an open-ended intent, a judge has to understand the situation, and the situation lives in the untrusted data, so a judge that can actually make the call has to read the very content that would inject it.
There is a tempting third door: have a walled-off model read the untrusted content and hand back only structured fields, then check those fields deterministically, which is exactly what CaMeL’s quarantined reader does. It works, but only for the part of an intent that reduces to fields, and reducing an intent to fields is just re-typing it. You recover the typed slice and nothing of the irreducibly open part. A check smart enough to judge the open part has to take in the situation the agent is reacting to, and taking in that situation is what makes it injectable. That is why the serious work constrains the data flow instead of trying to judge the intent.
Typed intent vs open intent: the line worth drawing
There is a clean distinction here, as long as you draw it in the right place. The line runs between typed intent and open intent, not between authorization and judgment.
For a typed intent, a payment, a refund, a provisioning request with a known shape, intent-fit is a crisp boundary you can enforce inline and deterministically, and RFC 9396 is the right tool. Use it. For an open intent, “does this action serve the purpose” is a judgment call by construction, which is exactly why it is the frontier: you cannot enforce inline what you cannot yet decide deterministically. The sharpest vendors already say the right-sounding thing, authorize the task and not the stated intent, because they know untrusted text can rewrite a declared intent. But a task you can authorize is a task you could type, and the intents that matter here cannot be typed. Treating the open case as the typed case with more fields is the category error, and even the “authorize the task” camp makes it by assuming there is always a task to bind.
The quality of an agent’s judgment inside its bounds is a third thing again, and it does not belong in any gate. That is what evaluation suites are for before you ship and what trajectory observability is for in production, with a human reserved for the actions where a wrong call cannot be undone. For an interactive agent, a gate on every action buys safety with latency you cannot afford, though a batch or overnight agent can happily pay it. Containment bounds the damage, evals and monitoring watch the judgment, and neither one is a token.
Agent identity and delegation: do the plumbing anyway
None of this is a reason to skip the identity work, and the identity work is worth doing on its own merits. It is also, unlike intent, mostly solved.
Give the agent its own identity, because you cannot revoke what you never named. SPIFFE and SPIRE, both graduated in the CNCF, issue every workload a verifiable name and a short-lived credential that rotates automatically, an hour or less by default, with no static secret to leak. At the enterprise layer, Microsoft Entra Agent ID reached general availability in April 2026 and Auth0 for AI Agents in November 2025, though the agent-specific pieces of each are young and some are still in preview.
Then delegate instead of impersonating. The default path today is impersonation: the agent runs on a user’s token or personal access token and simply is that user to every system it touches, which is account takeover with a friendlier name. Instead, exchange the token. OAuth 2.0 Token Exchange, RFC 8693, lets the agent trade the user’s token and its own for a new one whose subject is still the user but which names the agent as the actor.
When an agent hands work to a sub-agent, re-delegate rather than sharing the token, and the act claim nests to record the chain instead of flattening it into one borrowed identity.
You do not build this into every backend. Put it in a gateway or sidecar and let the services stay dumb, the same pattern a service mesh already uses for workload identity. Solo’s agentgateway, a Linux Foundation project, does RFC 8693 exchange at the gateway today, and Ping, Kong, and Google ship agent gateways of their own. Two honest limits. The gateway becomes a component that can mint any delegated token for any user, so it is a crown jewel in the hot path and has to be treated like one. And it reaches only as far as your own trust domain: a third-party SaaS will not accept your issuer, so at that boundary you fall back to storing and replaying the user’s own OAuth token, which is impersonation with better key management. For most agents, which live and die at the SaaS edge, the identity problem is not fully solved either.
Do all of it anyway. It limits blast radius, it gives you an audit trail that names the real actor, and it is overdue in most shops. Just do not let anyone tell you it solved intent. It settles who is acting. Whether the act was the one you meant is a question this layer never asks.
Where that leaves your agent security program
Sort your agent program by what is actually solved. Identity and delegation are ratified standards and graduated infrastructure, borrowed with small changes from the way services have authenticated for a decade; the work is real but the invention is done, at least inside your own trust domain, since cross-domain identity at the SaaS edge is still an open front. Typed-intent binding is a shipped standard that works for the transactions that fit it. Open-ended intent is different in kind, and no standard is going to close it, because it is a containment-and-comprehension problem whose best available answer bounds the damage rather than understanding the goal.
So put in the plumbing, use RFC 9396 wherever your agent’s job really is a typed transaction, and for everything else treat intent as what it is: a containment problem to engineer around, an evaluation problem to measure, and a human-judgment problem to supervise, not a claim to mint. And the next time a vendor tells you their product makes an agent act only on your intent, ask them to show it working on “clean up the staging environment,” an intent with no fields to write down. The typed transaction was never the hard part.
Questions to ask an agent-authorization vendor
Show it working on “clean up the staging environment” — an intent with no amount, type, or counterparty to bind.
Where do the grant's constraint values come from? If the agent assembles them from the same untrusted input it's reading, the binding is worthless.
What happens on a quiet, in-distribution wrong action — dropping the one database that matters while cleaning up databases — not just the loud anomaly?
Is this containment that bounds the blast radius, or a token that only feels like a control?
How does it handle the cross-domain SaaS edge, where your issuer isn't accepted and you fall back to replaying the user's own token?
This is the kind of call we help enterprise teams get right: separating what's genuinely solved from what only looks solved, then designing the containment, evaluation, and delegation around it. If your teams are moving agents into production and want a clear-eyed read on where the real risk sits, that's the enterprise AI and AI consulting work we do.
Standards and sources referenced
RFC 9396, Rich Authorization Requests — typed-intent binding.
RFC 8693, OAuth 2.0 Token Exchange — delegation with the actor (act) claim.
“Defeating Prompt Injections by Design” (CaMeL), 2025 — Google DeepMind and ETH Zurich.
SPIFFE and SPIRE — workload identity and short-lived credentials (CNCF).
Microsoft Entra Agent ID and Auth0 for AI Agents — enterprise agent identity.
.svg){kind=small}
Article