# Service Twin: The Agent Never Holds The Credential, Which Closes The One Boundary Capability And Sequence Controls Could Not Reach **version** v0.33.60 **date** 19 August 2026 **from** Human (project lead) **to** Engineering, Architecture, AppSec, Strategy **type** Architecture brief *Fourth 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 closes a gap this corpus has named repeatedly, that is drawn out; where it creates a concentration risk the original does not foreground, that is added. A naming collision is flagged.* --- ## What This Is An execution broker that performs actions against external services on an agent's behalf, so the agent never receives the service credential, and the reason that matters more than it first appears: **the shift is that the unit of delegation stops being credential access and becomes authorised action, since the agent presents a cryptographic identity, a signed mandate, the specific action and the contextual evidence that mandate requires, and the broker verifies all of it, performs only the permitted operation using credentials held inside its own boundary, and returns a signed receipt; the problem it addresses is one that short-lived credentials, just-in-time access, workload identity and gateway policy do not solve, because all of them eventually hand the agent a credential, and from that moment the agent's effective authority is bounded by the target platform's permission granularity rather than by the business operation, so a system can say this agent may hold this token for five minutes and cannot say this agent may perform exactly this operation, on this resource, at this workflow stage, once; the corpus has hit the resulting boundary three separate times and named it each time, since capability grants constrain what a component may touch and not what it does with it, the kernel state machine constrains which actions occur and not what they carry, and the relay pattern constrains which agent acts at which step and not what that agent does within its step, and this closes exactly that gap because the agent does not perform the action at all; two things the original states deserve keeping verbatim, that encryption and authorisation must remain separate concepts since encryption restricts who may read a mandate while the signature and subject binding establish who may exercise it, and that receipts create an evidence chain rather than relying on mutable platform audit logs; two things it does not foreground need adding, of which the first is that the broker becomes the highest-value target in the estate because it must hold usable credentials, which inverts the catastrophic failure property the rest of the architecture depends on, and the second is that enforcing a constraint such as an allowed path list requires understanding the operation rather than proxying it, so the broker is an interpreter per provider per capability rather than a gateway; and the name collides, because twin already means something specific in this corpus.** It is the fourth document of 19 August (cross-ref: the v0.33.60 enrolment architecture, the v0.33.59 relay pattern brief, the v0.33.56 plugins brief, the v0.33.59 NHI site brief, and the v0.33.56 token gateway brief). New contributions from the corpus side: **the boundary this closes named across three prior briefs, the concentration risk stated, enforcement identified as interpretation rather than proxying, the rented-agent argument, and the naming collision.** ## The Shift The original's framing, which is the clearest statement of what changes. ``` TRADITIONAL SERVICE TWIN agent receives credential agent sends mandate and request | | v v external service the broker | | agent may exercise whatever executes only the approved the credential and the API operation, using credentials permit the agent never sees ``` **The unit of delegation moves from credential access to authorised action.** That is worth stating precisely because it is the whole product. Every other mechanism in this space improves how a credential is issued, scoped or expired. This removes the credential from the agent entirely. ## The Problem The Existing Improvements Do Not Solve The original's diagnosis is right and worth keeping in its own terms. Non-human identity, short-lived credentials, just-in-time access, rotation, secret injection, workload identity, policy enforcement and gateway products are all genuine improvements. **They also all eventually hand the agent a credential.** Once that happens, the agent's effective authority is bounded by **the target platform's permission granularity**, not by the operation anybody intended. 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. **What remains is a hope**, and the original names it: we hope the agent does not use the credential for anything beyond the intended action. The corpus has the evidence for how that hope fares, from 14 August: one coding assistant held a token scoped to every repository its developer had authorised, and a disclosure showed an unprivileged issue reaching pipeline secrets in three vendors' own repositories. ## This Closes A Boundary The Corpus Has Named Three Times The most important connection, and the reason this document matters beyond its own argument. Three briefs here have reached the same edge from different directions, and each named it honestly as the limit of what that control could do: | Brief | Control | Stated limit | |---|---|---| | 6 Aug, plugins | Capability grants | Constrains what a component may **touch**, not what it does with it | | 6 Aug, vault kernel | Plan-then-execute | Constrains **which actions occur**, not what arguments they carry | | 16 Aug, relay pattern | Per-agent keys | Constrains **which agent acts when**, not what that agent does within its step | Every one of those ends at the same place: **an authorised party misusing authority it legitimately holds.** The relay brief said so explicitly, that 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, and it closes it by construction rather than by policy.** The agent does not perform the action. It asks for one, and something else decides whether to perform it and then performs it within constraints the agent cannot exceed, because the agent has no means of acting directly. That is a genuinely different kind of control from the other three, and it is the member of the set that was missing. Worth stating in those terms, since three briefs have already told readers where their control stops. ## The Mandate, And One Distinction To Keep The mandate is the authorisation object, and the original is precise about why identity is not enough: a valid certificate proves a request came from a given agent, and proves nothing about whether that agent may do the thing. The mandate carries subject, issuer, service and instance, capability, resource, constraints, workflow and stage, environment, validity window, usage limit, and a signature. The verification checks the issuer signature, the subject, the requester's proof of possession, the requested action, and validity including revocation. **One distinction in the original should be preserved verbatim in any implementation:** > Encryption restricts who can read a mandate. The signature and subject binding establish who may exercise it. That is worth protecting because the two get conflated constantly, and conflating them produces a system where somebody believes 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 have. The corpus made the same separation on 16 August when the relay pattern's three mechanisms were untangled: encryption is confidentiality, signing is attribution, and neither is ordering. **This is the same discipline applied to authorisation.** ## Receipts Are The Evidence Chain The original's strongest secondary idea, and it connects to a thread running through this corpus. 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. **The line worth keeping is the original's own**: this creates an evidence chain rather than relying solely on mutable platform audit logs. That is the same argument made on 14 August about published artefacts carrying their own history, and on 6 August about payment receipts proving who authorised something and for what purpose. **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 original also notes receipts can become inputs to later workflow stages, which is the more interesting use: **a 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 Worth drawing out because it addresses the gap the corpus documented on 16 August. That research found the industry's answer to agent identity is attestation-based, which requires a workload you run, and that for agents running inside a hosted assistant there is no answer at all: every option authenticates as you, with no per-agent identity, no attribution and no scoping. **This needs no attestation.** It needs the agent to hold a key and present a mandate. A hosted agent can do both. And 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. That also disposes of the failure mode the disclosures describe. **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 honest limit is unchanged from the enrolment work: this establishes that a specific key presented a specific mandate. It does not establish what software that key is running inside. **Attribution without attestation**, again, and for many purposes attribution is what was wanted. ## The Concentration Risk The Original Does Not Foreground The thing to add, because it inverts a property the rest of the architecture depends on. **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. Apply the catastrophic failure principle from 16 August, which asks what a total compromise of a component discloses: | Component | Total compromise yields | |---|---| | The vault | Ciphertext and the shape of the estate | | **The broker** | **Every credential it holds, usable immediately** | **That is the opposite property**, and it should be stated plainly rather than left for a reader to notice. The architecture removes credentials from many agents by concentrating them in one place, which is a real and defensible trade and is not a reduction in total exposure. Three things follow. **The deployment models matter more than they look.** The original lists hosted multi-tenant, dedicated tenant, customer cloud and fully self-hosted. That is not a commercial menu; it is **the mitigation**, because a customer running their own broker has not handed their credentials to anybody. The self-hosted option should be treated as a first-class requirement rather than an enterprise upsell. **The broker's own identity matters for the same reason.** The original says it should have one, and the reason is stronger than verification: **an agent should be able to refuse to send a mandate to a broker it does not recognise.** **And the security boundary around credential storage is the product's most important engineering.** Everything else can be rebuilt; a credential store compromise cannot be undone. ## Enforcement Is Interpretation, Not Proxying The second thing to add, and it is where the real engineering cost sits. The mandate carries constraints such as an allowed path list, a maximum number of changed files, or a base branch. **Enforcing those 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. To check that a change targets a permitted branch, it must read the request structure. None of that is proxying. So the broker is **an interpreter, per provider, per capability**, and each capability needs its constraints implemented in terms of that provider's specific request format. Two consequences worth planning for. **The capability catalogue is a semantic mapping problem.** An abstract action name has to map onto a provider operation, and composite capabilities compound it. That mapping is where meaning is lost, and it will need the same care the corpus applied to concepts and labels on 6 August. **And adapters are maintenance rather than a build.** The token gateway brief of 6 August made this point about routing to model providers: every provider carries its own authentication, error semantics, rate limits and naming, all of which change. The same applies here, with the additional burden that each capability's constraints must track the provider's request format as it evolves. That argues strongly for the original's own phasing: **one provider, one capability, deeply**, before breadth. ## The Name Collides Flagged because it is cheap now and expensive later, and it is the third such collision caught in this corpus. **Twin already means something specific here.** The grounding work established a digital twin as the point where a graph meets reality: the node representing a real system, to which facts attach and against which obligations are assessed. It appears throughout the risk work and the worked example of 2 August. A Service Twin is not that. **A digital twin represents a thing. A Service Twin acts on one.** Those are different enough that using one word for both will confuse a reader who has met the first, and the confusion will land in security documentation. The precedent is the plugin collision caught on 14 August and the folder-name collision caught on 16 August. The pattern is the same: a generic word claimed for a system purpose, colliding with an existing specific meaning. Alternatives worth considering: **broker**, **execution broker**, or **mandate broker**, all of which describe what it does and none of which is already in use here. The decision costs nothing today. ## The Economics Are Buildable Now The original proposes on-demand, pay-per-execution and micropayments. Worth noting that this became practical since July. The payments work of 6 August established a settlement protocol with sub-cent transactions, no account required, and a scheme for when the price is not known in advance. **A per-execution charge is exactly the shape that supports**, and it is what card rails cannot serve. It also fits the receipt model neatly: an execution produces a receipt, and the receipt is the billable record. **The same artefact serves audit and billing**, which is a rare alignment. ## Phasing The original's four phases are the right shape and the ordering argument is worth stating: **one provider, one capability, end to end, before any breadth.** The reason is the interpretation problem above. Breadth multiplies adapters and constraint implementations, and nothing is learned twice. A single capability taken all the way through identity, mandate, constraint enforcement, execution and receipt will surface every hard part once. The first success criterion should be the one that matches the corpus's standard: **can a third party verify, afterwards, that a specific agent caused a specific effect under a specific mandate**, using only the receipt. ## What This Does Not Try To Be - **Not a credential manager.** Credentials never reach the agent at all. - **Not a proxy.** Enforcing constraints requires interpreting requests per provider and capability. - **Not a reduction in total exposure.** It concentrates credentials, which is a trade rather than a saving. - **Not attestation.** It proves a key presented a mandate, not what software holds the key. - **Not part of the vault.** A complementary execution plane; the vault stays state, identity and messaging. ## Honest Tensions | Tension | Note | |---------|------| | Concentration | It removes credentials from many agents by holding them all in one place, which is defensible and must be stated | | Self-hosting as mitigation | It is the answer to concentration and it is also the deployment mode with the least commercial leverage | | Interpretation per capability | Real enforcement requires it and it makes every new capability a piece of engineering rather than configuration | | Adapters | Provider neutrality is the ambition and each provider is a maintenance commitment that changes underneath you | | Receipts as evidence | They are stronger than platform logs and they only mean something if somebody checks them | | The name | It communicates instantly and it collides with an established meaning in this corpus | ## Open Questions | Question | Notes | |----------|-------| | What is the credential storage boundary? | The most important engineering in the product, and the one failure that cannot be undone | | Can an agent verify which broker it is talking to? | It should be able to refuse an unrecognised one | | Which capability goes first? | One provider, one capability, all the way through, including constraint enforcement | | How are constraints expressed generically? | They are provider-specific in practice, and a generic schema will leak provider detail | | Does a receipt feed the next workflow stage automatically? | It is the more interesting use and it needs a defined consumption path | | Is the name changed before it ships? | Cheap now, and the third collision of this kind here | | What happens when a provider changes its request format? | Constraint enforcement breaks silently unless something tests it | ## Relationship To Previous Briefs | Date | Document | Relationship | |---|---|---| | 16 Aug | `v0.33.59__arch-brief__relay-pattern-encryption-signing-and-ordering-are-three-mechanisms.md` | The boundary this closes, stated there as what an authorised agent does within its step | | 6 Aug | `v0.33.56__arch-brief__sg-send-plugins-are-capability-grants-ambient-authority-is-the-injection-root-cause-instrument-before-enforcing.md` | Capability grants constraining what may be touched but not what is done | | 19 Aug | `v0.33.60__arch-brief__agent-enrolment-without-borrowed-authority-append-lane-is-the-narrow-door.md` | The identity and mandate this consumes | | 16 Aug | `v0.33.59__strategy-brief__nhi-site-two-populations-industry-answers-only-agents-you-run.md` | The rented-agent gap, addressed here without attestation | | 6 Aug | `v0.33.56__arch-brief__sg-send-token-gateway-resale-prohibited-in-line-forced-append-and-settle.md` | Provider adapters as maintenance, and the settlement rail that makes per-execution charging practical | --- ## Key Claims | # | Claim | |---|-------| | 1 | The unit of delegation moves from credential access to authorised action | | 2 | Existing improvements still hand the agent a credential, after which authority is bounded by the platform's granularity | | 3 | What remains is a hope, and the corpus has documented how that hope fares | | 4 | Three prior briefs named the same boundary: an authorised party misusing authority it holds | | 5 | This closes it by construction, because the agent does not perform the action | | 6 | Encryption restricts who may read a mandate; the signature and subject binding establish who may exercise it | | 7 | Receipts create an evidence chain rather than relying on mutable platform logs, and can feed later stages | | 8 | It works for rented agents without attestation, and an agent holding no credential cannot leak one | | 9 | The broker holds every credential, which inverts the catastrophic failure property elsewhere in the architecture | | 10 | Self-hosting is therefore the mitigation rather than an enterprise option | | 11 | Enforcing constraints requires interpreting requests, so this is an interpreter per provider per capability | | 12 | The name collides with the established meaning of twin in this corpus | --- This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).