Agents live where they run; C=US says who they are and what they may do
An agent should run in its native hosted environment: a Gemini agent on Google Cloud Run, an edge agent on Cloudflare Workers, a sensor agent on a farm's Raspberry Pi, a research agent in a CI pipeline. Its identity and its authority should not live there. They come from the c=US directory, and from a person whose identity is proofed through Utah's State-Endorsed Digital Identity (SEDI) program. This page sets out that architecture: what exists today, what is missing, and a first step.
Run the agent anywhere. Decide who it is, and what it may do, in one place.
The host proves which workload is running. The directory decides which agent that workload is, and which grants it holds. A SEDI-proofed person answers for it, and can stop it. Relying parties ask C=US before they act, and the host is told when to stop.
Where the agents run today
As of the evening of 11 October 2026 (US Eastern), from the deployment notes and the agent gateway's public status page, every C=US agent runs either on the cequs.com server or on the project owner's laptop. Only two act on a schedule.
| Agent | Runs on | Started by | Native home it could have |
|---|---|---|---|
architecture-review-001 | cequs.com; calls Google's Gemini API | A daily timer | Google Cloud Run, next to the model it calls |
sensor-relay-001 | cequs.com; reads a simulated sensor on Google Apps Script | A timer, every 15 minutes | The sensor's own device, once it can hold a key (a TPM) |
vt-maple-quality-001, qc-maple-quality-001 | The owner's laptop | By hand | The farm or warehouse, beside the Raman analyser |
research-intern-001, project-steward-001 | The owner's laptop | By hand | A CI pipeline, such as GitHub Actions |
tpm-agent-demo-001, claude | Clients on the laptop, checked by Cloudflare Workers at sugarbushagent.com | By hand | Already partly native: the Workers check C=US at the edge |
Keeping agents on the control plane's own server, or on one laptop, makes the demonstration easy to run but mixes two jobs. The server that decides authority should not also be the place every agent runs, and an agent's key should not sit on a laptop.
The shape
1. Identity: the host proves the workload, the directory names the agent
Every major hosting platform can already prove which workload is running, without a long-lived key copied onto it:
| Host | What it can prove | Example agent |
|---|---|---|
| Google Cloud Run | A Google-signed OpenID Connect token from the metadata server, naming the service's account and the audience it is for | The architecture review agent, beside the Gemini model it calls |
| Cloudflare Workers | A client certificate from Cloudflare's managed certificate authority, as agent.sugarbushagent.com already uses | The sugarbushagent.com edges |
| A farm device | A key held in a TPM, which cannot be copied off the device | The Brix reader and, later, grading at the farm |
| GitHub Actions | A GitHub-signed OpenID Connect token naming the repository, workflow and commit | The research intern and the project steward |
The missing piece is a token exchange at C=US, in the manner of OAuth token exchange (RFC 8693) or SPIFFE federation. The agent presents its host's proof; C=US checks it against that host's published keys; the directory maps the issuer and subject to exactly one agent entry, through a new attribute such as cequsWorkloadIdentity; and C=US returns a short-lived credential for the agent's wimse://cequs.com/agents/… identity. That credential could be the SD-JWT verifiable credential the gateway already issues at /credentials, or a certificate that lasts minutes rather than days.
The directory remains the only place that decides which workload is which agent. A workload the directory does not name gets nothing, however valid its host's token.
2. Authority: signals relying parties pull, and signals hosts are sent
- Pulled (works now). Before acting on an agent's request, a relying party asks the trust registry, which applies the same rule the gateway enforces, or checks a C=US credential that points back to it. A registry answer is good for 5 minutes, so a stop reaches everyone who asks within minutes. That rule's stop properties are proved with Z3.
- Sent (half built). C=US already receives signed kill signals from systems it trusts (OpenID Shared Signals, CAEP). It does not yet send them. To stop an agent at its source, C=US would act as a Shared Signals transmitter to each host, which could then scale the service to zero, revoke its token or switch it to a tighter, already-proved sandbox policy. As with every C=US signal, these could only take authority away. A host that cannot receive signals relies on short credential lifetimes instead.
3. The person: SEDI behind every agent
An agent is only as accountable as the person who answers for it. In this architecture that person's identity is proofed through Utah's State-Endorsed Digital Identity program. C=US acts as a verifier and relying party, never as the issuer: it records that the person is proofed, and a digest rather than the identifier itself. The chain of accountability then reads:
- a SEDI-proofed person,
- a dated grant they signed in the directory,
- the agent's workload identity on its host,
- each action, signed into the evidence log.
Because the person's passkey stop withdraws authority at C=US, it works wherever the agent runs.
4. Enforcement moves to where agents act
Once agents run on their own hosts, many of their actions no longer pass through the C=US gateway. Two things fill the gap:
- Relying parties that check C=US before they act, as the sugarbushagent.com edges already do.
- Deployment bindings filled from what the host can measure. The delegation demonstration already binds a deployment to its software, model, sandbox policy and guard policy digests, and refuses an agent whose request does not match. On a native host, those digests would come from the platform: a Cloud Run revision's image digest, a Worker's script, a TPM's measurements.
An action against a service that never asks C=US is outside its control. That limit is the same one the kill switch page states.
What exists and what does not
| Piece | Status | Where |
|---|---|---|
| Directory of agents, grants and accountable people | Works now | c=US and c=CA directories |
| Trust registry and SD-JWT credentials | Works now | trust-registry.html; the gateway's /credentials |
| Receiving kill signals; the person's passkey stop | Works now | Zero Trust; stop my agent |
| Stop properties of the decision rule | Proved | Formal methods: a Z3 model, tested against the code |
| Sandbox and guard policy digests in the deployment binding; guard proofs re-checked at registration | Local demonstration | The delegation demonstration |
| SEDI-proofed accountable person | Synthetic only | No SEDI conformance profile chosen |
| Token exchange from host proofs to C=US credentials | Built and tested; not deployed | Google Cloud Run tokens, advisory scopes only (2026-10-11); bound to the agent's key with DPoP and server nonces (2026-10-12) |
Workload identities in the directory (cequsWorkloadIdentity) | In the schema; not applied | The live directory needs a schema upgrade |
| Sending stop signals to hosts | Not built | — |
| Deployment digests measured by the host, not declared | Not built | — |
A first step: the review agent on Cloud Run
The architecture review agent is the natural pilot. It already calls Google's Gemini API, it acts once a day, and it can only propose. The steps:
- Run it as a Cloud Run job under its own service account, with its Nagini-verified guard unchanged.
- Record that service account in its directory entry as its workload identity.
- Build the token exchange for Google-signed tokens: check the token, find the one agent it names, return a short-lived credential. Built and tested on 2026-10-11, not yet deployed: the agent exchanges its Google ID token for a C=US access token lasting at most five minutes and bound to a key the agent makes for each run (DPoP), so a copied token is useless without that key; every request that presents it is decided again from the directory, so a stop refuses the next request.
- Submit proposals with that credential, and remove the agent's private key from cequs.com.
- Check that a stop by its accountable person still refuses it on the next run.
Limits
- A host's token proves the workload's account, not what it is running. A Cloud Run token names a service account, not the image; binding the image needs Google's Binary Authorization or the revision's metadata.
- Trusting a host's tokens means trusting that host's operator for workload identity. The directory limits the damage (a token maps to one agent and only its grants), but cannot remove that trust.
- Short credential lifetimes shrink, but do not close, the window between a stop and its effect on a host that does not receive signals.
- SEDI here is synthetic. Nothing on this page has been checked against real SEDI credentials.
Sources
- IETF RFC 8693, OAuth 2.0 Token Exchange (2020).
- SPIFFE: Secure Production Identity Framework for Everyone (CNCF).
- IETF WIMSE working group: Workload Identity in Multi-System Environments.
- OpenID Foundation Shared Signals working group: the Shared Signals Framework and CAEP.
- Trust over IP Trust Registry Query Protocol.
- Google Cloud: getting an ID token and Binary Authorization.
- Cloudflare: client certificates (mTLS).
- GitHub: security hardening with OpenID Connect.
- Utah SEDI Implementation Guide (0.1.0-draft).
- This project: the kill switch, the trust registry, state-endorsed identity, identity versus runtime.
Drafted by Claude Code (Claude Opus 5.5) at the project lead's request, 2026-10-11, from the project's own code, deployment notes and the agent gateway's public status page. The architecture is the project lead's direction; the design details are proposals and, except where marked, are not built or tested.