EVIDENCE TRAIL
Intent attestation tokens — bind user intent to tool invocation
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The composed pattern — PAR + Token Exchange + DPoP + Step-Up — is a research-stage design that draws on four mature IETF standards; none of those RFCs defines the full intent-binding pattern as a single specification. Helmwart classifies this control at Tier 3 accordingly.
Last cross-checked against upstream sources: · 9 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP Agentic AI — Threats & Mitigations v1.1
§T6 Intent Breaking & Goal Manipulation — Description
"Intent Breaking and Goal Manipulation occurs when attackers exploit the lack of separation between data and instructions in AI agents, using prompt injections, compromised data sources, or malicious tools to alter the agent's planning, reasoning, and self-evaluation. This allows attackers to override intended objectives, manipulate decision-making, and force AI agents to execute unauthorized actions."
Supports: Verbatim statement of the threat this control directly closes. Confirms that goal-drift arises from the inability to separate data from instructions — which intent attestation addresses by cryptographically anchoring each tool invocation to the user's stated parameters before execution.
Does not prove: T6's recommended mitigations (Playbook 1) focus on planning validation and behavioural constraints; the document does not explicitly name intent attestation tokens or OAuth token exchange as the mechanism.
OWASP Agentic AI — Threats & Mitigations v1.1 · Playbook 1
§Playbook 1: Preventing AI Agent Reasoning Manipulation — Step 2 "Prevent AI agent Goal Manipulation (Reactive)"
"Apply behavioral constraints to prevent AI self-reinforcement loops. Ensure AI agents do not self-adjust their objectives beyond predefined operational parameters."
Supports: Establishes predefined operational parameters as the authoritative boundary AI agents must not cross — the same boundary that intent attestation tokens encode and enforce at the tool-call layer.
Does not prove: Frames the constraint as a behavioural / monitoring concern. Does not specify cryptographic binding or token-exchange primitives as the enforcement mechanism.
IETF RFC 8693 — OAuth 2.0 Token Exchange
Abstract
"This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation."
Supports: Defines the canonical protocol primitive for delegating user authority to a downstream actor (the agent) without conferring broader scope than necessary. The actor (act) claim in the issued token explicitly records which party is acting on behalf of whom — the foundational mechanic that intent attestation tokens build on.
Does not prove: Does not define an "intent" claim or a parameter-envelope binding. The intent-bound extension described in Helmwart's control is a composed pattern atop RFC 8693, not a feature of the RFC itself.
IETF RFC 9470 — OAuth 2.0 Step Up Authentication Challenge Protocol
Abstract
"This document introduces a mechanism that resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements."
Supports: Provides the re-attestation trigger that intent attestation tokens use for high-impact calls: a resource server that receives a call without a valid intent attestation can respond with an insufficient_user_authentication challenge, forcing the agent to request fresh user authorisation before proceeding.
Does not prove: RFC 9470 operates at the authentication-assurance level (ACR / max_age) rather than at the level of parameter-envelope binding. The intent-specific dimension of the challenge is a Helmwart extension, not part of the RFC.
IETF RFC 9126 — OAuth 2.0 Pushed Authorization Requests
Abstract
"allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint."
Supports: PAR pre-registers the exact parameter envelope being authorised before any user-agent interaction, providing cryptographic integrity and confidentiality protection for the request. This is the mechanism by which the agent's parameter envelope cannot be swapped or widened between the user's approval and the tool invocation.
Does not prove: RFC 9126 does not define how PAR integrates with downstream tool calls in an agentic pipeline. The composition with token exchange and intent claims is a Helmwart design pattern.
IETF RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP)
§1 Introduction
"The value of the header is a JSON Web Token (JWT) that enables the authorization server to bind issued tokens to the public part of a client's key pair. Recipients of such tokens are then able to verify the binding of the token to the key pair that the client has demonstrated that it holds."
Supports: DPoP ensures the intent attestation token is cryptographically bound to the agent that requested it. A stolen token cannot be replayed by a different actor because it is tied to the private key that only the legitimate agent holds. This closes the token-theft replay vector that would otherwise undermine intent attestation.
Does not prove: DPoP binds the token to a key pair but not to a specific parameter envelope. The parameter-level binding is supplied by the PAR request object, not by DPoP alone.
MITRE ATLAS AML.M0029 — Human In-the-Loop for AI Agent Actions
AML.M0029 mitigation description
"Systems should require the user or another human stakeholder to approve AI agent actions before the agent takes them. Human In-the-Loop policies should follow the degree of consequence of the task at hand."
Supports: Defines the human-approval escalation path that intent attestation tokens operationalise programmatically. Where HITL relies on a human reviewer to approve each action, intent attestation encodes that approval cryptographically so it can travel with the tool call through the agent pipeline.
Does not prove: AML.M0029 requires a human in the loop for every consequential action; intent attestation is a mechanism to reduce that overhead by pre-binding approval, not a replacement for HITL on the highest-risk calls.
MITRE ATLAS AML.M0030 — Restrict AI Agent Tool Invocation on Untrusted Data
AML.M0030 mitigation description
"Untrusted data can contain prompt injections that invoke an AI agent's tools, potentially causing confidentiality, integrity or availability violations. It is recommended that tool invocation be restricted or limited when untrusted data enters the LLM's context."
Supports: Names prompt-injection-driven unauthorised tool invocation as the threat class and advocates restricting tool invocation when untrusted data is present. Intent attestation tokens implement this restriction at the protocol layer: a tool call without a valid attestation signed by the user is structurally equivalent to untrusted data commanding a tool and is rejected.
Does not prove: AML.M0030's recommended control is user-confirmation gating, not cryptographic attestation tokens. The token-exchange mechanism is a Helmwart interpretation of how to make that user confirmation durable and verifiable.
NIST SP 800-207 — Zero Trust Architecture
§2.1 Tenets of Zero Trust — Tenet 3
"Access to individual enterprise resources is granted on a per-session basis. Trust in the requester is evaluated before the access is granted. Access should also be granted with the least privileges needed to complete the task."
Supports: The per-session access tenet establishes that authorisation for one resource does not imply authorisation for any other. Intent attestation tokens are the per-call generalisation of this tenet: each tool invocation requires its own signed attestation, so a compromised or replayed token from a previous call cannot authorise a subsequent one.
Does not prove: NIST SP 800-207 does not discuss agentic AI or intent tokens. The mapping is an architectural generalisation of the ZTA tenet to the per-tool-call granularity, which is Helmwart's interpretation.