Zero Trust and how it is implemented
Zero Trust means no request is trusted because of where it comes from: not because it is inside a network, not because it came from a known address, and not because the same caller was trusted a minute ago. Every request has to prove who is making it and show that it is allowed, every time (NIST SP 800-207). For AI agents, which act on their own and at machine speed, this is the difference between a registry that records agents and one that controls them. Here is how C=US does it, starting with the part everyone has already used: the padlock in a browser.
Website TLS: only the server proves who it is
When you open https://cequs.com, TLS does two things. It encrypts the connection, and it lets the server prove its identity: it presents a certificate from a public certificate authority your browser already trusts, and signs part of the handshake with the matching private key. You, the client, prove nothing at this stage. The server learns who you are later, if at all, from a password, a cookie or a token sent inside the encrypted connection.
That later step is the weak point. A password can be phished; a session cookie or API token is a bearer credential: whoever holds a copy can use it, from anywhere, until it expires. For a person at a keyboard, extra factors and short sessions help. For an agent that runs unattended, a stored token is simply a secret on a disk.
Mutual TLS: both sides prove who they are
With mutual TLS (mTLS), the server also asks the client for a certificate, and the client must sign the handshake with its private key. A C=US agent connecting to agents.cequs.com does exactly that, before a single byte of its request is sent.
| A website (TLS) | A C=US agent (mutual TLS) | |
|---|---|---|
| Who proves identity in the handshake | Only the server | Both: the server, and the agent with its own certificate and key |
| Who vouches for the certificate | Any of the public CAs your browser trusts | Only the C=US agent CA (or, at the Cloudflare edge, a pinned issuer); the server trusts nothing else |
| What the client sends to identify itself | A password, cookie or token, later, inside the connection | Nothing that can be replayed: a signature that only its private key can make, during the handshake |
| If someone copies what is on the wire or on disk | A copied cookie or token works | A copied certificate is useless without the private key. Tested: an attacker with a copy of the TPM agent's certificate was refused in the handshake |
| Where the private key lives | The server's key on the server; the client has none | Generated where the agent runs, and kept there: on cequs.com, on a laptop, inside a TPM chip, or on a YubiKey |
| Protocol | Usually TLS 1.2 or 1.3 | TLS 1.3 only; the certificate is requested for the whole host name |
The handshake proves that the caller holds the key for a certificate the C=US CA issued. It says nothing about whether that caller should be allowed to do this, now. A valid certificate is authentication, not authorization.
What C=US checks on every request, after the handshake
The agent gateway re-decides every request from the live directory. It keeps no sessions and remembers nothing from the last request:
- Bound: the certificate's SHA-256 fingerprint is bound to exactly one registered agent, and the certificate names that agent (
wimse://cequs.com/agents/…). A certificate the CA issued but the directory never bound gets nowhere. - Active: the agent's status is
active. Suspending it takes effect on its very next request: tested live on 2026-10-09, with the agent's certificate still valid for six more days. - Not flagged elsewhere: no other system C=US trusts has sent a kill signal for the agent. Such a signal is an OpenID Shared Signals (CAEP) security event, signed by a transmitter whose key C=US pins and limited to the agents that transmitter may act on; the demonstration's only transmitter is a simulated LLM guardrail. A signal can only take authority away. A person lifts the suspension, and both are kept on record.
- Accountable: an identity-proofed person answers for the agent.
- Granted: a dated grant covers exactly the requested scope (to propose a grade, submit readings, or propose an improvement) and, for grading, the lot's jurisdiction. Registration alone grants nothing.
- Fail closed: if the directory cannot be read, the answer is no.
- Signed: the decision, allow or deny, is signed into a hash-chained log anyone can check.
The same rules answer the public trust registry, which other services rely on. The two Cloudflare services at sugarbushagent.com authenticate agents by mTLS themselves, then ask the registry, and accept only an answer signed by a pinned C=US key and at most five minutes old.
The kill switch: stopping an agent
The full explanation, with a diagram, is on the kill switch page.
An agent runs on someone else's machine: a farm laptop, a Raspberry Pi in a sugarhouse, a model at Google. C=US cannot reach in and end that program. What it can do is take away the agent's authority. Because every request is decided again from current records, a stop recorded now means the agent's next request is refused, wherever C=US is asked.
| Switch | What is changed | What stops | Status |
|---|---|---|---|
| End a grant | The grant's end date is set to now, or the grant is removed | One capability, such as grading in Vermont | Works now |
| Suspend the agent | The agent's directory status becomes suspended | Everything that agent does | Tested live 2026-10-09: refused on the next request, with its certificate still valid for six more days |
| Revoke the key | The certificate bound to the agent is removed or replaced | That certificate, even before it expires | Works now |
| Revoke the person | The accountable person's identity proofing is marked revoked | Every agent that person answers for | Works now |
| A kill signal from another system | A signed security event (OpenID Shared Signals: CAEP or RISC) arrives at https://cequs.com/ssf/events | The agent it names, until a person lifts the suspension | Drill 2026-10-10: 0.35 seconds from the signal to the trust registry answering "not authorized" |
| The accountable person stops it | The person the directory names as accountable confirms with their own passkey on the stop-my-agent page | One of their agents, or all of them, until the same person restarts it | Drill 2026-10-10: a stop of research-intern-001 was refused by the trust registry, its sibling agent stayed authorized, and the restart restored it |
Kill signals from other systems
Other systems often notice trouble first. An LLM guardrail may see an agent being prompt-injected, or a security monitor may flag a stolen key. They can tell C=US with an OpenID Shared Signals event. C=US accepts one only if all of these hold:
- it is signed by a transmitter whose key C=US has pinned in advance (keys are never fetched from the sender);
- it was issued in the last five minutes, and its ID has not been seen before, so a captured signal cannot be replayed;
- it names an agent that this transmitter is allowed to act on.
In the demonstration the one transmitter is a simulated LLM guardrail, which may suspend only the three advisory agents. In the 2026-10-10 drill it could not touch a grading agent: that signal was refused, and the grading agent stayed authorized.
A signal can take authority away. Nothing a signal says can grant or restore it: only a person lifts a suspension, and the suspension, the lift and every signal, accepted or refused, are signed into the evidence log. If the record of suspensions cannot be read, every request is refused.
Where a stop takes effect
- The agent gateway: grading, sensor readings and advisory proposals are refused.
- The trust registry: it answers "not authorized", and the sugarbushagent.com services, which ask it, refuse the agent too.
- Credentials: no new ones are issued. A verifier that checks the registry, as the credentials ask it to, sees the stop at once.
What a stop cannot do
- End the program: it can keep running on its own machine; it just cannot act through anything that asks C=US.
- Reach systems that never ask C=US: those never see the stop. A credential issued before the stop stays unexpired for up to 24 hours, so a verifier that only checks its signature will still accept it.
- Stop unregistered agents: C=US cannot stop an agent it does not know about.
Not built yet
- Stops for many agents at once: a model version or a whole jurisdiction, with two people approving.
- A government stop: the proposed federal AI Kill Switch Act is pending; this is where such a stop would plug in.
Short-lived certificates
A certificate is a promise with a date on it. The shorter the date, the less a stolen key or a forgotten agent is worth. C=US keeps its promises short:
| What | Lifetime in C=US | For comparison |
|---|---|---|
| Agent certificates | 7 days (renewed in one step; a daily check warns three days ahead) | Public website certificates: at most 200 days since March 2026, 100 days from March 2027, 47 days from March 2029 (CA/Browser Forum ballot SC-081); Let's Encrypt has offered optional 6-day certificates since January 2026 |
| Hardware-held agent keys | 30 days (TPM); about 90 days (a Cloudflare-issued certificate on a YubiKey) | Longer, because renewing touches hardware; the directory can still suspend them at any moment |
| A trust registry answer | 5 minutes | Comparable to a short-lived token, but signed and tied to a certificate |
| Authorization grants | Dated, currently to the end of 2026 | A grant can be ended early by suspending the agent or removing the grant |
Live: the certificates in use right now
Asking the trust registry for each registered agent's bound certificate…
| Agent | Certificate valid until | Time left |
|---|
Why so short, if the directory can suspend an agent instantly?
Because not everyone who sees a certificate asks the directory. A certificate can be copied into logs, backups and other systems; it can be checked by a service that only verifies the chain. Revocation lists are checked unevenly on the web, which is one reason Let's Encrypt gives for six-day certificates. A short lifetime is the backstop that needs no one to remember to check anything: it limits how long any copy, any mistake and any forgotten agent can last.
Are seven days too short?
The case for shorter: a stolen key is good for days, not months, and every renewal re-checks that the agent should still exist. The case for longer: every renewal is work (here it needs a hardware-key touch to rebind the certificate), an agent whose renewal is missed simply stops, and a key held in a TPM or a YubiKey is already hard to steal. Pick a lifetime and see what it would mean for C=US.
Choose a lifetime.
There is no single right answer. What would you choose for an agent with a key in a TPM, and for one with a key in a file? Would you want the same answer for an agent that can only propose as for one that could finalize?
Sources: NIST SP 800-207, Zero Trust Architecture; CA/Browser Forum ballot SC-081v3 (April 2025), summarized by DNSimple; Let's Encrypt, 6-day and IP certificates generally available (January 2026). C=US behavior: security/agent-gateway/gateway.py, deploy/agent-gateway/README.md.