# Agent Enrolment Without Borrowed Authority: Start With A Keypair, Post Through An Append Lane, And Keep Identity Separate From Mandate

**version** v0.33.60
**date** 19 August 2026
**from** Human (project lead)
**to** Engineering, Architecture, AppSec

**type** Architecture brief

*First of 19 August. Converted from a document produced in a voice session with a different assistant, restructured into the corpus format with its substance preserved. Where it aligns with or extends positions already held here, that is noted rather than silently merged. Proposals throughout; nothing described is shipped.*

---

## What This Is

An enrolment architecture that lets an agent obtain a project-recognised identity while starting from nothing but a keypair, and the reason that constraint is the whole design: **the desired initial state is an agent possessing computation, a source of randomness and its own newly generated private key, and nothing else, meaning no repository credential, no project token, no certificate authority key, no vault key and no administrator identity, because every one of those would grant authority far broader than the identity being created; the agent signs a canonical enrolment request over its own public key, which proves possession of the corresponding private key and proves nothing else, since whether the project should trust the agent remains an issuer policy decision made afterwards rather than something a signature can establish; delivery uses a project append lane, a managed transport outside the commit history with a small operation set, which is deliberately the narrowest possible ingress, since the capability it grants is to add an object to an inbox and specifically not to read that inbox, alter it or reach anything else, and that is the sixth instance of the write-only channel this corpus adopted as its house pattern; a trusted processor holding the certificate authority key reads the inbox, applies policy, issues a certificate and writes the result to a registry, which means the authority that matters never leaves the trusted side and the untrusted side never holds more than its own key; identity and mandate are kept as separate signed statements, so that what an agent is and what it is permitted to do are issued, revoked and reasoned about independently, which is the position this corpus reached separately on 16 August; and the registry is fractal, with registries recognising other registries, which works and requires each to declare which roots it accepts or the trust graph becomes unevaluable.** It is the first document of 19 August (cross-ref: the v0.33.59 PKI site brief, the v0.33.59 NHI site brief, the v0.33.59 shared drives research, the v0.33.56 plugins brief, and the v0.33.59 relay pattern brief). New contributions from the corpus side: **the append lane identified as the sixth write-only channel, the observation that this mechanism works for rented agents where nothing else does, the registry design constrained by the keyserver failure, and the boundary between what proof of possession establishes and what it does not.**

## The Initial State Is The Design

Everything else follows from what the agent is allowed to start with.

```
   UNKNOWN AGENT
     computation
     randomness
     its own newly generated private key
     ------------------------------------
     and nothing else
```

Explicitly **not** required at the outset: a repository credential, repository read or write authority, a project token, the certificate authority's private key, the vault key, or an administrator identity.

The reason to be strict about this is not purity. **Every item on that list grants authority broader than the identity being created**, which means the usual bootstrap makes the security position worse rather than better, and the companion brief on the bootstrap trap sets out why in detail.

The property being sought is narrow and worth stating exactly: possession of this private key lets the agent act **as itself**, rather than as the project or as the human operator. That is the difference between an identity and a borrowed credential.

## The Enrolment Request

The agent constructs a canonical request and signs it with the key being enrolled. At minimum it carries:

| Field | Purpose |
|---|---|
| Type and version | So the format can change |
| Project | Which project is being asked |
| Subject public key and fingerprint | What is being enrolled |
| Requested identity | An optional label and agent type |
| Requested mandate | An optional role and scope |
| Created at, and a nonce | Freshness and replay resistance |
| Proof of possession | A signature over the canonical request |

**What the signature proves is narrow and should be stated as such**: the submitter controls the private key corresponding to the public key being enrolled. That is proof of possession and nothing more.

**What it does not prove is that the project should trust the agent.** Trust is a policy decision made by the issuer afterwards. Conflating the two is the most likely way to misread this design, and the original document is careful about it.

Two things worth adding from the corpus's own experience. **The nonce is not optional**, since the relay pattern work of 16 August found that replay protection needs a nonce or sequence number inside the signed payload and is easily left out. And **the canonical form must be specified precisely**, because a signature over an ambiguously serialised object is a signature over whatever the verifier happens to reconstruct.

## The Append Lane Is The Narrow Door

The delivery mechanism, and it is the part that makes the whole thing possible.

The enrolment request is delivered through a project append lane: a managed transport outside the commit history, with a small operation set covering configure, write, list, fetch, mark processed and purge.

**The capability granted to the agent is to add an object to an inbox.** Not to read that inbox, not to alter what is there, not to reach anything else in the project. That is the smallest useful grant, and it is why the bootstrap does not require borrowing a larger identity.

**This is the sixth instance of the same pattern in this corpus**, after write-only telemetry, the staging folder for issues, the usage event ledger, the vault inbox and the relay channels. It was named the house pattern on 2 August and the rule stated then applies unchanged: a component that must communicate defaults to a channel it can write and cannot read, and anything needing read access has to justify it.

Worth being explicit about the consequence: **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 certificate authority. The blast radius of the ingress is a queue that needs draining, which is the correct shape for a public door.

## The Trusted Side

The processing side holds everything that matters and is deliberately not reachable from the ingress.

| Component | Holds | Does |
|---|---|---|
| **Enrolment inbox** | Submitted requests | Receives, nothing else |
| **Trusted processor** | Read access to the inbox | Verifies signatures, applies policy |
| **Certificate authority** | The issuing key | Signs certificates |
| **Registry** | Issued identities and mandates | Publishes what has been recognised |

The division that matters: **the untrusted side never holds more than its own key, and the trusted side never exposes the issuing key to anything reachable from outside.**

That is the same referee-and-player separation the corpus reached for the vault kernel on 6 August, and for the same reason: enforcement belongs at a layer that cannot be bypassed by the thing being enforced.

## Identity And Mandate Stay Separate

The design keeps these as distinct signed statements, and this corpus arrived at the same conclusion independently on 16 August, which is worth recording because agreement from two directions is evidence.

| Statement | Says | Revoked |
|---|---|---|
| **Identity** | This key is this agent | When the key is compromised |
| **Mandate** | This agent may do these things, until this date, on whose authority | When the permission changes |

Two consequences make the separation worth its cost.

**They revoke independently.** An agent whose permissions change does not need a new identity, and an agent whose key is compromised does not lose the record of what it was permitted to do.

**And a mandate is checkable by a third party.** A bearer token tells a recipient only that the holder has it. A signed mandate tells them what was granted, by whom, and until when, and they can verify it without asking the issuer.

The limit stated on 16 August applies here too and should travel with the design: **a mandate constrains what an agent may be authorised to do, not what it does within that authority.** It is one control among several.

## This Works For Rented Agents, Which Nothing Else Does

A connection worth making explicitly, because it is the strongest argument for this architecture and it comes from research done three days earlier.

The survey of 16 August found that the industry's mature answer to agent identity is attestation-based, and attestation requires a workload you run. For **agents you rent**, meaning those running inside a hosted assistant or coding tool, nothing works: you cannot install an attestation agent, cannot verify the workload, and the only lever is the credential you hand over. The research found every available option authenticates as **you**, with no per-agent identity, no attribution and no cryptographic scoping.

**This architecture requires none of the things a rented agent cannot provide.** It needs computation, randomness, a private key and the ability to make one request. A hosted agent has all four.

That is a genuine gap being addressed rather than a reimplementation of an existing answer, and it should be stated carefully rather than overclaimed. What it establishes is that **a specific key made these requests and holds this mandate.** It does not establish what software that key is running inside, which is exactly what attestation provides and this does not. **Those are different guarantees**, and the honest position is that this offers attribution without attestation.

For many purposes attribution is the thing actually wanted, and for some it is not.

## The Registry, With A Known Failure To Avoid

The registry publishes what has been recognised, and the corpus has a directly relevant caution from 16 August.

The global key server network was destroyed in 2019 by an attack that abused three properties: unlimited signatures per certificate, universal rights to append to anybody's certificate, and no way to distinguish a legitimate signature from garbage. It could not be repaired because the inability to delete was a stated design goal.

**Three rules follow and they should be built in rather than added later:**

**Only the owner writes to their own record.** This is what the keyserver lacked, and it is the difference between an append-only channel that is a guarantee and one that is an attack surface.

**Revocation is an appended statement signed by the key being revoked**, not a deletion. That preserves append-only and supplies withdrawal, which is the supersede-rather-than-delete rule the corpus settled on 9 August.

**And records are size-bounded**, since unlimited attachment was the third abused property.

The architecture's own revocation section is compatible with all three and should state them explicitly, because a registry that gets this wrong fails in a way that cannot be fixed afterwards.

## Fractal Registries Need Declared Roots

The design proposes registries recognising other registries, which matches the corpus's fractal pattern elsewhere and needs one thing named.

**A fractal trust structure requires roots.** A key is trustworthy because something already trusted vouches for it, and in a nested arrangement each registry must declare **which roots it accepts**, or the graph is unevaluable by anybody trying to verify a chain.

That is the same point raised on 16 August about names being identities in the relay pattern: **who may be a root is a privileged decision** and needs a stated answer, even if the answer is that it is set once at setup.

The private case is the easier one and probably the more valuable commercially: an organisation running its own registry for its own agents has a bounded trust problem and an obvious buyer.

## What Phase One Should Prove

The original proposes a milestone sequence and the shape is right. Restated as the question each milestone answers:

| Milestone | Answers |
|---|---|
| Canonical enrolment object | Can two implementations agree on what was signed? |
| Enrolment client | Can an agent produce a valid request from nothing? |
| Append lane | Can it deliver without holding any other credential? |
| Trusted processor | Can the trusted side verify and decide without exposing the issuing key? |
| Registry | Can a third party check what was recognised? |
| Mandates | Can permission be granted and revoked without touching identity? |
| First attributable action | **Can somebody verify who did something, afterwards?** |

The last is the success criterion, and it is the right one because it is the only one a person outside the system can evaluate.

**Worth adding a milestone zero**, from the corpus's own discipline: decide what the honest claim is at each stage. Before the registry exists, a signature supports *the same key made these requests*, which is real and useful. It does not support *this named agent* until the registry can resolve the key. Stating that as it changes prevents the claim drifting ahead of the mechanism.

## What This Does Not Try To Be

- **Not attestation.** It proves key possession, not what software holds the key.
- **Not a trust decision.** Proof of possession is not grounds for recognition; policy is.
- **Not a general ingress.** The append lane grants adding to an inbox and nothing else.
- **Not one statement.** Identity and mandate are separate and revoke independently.
- **Not a key server.** Only the owner writes their own record, and revocation is a signed append.

## Honest Tensions

| Tension | Note |
|---------|------|
| Attribution without attestation | It is the thing rented agents can actually provide and it is a weaker guarantee than the industry's answer, so the difference must be stated |
| A public append lane | It is what removes the bootstrap trap and it is an unauthenticated door that will need spam and rate controls |
| Identity and mandate separated | It is the right model and it doubles the number of objects to issue, revoke and reason about |
| Fractal registries | The structure is powerful and every registry must declare its roots or nobody can evaluate a chain |
| Proof of possession | It is cheap and unambiguous and it is routinely mistaken for evidence of trustworthiness |
| Phase one scope | Seven milestones is a real project, and the success criterion is a single verifiable action |

## Open Questions

| Question | Notes |
|----------|-------|
| What is the canonical serialisation? | A signature over an ambiguous encoding is a signature over nothing |
| How is the append lane protected from flooding? | It is deliberately unauthenticated, so rate limiting and proof of work are the available levers |
| Where does the issuing key live? | The corpus recorded on 16 August that platform secret storage is not encrypted by default |
| How does an agent receive its certificate back? | The return path, which is the one direction the write-only lane does not cover |
| Who may be a trust root? | A privileged decision needing a stated answer even if it is set once |
| What is the honest claim at each phase? | It changes as the registry arrives, and stating it prevents drift |
| Does a rented agent persist its key between sessions? | If not, every session is a new identity, which changes what a mandate can mean |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 16 Aug | `v0.33.59__strategy-brief__pki-site-keyserver-failure-is-the-design-input-owner-writes-own-record.md` | The registry rules and the identity-mandate split, reached independently |
| 16 Aug | `v0.33.59__strategy-brief__nhi-site-two-populations-industry-answers-only-agents-you-run.md` | The rented-agent gap this addresses |
| 16 Aug | `v0.33.59__research-brief__shared-drives-for-agents-everything-runs-on-your-identity-segregation-not-scoping.md` | The finding that nothing available supports per-agent keys |
| 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, which the bootstrap trap is an instance of |
| 16 Aug | `v0.33.59__arch-brief__relay-pattern-encryption-signing-and-ordering-are-three-mechanisms.md` | Per-agent keys, replay protection, and names as identities |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | The agent starts with computation, randomness and its own key, and nothing else |
| 2 | Every credential omitted from that list would grant authority broader than the identity being created |
| 3 | The signature proves possession of the private key and proves nothing about trustworthiness |
| 4 | Trust is an issuer policy decision made afterwards, and conflating the two misreads the design |
| 5 | The append lane grants adding to an inbox, not reading it, which is the sixth write-only channel here |
| 6 | A hostile agent can therefore add junk to a queue and reach nothing else |
| 7 | The issuing key never leaves the trusted side, which is the referee-and-player separation again |
| 8 | Identity and mandate are separate statements that revoke independently and are third-party checkable |
| 9 | This works for rented agents, which the 16 August research found nothing else does |
| 10 | It offers attribution without attestation, and the difference must be stated rather than blurred |
| 11 | The registry must enforce owner-writes-own-record, signed revocation and size bounds, per the 2019 failure |
| 12 | Fractal registries require each to declare which roots it accepts, or the trust graph is unevaluable |

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).