| Internet-Draft | Verifiable Agent Protocol (VAP) | June 2026 |
| Samal | Expires 4 December 2026 | [Page] |
This document specifies the Verifiable Agent Protocol (VAP), a thin, tool-agnostic verification layer for protocols in which an autonomous agent (a client driven by a large language model) invokes tools exposed by a server (for example, the Model Context Protocol, MCP). Existing tool-invocation protocols convey WHAT tool is to be run and, with authorization extensions, WHO is calling, but carry no machine-verifiable statement of WHY a call is being made. VAP adds a declared, structured, optionally signed statement of purpose and a stable per-session scope-and-budget commitment, against which a server performs admission control before executing a call. VAP defines four messages -- Scope Commitment, Intent Envelope, Scope Amendment, and Verdict -- carried inside the host protocol's existing metadata channel, requiring no change to that protocol and no change to existing servers. VAP targets erroneous and runaway agent behavior, session cost control, and audit; it is defense-in-depth for, not a replacement for, authentication and authorization.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Tool-invocation protocols for LLM-driven agents, most prominently the Model Context Protocol [MCP], expose a server's capabilities to a client that decides, at runtime, which tools to call. The decision is made by a language model. The request conveys the tool name and arguments; an authorization extension may convey the caller's identity and granted scopes. The request does not convey, in any machine-verifiable form, the caller's PURPOSE: the goal it is pursuing and the reason this particular call serves that goal.¶
Because purpose is absent from the wire, a server cannot determine whether a syntactically valid, authorized call is consistent with what the agent is actually trying to do. A confused, mis-prompted, or compromised agent can therefore issue a sequence of individually valid but collectively incoherent calls -- exhausting budget, causing unintended side effects, and producing logs that record WHAT happened but not WHY.¶
VAP addresses this by making purpose a first-class, declared, and verifiable element of a session, and by giving the server an admission-control procedure that evaluates each call against that declared purpose before execution. VAP is deliberately thin: it reuses the host protocol's transport, identity, and metadata facilities, and it confines itself to tool IDENTITY (the public tool namespace) and universal resource BUDGET. It never encodes a tool's argument semantics; argument-level rules are deployment-local operator policy (Section 9).¶
VAP is defense-in-depth. Declared purpose is attacker-controllable text; VAP raises the cost of, and the auditability of, incoherent behavior, but MUST NOT be relied upon as an authentication or authorization mechanism.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
VAP separates two concerns that are frequently conflated:¶
This boundary keeps VAP universal: it applies identically to a payments tool and to a read-only search tool, and a Verifier never needs to understand any tool's domain.¶
In scope: declared purpose, per-session scope/budget commitment, pre-execution admission control, intent-bound audit.¶
Out of scope: authentication, authorization, tool/server attestation, transport security, and tool argument semantics. VAP composes with, and relies upon, separate mechanisms for these.¶
A VAP session has two tiers:¶
When legitimate re-planning requires widening the committed envelope, the Agent sends a Scope Amendment (Section 7), which the Verifier re-verifies and which re-baselines the commitment. Silent escape of the committed envelope is treated as Drift and denied.¶
All VAP messages are carried inside the host protocol's metadata channel (Section 12) and are therefore transparent to host-protocol parties that do not implement VAP.¶
Sent once per session. Fields:¶
The normative JSON Schema is in [VAP-SCHEMAS].¶
Sent per tool call. Fields:¶
The Agent MUST NOT transmit raw chain-of-thought in the Intent Envelope. A minimal, structured intent claim is REQUIRED; full reasoning, if retained, is referenced by reasoning_digest only.¶
Sent to widen an active commitment during legitimate re-planning. Fields: vap, type ("scope_amendment"), session_id, prev_commitment_digest (REQUIRED, forming a tamper-evident chain), reason (REQUIRED), and at least one of add_scope (tools_allow / tools_deny only) or increase_budget (add_calls, extend_deadline, add_limits). An OPTIONAL new_plan_digest and signature MAY be present; the Verifier SHOULD require amendments to be signed because they alter the trust envelope.¶
The Verifier MUST re-verify an amendment (Section 9, step S2) and MAY accept, downgrade, deny, or require human approval. An amendment is the ONLY legitimate means of widening scope or budget.¶
The Verifier's response to any VAP message. Fields: vap, type ("verdict"), session_id, in_response_to, and:¶
On a Scope Commitment (session start):¶
On an Intent Envelope (per call), in order, failing closed:¶
On a Scope Amendment: re-run S2 against the requested widening; on acceptance, re-baseline and chain the commitment digest.¶
Semantic verification (C5/S2) is the most expensive check and, if applied naively, can cost more than it saves and can be evaded. A Verifier MUST NOT gate C5 solely on proximity to a budget limit.¶
A Verifier SHOULD compute, for every call, a cheap deterministic risk score from signals including: the declared or server-assigned sensitivity/irreversibility class; burn-rate anomaly (consumption outpacing the plan); looping (repeated identical calls); novelty (first use of a tool, or arguments far from prior accepted calls); and proximity to a limit. A Verifier MUST additionally invoke C5 on a configurable random sample of otherwise-passing calls, so that an Agent cannot reliably stay below deterministic thresholds while drifting.¶
A Verifier SHOULD cache semantic verdicts keyed by (plan_digest, tool, argument-shape) to bound repeated cost. Any inference consumed by C5/S2 SHOULD itself be billed to a budget meter (Section 11).¶
A budget is multi-dimensional and unit-agnostic. It comprises the universal meters max_calls and deadline, and an extensible "limits" map from a meter name to its maximum cumulative value.¶
A Verifier treats meter names as OPAQUE. A tool self-declares its per-call contribution to one or more meters by returning a cost map in its result metadata (Section 12). The Verifier sums declared contributions and denies any call that would cause any meter to exceed its ceiling. If a tool declares no contribution, the operator MAY supply default per-tool costs.¶
This design lets a commitment bound an aggregate side effect (for example, total monetary value disbursed across many calls) as an ordinary meter, WITHOUT the Verifier possessing any knowledge of what the meter represents or what the tool does. Well-known meter names include "tokens" and "usd_opcost" (operational cost); all others are deployment-defined.¶
When the host protocol is MCP [MCP], VAP messages are carried in the "_meta" object that MCP permits on requests and results, under the key "vap". Specifically:¶
Because all VAP data rides in _meta, an MCP server that does not implement VAP is unaffected, and a VAP Verifier deployed as a proxy is transparent to it. Other host bindings (e.g. A2A) MAY be defined in companion documents.¶
A Verifier advertises its VAP posture during host-protocol capability negotiation, including whether a Scope Commitment is required, whether messages must be signed, which verification tiers it runs, the conditions under which it invokes semantic verification, and its audit format. An Agent that does not present VAP metadata MAY be rejected, served in a restricted mode, or served with intent treated as advisory, at the operator's discretion.¶
For every decision, a Verifier SHOULD emit an append-only audit record binding session_id, the active commitment digest, principal, intent, call, verdict, verification result, a hash of any result, and a timestamp; and a session-level record of the commitment and every amendment. Records SHOULD be signed. Unlike a conventional access log, a VAP audit answers why a call was made, within what committed envelope, and how it was adjudicated.¶
Declared purpose is attacker-controllable. An adversarial Agent can author a plausible rationale for a harmful call. VAP therefore MUST NOT be used as an authentication or authorization mechanism; it is defense-in-depth that raises the cost and auditability of incoherent behavior and is most effective against confused or mis-prompted (as opposed to actively malicious) Agents.¶
Semantic verification employs an LLM and is subject to prompt injection via the goal, rationale, or tool content it examines. Implementations SHOULD isolate the judge's instruction channel from examined content and SHOULD treat all examined fields as untrusted.¶
The semantic judge can be evaded by an Agent that keeps each call below deterministic risk thresholds; mandatory random sampling (Section 10) mitigates but does not eliminate this.¶
A Verifier that calls an external judge endpoint MUST fail closed by default: on judge error or timeout, the call is treated as not consistent (clarify/deny), never served by default.¶
Signatures (commitments, amendments, verdicts) provide non-repudiation only if key distribution and canonicalization are sound; implementations MUST use JCS [RFC8785] before signing to avoid cross-implementation signature divergence.¶
Intent and rationale fields may contain sensitive information; raw chain-of-thought MUST NOT be transmitted (Section 6). Audit records may contain sensitive data and MUST be access-controlled.¶
This document has no IANA actions. A future revision may request registration of a well-known meter-name registry and a VAP version registry.¶