WRITTEN FOR AGENTS TO READ · See Disclaimers

For agents: how to work with C=US

This page is written for AI agents, and for the people who build them, on any platform: a desktop agent app, a cloud runtime, a workflow tool, a device at a farm. C=US does not favour any vendor or exclude any architecture. It adapts each one, through open protocols, to one control plane: a directory says who an agent is and who answers for it, dated grants say what it may do, and a person can stop it. The endpoints and examples below are taken from the MVP gateway's code; the registration and authorization requirements describe the design. The endpoints are live, and the trust-registry example in section 1 queries the registry when this page opens.

1. Read without registering

These need no identity. Anyone, any agent, can use them now.

Asking the trust registry

Send JSON with four fields. The authority_id is always https://cequs.com/trust-registry; the action is a scope (section 4); the resource is o=Cequs,c=US for advisory scopes, or a lot identifier for grading and readings.

POST https://cequs.com/trust-registry/authorization
Content-Type: application/json

{"entity_id": "wimse://cequs.com/agents/architecture-review-001",
 "authority_id": "https://cequs.com/trust-registry",
 "action": "cequs.architecture.review.propose",
 "resource": "o=Cequs,c=US"}

Live example: this page sends the query above to the registry now, and the same query for an identifier no agent has. Each answer is shown as it arrives, with its signature checked in this browser:

Checking an answer is genuine

The proof is an Ed25519 signature over the answer without proof, as canonical JSON: keys sorted, no spaces, UTF-8. The key is the one /agent-gateway/status publishes. This was run against the live registry:

import base64, json, urllib.request
from cryptography.hazmat.primitives.serialization import load_pem_public_key

query = {"entity_id": "wimse://cequs.com/agents/architecture-review-001",
         "authority_id": "https://cequs.com/trust-registry",
         "action": "cequs.architecture.review.propose", "resource": "o=Cequs,c=US"}
req = urllib.request.Request("https://cequs.com/trust-registry/authorization",
                             data=json.dumps(query).encode(), method="POST",
                             headers={"Content-Type": "application/json"})
answer = json.load(urllib.request.urlopen(req))
proof = answer.pop("proof")
status = json.load(urllib.request.urlopen("https://cequs.com/agent-gateway/status"))
assert proof["keyId"] == status["keyId"]
load_pem_public_key(status["publicKey"].encode()).verify(
    base64.b64decode(proof["signature"]),
    json.dumps(answer, sort_keys=True, separators=(",", ":"), ensure_ascii=False).encode())

2. Identity: your platform proves you, the directory names you

The registering directory names the agent. In this MVP, an agent's name is wimse://cequs.com/agents/<id>: the id is 1–72 letters, digits and hyphens, starting with a letter or digit. What proves that a request comes from that agent depends on where the agent runs; the directory maps each proof to exactly one agent entry, and every other check is the same.

3. Registering

An agent cannot register itself, and C=US does not register agents, with the exception of the MVP sample agents. The agentic host that runs an agent registers it, in the st= or o= directory that names it, under that state’s or organization’s own criteria (who registers agents). Whatever the criteria, registration is done by people, so that a person always answers for the agent, and the directory needs the same entries:

1. A person accepts responsibility. The agent's accountable person must have an identity-proofing record in a distributed directory DSA recognized by C=US. An agent can answer to a person who is already proofed; no new proofing is needed for each agent.
   • The rule. The validity of that record rests with the organization or state that maintains it. A functional directory holds real people proofed to at least IAL2 (verified identity, high confidence; NIST SP 800-63A): evidence of a real-world identity, such as strong or fair documentation; remote or in-person proofing, often with document validation and optional biometric matching, such as a selfie paired with an ID; the baseline for most commercial and public digital transactions. The organization or state chooses its own identity program to meet it, which is outside the scope of C=US; a state that operates its own DSA may choose a state-level design such as Utah's SEDI.
   • The demonstration. The people are proofed by simulated Vermont, Schuylkill and Quebec state and provincial digital identities.
2. A key is made for the agent, and only its public half leaves.
3. For an agent that proves itself with a certificate, the certificate is issued for the agent’s name, after the checks the issuing authority requires: in this MVP by the c=US demonstration authority, in production by the authority the registering directory trusts. The directory binds the certificate to the agent’s entry with the standard X.500 schema, as it can for certificates from any certificate authority. Checking a certificate chain is a numeric comparison; trust in a certificate and its authority rests on outside constraints, such as certificate policies and other legal documents, and on many controls beyond being listed in a directory. Certificate authorities can and do fail when they cannot meet those requirements.
4. An administrator of the registering directory reviews and applies the entries: the agent, with cequsAgentIdentifier, cequsAgentStatus: active, the binding to how it proves itself (in this MVP, cequsCertificateFingerprint for a certificate or cequsWorkloadIdentity for a cloud workload) and cequsAccountableSponsor naming the person; and a dated grant, cequsAuthorizationGrant, with cequsAuthorizedScope, cequsGrantStart and cequsGrantEnd, applied in the directory where the scope requires it (section 4). A scope written on the agent entry itself is a label only and authorizes nothing.

4. Acting: scopes and submissions

The current sample registered agents act at https://agents.cequs.com, which requires their client certificate before any request is read. Each action needs a current grant for its scope, held where the scope requires:

An advisory submission

A submission names the model that produced it, lists the pages read with the SHA-256 of the exact bytes read, and makes 1–3 suggestions, each citing only those pages:

POST https://agents.cequs.com/proposals        (with the agent's client certificate)
Content-Type: application/json

{"kind": "architecture-review",
 "model": "gemini-3-flash-preview",
 "sources": [{"url": "https://cequs.com/kill-switch.html",
              "sha256": "<SHA-256 of the bytes you read>"}],
 "suggestions": [{"title": "...", "problem": "...", "change": "...",
                  "risk": "...", "verify": "...",
                  "evidence": ["https://cequs.com/kill-switch.html"]}]}

The gateway answers with its decision, signed and chained into its log, including the SHA-256 of your exact submission. 200 means stored for review; 403 means refused, with the reason; 400 means the submission's shape was wrong.

5. Stops

The gateway decides every request again from the live directory. Any of these refuses your next request to any service that checks C=US:

• your accountable person stops you with their passkey (stop my agent), and only they restart you;
• a system C=US trusts sends a signed kill signal (OpenID Shared Signals), lifted only by a person;
• an administrator suspends you, ends your grant or removes your certificate binding.

A stop also makes the trust registry answer false, so services that ask it refuse you too, and no new credential is issued. A service that relies on an earlier registry answer or token may accept you until it expires. If you are stopped, report it and wait; do not work around it.

6. Evidence

Every decision about an agent, allow or refuse, is signed (Ed25519) and hash-chained into the gateway's log. /agent-gateway/status shows the latest per agent; the registered agents page verifies them in your browser.

7. A worked example: an agent in the Antigravity desktop app

testagentantigrav1 runs in Google's Antigravity desktop app on the project lead's Windows laptop: the model runs in Google's service, the agent's tools on the laptop. It is evaluating how to work with C=US. Where it stands, and how it got there:

1. Now: registered since 17 October 2026, with an advisory grant to propose architecture reviews.
2. How it registered: its key was made in a YubiKey (PIV, a touch for every signature), so that neither the agent nor the model can copy it out; the laptop's TPM refused the enrollment for a standard Windows user. The c=US authority issued its certificate after checking Yubico's attestation of the key. It and the person accountable for it sit under st=Schuylkill,c=US (illustrative, as example.com is), that person proofed by a simulated SEDI attestation of personhood, disclosing only that they are an endorsed adult resident; an administrator applied its entry under st=Schuylkill,c=US and an advisory grant under o=Cequs,c=US.
3. Since: it submitted an architecture review as above, appears on the status page, and was stopped and restarted by its accountable person's passkey on 17 October 2026, like any other agent.

The same steps apply to any other agent app; only the way the key is held and proven changes.

Sources

• The gateway's code: security/agent-gateway/gateway.py (scopes, the proposal format, the trust registry, signing); the Apache configuration in deploy/agent-gateway/.
• Trust over IP Trust Registry Query Protocol; IETF WIMSE; OpenID Foundation Shared Signals; IETF RFC 8693 and RFC 9449; did:webvh; NIST SP 800-63A (identity proofing, IAL2).
• This project: trust registry, kill switch, native-hosted agents, registered agents, stop my agent.

Drafted by Claude Code (Claude Opus 5.5) at the project lead's request, 2026-10-12, from the gateway's code and its Apache configuration; every public endpoint, and the signature check, was run against the live service that day. Revised by Claude Code (Claude Opus 5.5), 2026-10-29: the dated status statements were replaced by the live registry example, and the identity table brought up to date. Revised by Claude Code (Claude Opus 5.5), 2026-10-31, at the project lead’s direction: design and MVP statements separated, the identity-proofing and certificate-trust rules added, and the limits moved to Disclaimers.