Intent-Bound Authorization

Most security failures with agents are not break-ins. They are permissions that were handed out too broadly and then used for something no one intended. An agent is asked to book one flight and is given, in effect, the keys to the whole travel account. Nothing is hacked; the agent simply does more than the task required, because the permission it held said nothing about the task at all. Intent-bound authorization is the discipline of closing that gap — tying each grant of power to the specific intent behind it, so that the permission and the purpose can never drift apart.

The permission you never meant to give

Authorization is the act of deciding what a request is allowed to do. For decades it worked on a simple model: prove who you are, and the system looks up what your identity is permitted to touch. That works when a person is behind every request, choosing each action deliberately. An agent breaks the assumption. It receives a broad, standing permission once, then makes many decisions on its own — and the permission has no idea which of those decisions the person actually wanted.

This is the classic confused deputy problem: a program holding real authority is tricked, or simply drifts, into using that authority for the wrong purpose. The token in the agent's hand says act as this user. It does not say book exactly one economy flight under two hundred dollars. So when a poisoned instruction or a buggy plan tells the agent to do something larger, the permission does not object — because the intended action and the unintended action look identical to it.

Identity is necessary, but not the answer

It is tempting to fix this by strengthening identity — proving more rigorously that the agent is who it claims to be. That matters, but it solves a different problem. Authentication answers who is asking. Authorization answers what this particular ask is allowed to do. A perfectly authenticated agent with an over-broad grant is still dangerous, because the danger was never about impersonation. It was about scope.

The shift intent-bound authorization asks for is small to state and hard to do: stop granting power to an identity in general, and start granting it to a request in particular. The unit of permission becomes not the agent, but the task the agent was asked to perform. Everything else in this article is about how to express that task precisely enough that a resource can check it.

What an intent actually binds

An intent-bound grant is a permission that carries the shape of the task inside it. Instead of a blank cheque, it is a narrow instruction that a resource can read and enforce. The useful mental model is a short list of dimensions that together pin down one action and forbid everything adjacent to it.

At minimum, a bound grant names the actor — which specific agent may use it; the action — a single verb, not a category; the resource — the exact target, not a whole namespace; the constraints — the amounts, parameters, or filters that bound the action's blast radius; and an expiry — a short window after which the grant is worthless. Miss any one of these and the grant quietly widens back toward ambient authority.

Binding intent at request time

Intent has to be captured at the moment authority is requested, not reconstructed afterward. The pattern echoes a maturing idea in the OAuth 2.0 world — Open Authorization, the widely used standard for delegated access — called Rich Authorization Requests, or R A R, where the client states the detailed action it wants rather than asking for a coarse scope. The agent presents both its identity and the concrete task; the authorization server evaluates that task against policy and issues a grant scoped to it and nothing more.

The resource then does the other half of the job. When the agent acts, the resource does not just accept a valid-looking token — it verifies that the action in front of it falls inside the grant's declared intent. A request to transfer five hundred dollars fails against a grant that authorized a two-hundred-dollar purchase, even though the same agent, the same identity, and the same account are involved. The task, not the identity, is what gets checked.

The life of a bound grant

Because a bound grant is tied to a task, it has a natural lifetime that a standing permission never had. It is created for one intent, ideally consumed once, and then it should be gone — either used, timed out, or pulled back. Treating the grant as a short-lived object rather than a durable capability is what keeps the window of exposure small.

Thinking in states makes the design decisions explicit. A grant is requested, then bound to a validated intent, then exercised when the agent acts. From there it must reach an end: it expires when its window closes, or it is revoked early if the system detects that the situation has changed. Every arrow that does not lead to expiry or revocation is a way for authority to linger longer than the task that justified it.

Make the grant hard to steal

Narrowing a grant only helps if the grant cannot simply be lifted and replayed by someone else. A bearer token — one that anyone holding it can use — undermines the whole idea, because a scoped-but-stealable permission is still a permission in the wrong hands. The countermeasure is proof-of-possession, also called sender-constrained tokens: the grant is cryptographically tied to a key the legitimate agent holds, so presenting the token without proving control of that key is useless.

This closes the loop between intent and identity. The grant says what may be done and, implicitly, who may do it, and the resource can insist on both. An attacker who exfiltrates the token still cannot exercise it, and even if they could, its intent and expiry would sharply limit what that stolen moment is worth.

What this changes for builders and leaders

For engineers, intent-bound authorization reframes the design question from what can this agent access to what is this agent trying to do right now, and does the grant say so. It pushes teams toward short-lived, single-purpose grants requested per task, resources that verify the action against declared intent, and sender-constrained tokens by default. These are concrete choices, not aspirations, and they compose with the identity and delegation work covered elsewhere in this series.

For leaders, the value is expressed in blast radius. When a grant carries its own intent, a compromised agent, a poisoned instruction, or a flawed plan can only ever do the small, specific thing it was authorized to do — and every action leaves a record of the intent it was checked against. That is the difference between an incident that is one bad transaction and an incident that is an emptied account.

• Request authority per task, not per session — one grant, one intent.
• Verify the action against the declared intent at the resource, not just the token's validity.
• Keep grants short-lived; prefer expiry and single use over long-lived scopes.
• Bind grants to a key the agent must prove it holds, so a stolen token is inert.

Where intent-binding still fails

Intent-bound authorization is powerful, but it is not self-executing. It fails quietly when the intent is captured too coarsely — a task described as manage the account is barely narrower than ambient authority. It fails when resources accept a valid token without re-checking the action against its intent, turning the binding into decoration. And it fails when grants are minted so freely, or live so long, that a single leaked one covers a wide surface anyway.

The connection to real agent risk is direct. Prompt injection, over-eager planning, and tool misuse all express themselves as an agent trying to do something outside the task it was given. Intent-bound authorization is the layer that makes that attempt fail at the moment of action — but only if the intent is specific, the check is real, and the grant is short. Treat those three as non-negotiable, and most over-reach incidents become impossible rather than merely detectable.

Glossary

Authorization

Deciding what a particular request is permitted to do, as distinct from proving who is asking.

Authentication

Establishing who or what is making a request, without deciding what they may do.

Confused deputy

A program that holds real authority and is tricked or drifts into using it for a purpose no one intended.

Ambient authority

A broad standing permission that applies to any action the holder takes, regardless of the task at hand.

Intent-bound grant

A permission scoped to a specific task, naming the actor, action, resource, constraints, and expiry.

Rich Authorization Requests (RAR)

An OAuth 2.0 extension letting a client ask for a detailed, specific action rather than a coarse scope.

Bearer token

A credential that anyone holding it can use, with no proof that the presenter is the rightful owner.

Proof-of-possession

Binding a grant to a cryptographic key the legitimate holder must prove control of, so a stolen token is unusable.