Security Principal and Verifier Binding for Agent Communication Protocols

Introduction Agent protocols are being proposed for long-lived communication among agents, tools, gateways, services, and human or organizational principals. These protocols need to express several different kinds of security meaning:

who authorized the task;
which live agent or runtime instance is acting;
which tool, gateway, or external resource is being invoked;
what authority has been delegated, by whom, and under what scope;
what is bound to the current session or channel; and
what evidence can later be verified about an action.

These are not the same claim. A valid organizational identifier does not by itself prove a live agent instance. A session identifier does not by itself prove delegated authority. A transparency receipt does not by itself prove that the action was authorized. A tool invocation record does not by itself prove that the tool was within delegated scope. The purpose of this document is to make these boundaries reviewable. It does not define a new agent protocol, token format, audit log, transparency service, or authorization system. Instead, it defines a claim-to-verifier discipline that other drafts can map to.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document is currently intended as Informational guidance. Requirement language is used to make security expectations reviewable by protocol authors; it does not by itself define a wire protocol.

Terminology

Agent: An automated software component that initiates, receives, mediates, or performs actions on behalf of a human, organization, account, workload, or policy authority.
Security principal: An entity whose authority, identity, state, or responsibility is relevant to a security decision.
Claim: A security-relevant statement that a protocol participant, credential, token, receipt, attestation, record, or external system asserts or carries.
Carrier: The protocol field, credential, record, header, receipt, attestation, envelope, or external reference that carries a claim.
Verifier: The party that evaluates a claim for a particular security decision.
Binding: The relationship between a claim and the specific state to which it applies, such as a session transcript, task digest, delegation chain, subject identifier, tool invocation, or evidence record.
Freshness: The replay, expiration, revocation, sequence, rotation, challenge, nonce, or recency rule used to determine whether a claim can still be relied upon.
Failure behavior: The required behavior when a claim is missing, stale, inconsistent, not verifiable, or out of scope for the decision being made.
Layer label: A descriptive label for where a verifier decision is made or where a claim is carried. The label can use ordinary protocol-layer terminology, such as application, transport, or network, or an agent-native architectural taxonomy, but the vocabulary needs to be defined by the draft that uses it.
Evidence reference: A stable reference to a public test vector, example, test case, implementation note, interop record, issue, pull request, or other reviewable artifact that supports a mapping row.

Problem Statement Agent communication drafts can become difficult to review when a single architectural label is used to imply several security properties. Common examples include:

treating an account, organization, or credential identifier as evidence that a particular live agent instance is acting;
treating session continuity as evidence of delegated authority;
treating tool invocation evidence as evidence that the tool invocation was authorized;
treating an audit record or transparency receipt as proof of correctness, completeness, or authorization;
treating a governance or reputation mechanism as a current protocol guarantee when the current draft does not specify the verifier, evidence, or failure path; and
treating inherited mechanisms from other drafts as if they were fully specified by the draft under review.

These ambiguities are not merely editorial. They affect interoperability and security review. Two implementations can agree on a field name while making different decisions about who verifies the field, what state the field is bound to, and what happens when the field cannot be validated. This document addresses that problem by requiring each security-relevant claim to be mapped to a carrier, verifier, verification rule, binding, freshness rule, layer, and failure behavior.

Goals

Separate security principals and security claims that are often conflated in agent communication protocols.
Define a reusable verifier matrix for agent protocol drafts.
Make delegation, session binding, freshness, replay, revocation, and failure behavior mechanically reviewable.
Support comparison among candidate protocols without requiring them to share the same wire format.
Provide candidate security-considerations text for agent communication work.
Make explicit which mechanisms are specified by the current draft, inherited from another document, planned for future work, or only architectural assumptions.

Non-Goals This document does not:

define a new agent transport protocol;
define a credential format;
define a delegation-token format;
define an audit-record format;
define a transparency-receipt format;
require any specific public key, certificate, Verifiable Credential, SCITT, WIMSE, OAuth, GNAP, RATS, or vLEI mechanism;
decide whether any existing draft satisfies the matrix; or
select a single protocol as the architectural solution for all claims.

Security Principal Model The following principals commonly appear in agent communication designs.

Human or organizational authority: The person, organization, role, legal entity, account, or policy authority on whose behalf the agent acts.
Agent instance: The concrete live agent, runtime, workload, or execution environment that participates in the protocol exchange.
Agent provider or runtime provider: The party that supplies, hosts, or controls an agent implementation or runtime environment.
Tool or external resource: A tool, API, service, file, database, payment endpoint, browser, physical device, or other resource invoked by an agent.
Gateway, broker, or mediator: An intermediary that translates, routes, composes, gates, or mediates agent interactions.
Delegator: The party that grants authority to another party or agent.
Delegatee: The party or agent that receives attenuated authority.
Verifier or relying party: The party that decides whether a claim is sufficient for a specific protocol action.
Evidence consumer: A party that later reviews, audits, composes, or relies on evidence of an action.

A protocol can use one credential, key, session, or record to carry more than one claim, but the draft needs to identify each claim separately. Reusing a carrier does not make the claims equivalent. Workload identity documents, such as the WIMSE architecture and workload identity practices , are useful examples of why an instance, workload, or execution environment claim should be separated from human or organizational authority and from delegated task scope.

Claim Classes and Initial Claim Registry A draft SHOULD identify which of the following claim classes it carries or depends on. The identifiers below are provisional and are intended to make early review concrete. Initial Claim Registry

ID	Claim Class	Review Question
C-001	Instance identity	Which live agent, runtime, workload, endpoint, or process is acting now?
C-002	Human or organizational authority	Who authorized the task, policy, role, or delegation?
C-003	Delegated scope	What authority has been delegated, by whom, to whom, under what scope and attenuation?
C-004	Session continuity	What state is bound to the current channel, connection, long-lived session, or task?
C-005	Action evidence	What action was requested, attempted, completed, blocked, or failed?
C-006	Tool or resource identity	Which external resource is being invoked or affected?
C-007	Evidence provenance	What evidence, signature, receipt, attestation, log entry, or record supports an action or decision?
C-008	Freshness or revocation	Is the authority, delegation, instance state, tool binding, or session state still current?
C-009	Failure handling	What happens when the verifier cannot validate the claim for the requested action?
C-010	Composition boundary	Which claims are preserved, transformed, or lost when agents, gateways, receipts, or tools are composed?

The registry is intentionally claim-oriented rather than protocol-oriented. More than one candidate protocol can map to the same claim, and a protocol can map to only a subset of the registry.

Verifier Matrix For each security-relevant claim, a protocol draft SHOULD provide a row with the following fields.

Claim ID: The registry identifier for the claim being mapped.
Claim: The precise security statement being made.
Carrier: The protocol field, token, credential, record, header, receipt, attestation, or out-of-band reference that carries the claim.
Verifier: The party that validates the claim.
Verification rule: The check performed by the verifier.
Layer: The protocol layer or architectural review dimension associated with the row. This field is descriptive. It does not impose a fixed layer taxonomy on every protocol, and it does not require a protocol to spread claims across different layers.
Binding: The other state to which the claim is bound, such as a session identifier, TLS exporter, action digest, delegation chain, subject identifier, or tool invocation.
Freshness: The replay, expiration, revocation, rotation, sequence, or recency rule.
Failure behavior: The required behavior when the claim is missing, stale, inconsistent, or not verifiable.
Implementation status: Whether the row is implemented, not implemented, partially implemented, or externally implemented.
Specification status: Whether the row is specified in the current draft, planned for a later revision, inherited from another document, or an architectural assumption.
External dependency: The external draft, standard, service, governance process, transparency log, authorization system, attestation system, registry, or operational practice on which the row depends.
Evidence reference: An optional reference to a public test vector, example, test case, implementation artifact, interop note, issue, pull request, or other stable evidence that makes the row checkable.

Matrix Review Rules The matrix is intended to make review strict enough that a draft cannot obtain a security property merely by naming an adjacent mechanism. The following rules apply to a verifier matrix.

A carrier does not imply a claim unless the claim is explicitly stated.
A claim does not imply a verifier unless the verifier is identified for the decision being made.
A verifier decision is not complete unless the binding and freshness rule are stated.
An inherited mechanism is not a current protocol guarantee unless the dependency and failure behavior are stated.
A receipt, log entry, or audit record proves only the statement it records; it does not automatically prove authorization, completeness, or correct execution.
A row that is marked as planned, inherited, partial, or assumption MUST NOT be used as evidence that the current draft fully specifies the corresponding security property.
A layer label is not itself a security property. It helps reviewers locate where a claim is carried or verified, but the security property still depends on the carrier, verifier, binding, freshness rule, and failure behavior.
An evidence reference is not required for every early row, but when one is present it needs to support the specific verifier decision described by the row.

Layer Vocabulary The Layer field needs to be explicit because candidate agent communication drafts do not all use the same architectural model. A draft MAY use conventional protocol-layer language, such as application, transport, and network, when that is the clearest description of where the relevant carrier or verifier behavior sits. A draft MAY instead use an agent-native architectural taxonomy, such as substrate, composition, application, governance, or audit. If it does so, the draft needs to define that taxonomy and explain how the labels are used. For example, a "governance" label might be useful for review when a claim depends on a policy, registry, reputation process, slashing process, or administrative authority; however, that label is not a protocol layer unless the draft defines it as one. The Layer field is open-ended per row. A protocol can place all of its relevant carriers or verifier behavior at the transport layer if that is how the protocol is designed. Conversely, a protocol can use an architectural label when the verifier decision depends on composition, audit, or governance behavior outside the transport exchange. The matrix does not require either vocabulary; it requires the chosen vocabulary to be explicit.

Two-Level Matrix Model The matrix can be maintained as two linked tables. The first table is a claim registry for AGENTPROTO review. It assigns stable identifiers to security claims or requirements, without selecting one protocol as the general solution for every row. Each row can name one or more candidate protocols that map to that claim. Example Claim Registry Rows

ID	Claim or Requirement	Candidate Protocol Mapping
C-001	Agent or workload instance identity	AGTP, IACP, WIMSE profile, or another candidate
C-002	Human or organizational authority	vLEI, OAuth, GNAP, authorization receipt, or another candidate
C-003	Delegated scope	Delegation chain, delegation receipt, or capability profile
C-004	Session continuity	Protocol session state, transport binding, or migration profile
C-005	Action evidence	Audit receipt, capsule, transparency statement, or evidence graph

The second table is a protocol mapping table. Each candidate draft provides one table for the claims it carries or depends on. This prevents a protocol from being treated as a complete architecture merely because it covers one claim well, and it lets the working group compare drafts row by row. A protocol mapping row records the claim ID, claim text, carrier, verifier, verification rule, binding, freshness rule, layer label, failure behavior, implementation status, specification status, and any external dependency. For example, an instance-identity row might state that the carrier is a protocol field, the verifier is the peer, the binding is the handshake transcript, freshness is supplied by a nonce or epoch, and the failure behavior is connection rejection. The claim registry is not a conformance target by itself. The protocol mapping table is the review surface: it states what the draft actually specifies, what is implemented, what is inherited from another component, what remains an architectural assumption, and what evidence or test vector can be used to check the row.

Status Value Semantics The implementation and specification status fields are security relevant. They prevent an author, implementer, or reviewer from treating an intended mechanism as a current protocol guarantee.

specified: The current draft contains enough protocol text for an independent implementer to identify the carrier, verifier, binding, freshness rule, and failure behavior.
implemented: At least one implementation performs the verification behavior described by the row. The row SHOULD identify whether that evidence is source-level, unit-level, local-harness, interop, or deployment evidence. If a public test vector or reproducible artifact exists, the row SHOULD include an evidence reference.
partial: The draft or implementation covers part of the row, but at least one of the carrier, verifier, binding, freshness rule, or failure behavior is incomplete.
inherited: The row depends on another specification or system. The dependency needs to be identified, and the draft needs to state what happens if the dependency is absent or not trusted. An inherited row is not complete if it merely names another document; it also needs to identify the inherited verifier, binding, freshness rule, and failure behavior or state that they are outside the current draft's scope.
planned: The row is intended for a later revision and MUST NOT be treated as a current security guarantee.
assumption: The row depends on architecture, deployment, governance, or operational behavior that the draft does not specify.

Protocol Mapping Template Candidate protocol drafts can use the following compact template in a Security Considerations section, appendix, or companion document. Protocol Mapping Template Fields

Field	Description
ID	The claim identifier from the registry.
Claim	The precise statement being asserted or depended upon.
Carrier	The protocol field, credential, token, receipt, attestation, envelope, or external reference that carries the claim.
Verifier and verification rule	The party that performs the check and the rule it applies.
Binding and freshness	The state to which the claim is bound and the replay, revocation, expiration, sequence, nonce, or recency rule.
Layer	The protocol layer or architectural review dimension used by the draft for this row.
Failure behavior	The behavior when the claim is absent, stale, inconsistent, or not verifiable.
Implementation status	One of implemented, partial, none, or externally implemented.
Specification status	One of specified, planned, inherited, or assumption.
Dependency	The external document, system, service, registry, or operational process on which the row depends, if any.
Evidence reference	A stable public pointer to the test vector, example, test case, implementation artifact, interop record, issue, or pull request that supports the row, if available.

When a draft does not carry a claim, the corresponding row MAY be omitted. If the draft relies on the claim for a security decision, the row SHOULD NOT be omitted; it should instead state the dependency or assumption explicitly.

Evidence and Test Vector References A verifier matrix becomes more useful when its rows are checkable rather than only asserted. A row therefore MAY include an evidence reference. The reference can point to a public test vector, example, conformance test, implementation test, interop note, issue, pull request, or other stable artifact. An evidence reference does not need to prove that a protocol is complete. It needs to support the specific row. For example, a test vector for session replay resistance supports a freshness or binding row; it does not by itself prove delegated authority. A receipt verification example supports an evidence-carrier row; it does not by itself prove that the recorded action was authorized. When evidence is implementation-related, the row SHOULD distinguish the evidence type. Useful categories include source-level evidence, unit-level evidence, local-harness evidence, cross-implementation interop evidence, and deployment evidence. This distinction prevents a draft from treating a local unit test, public interop vector, and deployment signal as equivalent. A useful evidence reference is row-specific. It identifies the input object, the canonicalization or serialization rule when bytes are compared, the verifier decision being tested, the expected positive result, and at least one negative case that fails for the same row. If the evidence depends on a private deployment or non-public implementation, the row should say so instead of treating the evidence as publicly reproducible.

Inheritance Targets and Artifact-Layer Mechanisms Some mechanisms used by agent communication protocols are not communication protocols themselves. For example, an authorization receipt, transparency statement, action-evidence graph, revocation statement, or attestation result can be an artifact-layer mechanism that is carried by, referenced by, or bound to a communication exchange. Such a mechanism can be a valid inheritance target for a protocol mapping row. If a draft marks a row as inherited, the row SHOULD identify the inherited mechanism and the decision state it supplies. The row should state the inherited verifier, carrier, binding, freshness rule, failure behavior, and evidence reference when available. Marking a row as inherited is preferable to silently implying a guarantee. It allows a communication protocol to stay focused on its transport or session design while still making authority, action evidence, revocation, or audit dependencies visible to reviewers.

Protocol-Neutral Worked Example The following example is deliberately protocol-neutral. It is not a complete mapping for AGTP , IACP , WIMSE , or any other candidate draft.

C-002: user or organization authorized the task: Possible carriers include a role credential, account policy, vLEI, OAuth token, GNAP grant , or equivalent. The verifier is the receiving agent or policy verifier. The claim is bound to the task, scope, subject, and resource. Freshness comes from token lifetime, revocation, or policy version. Failure behavior is rejection or fresh authorization.
C-001: live agent instance is acting: Possible carriers include channel authentication, an agent credential, attestation, or a protected key. The verifier is a peer, gateway, or relying party. The claim is bound to a session or channel transcript. Freshness comes from handshake freshness or attestation recency. Failure behavior is session rejection or capability downgrade.
C-003: delegation is in scope: Possible carriers include a delegation token or chain. The verifier is the recipient or gateway. The claim is bound to the delegator, delegatee, action class, and resource. Freshness comes from expiry, revocation, or attenuation version. Failure behavior is rejection of the delegated action.
C-006: tool invocation is in scope: Possible carriers include a tool call envelope or capability reference. The verifier is the tool gateway or policy engine. The claim is bound to delegated scope and tool identity. Freshness comes from a per-call nonce, session binding, or sequence. Failure behavior is denial of the invocation and failure recording if audit is claimed.
C-005: action evidence refers to the same action: Possible carriers include an action digest, receipt, capsule, or audit record. The verifier is the profile verifier or composition verifier. The claim is bound to the canonical action input and native record. Freshness comes from digest context version and receipt policy. Failure behavior is refusal to compose the records as evidence of the same action.

Negative Test Cases Protocol authors SHOULD consider negative tests for each row in the verifier matrix. The following cases are intended as examples.

Stale delegation: A delegation token or chain is structurally valid but expired, revoked, or superseded. The verifier rejects the delegated action or requests fresh authorization.
Unbound tool invocation: A tool call envelope is valid, but the envelope is not bound to the delegation scope, resource identifier, or session state used for the decision. The tool invocation is denied.
Replay across sessions: A claim or receipt from one session is replayed in another session. The verifier detects that the claim is not bound to the current session transcript, nonce, exporter, or equivalent channel state.
Mismatched action evidence: A receipt, log entry, capsule, or evidence record refers to a different action digest, input, resource, or policy version than the action being reviewed. The records are not composed as evidence of the same action.
Inherited mechanism absent: A draft states that another component supplies authorization, attestation, or evidence, but does not identify the dependency or the failure behavior when the dependency is unavailable. The row is marked as inherited or assumption, not as a current protocol guarantee.

Guidance for Candidate Protocol Drafts A candidate agent communication draft can use this document in three ways.

It can include a verifier matrix in its Security Considerations section.
It can publish a companion mapping document that maps its protocol fields to the claim registry.
It can state that a claim is intentionally out of scope, inherited from another document, or left to deployment policy.
It can link public vectors or evidence references for rows that have executable or reproducible evidence.

A draft that takes the third path remains reviewable if it identifies the dependency and failure behavior. The main review problem is not that a protocol omits a claim; the problem is when a protocol relies on a claim while leaving the verifier, binding, freshness rule, or failure behavior implicit.

Current-Draft Versus Future Mechanism When a draft supplies a verifier matrix, it SHOULD distinguish:

mechanisms implemented or normatively specified in the current draft;
mechanisms described as future work;
mechanisms inherited from another draft or external system; and
mechanisms that are architectural assumptions rather than protocol checks.

This distinction is important for review. A row that depends on a future reputation system, slashing process, governance committee, or external log can still be useful, but it should not be presented as a current protocol guarantee.

Security Considerations An agent communication protocol MUST NOT rely on a single identifier, token, session handle, log entry, or credential to imply multiple security properties unless the draft explicitly specifies the verification rule for each property. In particular:

authority and live-instance identity need separate validation;
possession of a session key does not by itself prove delegation scope;
a delegation chain does not by itself prove current session continuity;
a tool call does not by itself prove that the tool was within delegated authority;
an audit log or transparency receipt does not by itself prove authorization, truth, completeness, or correct execution; and
an architectural label such as "identity at the wire" should be mapped to concrete protocol checks.

If a claim is required for a security decision and the verifier cannot validate that claim, the protocol MUST specify whether the action is rejected, downgraded, quarantined, delayed for additional authorization, or allowed with a recorded warning. Silent acceptance is not an acceptable default for a security-relevant claim. Protocol authors should also consider cross-protocol composition. A claim that is valid in one protocol context might lose its security meaning when it is copied into a receipt, gateway envelope, audit record, or delegated session without preserving the binding and freshness state needed by the verifier. Where attestation evidence is used, this document follows the RATS distinction among claims, evidence, appraisal, and relying-party decisions described in . Where transparency services or signed-statement receipts are used, this document treats those receipts as evidence carriers and not as automatic proof of authorization or correct execution; see the SCITT architecture in .

Privacy Considerations Verifier-facing matrices can expose privacy-relevant design choices. A draft that binds actions to human authority, organizational identifiers, tool invocations, or long-lived sessions should state whether the binding creates linkability across actions, sessions, deployments, or administrative domains. Drafts should avoid requiring globally linkable identifiers unless the security property being claimed requires them. Where possible, a matrix row should state whether the verifier needs a stable identifier, a pairwise identifier, a role or capability assertion, a freshness proof, or only evidence that a locally authorized policy decision was made.

IANA Considerations This document makes no IANA requests. If later versions define a reusable registry of claim identifiers, verifier matrix fields, or protocol mapping status values, that registry will need a separate IANA considerations section.

Initial Application to AGENTPROTO Discussion The AGTP and IACP discussion threads provide useful early examples. AGTP appears to expose candidate carriers for authority, agent identity, delegation, session state, composition-layer tool identity, and audit evidence. The next useful step is to turn those carriers into a matrix that states who verifies each claim and what failure behavior applies. IACP has already been sketched by its author as a verifier-facing matrix. For reviewability, the useful next step is to separate rows that are currently in draft-gebauer-iacp-01 from rows that are future work or depend on governance systems not yet specified in the current I-D. Both mappings can help converge a shared requirements note without requiring either protocol to adopt the other's wire format.

Open Issues

Should the matrix be a requirements document, a security-considerations companion, or a section to be imported by candidate protocol drafts?
What is the minimal set of mandatory claim classes for AGENTPROTO?
Should the matrix define conformance language, or remain an Informational review aid?
Should a shared repository hold the claim registry and protocol mapping tables before the Internet-Draft is posted, or should the initial I-D define the table format first?
How should action evidence be bound to delegation and session state without forcing a single audit-record format?
Which negative test cases should protocol authors provide for stale delegation, replayed sessions, unbound tool calls, and mismatched evidence?
Should privacy and linkability expectations be part of the same matrix, or a separate privacy considerations profile?
Should the claim matrix repository require an optional evidence reference field from the beginning, or add it after the initial claim IDs are stable?

Acknowledgments The author thanks Leonard Gebauer for proposing a two-level claim-registry and per-protocol mapping-table structure and for providing IACP-oriented mapping examples; Chris Hood for clarifying open-ended layer vocabulary and AGTP transport-layer mapping considerations; and Iman Schrock for proposing evidence-backed mapping rows and inheritance-target framing for artifact-layer mechanisms. The author also thanks participants on the AGENTPROTO mailing list for discussion of security-principal separation, verifier-facing review matrices, protocol comparison, and claim-level coordination among candidate drafts. Acknowledgment does not imply endorsement of this document or of any particular protocol mapping.