"How do I give an identity to my agents?" splits into agents you run and agents you rent — and everything the industry sells assumes the first, while every agent you actually name is the second. For those, the honest current answer is: hand over a broad credential, and hope.
The question asked is concrete: how do I give an identity to the agents running in Claude, in Claude Code, in Codex, or behind an API? Every one of those is an agent you rent. The industry answer assumes agents you run.
| Agents you run | Agents you rent | |
|---|---|---|
| Where it executes | Your infrastructure | Somebody else's |
| Can you attest the workload? | Yes — that is the mechanism | No |
| Can you install an identity agent? | Yes | No |
| What you control | Everything | The credential you hand over |
| Industry answer | Mature — and expensive | None |
For the first population, an open standard (SPIFFE) issues short-lived cryptographic identities based on workload attestation — described by practitioners as a multi-year engineering project needing a dedicated team. For the second, the equivalent capability is an open feature request. The full argument, with citations →
When you hand an agent a broad credential you are making two hopes: that it will not misuse what it holds, and that it will not find the rest of what that credential actually reaches. Neither hope changes your accountability — which runs all the way to the board.
Hope about behaviour, and hope about discovery. Hope-driven development named as the anti-pattern behind today's agent deployments.
Read → ConceptInbox access is every account resettable by email. Desktop access is every stored credential. The grant is not the words — it is everything reachable from them.
Read → WorkflowsEnumerate, bound, observe, contain, account — and workflows like the serialised pull request, where the agent holds no credential at all.
Read →Three checkable facts establish that rented agents have no scoped-credential mechanism today.
The platform feature request for user-minted, short-lived, repository-scoped tokens for AI agents (June 2026) is still open. Personal access tokens are long-lived; app installation tokens need admin setup.
One coding assistant held a token scoped to every repository its developer had authorised — far more than the surgical changes it was making required.
Research disclosed at Black Hat (5 Aug 2026): a repository issue opened by an account with no privileges reached CI secrets in three vendors' own repositories, under default configurations.
Not a vendor list. Four agents, four vaults, one repository, nobody able to use another's access. Every option answers the same scenario in the same columns — with privileges granted as the differentiating column, and a verification date on everything, because this dates in weeks.
The scenario and the columns, published before any option is assessed. A participant's comparison is credible only in that order.
Read → OptionSPIFFE/SPIRE: attested, short-lived, cryptographic — and a multi-year project with compounding operational costs.
Read → OptionProducts that broker access without standing secrets — for workloads in infrastructure you control.
Read → BaselineWhat almost everybody actually does, assessed with the same honesty as everything else.
Read → The thesis, testedA second scenario, fully scored: every option acts as you, granularity is segregation not scoping, and nothing supports per-agent keys. Three empty rows — the finding, not an omission.
Read →Over 120 published documents mention non-human identity and over 300 mention blast radius. You arrive with a problem, not an interest in chronology — so the collection is organised by the question you are asking.
The union of everything possible — not the words of the grant.
Browse → QuestionBlast radius over the transitive closure of the credential.
Browse → QuestionThe two cheapest unimplemented controls in agentic estates.
Browse → QuestionProvenance, per-agent keys, and reviewable artefacts.
Browse → FrameworkCould your agents reach someone else — and would you know before they told you? The strongest artefact in the collection, promoted to a page.
Read → Preparing pki.sgit.aiA key registry for agents, designed from the documented 2019 keyserver failure: owner-only writes, revocation as a signed append, and mandate separate from identity.
Read → The marketThe main NHI products and services, grouped by which layer they answer — discovery & governance, workload IAM, secrets, machine identity, platform IdPs — with a profile page per provider and SPIFFE explained with diagrams.
Browse → The sourcesThe original briefs behind this site, readable in-page: summary, key concepts and ideas, then the full markdown — raw file as the source of truth.
Read → EngineeringImplementation-plan packs authored by dev agents, presented for reading: static publishing (a vault on any static host, no server, no auth) and the fractal forge (hub.sgit.ai — a hub is itself a vault).
Read →This site is hosted on the sgit domain, and encrypted vaults are a candidate answer to where an agent's secrets live. So this is a participant publishing a comparison — stated here, upfront, not in a footer. The method is published before the findings, everything is dated and re-runnable, and we publish where our own approach loses: vaults do not solve attestation, do not provide lifecycle governance, and do not answer the rented-agent problem either.