AWS TSAITrust Signals for Agentic Interactions

Implementation

Choose the role your organisation implements and follow that path. Each path is self-contained and assumes the other actors are available as test counterparts. It explains the first working outcome, the components you own, the decisions you must make, and the protocol artefacts that support the work.

Choose your role

Operators

Register one agent, obtain a current credential, and create a valid presentation for one service provider.

Operator path

Service providers

Publish one accepted issuer, verify one presentation, and expose the verified identity and signals to application policy.

Service provider path

Trust authorities

Register one operator and agent, issue one credential, and publish the material required for independent verification.

Trust authority path

Operator implementation

First outcome: One registered agent can obtain a current credential and present it successfully to a test service provider.

External counterparts: This path assumes a trust authority test environment that can register and issue, plus a service provider endpoint that can verify. The operator team does not implement either counterpart.

Establish identity and key control

The operator first establishes an authenticated relationship with a trust authority. It registers a persistent agent sub under a controlled domain and a P-256 binding key, then completes the authority's domain and key-control challenges. Domain control must have been verified no more than 12 hours before issuance. The operator therefore treats the domain as identity infrastructure because confirmed loss of control blocks every registered agent anchored to it.

Obtain and protect the credential

The agent requests a credential against the registered key. The trust authority copies identity and evidence from its records, so the request cannot invent a new subject or replace mandatory signals. The agent protects both the credential and private key and obtains a replacement before the 30-minute lifetime ends.

Create the presentation

For each service provider interaction, the agent creates a new key-binding JWT with the target audience, current time, nonce, and credential hash. It sends the complete presentation in TSAI-Credential. Reusing an old holder proof would weaken freshness even when the credential remains valid.

Design decisions

Choose how agent identifiers are assigned and retained, where binding keys are generated and stored, how rotation and repudiation reach the operator management channel, and when credentials are refreshed. Keep operator management and refresh credentials outside the agent runtime where practical. Optional signal selection should reflect the interactions the agent expects rather than expose all available evidence by default.

Starting artefacts

Use the Trust Authority OpenAPI for challenge and issuance operations, the key-binding JWT schema for presentation claims, and the freshness vectors to exercise valid, stale, and future-dated proofs.

First expansion: Add a service-provider challenge and req binding for one state-changing action. This introduces replay and request-substitution protection without changing the agent identity or credential model.

Service provider implementation

First outcome: One endpoint verifies a TSAI presentation and records the result without changing access.

External counterparts: This path assumes a test agent that can present a credential and published issuer material from one trust authority. The service provider team implements only verification and the application handoff.

Publish acceptance

The service provider chooses one trust authority issuer and publishes it through /.well-known/tsai-config.json. It also defines the exact aud expected by the endpoint. Publishing these values before the interaction lets the agent select a compatible credential and construct the correct holder proof.

Prepare the verifier

The verifier obtains issuer metadata, the selected signing key from its embedded or referenced JWK Set, canonical Type Metadata, and the JSON Schema before requests arrive. It checks their integrity where defined and caches them under the applicable content or HTTP rules. This removes remote metadata fetches from the request path and gives every presentation the same local interpretation. Where policy requires status, the verifier also implements signed status-token checks and the same hardened, no-redirect fetch policy.

Verify and expose context

The request handler verifies the credential, identity floor, trust signals, key-binding JWT, audience, and fixed freshness bound of 90 seconds with at most 30 seconds of forward clock skew. It returns a structured result to application policy. Starting in log-only mode allows the team to compare that result with existing telemetry before it affects access.

Design decisions

Define the accepted issuer set, audience value, failure posture, cache lifecycle, and status policy. Decide whether verification belongs in the application or at the edge; if verification and execution occur in different components, the presentation must bind the exact request and the forwarded verification context must be authenticated.

Starting artefacts

Use the credential schema for canonical payloads, the canonical Type Metadata for disclosure and schema binding, and the test vectors for holder freshness, derived types, and signed trust authority publications.

First expansion: Move from log-only to annotate posture so downstream policy can inspect verified signals without gating traffic, then use enforce posture for one low-risk operation. An absent or failed presentation can affect access according to the selected posture, but a failed verification is never represented as verified. Add a single-use challenge and request binding before enforcing one state-changing operation.

Trust authority implementation

Operating commitment

A production trust authority is a substantial programme. It combines evidence processes, secure key management, issuance, status, auditability, incident response, availability, and legal accountability. Building and validating these capabilities can take months, while ongoing operation requires dedicated ownership, funding, and a viable business model.

First outcome: One operator and agent can enrol, prove key control, obtain a credential, and have it verified independently.

External counterparts: This path assumes a test operator and agent plus an independent service provider verifier. The trust authority team implements enrolment, issuance, and publication rather than the agent or verifier.

Create the management record

The trust authority authenticates the operator, establishes its identity and controlled domains, and registers one agent sub. A domain challenge uses at least 256 bits of entropy and remains single-use, short-lived, and bound to the account, agent, domain, and validation method. The authority records successful verification as dct.asof and revalidates it within the 12-hour domain-freshness window.

Issue from established evidence

The issuance service selects the registered agent and key, verifies a single-use key-control challenge that expires within five minutes, includes the mandatory identity floor, and adds only signals supported by current evidence. It signs a canonical credential with an HSM-held key and a 30-minute lifetime. The issuance request cannot define its own identity or unverified claims.

Publish verification material

The authority publishes issuer metadata and keys, Type Metadata, schemas, and an agent-and-operator status list. It also publishes a signed operational report and HSM attestation so service providers can review current operation and key custody. The common verification path remains independent of a request-time call to the authority.

Security-critical state: The registration index accepts changes only through authenticated and authorised management actions, records them in tamper-evident audit logs, and resists rollback. An active kid maps to exactly one agent across the trust authority, and registration enforces that rule atomically. Key-control challenge responses are non-cacheable, while every protocol-directed fetch rejects redirects and private destinations.

Design decisions

Define how evidence is established and expires, how signing keys are protected and rotated, how agent and operator blocks are set, and how incidents affect issuance. Define immediate revocation for operator sessions, emergency out-of-band signing-key rotation, and the revalidation response to inconclusive and confirmed domain-control failures. If reputation is issued, publish its range, direction, calculation, evidence basis, and insufficient-history treatment through an immutable methodology document.

Starting artefacts

Use the Trust Authority OpenAPI for protocol-facing lifecycle operations, the JSON Schemas for credentials and publications, and the Type Metadata examples for canonical and derived definitions.

Production scope: The first outcome proves protocol interoperability; it does not constitute a production trust authority. Production operation requires TLS 1.3 APIs, HSM-backed signing keys, auditable evaluation and registration processes, high availability, bounded challenges, signed transparency publications, incident response, and legal accountability.

Review Protocol for the shared credential model and Security and privacy before production use.