Technical note

Agents Secure Binding

Binding delegated agent identity to the actual TLS and attestation session.

We propose this as a verifier-side acceptance profile and implementation experiment. The receiver accepts an Agent only when the authority grant, holder-of-key proof, accepted TLS or exported-authenticator session, freshness and replay state, any required attestation result, and local expected policy all describe the same intended interaction.

Read the SSOT Download PDF GitHub repository

Source of truth

This page is an entry point, not the specification

The only public source of truth for the profile is docs/SSOT.md in the GitHub repository. This ToppyMicroServices page is a short reader-facing note and link hub. If this page and the public SSOT ever differ, the SSOT wins.

Animated explainer

Valid credentials still need session binding

The receiver accepts only when the Identity Grant, holder proof, current TLS or exported-authenticator session, freshness state, optional attestation result, and Alice's local expected policy all line up. Replayed bindings, substituted grants, wrong keys, peer-selected labels, cached security state, and peer-supplied metadata fail closed.

Verifier outcomes

Case Result Why
valid grant + valid binding ACCEPT The signed grant, Agent key, grant_hash, session binding, freshness state, and local policy all match.
replayed binding REJECT The statement does not bind to Alice's current TLS or attestation session.
grant_hash mismatch REJECT The binding statement points at a different Identity Grant.
wrong Agent key REJECT The confirmation key does not match the agent authorized by the grant.
Manager key reused as Agent key REJECT Manager authority and Agent confirmation roles are separate.
missing attestation binder REJECT When attestation is required, the receiver cannot bind the statement to the accepted attestation result.
peer-selected exporter label REJECT The binding input is selected by the application or deployment profile, not by the peer.
TLS 0-RTT or resumed-session proof reuse REJECT Profile-authenticated identity is not returned for 0-RTT, and a resumed connection needs its own proof and replay state.
cached security decision reused REJECT Verified grants, session proofs, attestation evidence, and verifier decisions are not reusable acceptance evidence for a later request.
peer metadata injection REJECT Alice uses local expected policy, not peer-supplied metadata, as the acceptance policy.

Problem

Successful components can still compose into the wrong actor

TLS, signed authorization material, holder-of-key proof, attestation, and local policy can each verify successfully while the composition still authenticates the wrong session, service, Agent, task, or authority boundary.

Valid credentials are not enough

A peer can present valid cryptographic material while still causing replay, relay, token substitution, context diversion, wrong-agent, cache-confusion, or confused-deputy failures.

Peer metadata is not policy

The receiver should not turn service, tenant, task, scope, or agent metadata supplied by the peer into local authorization policy.

Acceptance model

One invariant, checked across separate dimensions

Before the application receives a profile-authenticated Agent identity, Alice checks that authentication facts and local policy facts identify the same intended interaction. The labels below are diagnostic dimensions, not protocol layers or a trust hierarchy.

Authentication and binding

  • D0: accepted TLS or exported-authenticator session.
  • D1: attested platform validity, when required by local policy.
  • D2: authenticator, proof, or attestation result bound to the accepted session.

Verifier-local policy

  • D3: service, tenant, deployment, or environment.
  • D4: workload, process, service component, or Agent.
  • D5: task, thread, context, delegation, or request scope.
  • D6: capability, tool authority, or action boundary.

Approach

Separate authority, holder proof, and session evidence

This profile separates who is allowed to authorize a delegated identity from who proves possession in the live session, then requires the verifier to compare both against local expected policy before acceptance.

Two signed materials

  • Identity Grant: Manager or policy authority signs the intended agent, task, delegation, scope, and related values.
  • Session Binding Statement: the holder of the authorized confirmation key binds that exact grant to the accepted session.

Three key roles

  • Manager or policy-authority key for Identity Grants.
  • Agent confirmation key for Session Binding Statements.
  • TLS endpoint key for the accepted TLS or exported-authenticator endpoint.

Local policy comparison

The receiver compares signed and session-bound material against canonical local expected values. Peer-provided aliases, display names, natural-language labels, and reserialized metadata are not repaired during final acceptance.

Verifier-side gate

The profile does not replace an agent protocol. It defines a fail-closed acceptance gate that an application or deployment profile can place before treating the peer as the intended Agent.

Verification procedure

Authentication, policy, then replay commit

The verifier first authenticates the signed material, then compares canonical local policy values, then commits replay state only after the full acceptance decision succeeds.

Authentication phase

  • Verify the authority grant under a trusted policy-authority key.
  • Check issuer, audience, profile guard, algorithm, key status, time validity, grant ID, and required authorization fields.
  • Verify the session proof under the authorized Agent confirmation key or explicitly authorized endpoint key.
  • Recompute grant_hash over the exact verified grant bytes.

Policy and replay phase

  • Compare service, tenant, Agent, task, capability, and endpoint values against local expected policy.
  • Reject missing, stale, ambiguous, revoked, wrong-use, or peer-selected policy values.
  • Bind each accepted task to a task-specific context and verifier nonce or attempt ID.
  • Commit replay state only for the accepted interaction.

Implemented work

What the repository currently contains

The implementation tests focus on fail-closed acceptance: attacker-shaped input should be rejected before an application treats the observed identity as accepted.

Token profiles

  • JWT/JWS Identity Grant and Session Binding Statement profile.
  • CWT/COSE verifier coverage for the same trust model.

Verifier and cache safety

  • Local expected-policy comparison before acceptance.
  • Replay-state and response-cache safety policy for caller-dependent results.

Red-team coverage

  • Live-style red-team tests for replay, relay, diversion, wrong-agent, key-role confusion, grant substitution, and cache misuse.
  • Separate notes for boundaries that remain outside the direct-Agent profile.

Readable specification artifact

The repository includes the Markdown SSOT and a rendered PDF for review.

View red-team report View security red-team tests

Boundaries

What is not claimed

Not a standard

This is a proposal and implementation experiment, not standards-body consensus or AGTP/A2A core protocol text.

Not a full protocol stack

This page defines an acceptance profile, not a TLS extension, identity provider, registry, gateway, or application protocol. Gateway-routed deployments need separate binding-profile work.

Links

Repository entry points

Use the repository documents for the current profile text, rendered specification, and red-team evidence.

GitHub repository Read the SSOT Download PDF View red-team report View security red-team tests