pki.sgit.ai / bootstrap

The bootstrap trap

Creating a key is easy. Getting it recognised requires an identity you do not yet have — and every common escape hands over a larger one. This is a loop, not a missing feature, and it is why agent key registries do not exist. It is also the mechanism behind incidents that have already happened.

Why this page sits next to the failure. That page explains why the last generation of key repositories was destroyed. This one explains why the next generation has not been built. The two are different obstacles and a registry has to clear both.

The loop

Stated in the form that makes it tractable:

   Agent needs an identity
        |
   must request certification
        |
   request must reach trusted infrastructure
        |
   infrastructure requires authentication
        |
   agent must already possess an identity
        |
        +---- back to the top

Generating a keypair takes milliseconds. Getting the public half recognised by something that matters is the whole difficulty. The distinction that carries the argument:

Creating a key is not creating an identity. A key is a mathematical object anybody can make. An identity is a relationship somebody else has agreed to — and agreement requires a channel.

Every workaround trades a small problem for a larger one

The escapes people actually use, and what each one grants:

Workaround	What it grants
The operator's platform credential	Everything that person can do, everywhere
Repository write access	The whole repository, permanently
A shared bot token	Whatever the bot can do, to everybody holding it
A vendor integration	Whatever its permissions cover, which is usually broad
A cloud or service credential	Whatever that principal can reach
A project signing secret	The ability to sign as the project
A bespoke public enrolment server	A new service to secure — and its own identity problem

Every row solves transport by creating a larger identity problem than the one being solved. That is the argument, and it holds for all seven.

Not theoretical — the mechanism behind documented incidents

The first two rows in particular have public evidence:

One coding assistant was found holding a token scoped to every repository its developer had authorised — far more than the surgical changes it was making required.
A disclosure at a security conference on 5 August 2026 showed a repository issue, opened by an account with no repository privileges, reaching continuous-integration secrets in three vendors' own repositories, under their own default configurations.
The platform feature request for short-lived, repository-scoped tokens for AI agents remains open — which is why the workaround persists rather than being a choice anybody defends.

So this is not a concern about elegance. It is why rented agents have no identity: that site observes that for agents you rent the honest answer is to hand over a broad credential and hope. The bootstrap trap is why, and the two arguments are considerably stronger adjacent than apart.

Two named failure modes underneath

Failure mode	What it is	Why the workarounds produce it
Ambient authority	Privilege a process holds by virtue of where it runs, rather than because it was handed something specific	A borrowed credential is ambient authority by construction — the agent inherits everything the holder could do, whether or not the task needs it. Published analysis identifies this as the root cause of prompt injection: an attacker need not break anything, and need only ask the holder to use authority it already has.
The confused deputy	A party with more authority than its task required, acting on instructions that may not have come from whoever granted it	The workarounds create deputies as a side effect of solving delivery.

Both point at the same conclusion. The fix is not a better credential. It is not needing one.

The constraint is transport, not cryptography

The hardest part of agent identity is not cryptography but authority choreography — the order in which claims are established, and what each step requires.

That reframing does real work. The question is not which signature scheme, which certificate format or which key length; those are settled. The question is what the smallest possible ingress looks like, because the ingress determines what the agent must already have. Stated as the failure it prevents:

A system can use excellent cryptography and still have a weak bootstrap if the first instruction is to hand over a platform token.

The gradient

Each step establishes strictly more than the last, and none requires borrowed authority:

I control this private key

Proof of possession. Self-issued, free, checkable by anybody, and requiring no relationship with anybody. The smallest defensible primitive, which is why it is the right starting point.

Costs: nothing · Establishes: possession, and only possession

The project recognises this key

A decision, not a computation. Nothing in the request compels recognition — which is a feature, because it means the project retains judgement and a signature can never be mistaken for an endorsement.

Costs: a policy decision by the issuer · Establishes: a relationship

The project delegates this mandate

A permission — scoped, dated and revocable independently of the identity. This is the identity-and-mandate split, reached here from a second direction.

Costs: a delegation · Establishes: what the agent may do

A signature over an enrolment request proves the submitter controls the corresponding private key. It does not prove that the project should trust the agent. Trust is a policy decision made afterwards.

The exit: a door narrow enough that walking through it requires nothing

If the loop is a transport problem, the answer is a channel whose granted capability is to add an object to an inbox — and specifically not to read it, alter it, or reach anything else. An agent that holds nothing can still walk through a door like that.

Shipped

That channel is not a proposal. The append lane exists and is account-less: a write requires an append token carried in the request body, no account and no access token, and returns a blind acknowledgement that tells the sender nothing. So the enrolment path is buildable rather than theoretical — how it works, and what ships versus what is proposed.

The consequence is worth stating plainly rather than glossing: a compromised or hostile agent can add junk to an enrolment inbox. It cannot read other requests, cannot see who else has enrolled, and cannot reach the registry or the issuing key. The blast radius of the ingress is a queue that needs draining, which is the correct shape for a public door.

What this does not fix

A page claiming the problem is solved would be wrong. The remaining work is substantial: append-capability distribution, spam and denial-of-service controls, replay protection, canonical message formats, certificate expiry, issuer key protection, key rotation, revocation, mandate semantics, private key persistence, cross-registry trust, recovery from compromised keys, lifecycle for ephemeral identities, and confidential response delivery.

None of that disappears. The narrower and better claim is that those problems can now be solved without first giving an unenrolled agent a high-authority identity.

Two items deserve flagging. Private key persistence for a rented agent is genuinely unresolved: if a hosted session cannot keep a key between runs, every session is a new identity and a mandate cannot outlive one conversation. And confidential response delivery is the direction a write-only lane does not cover — the certificate has to get back, so the return path needs its own answer rather than inheriting the ingress design.

Open questions

Can a rented agent persist a key between sessions? If not, mandates cannot outlive a conversation, which changes what the architecture delivers.
How is the return path secured? A write-only lane covers ingress only.
What stops the ingress being flooded? It is deliberately unauthenticated, so this needs an answer before it is exposed.
Is proof of possession ever mistaken for recognition? The distinction is clear when stated and will not survive casual reading, so the interface has to carry it.
Does the gradient need a fourth step? Recognition and mandate may not cover attestation, which remains unavailable for rented agents.

← The failure Next: how a key actually gets in →