Helmwart
← Atlas · Mitigations Tier 3 · Research-stage

MITIGATION · m-intent-attestation

Intent attestation tokens — a cryptographic binding from user approval to tool execution

An agent acts on behalf of the user, but nothing in a standard OAuth bearer token records what the user actually approved. If the agent's planning is manipulated, it can invoke tools with parameters the user never sanctioned, while presenting credentials that look valid. Intent attestation fixes this by issuing a short-lived signed token that encodes the exact action and parameter envelope the user authorised, and requiring the resource server to verify that envelope before executing the call.

Last reviewed 2026-05-12 · Status: published · Evidence →

At a glance

MATURITY
Tier 3
Promising in literature or single-vendor implementations; not yet a settled industry pattern. Use with explicit risk acceptance.
PLACES ON
node · edge
Restricted to node kinds: agent
COVERAGE
2 threats
T2 · T6
TRADE-OFFS
LAT
low
COST
low
UX
medium
DEV
high
Latency · cost · UX friction · dev effort.
TL;DR
  • Every tool call the agent makes must carry a short-lived signed token proving the user authorised that specific action with those specific parameters; the resource server rejects any call without a valid attestation before execution.
  • The token is issued via OAuth 2.0 Token Exchange (RFC 8693) with the user's credential as the subject and the agent credential as the actor, so both identities appear in every downstream audit record.
  • For high-impact operations, the resource server issues an RFC 9470 step-up challenge; the agent routes the challenge to the user for fresh re-attestation before the call proceeds.
  • The parameter envelope encoded in the token is verified against the actual call at execution time; a mismatch on action name or any parameter value is a hard rejection with no fallback.

How it behaves

Agent proposes a tool call (action + parameter envelope)
Does the call carry a valid intent attestation token whose action and parameters match the proposed invocation, and whose exp has not elapsed?
Tool executes; attestation ID and parameter hash are logged
Hard reject; no execution; AttestationRequired or AttestationMismatch event is raised
The reject path is fail-closed: the tool does not execute a degraded version or proceed without attestation.
For high-impact operations: resource server issues an RFC 9470 step-up challenge; agent surfaces it to the user for fresh re-attestation before re-presenting the token.

What it is

An agent is, by design, a delegate: it acts on behalf of a user, carrying that user's credentials into downstream tool calls. The standard delegation primitive is an OAuth 2.0 bearer token scoped to a set of permitted operations. The problem is that scope is coarse. A token scoped to files:write permits any file write the agent chooses to make, regardless of which file or with what content the user actually approved. If an attacker manipulates the agent's planning layer through prompt injection or a poisoned tool response, the agent can call a tool with parameters the user never sanctioned, and the resource server will accept the call because the scope checks out.

Intent attestation closes that gap. At the point where the user approves an action, the authorisation server issues a short-lived signed token that encodes not just the permitted operation class but the specific action name and the parameter envelope the user reviewed. The token travels with the agent's tool call to the resource server, which verifies that the action and every parameter in the call match the attested envelope before executing. A planner that has drifted, been injected, or been manipulated will produce a call that fails that match, and the resource server rejects it without execution.

The control composes four IETF standards. RFC 8693 OAuth 2.0 Token Exchange is the delegation primitive: the agent exchanges the user's credential for a new token that carries both the user identity as the subject and the agent identity as the actor, making both visible in downstream calls. RFC 9126 Pushed Authorization Requests (PAR) submits the full intent-bearing parameter envelope to the authorisation server before the user-agent redirect, so it is never exposed in URL query strings or browser history. RFC 9449 DPoP (Demonstrating Proof of Possession) binds the issued token to the agent's ephemeral public key, so a stolen token cannot be replayed by a different process or endpoint. RFC 9470 Step-Up Authentication Challenge lets the resource server demand fresh re-attestation for high-impact calls whose authentication context falls below the policy threshold.

The intent-bound parameter envelope is not yet standardised as a standalone IETF or OpenID Foundation profile. The four underlying primitives are individually mature and production-deployed; the composed agentic application is an active design pattern without a settled specification. This is why Helmwart classifies the control at Tier 3 rather than Tier 2.

Detection signals

  • Attestation rejection rate by rejection type (expired, action mismatch, parameter mismatch). A rise in action or parameter mismatches points to prompt injection or planning manipulation, not clock skew.
  • Step-up challenge rate. A sustained high rate means the agent's authorisation scope is calibrated too narrowly for its normal operation, which is a design problem distinct from an active attack.

Threats it covers

  • T2 Tool Misuse −1 severity step

    WHY IT HELPS Tool Misuse is the execution of tools with parameters or in combinations the operator did not intend to allow. Intent attestation enforces that the parameters in the actual tool call match the parameter envelope the user approved at authorisation time, so a manipulated planner cannot substitute different parameters without triggering a hard rejection at the resource server.

  • T6 Intent Breaking and Goal Manipulation −1 severity step

    WHY IT HELPS Intent Breaking is the manipulation of an agent's planning so it pursues goals that diverge from the user's stated intent. A valid bearer token with the right scope does not prevent this because scope is coarse and does not encode what the user approved. Intent attestation binds the token to the specific action and parameter values the user saw and confirmed, so goal drift that produces a different tool call fails attestation verification even when the agent's credentials are otherwise valid.

Principle coverage

Defence-in-Depth stage: Prevent — and it advances:

  • Zero Trust Zero Trust holds that no credential should be trusted beyond what it explicitly proves. Intent attestation extends that to the parameter layer: a valid bearer token proves only that the agent has the right scope, not that the specific action and parameters were user-approved. Intent attestation closes the gap by requiring cryptographic proof of parameter-level authorisation before each tool call executes.
  • Confused-Deputy Prevention The confused-deputy problem arises when a delegate (the agent) is induced to exercise authority the principal (the user) did not grant for that specific request. Intent attestation is the direct technical fix: the agent cannot proceed with a tool call unless it carries a token that records exactly what the user authorised, so a manipulated planner cannot redirect the agent's authority to parameters or actions outside the attested envelope.

Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.

Implementation options

Five patterns covering the full spectrum from standards-composed OAuth pipelines to a self-build signed envelope for agent frameworks that predate OAuth. The OAuth patterns (RAR + PAR + Token Exchange) are the recommended path for any deployment that already has an OAuth 2.0 authorisation server. DPoP adds sender-constraining on top. Step-up handles runtime re-attestation for high-impact calls.

RFC 9396 Rich Authorization Requests Extend an OAuth 2.0 authorisation request with an authorization_details JSON array that encodes the exact action and parameter envelope the user is authorising. The issued access token carries the same authorization_details claim, which the resource server verifies at tool-call time.

Why choose it: Best starting point for any OAuth 2.0 deployment. RAR replaces the coarse-grained scope parameter with a structured, type-safe intent claim. The authorization_details object can encode the exact tool name, parameter names, and value bounds the user approved, making the token a machine-verifiable record of intent. RFC 9396 is finalised (IETF, May 2023) and supported by major authorisation servers (Keycloak, Auth0, Authlete). Pair with PAR (RFC 9126) so the authorization_details object is submitted server-side and never exposed in URL query strings or browser history.

More details:

RFC 9126 Pushed Authorization Requests Submit the full authorisation request, including the intent-bearing authorization_details or request object, directly to the authorisation server via HTTP POST before the user-agent redirect. The server returns a short-lived request_uri; only that URI appears in the redirect URL, keeping the parameter envelope out of browser history and proxy logs.

Why choose it: Best used alongside RAR or a signed request object to prevent parameter tampering in transit. Because the authorisation server authenticates the client and processes the full request before issuing the request_uri, it can validate the parameter envelope and reject it before the user sees a consent screen. RFC 9126 is finalised (IETF, September 2021). The request_uri is one-time-use, so replay is structurally prevented. Add as a mandatory layer alongside RAR for any intent-attestation deployment.

More details:

RFC 8693 OAuth 2.0 Token Exchange Exchange the user's access token for a new delegated token that carries both the subject identity (user) and the actor identity (agent) in the may_act / act claim chain. The resource server can verify that the agent acted on behalf of the specific user and that the scope of delegation did not exceed the user's grant.

Why choose it: Best for multi-step or multi-agent pipelines where the originating user's identity must be traceable through every downstream hop. RFC 8693 is finalised (IETF, January 2020): subject_token is the user credential; actor_token is the agent credential; the issued token binds both. Combine with authorization_details (RFC 9396) in the exchange request to carry the intent claim through the delegation. Without Token Exchange, agents typically hold a bearer token with the user's full scope but no record of what the user intended; the intent-attestation addition closes that gap.

More details:

RFC 9449 DPoP Bind the intent attestation token to the agent's ephemeral public key. Every tool-call request includes a DPoP proof JWT signed by the corresponding private key; the resource server verifies both the token and the proof. A stolen intent token is unusable by any actor that does not hold the private key.

Why choose it: Best as a hardening layer on top of RAR + Token Exchange when the token transit path is untrusted or when the threat model includes insider interception of bearer tokens. DPoP converts the intent token from a bearer token into a sender-constrained token: replay at a different endpoint, by a different process, or after key rotation is blocked by the ath, htm, and htu claims in the DPoP proof. RFC 9449 is finalised (IETF, September 2023). The agent generates a fresh DPoP key pair per session; the authorisation server records the public key thumbprint in the token's cnf claim.

More details:

RFC 9470 Step-Up Authentication Challenge When the resource server determines that the intent attestation token's authentication context is insufficient for the requested operation, it returns a 401 with an insufficient_user_authentication challenge specifying the required acr_values and optional max_age. The agent surfaces this to the user for re-authentication, then presents the upgraded token.

Why choose it: Best as the runtime escalation mechanism for tools that carry irreversible or high-value effects, such as financial transfers, infrastructure mutations, or data deletion. Step-up fires only when the resource server determines the current token's authentication strength falls below the policy threshold for that specific operation, so it does not interrupt every call. RFC 9470 is finalised (IETF, September 2023). The acr_values in the challenge can require step-up to a specific assurance level, such as phishing-resistant MFA, without re-issuing a full authorisation flow.

More details:

Trade-offs

  • PAR + Token Exchange adds one round-trip to the agent's action path, typically 50-100 ms against a local authorisation server and higher against a cloud-hosted one. For most interactive workflows this is imperceptible; for high-frequency automated loops it becomes the dominant latency cost.
  • DPoP requires the agent to generate and protect an ephemeral key pair per session. A process crash that loses the private key before the session ends requires a fresh authorisation flow.
  • Step-up challenges interrupt the agent's execution until the user re-authenticates. A workflow that issues many high-impact calls in sequence will present multiple prompts; calibrate the acr and max_age policy to the session window, not per-call.
  • There is no off-the-shelf agent framework integration for the composed RAR + PAR + Token Exchange + DPoP pattern as of mid-2026. Every deployment assembles and tests the protocol composition itself, which is the dominant dev-effort cost and typically requires several engineer-weeks for a first deployment.

When NOT to use

  • Do not use intent attestation in fully automated pipelines with no human in the loop. The step-up challenge has no one to answer it; the control either blocks the pipeline or degrades to a no-op if the step-up path is bypassed.
  • Do not apply this control to tools with no meaningful parameter surface. A single-verb tool with no arguments cannot express intent in the envelope, so the attestation provides no protection beyond what a normal scope check already gives.
  • Do not use intent attestation as a substitute for least-privilege scoping. Narrow the OAuth scope first (m-tool-scope); apply intent attestation on top for parameter-level binding. Attestation on a broad-scope token still leaves the user exposed if the token is stolen.
  • Avoid this pattern for very-high-frequency tool calls where the PAR + token-exchange round-trip becomes a dominant infrastructure cost. Rate-quota controls are a better fit for volume limiting at that scale.

Limitations

  • Intent attestation defends against drift between user-stated intent and agent-executed action. It does not defend against the case where the user was socially engineered before stating their intent; the attestation faithfully records a manipulated approval.
  • The protection is only as strong as the parameter envelope's expressiveness. An envelope too coarse (for example, action: "write", resource: "*") allows parameter pollution inside the attested surface. An envelope too fine triggers re-attestation for every legitimate variation and causes user fatigue.
  • The composed pattern (RAR + PAR + Token Exchange + DPoP + step-up) is not yet described in a single IETF or OpenID profile. Each deployment must specify its own intent claim schema, so attestation tokens from different deployments are not interoperable.
  • An authorisation server that does not validate the authorization_details schema will accept and re-issue intent tokens with arbitrary, attacker-supplied parameter envelopes. AS-side schema enforcement is a prerequisite and cannot be assumed.

Maturity tier reasoning

  • Tier 3 because the four underlying IETF primitives (RFC 8693, RFC 9126, RFC 9449, RFC 9470) are all finalised and production-ready, but the composed pattern that binds a specific action and parameter envelope to an agent tool call has no finalised IETF or OpenID Foundation profile.
  • No major agent framework (LangChain, LlamaIndex, AutoGen, CrewAI) ships intent attestation out of the box as of mid-2026. Every production deployment is a custom protocol composition.
  • Expect upgrade to Tier 2 once the IETF or OpenID Foundation publishes an intent-attestation profile for agentic AI, or once a major authorisation server ships a purpose-built intent-binding API.

Last verified against upstream docs: 2026-05-30.