The execution broker, and why receipts are the third corner

A registry that records who a key belongs to and what it was permitted to do leaves out the most auditable event of all: what it actually did. This site does not own the execution layer — but a reader arriving at a key registry is usually trying to answer a question about something that happened, and the registry alone cannot answer it. So it is named here.

Three questions, three layers

   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 first two are what a registry publishes. The third is a different kind of control and a different product line — but the three only make sense together, and a site that shows two of them without naming the third is describing a triangle with a missing corner.

The shift: the agent never holds the credential

The example is exact. An agent may need to create one pull request containing changes to three approved files. The platform may only offer a token whose permissions permit substantially more. So the security system can say this agent may possess this token for five minutes, and cannot say this agent may perform exactly this operation, on this repository, in this workflow, at this stage, using these files, once.

This closes a boundary named three times

Three separate pieces of work reached the same edge from different directions, and each named it honestly as the limit of what that control could do:

Every one ends at the same place: an authorised party misusing authority it legitimately holds. A compromised agent can read its input, do something wrong, sign it correctly and pass it on — with every cryptographic check passing. This closes that gap by construction rather than by policy, because the agent does not perform the action at all.

The mandate as the authorisation object

A valid certificate proves a request came from a given agent. It proves nothing about whether that agent may perform the action. So the mandate carries: subject, issuer, service and instance, capability, resource, constraints, workflow and stage, environment, validity window, usage limit, and a signature. Verification checks the issuer signature, the subject, the requester's proof of possession, the requested action, and validity including revocation.

Encryption restricts who can read a mandate. The signature and subject binding establish who may exercise it.

That distinction is worth protecting because the two get conflated constantly — and conflating them produces somebody believing a mandate is safe because it is encrypted, when what makes it safe is that exercising it requires a private key the reader does not hold.

Receipts are the evidence chain

Every operation, successful or rejected, produces a signed receipt establishing that a named broker executed a named action for a named agent under a named mandate at a given time.

This creates an evidence chain rather than relying solely on mutable platform audit logs.

A receipt is a fact with provenance — produced by the party that performed the action rather than by the party being assessed, and it cannot be quietly amended afterwards. The more interesting use is forward rather than backward: a workflow stage that requires evidence the previous stage completed can consume the receipt directly, rather than trusting a status field somebody could set.

It works for rented agents, without attestation

The industry's answer to agent identity is attestation-based, which requires a workload you run. For an agent running inside a hosted assistant there is no answer at all — the two-populations thesis. This needs no attestation: it needs the agent to hold a key and present a mandate, and a hosted agent can do both.

The practical consequence is the one people actually want: you can let a hosted coding agent open a pull request without giving it repository write access, because it never holds a token. And an agent that never holds a credential cannot leak one, whatever is injected into it, because there is nothing in its context to exfiltrate.

The concentration risk, stated plainly

The broker holds every credential. That is the mechanism — it cannot execute against a service without a usable credential for it, and it holds them for every service and every tenant it serves. Applying the catastrophic-failure question:

That is the opposite property to everything else in this architecture, and it should be stated rather than left for a reader to notice. The design removes credentials from many agents by concentrating them in one place: a real and defensible trade, and not a reduction in total exposure. Three things follow.

• Self-hosting is the mitigation, not an upsell. A customer running their own broker has not handed their credentials to anybody. It should be a first-class requirement.
• The broker needs its own identity — so that an agent can refuse to send a mandate to a broker it does not recognise.
• The credential storage boundary is the most important engineering in the product. Everything else can be rebuilt; a credential store compromise cannot be undone.

Enforcement is interpretation, not proxying

A mandate carrying an allowed path list, a maximum changed-file count or a base branch requires understanding the request, not forwarding it. To check that a pull request touches only permitted paths, the broker must parse the diff; to check a file count, it must count. None of that is proxying.

So the broker is an interpreter, per provider, per capability — which is where the real engineering cost sits, and why the phasing argument is one provider, one capability, deeply, before any breadth. Adapters are maintenance rather than a build: every provider carries its own authentication, error semantics, rate limits and naming, all of which change underneath you, with the added burden that each capability's constraints must track the provider's request format as it evolves.

Independent check: the market has not closed this either

The acceptance test, worth reusing verbatim

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?

That is a better question than any feature list, because every clause is checkable against a real product. It is offered here as a tool for evaluating anything in this space — including whatever we build.

A note on the name

The source document calls this a Service Twin. This site calls it an execution broker, deliberately. A digital twin already means something specific in this corpus: the node where a graph meets reality, the thing facts attach to and obligations are assessed against. A digital twin represents a thing; this acts on one. Using one word for both would confuse readers who have met the first, and the confusion would land in security documentation. The rename costs nothing today.