Frequently asked questions

What does TSAI enable?

TSAI gives service providers the information they need to make risk-calibrated access decisions about agent traffic. Instead of a binary block-or-accept choice, platforms can differentiate based on verified identity, reputation, certifications, and accountability. For agent operators, it provides a way to prove legitimacy and build a portable track record that opens doors across platforms.

How is this different from OAuth or API keys?

OAuth and API keys handle authorisation — what a user has consented to let an agent do. TSAI handles trust — whether the agent and its operator are legitimate, reputable, and accountable. The two are complementary: TSAI tells you who the agent is and whether it deserves access, while OAuth tells you what the user has permitted. In practice, a request might carry both a TSAI credential and an OAuth token.

What does integration look like for a service provider?

You check for a TSAI-Credential HTTP header on incoming requests, verify the JWT signature against the Trust Authority's public key (a standard crypto operation, offline, under 5ms), and read the trust signals inside. Then you apply your own policies — the protocol provides information, your platform makes the decision. No SDK is required; the open spec on GitHub is sufficient for implementation.

What does it cost?

For service providers, basic credential verification is a standard cryptographic operation with no external dependency — there is no protocol-level fee. For agent operators, the cost depends on the Trust Authority and the tier of service. Basic identity verification (T0) is designed to be accessible, while higher tiers involving reputation monitoring, premium rate limits, or value-added services carry fees that reflect the evaluation and infrastructure involved. Each TA sets its own pricing.

How mature is the protocol?

The protocol specification is published and open source. The first Trust Authority (Trusted Shops) is operational. The protocol builds on established standards (W3C Verifiable Credentials, DIDs, JWT) rather than inventing new ones — which means implementations can rely on existing, well-tested libraries for the cryptographic operations. It is early-stage, but production-ready for T0/T1 credentials.

What happens if we wait?

There is no penalty for waiting, but there is an opportunity cost. For agent operators, reputation compounds over time — agents verified today build a track record that later entrants cannot shortcut. For service providers, early adopters gain visibility into agent traffic patterns while competitors continue operating blind. The protocol is designed so that adoption is incremental and low-risk, which makes starting early relatively inexpensive.

Who governs the protocol?

TSAI is stewarded by AWS and published as open source under Apache 2.0. The specification is developed in collaboration with industry partners and open to contributions. The protocol is designed to prevent vendor lock-in — service providers choose which Trust Authorities to accept, and the credential format uses open W3C standards that any party can implement independently.

Can credentials be faked or replayed?

Credentials are cryptographically signed by the Trust Authority using HSM-backed keys — forging one requires breaking the TA's private key. Replay is mitigated by short credential lifetimes (2–4 hours) and by binding credentials to the agent's DID. A stolen credential expires quickly and cannot be transferred to a different agent identity.

How does this relate to the EU AI Act?

Article 50 of the EU AI Act (effective August 2026) requires AI systems to identify themselves when interacting with people. TSAI provides infrastructure for compliant agent identification — a machine-readable, verifiable way for agents to declare who they are and who operates them. It addresses the identification requirement directly, though full compliance depends on the specific use case and deployment context.

Can there be multiple Trust Authorities?

Yes — the protocol is explicitly designed for multiple independent TAs that compete on methodology, geographic expertise, and vertical specialisation. Service providers choose which TAs they trust (similar to how browsers choose which certificate authorities to accept). This prevents single points of failure and ensures that no single organisation controls access to the ecosystem.