# The Bootstrap Trap: Creating A Key Is Easy And Getting It Recognised Requires An Identity You Do Not Yet Have, So Every Workaround Hands Over A Larger One **version** v0.33.60 **date** 19 August 2026 **from** Human (project lead) **to** Engineering, Architecture, AppSec, Strategy **type** Strategy brief *Second of 19 August, and the companion to the enrolment architecture. Converted from a document produced in a voice session with a different assistant, restructured into the corpus format with its substance preserved. Its central argument is the justification for the architecture rather than a separate proposal.* --- ## What This Is Why non-human identity is hard, stated as a circular dependency rather than a cryptographic problem, and why the usual escapes make the position worse: **generating a keypair is trivial and the difficulty begins immediately afterwards, because an unknown agent must get its public key in front of a trusted authority, every route to that authority requires authentication, and authentication requires an identity the agent does not yet have, which is a loop rather than a gap; every common workaround escapes the loop by handing over authority far broader than the identity being created, whether that is the operator's platform credential, repository write access, a shared bot token, a vendor integration with wide permissions, a cloud credential, a project signing secret or a bespoke public server, and each of those solves the transport problem by creating a larger identity problem; the original document enumerates seven such dependencies and the pattern across all of them is the same, that the transport is the constraint rather than the cryptography, which is why the answer is a channel narrow enough to require nothing rather than a cleverer credential; two failure modes underneath it already have names in this corpus, since ambient authority is the reason a borrowed credential grants everything the borrower could do, and the confused deputy is what an agent becomes when it holds authority it did not need for the task it was given, both established here on 6 August as the documented root cause of prompt injection; the argument's most useful formulation is that the hardest part of agent identity is not cryptography but authority choreography, meaning the order in which claims are established, and a system can use excellent cryptography and still have a weak bootstrap if the first instruction is to hand over a platform token; and the gradient it proposes is the right shape, moving from I control this private key, to the project recognises this key, to the project delegates this mandate, with each step establishing strictly more than the last and none requiring authority borrowed from elsewhere.** It is the second document of 19 August (cross-ref: the v0.33.60 enrolment architecture, the v0.33.56 plugins brief, the v0.33.59 NHI site brief, the v0.33.58 serialised pull request brief, and the v0.33.59 shared drives research). New contributions from the corpus side: **the loop connected to ambient authority as already documented here, the seven dependencies grouped by what they actually cost, the external evidence for the workarounds' failure, and the gradient related to work already done.** ## The Loop The problem 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 ``` **That is a loop, not a missing feature**, and it is why the problem persists despite the cryptography being entirely solved. Generating a keypair takes milliseconds. Getting the public half recognised by something that matters is the whole difficulty. The original document's framing of the key distinction is the one to keep: **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 costs: | 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 of the dependencies the original enumerates. The corpus has external evidence for the first two rows in particular. One coding assistant was found holding a token **scoped to every repository its developer had authorised**. A disclosure at a security conference on 5 August showed an issue opened by an account with **no repository privileges** reaching continuous integration secrets in three vendors' own repositories under their own default configurations. And the platform feature request for short-lived repository-scoped tokens for agents remains **open**, which is why the workaround persists. So this is not a theoretical concern about elegance. **It is the mechanism behind incidents that have already happened.** ## Two Named Failure Modes Underneath The original identifies both and the corpus already documented them, which is worth recording because it means the analysis converges from two directions. **Ambient authority** is 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 credential holder could do, whether or not the task needs it. The corpus established this on 6 August as the foundation of the capability discipline, and published analysis identifies it as **the root cause of prompt injection**, because an attacker need not break anything and need only ask the holder to use the authority it already has. **The confused deputy** is what the agent then becomes: a party with more authority than the task required, acting on instructions that may not have come from whoever granted it. The original document's framing is that 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 Real Constraint Is Transport, Not Cryptography The observation that reorganises the problem, and the original states it well: the hardest part of agent identity is not cryptography but **authority choreography**, meaning the order in which claims are established and what each step requires. That reframing does real work. It means 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. Which is exactly why the companion architecture's answer is an append lane: 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. **A door narrow enough that walking through it requires nothing.** The original's summary of the failure is the sentence worth keeping: > 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 The proposed sequence, and its shape is right because each step establishes strictly more than the last while none requires borrowed authority. ``` I control this private key. | proof of possession, self-issued, free v The project recognises this key. | a policy decision by the issuer v The project delegates this mandate. a permission, scoped and revocable ``` Three things worth drawing out. **The first step costs nothing and proves something real.** Possession of a private key is checkable by anybody and requires no relationship with anybody. It is the smallest defensible primitive, which is why it is the right starting point. **The second is a decision, not a computation.** Nothing in the request compels recognition. That is a feature: it means the project retains judgement, and it means a signature can never be mistaken for an endorsement. **And the third is separable, which the corpus reached independently.** The identity and mandate split proposed on 16 August is the same structure: what an agent is and what it may do are different statements, issued and revoked independently. ## What The Architecture Does Not Fix The original is honest about this and the honesty should survive the conversion, because a document that claimed the problem was solved would be wrong. The remaining work it names: 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. **That is a substantial list and none of it disappears.** The claim is narrower and better: those problems can now be solved **without first giving an unenrolled agent a high-authority identity.** Two items on that list deserve flagging because the corpus has already touched them. **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, so the return path needs its own answer rather than inheriting the ingress design. ## Why This Argument Is Worth Publishing Separately from the architecture, this document has value as an explanation, and it fits work already scoped. The identity site brief of 16 August proposed a thesis: that the industry answers agent identity for **agents you run**, through attestation, and has no answer for **agents you rent**, where attestation is impossible. This document supplies the mechanism behind that gap. **The reason rented agents have no identity is the bootstrap trap**, and the reason the workarounds persist is that the loop has no exit without a narrow ingress. So the two fit together: the site's thesis is the observation, and this is the explanation. Published together they are considerably stronger than either alone, and both are falsifiable, which is what the site is meant to be. ## What This Does Not Try To Be - **Not a cryptography problem.** The cryptography is settled; the choreography is not. - **Not a claim that the problem is solved.** A long list of remaining work, stated in the original. - **Not an argument for a better credential.** The fix is not needing one. - **Not theoretical.** The workarounds are the mechanism behind documented incidents. - **Not the architecture.** This is why it is shaped as it is. ## Honest Tensions | Tension | Note | |---------|------| | A narrow ingress | It removes the loop and it is an unauthenticated door, which trades an identity problem for an abuse problem | | Proof of possession as the first step | It is free and checkable and it establishes nothing about trustworthiness, which readers will conflate | | The remaining list | It is honest and it is long enough that somebody may conclude nothing has been gained | | Publishing the argument | It is the explanation behind a thesis and it also maps the weaknesses of every current practice, including our own | | Key persistence for rented agents | The architecture assumes a key survives, and in a hosted session it may not | | Authority choreography as the frame | It is the right reframing and it moves the problem into a domain with fewer established answers | ## Open Questions | Question | Notes | |----------|-------| | 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, and the certificate has to get back | | 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 in the document and will not survive casual reading, so the interface must carry it | | Does the gradient need a fourth step? | Recognition and mandate may not cover attestation, which remains unavailable for rented agents | | Where does this get published? | It is the explanation behind an already-scoped thesis, and they are stronger together | ## Relationship To Previous Briefs | Date | Document | Relationship | |---|---|---| | 19 Aug | `v0.33.60__arch-brief__agent-enrolment-without-borrowed-authority-append-lane-is-the-narrow-door.md` | The architecture this justifies | | 6 Aug | `v0.33.56__arch-brief__sg-send-plugins-are-capability-grants-ambient-authority-is-the-injection-root-cause-instrument-before-enforcing.md` | Ambient authority and the confused deputy, established here first | | 16 Aug | `v0.33.59__strategy-brief__nhi-site-two-populations-industry-answers-only-agents-you-run.md` | The thesis this supplies the mechanism for | | 14 Aug | `v0.33.58__strategy-brief__sgit-serialised-pull-request-is-the-headline-publish-the-sample-vaults.md` | The over-broad token evidence and the open feature request | | 16 Aug | `v0.33.59__research-brief__shared-drives-for-agents-everything-runs-on-your-identity-segregation-not-scoping.md` | The finding that every option authenticates as you | --- ## Key Claims | # | Claim | |---|-------| | 1 | Generating a key is trivial; getting it recognised is the difficulty | | 2 | The difficulty is a loop, since every route to a trusted authority requires an identity the agent lacks | | 3 | Creating a key is not creating an identity, because an identity is a relationship somebody agreed to | | 4 | Every common workaround grants authority broader than the identity being created | | 5 | Two of those workarounds are the mechanism behind documented incidents rather than a theoretical concern | | 6 | Ambient authority is why a borrowed credential grants everything the lender could do | | 7 | The confused deputy is what an agent becomes when it holds authority the task did not need | | 8 | The constraint is transport rather than cryptography, which the original calls authority choreography | | 9 | The answer is a door narrow enough that walking through it requires nothing | | 10 | The gradient runs from key possession, to project recognition, to delegated mandate | | 11 | Recognition is a decision rather than a computation, so a signature is never an endorsement | | 12 | The remaining work is substantial, and the gain is that none of it needs a high-authority identity first | --- This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).