In 2019 the global keyserver network was flooded with garbage signatures until importing a poisoned certificate broke your installation. Its own maintainer called it unsalvageable — and the cause was a design goal stated at the outset, not a bug. Anyone proposing a key registry now should be able to show they designed it with that history in hand. This site is that history, and the rules it produces, published before the registry exists.
Which third of the answer this site holds. Three sites carry one answer between them: nhi.sgit.ai states the problem (no identity for rented agents), this site holds the design (the rules, the mandate, the enrolment path, the registry pack), and sgit.ai/docs/pki documents the shipped commands the design operationalises. Page-to-page, not domain-to-domain — per the site access report that found the three thirds unjoined.
A key registry is usually approached as one problem. It is three, and they separate cleanly — which matters, because a system that answers only one of them and implies it answered all three is the failure mode worth avoiding.
| Question | What answers it | Kind of problem |
|---|---|---|
| Who is this agent? | Identity — a signed statement in a registry | A registry problem |
| What may it do? | Mandate — a separate statement, revoked separately | A delegation problem |
| Should that produce this effect, now, here? | Execution — a broker that holds the credential the agent never sees | A broker problem |
The third is a different product line and this site does not own it — but it is named here, because a reader arriving at a key registry is usually trying to answer a question about something that happened, and identity plus mandate cannot answer it. Recording who a key belongs to and what it was permitted to do leaves out the most auditable event of all.
The keypairs, the signing, the encryption to a named recipient and the contacts list already exist. The documentation says, in its own words, no revocation, no directory. Those two absences are precisely what a registry supplies.
sgit pki keygen makes two pairs — RSA-OAEP 4096 for encryption and ECDSA P-256 for signing. Encrypt to a fingerprint, sign, verify, keep contacts.
A compromised key cannot be withdrawn, and anybody verifying an old signature cannot tell whether the key was still good at the time.
Keys are exchanged out of band into a local contacts list. There is no answer to "what is the current key for this agent, and who says so".
Somebody already running these commands who has hit exactly those two walls. And it makes the keyserver history land harder — the last system that attempted both was destroyed by how it did them.
Read →The design goal that killed the network was append-only — a pattern this project uses in five places, and rightly. A documented catastrophe caused by a pattern you rely on deserves a precise resolution rather than a shrug. Here it is.
| Append-only, owner-writes | Append-only, anyone-writes | |
|---|---|---|
| Who may write to a record | Only its owner | Anybody |
| Can a stranger grow your record? | No | Without limit |
| Is every entry attributable? | Yes — signed by the owner | No — garbage is indistinguishable |
| Can something be withdrawn? | Yes — a signed append supersedes | Never — by design |
| Failure mode | A record grows slowly, in the owner's own hand | Destroyed the network |
Append-only is safe when a writer appends only to objects it owns, and fatal when anyone may append to somebody else's. The rule to carry forward is not "append-only" — it is the writer owns what it writes. The full argument, with sources →
Each one turns around a property the 2019 attack abused. Publishing them now is cheap; claiming them afterwards is impossible. If something ships that breaks one, this site is the evidence.
Turns around: anyone may append to anybody's certificate. This is the rule that carries the append-only pattern through the history intact.
Read → Rule 2Signed by the key being revoked. The record stays append-only, the revocation is self-authenticating, and what a key said before revocation stays checkable.
Read → Rule 3One poisoned key reached ~150,000 signatures because certificates had no limit. A stated parameter — with the honest cost that it will one day reject a legitimate record.
Read → Rule 4Which is what makes untrusted mirrors safe and the registry's contents portable — a reader verifies without trusting whoever served the bytes.
Read →Externally verifiable, and cited. Nothing on the failure page depends on trusting us — which is why it leads.
Two prominent contributors' certificates flooded with bogus signatures. Importing one broke a working installation in hard-to-debug ways; the recommended mitigation became to stop using the network entirely.
A key server could add information to a certificate but could never delete a certificate or anything in it — stated at the outset. Changing a goal of that magnitude means a fresh sheet of paper, not a patch.
The successor strips all third-party signatures and unverified identities. That stops the attack completely, and removes the web of trust with it — a trade to make deliberately rather than inherit.
A second obstacle, separate from the 2019 failure and just as load-bearing. Generating a keypair is trivial; getting it recognised requires reaching a trusted authority, every route to which requires authentication, which requires the identity the agent does not have. That is a loop, not a missing feature — and every common escape hands over authority broader than the identity being created.
The operator's credential, repository write access, a shared bot token, a vendor integration, a cloud credential, a project signing secret, a bespoke enrolment server. Every one solves transport by creating a larger identity problem.
Read → EvidenceA coding assistant holding a token scoped to every repository its developer had authorised. An unprivileged issue reaching CI secrets in three vendors' own repositories. The short-lived-token feature request still open.
Read → The reframingThe hardest part is not cryptography — it is the order in which claims are established. A system can use excellent cryptography and still have a weak bootstrap if the first instruction is to hand over a platform token.
Read → The exitAn append lane grants one capability: add an object to an inbox. It is shipped and account-less — a write needs a token in the body, no account, no access token — so the enrolment path is buildable rather than theoretical.
Read →Current systems give an agent your identity, and therefore all of your permissions. The registry separates two signed statements that revoke independently — a materially different position from a bearer token.
Identity: this key belongs to this agent. Mandate: this agent may do these things, until this date, on whose authority. Both checkable by a third party; the second revocable without touching the first.
Read → ComparisonA token's scope is knowable only to its issuer. A mandate's scope is published, so the party relying on it can see the limits of what it was given — and refuse work outside them.
Read → The cautionIt constrains what an agent may be authorised to do, not what it does within that authority. One control among several — it composes with observation and ceilings, it does not replace them.
Read → The third cornerIdentity says who, mandate says what may be done, and neither records what was actually done. A signed receipt is a fact with provenance — produced by the party that performed the action, not the party being assessed.
Read →The idea is old. What changed is that vaults supply the layer a key server used to have to build for itself: distribution (a published vault is readable from static hosting and mirrorable by anybody), custody without access (untrusted mirrors are safe by construction), and versioning (the state of a key at any past date is answerable natively). What vaults do not supply — the ownership rule, the size bound, signature checking — is the registry logic, and it is exactly the part that failed last time.
A registry with one organisation's agents in it is testable; a global one is a commitment. Steps 2 and 3 — the failure page and the rules — are done, and were done before anything was built.
Read → Honest tensionsSize bounds will one day reject a legitimate record. Fractal trust needs every store to declare its roots. Attestation is valuable and dangerous. Published, not buried.
Read → Open questionsStarting with the central one: does the registry accept third-party attestations at all? A documented failure on one side, no social trust on the other.
Read → Dev packEight documents: the leading brief, architecture, schemas, workflows, build order — plus the diagrams, the change control recording what v0.33.61 corrected, and a tabletop exercise that gives the four rules their first population.
Read → The sourceEverything here comes from one document, captured whole with its citations and readable in-page. The raw markdown stays the source of truth.
Read →A site arguing for provenance discipline owes a reader its own. PKI work here runs from a commit-impersonation incident in February 2026, through four changes of direction, past things that were built and retired and things fully specified and never coded — roughly 110 documents against 3,900 lines of code, and that ratio is itself the finding.
PKI as messaging → as provenance → as agent identity → as substrate. With the thirteen primary sources published verbatim, including the supply-chain ≅ agent-chain isomorphism drawn four months early.
Read → Prior artFive endpoints, duplicate-fingerprint rejection, soft delete and a hash-chained transparency log — shipped in February, superseded in June. Two of the four rules ran in production before they were written down.
Read → RedactedThe cross-reference review this rests on names a customer and findings against live code, so it is not published. A public edition is — and it states exactly what was removed and why.
Read →This site is published by the sgit project, which builds the vault layer the registry would be built on. So this is a participant publishing a design — stated here, upfront. The discipline applies lightly to the history, because those claims are externally verifiable, and heavily to the design, which is why the design is published as checkable rules before the thing exists. And we publish where our own approach loses: vaults do not supply the registry, do not solve attestation, and a mandate constrains authority rather than behaviour.