# Agent Identity, Mandate And Execution: What The Site Has, What It Is Missing, And Independent Confirmation That The Gap Is Real **version** v0.33.60 **date** 19 August 2026 **from** Human (project lead) **to** The sgit.ai site agent, Product, Engineering **type** Briefing pack, leading brief *Read this first. Eight briefs and one unconverted reference document follow in five folders. The reference is market research produced by a different assistant and is included as supplied, because its finding is an independent check on the argument the rest of the pack makes.* --- ## What This Pack Is For Two things. **A review of the identity registry site**, with what to add, in `01-the-site-review/`. **And the material that review draws on**, which is a week of work that reached a three-layer picture nobody set out to build: ``` WHO IS THIS AGENT? identity a registry problem WHAT MAY IT DO? mandate a delegation problem SHOULD THAT PRODUCE THIS EFFECT, NOW, HERE? execution a broker problem ``` The site currently answers the first. **The pack is mostly about the other two.** ## The Headline For The Site Four recommendations, in order of what they change. **The site answers whose key this is and not what the key may do.** Identity and mandate are separate signed statements that revoke independently, and a mandate is checkable by a third party where a bearer token is not. That is the largest gap and the most useful page to add. **It does not explain how a key gets in.** The bootstrap trap is the most linkable argument in the set: an unknown agent must reach a trusted authority, every route requires authentication, and authentication requires the identity it lacks. Every escape hands over something larger. That argument explains why agent key registries do not exist, and it pairs directly with the network page's existing claim about handing over a broad credential and hoping. **The registry is the missing half of a shipped feature**, and this is the strongest available reframing. The site's own PKI page states that the shipped commands have **no revocation and no directory**. Those two absences are exactly what a registry supplies. That gives a concrete user, a bounded scope, and makes the keyserver history land harder, because the last system that attempted both was destroyed by how it did them. **And reuse the capability model rather than inventing one.** Four capabilities are already implemented with the server holding only hashes. A second authorisation model in the same platform is a second thing to get wrong. ## What Changed This Week Worth knowing before reading, because two documents in this pack were partly superseded within days. **The append lane is shipped and account-less.** A write requires a token in the body, no account and no access token, and returns a blind acknowledgement. Two briefs here treat that channel as something to be built. It exists, which makes the enrolment architecture a materially smaller project than its milestones suggest. **And the shipped cryptography is not what the source material says.** Keypair generation produces **RSA-OAEP 4096 for encryption and ECDSA P-256 for signing**. Any document naming X25519 or Ed25519 is wrong, and the site now states the correct primitives explicitly. **The lane address derivation remains proposed.** No shipped command emits it, so the token is agreed out of band today. The site's own instruction is the one to follow: do not code against the derivation. ## The Reference Document, And Why It Is Here `05-reference-unconverted/` holds market research produced by a different assistant on the execution layer. **It is included as supplied**, with its own formatting and citation markers intact, because converting it would obscure that it is an independent source rather than corpus work. **Its finding is the reason it belongs in this pack.** It concludes that a market is forming around exactly the architecture described here, and that **no generally available product implements the whole model**. The convergence is happening from two directions: several products solve the credential boundary, keeping the provider secret away from the agent, and several newer ones solve parts of the authority boundary, with signed mandates, approval and receipts. What it did not find is the combination: **a portable signed mandate, followed by broker-side semantic execution, followed by a signed receipt from the party that actually performed the effect.** That matters for two reasons. **It is an independent check on a claim made in this pack.** The execution brief argues that this closes a boundary three earlier briefs each named as the limit of their control. The research says the market has not closed it either. **And it is falsifiable in a useful way.** It names products, so anybody can check. It also proposes a specific acceptance test worth reusing verbatim when evaluating anything in this space: can an agent holding no token request one pull request, constrained by an independently issued authorisation object covering repository, branch, exact path set, file count, workflow stage and single use, with those arguments enforced by the broker rather than trusted from the caller, and a signed receipt an offline third party can validate? **Two cautions on using it.** Its assessment of specific products is a snapshot on a stated date and will age, which is the dating discipline this corpus applies to any comparison. And it is written to a brief rather than as neutral research, so its whitespace conclusion should be read as a hypothesis somebody could disprove rather than as a finding. ## One Naming Decision Outstanding The execution layer is called a twin in its source document. **Twin already means something specific here**: the node where a graph meets reality, the thing facts attach to and obligations are assessed against, used throughout the risk work. A digital twin **represents** a thing. This **acts on** one. Using one word for both will confuse readers who have met the first, and the confusion lands in security documentation. Broker, execution broker or mandate broker all describe it and none is taken. The decision costs nothing today and is the third collision of this kind caught in this corpus. ## Reading Order | Order | Folder | Why | |---|---|---| | 1 | This document | The three layers and the four recommendations | | 2 | `01-the-site-review` | What to add, and the stated limitation on how it was produced | | 3 | `02-identity-and-enrolment` | Why registries are hard, the enrolment path, and what already ships | | 4 | `03-the-execution-layer` | The layer above identity and mandate | | 5 | `05-reference-unconverted` | Independent confirmation, and an acceptance test worth reusing | | 6 | `04-foundations` | The scoping briefs the rest builds on | ## Contents | Folder | Documents | Covers | |---|---|---| | `01-the-site-review` | 1 | What the site has, the mandate gap, the reframing, and a stated limitation on the review itself | | `02-identity-and-enrolment` | 3 | The bootstrap trap; enrolment starting from a keypair and nothing else; the shipped append surface with five corrections | | `03-the-execution-layer` | 1 | Credential never reaches the agent, mandates, receipts, and the concentration risk that creates | | `04-foundations` | 3 | The keyserver failure and registry rules; the two populations of agent; per-agent keys and their three mechanisms | | `05-reference-unconverted` | 1 | Market research on the execution layer, as supplied, with its whitespace finding and acceptance test | ## Three Things Worth Not Losing **Encryption restricts who may read a mandate; the signature and subject binding establish who may exercise it.** One line, and it prevents the confusion a key registry exists to prevent. **A signature proves possession of a private key and proves nothing about trustworthiness.** Trust is a policy decision made afterwards, and conflating the two is the most likely way to misread any of this. **And a mandate constrains what an agent may be authorised to do, not what it does within that authority.** The execution layer is what closes that, and it closes it by holding the credential rather than by policy. --- ## Key Points | # | Point | |---|-------| | 1 | The work reached three layers: identity, mandate, and whether a delegation should produce this effect now | | 2 | The site answers the first and not the second or third | | 3 | Identity and mandate are separate statements that revoke independently | | 4 | The bootstrap trap explains why agent key registries do not exist and is the most linkable argument here | | 5 | The registry is the missing half of a shipped feature that has no revocation and no directory | | 6 | Reuse the four-capability model rather than adding a second authorisation model | | 7 | The append lane is shipped and account-less, making the enrolment path smaller than its briefs suggest | | 8 | The shipped cryptography is RSA-OAEP 4096 and ECDSA P-256, not X25519 or Ed25519 | | 9 | The lane address derivation is proposed, and no shipped command emits it | | 10 | Independent research finds the market converging from two directions and nobody closing the gap | | 11 | Its acceptance test is worth reusing verbatim when evaluating any product in this space | | 12 | The execution layer needs renaming, because twin already means something specific here | --- This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).