The question splits into two populations, and the industry only answers one of them

The question practitioners actually ask is concrete: "how do I give an identity to my agents — the ones I have running in Claude, in Claude Code, in Claude Web, the ones that run in Codex, the ones I just run through an API?" Its concreteness is what exposes the gap.

Agents you run vs. agents you rent

Every one of the agents named above is an agent you rent, not an agent you run. And the entire industry answer assumes the opposite.

The mature answer — for the population that isn't asking

For agents you run, the answer is real and it works. An open standard (SPIFFE — explained with diagrams here) assigns each workload a cryptographic identity and issues short-lived certificates that rotate automatically, without long-lived secrets. A major secrets product now issues those identities natively. A mid-2026 reference architecture pairs that identity layer with relationship-based authorisation and an enforcement layer that checks every tool call.

It also costs what it costs. Practitioner analysis describes the reference implementation as a significant multi-year engineering project with compounding operational costs, demanding a dedicated team to deploy, scale, maintain and secure — alongside datastores, certificate infrastructure, proxy configuration, policy and monitoring. The same analysis notes it does not solve the software-as-a-service access problem, legacy credential types, or agent identity specifically.

All of it rests on one precondition: a workload you control, that something you installed can attest. A rented agent — in a hosted coding tool, a chat interface, or behind an API — fails that precondition by construction. You cannot install an attestation agent in somebody else's infrastructure. You have exactly one lever: which credential you hand over, and what it can reach.

For rented agents, the gap is evidenced

The corpus established this on 14 August 2026, with three checkable facts:

• The capability does not exist. The platform feature request for user-minted, short-lived, repository-scoped tokens for AI agents (June 2026) is open — noting that personal access tokens are long-lived and app installation tokens require administrative setup. The open request.
• The over-scope is documented. One coding assistant held a token scoped to every repository its developer had authorised, with a practitioner assessment that agents use far more permission than a human would. The reporting.
• The exploitation is disclosed. Research presented at Black Hat on 5 August 2026 showed that a repository issue opened by an account with no repository privileges reached continuous-integration secrets in three vendors' own repositories, under their own default configurations. The disclosure.

So the practitioner's honest position today is: hand over a broad credential, and hope. That is worth saying plainly, with evidence, because nobody selling into this market has a reason to say it. The Hope section takes that sentence seriously.

Why this position holds up

Three reasons this is a thesis rather than a complaint.

• It is falsifiable. The claim is that for rented agents there is no way to issue a scoped, short-lived, attested identity. Anybody who can show one refutes it — and this site improves. Refutations are welcome: tell us.
• It is evidenced rather than asserted. An open feature request, a documented over-broad token, and a public disclosure are all checkable, above.
• It explains the failures people are already seeing. 2026 industry commentary frames the gap as visibility not being enforcement; surveys report low confidence in preventing identity-based attacks and a substantial share of organisations not tracking creation of agent-related identities at all. The two-populations split explains why: the tools that provide enforcement require a workload you control, and the agents causing concern are not.

The thesis, tested against a concrete scenario

On 16 August the thesis was run against a specific case: give two agent sessions a shared file area. The result is its first concrete instance, with checkable evidence: every available option runs on your identity (a rogue session reaches everything every other session can reach), the only granularity is a dedicated drive per agent — segregation, not scoping — and nothing supports per-agent keys. Three requirement rows (per-agent identity, agent-level attribution, encryption to a specific agent) come back empty across the entire surveyed market. The full research, with the tables and sources →

The cryptographic half of the answer — per-agent keys in a registry, designed from the documented 2019 keyserver failure — is scoped in the PKI section, staging ground for pki.sgit.ai.

What this site is not

• Not a vendor directory. Those exist and date immediately. The research here answers one concrete scenario per option, dated and re-runnable.
• Not neutral. A participant, disclosed upfront, publishing a re-runnable method. Who is writing this, and where our own approach loses.
• Not a chronological archive. The collection is organised by the question a reader arrives with.

The measure of success: somebody with four agents and four vaults can read this site and know what to do next — including when the answer is that nothing available does what they want.

Sources

• SPIFFE for agentic AI and non-human actors; native issuance of workload identities by a major secrets product: hashicorp.com
• Practitioner analysis of the reference implementation as a multi-year project with compounding operational costs: aembit.io; vendor landscape: aembit.io
• Mature programmes as discovery + secrets + workload-identity layers under one policy: guptadeepak.com
• Mid-2026 reference architecture pairing SPIFFE with relationship-based authorisation and per-tool-call enforcement: stacklok.com
• The governance gap: low confidence in preventing identity-based attacks; agent identities untracked; visibility is not enforcement: cloudsecurityalliance.org