How it works
Agentic Root Trust connects an AI agent's workload identity to the organization that stands behind it, so the service receiving a request can check who is on the other end.
Three checks before a claim is accepted
A domain stays unclaimed until an organization passes all three. None can be skipped, and each is recorded and shown separately.
DNS challenge
The claimant publishes a one-time token in a DNS TXT record under the domain. This shows control of the domain's DNS at the time of the check.
Organization identity review
A reviewer confirms the organization exists and matches its official registration: legal name, jurisdiction and registration reference.
Representative authority
A reviewer confirms that the person making the claim is entitled to act for that organization. This approval expires and has to be renewed.
DV, OV and EV evidence
The directory borrows the evidence levels used for TLS certificates so relying parties can compare like with like.
| Level | Evidence it carries |
|---|---|
| DV | Domain control validated for issuance. |
| OV | DV plus vetted organization information. |
| EV | OV plus prescribed existence and applicant-authority checks. |
DV/OV/EV describe evidence, not legitimacy or agent safety. A fully verified organization can still run a careless or compromised agent.
What happens when an agent connects
The agent presents an SVID
Its SPIFFE Verifiable Identity Document names a trust domain, such as
spiffe://payments.example.com/agent/checkout.The relying party resolves the trust domain
It asks the directory who has authorized that trust domain.
The directory returns a signed assertion and the approved bundle
The assertion names the verified organization and its domains; the bundle holds the keys that organization approved for the issuer.
The relying party verifies and decides
It checks the signature and the SVID against the bundle, then applies its own authorization rules. Whether to let the agent act is always its decision.
The directory never issues credentials, never holds private keys, and a lookup never grants transaction access.
How it fits with SPIFFE, SPIRE and WIMSE
SPIFFE
The standard for workload identity. It defines trust domains, SVIDs and trust bundles, so a workload can prove who it is inside a trust domain. It does not say which organization operates that trust domain. The directory fills that gap.
SPIRE
The reference implementation that issues SVIDs. Your SPIRE servers stay the issuers and keep their keys. The directory records only that your organization authorizes them and which bundle it approved.
WIMSE
The IETF work on workload identity across systems, including the Workload Identity Token (WIT) and Workload Identity Certificate (WIC). Issuers of these credentials are authorized the same way: an approved trust domain with an approved bundle.
For developers
The directory is a plain HTTPS JSON API under /v1. The OpenAPI 3.1 description covers every public and organization route, with request and response schemas, examples, error codes and the signed assertion format.