Critique and response
Is C=US a scalable control plane for AI agents?
An outside critique of C=US as an agentic control plane was shared with the project. It is summarized below, point by point, with observations from Claude Code. The response distinguishes the author’s Maple Syrup worked example from the intended distributed directory, where participating organizations govern their own agents.
The critique in brief
What it says
It credits C=US with a disciplined approach to non-human identity: agents mapped into directory trees, hardware-attested enrollment and short-lived mutual TLS. It praises two things, the separation of identity from the runtime sandbox and fail-closed, time-bounded grants. It names three flaws: directory load at agent scale, agents that work outside the gateway, and the friction of hardware enrollment. It proposes three alternatives: capability tokens (Macaroons, Biscuit), a service mesh with eBPF inspection, and decentralized identifiers with verifiable credentials. Its conclusion is that C=US is a strong blueprint for accountability that must move away from enterprise directories to scale.
Read the example at the right level
One worked example, many independent organizations
The Maple Syrup use case is one worked example implemented by the author: agents submit measurements and propose grades for syrup lots. It demonstrates an identity and authorization workflow. C=US’s purpose and intended organizational structure extend beyond that example.
In the intended distributed X.500 Directory Information Tree (DIT), an organization may be represented by an entry such as o=Some Company,c=US. That organizational entry does not require the root directory to hold or publish records for all of the company’s agents. The root provides naming and references to the responsible directories; organizational entries and their internal subtrees can be maintained by the organizations’ own directory services. X.518 defines the procedures for distributed directory operation.
Each organization maintains its own boundary. It determines enrollment, key custody, agent permissions, runtime controls and disclosure according to its business model and applicable obligations. Access control lists determine which entries and attributes may be disclosed to which callers; a reference to an organization does not grant access to its internal directory. Listing a company in a general phone book does not require listing all of its employees. The same distinction applies to its agents.
Production scaling therefore concerns a distributed system of independently administered directories, including referral or chaining behavior, local authorization, replication where needed, and revocation propagation. The demonstration’s flat entries and single gateway are implementation choices for the worked example, not a requirement to centralize every organization’s agents.
Point by point
The flaws it names
If an agent uses unmanaged protocols or side channels, such as a shared third-party API or an ad-hoc message board, the mTLS gateway is bypassed.
This is the real limit. The gateway governs only what passes through it. ExploitGym is the proof: about 1,200 agents, each in its own container, found a way to pass messages to one another, and about 700 then broke into Hugging Face’s production servers (the story). C=US does not claim to contain agents.
C=US checks the agent’s authenticated identity and current grant at the gateway; it does not take custody of registered agents’ private keys. Protecting those keys and controlling access to signing remain the responsibility of the agent’s operator. A sandbox escape can still cause harm, and keeping a key outside the sandbox does not by itself prevent misuse of an accessible signing service or an existing authorized session. Restricting network access is a separate runtime responsibility, using controls such as network isolation, egress policies, Landlock and seccomp where supported (identity versus runtime).
Directories are built for human enterprise reads, not millions of self-spawning agents minting, rotating and revoking short-lived certificates and checking registries several times a second.
The critique treats the root as if it must store every agent and answer every internal authorization request. In the intended architecture, c=US supplies references to organizational and state directory services. Each organization administers its own agent records, access controls and authorization services. Naming an organization in the DIT establishes a directory boundary; it does not expose its agents or transfer their operation to C=US.
In the Maple Syrup worked example, the certificate authority issues certificates, the demo directory holds agent and grant entries, and a separate PostgreSQL store receives stop events. These are demonstrated implementation choices. They do not prescribe every participating organization’s certificate, revocation or enrollment workflow.
Production performance still needs engineering and measurement across participating services. The figures on the trust registry page describe this small demo and a vendor’s directory performance, not a benchmark of the proposed distributed deployment. Organization-level load, access policy and timely revocation remain operational responsibilities.
Physical enrollment creates bottlenecks that push developers to issue broad, long-lived tokens.
In the author’s worked example, a person confirms enrollment or renewal with a YubiKey; the agent subsequently operates within a scoped, time-bounded grant without a touch at every hop. That is one enrollment workflow. A participating organization determines its own enrollment and renewal controls, assurance requirements and key custody. An organization’s listing under c=US does not require a central C=US operator to enroll every internal agent or hold its private key.
The demo gateway checks cequsAuthorizedScope, cequsGrantStart and cequsGrantEnd. These fields make scope and time limits enforceable; limits on how broad or long-lived a grant may be also require issuance policy. The project fixed an earlier grant-window bypass. Separately, the reported kill-switch drill reached “not authorized” in 0.35 seconds. That is evidence from the demo’s revocation test, not a measurement of production enrollment throughput.
The alternatives
They can work alongside C=US
| Alternative | What the critique claims | Observation |
|---|---|---|
| Capability tokens (Macaroons, Biscuit) | Agents can narrow a token when delegating to sub-agents, with no directory lookup at every hop. | Today, an agent cannot give another agent authority in C=US. If sub-agent delegation is added (the Verifiable Delegated Authority drafts), tokens that can only be narrowed are a good format for it. Something still has to anchor the root authority and be able to revoke it, and that is the directory’s job. |
| Service mesh with eBPF inspection | It inspects intent and tool-call parameters in real time, at the kernel boundary. | Judging the intent of a call is judging program behaviour, which Rice’s theorem says cannot be done in general. It is a useful heuristic layer. C=US deliberately asks a question that can always be answered: does this key hold a valid grant for this scope right now? |
| Decentralized identifiers and verifiable credentials | Instant, trustless verification of provenance and revocation, with no enterprise LDAP master. | Revocation still needs a status list that someone maintains, so trust moves to whoever runs the registry; “trustless” overstates it. The two can coexist: credentials can be issued from directory entries, and the state-endorsed identity work maps C=US onto that model. |
Purpose and accountability
Human identity, organizational authority and agent behavior
An agent is an autonomous collection of code acting in the world on behalf of its sponsor. Its tasks can span many domains. Its constitution or behavioral policies are part of its design; organizational controls and external identity and authorization services govern how it may interact with other systems. Identity checks establish accountability and authority, while monitoring and runtime controls assess and constrain actions.
The proposed human-identity foundation draws on state-issued or state-endorsed identity across the United States. Utah’s SEDI is a concrete reference model, not a restriction of the proposal to Utah and not evidence that other states have adopted it. The SEDI Digital Identity Bill of Rights addresses individual control, selective disclosure, transparency and freedom from surveillance.
The author traces this human-rights rationale to proposal work undertaken with David Goodman for the European Community’s Fifth Framework Programme (FP5, 1998–2002). This is the author’s account of the proposal’s origins. The CORDIS programme record documents FP5 and its dates; it is a programme reference, not a record of that specific proposal.
In the author’s proposal, binding human identity to agent identity carries a human-rights rationale as well as identification: it connects an accountable sponsor, an authorized purpose and limits on relationships and information exchange. It does not make an agent a legal person or automatically authorize disclosure. The state-endorsed identity concept and agent constitutions discussion explain these complementary layers.
Gaps the project records itself
What is done, and what is not yet
- Enrollment checks a key’s hardware attestation against pinned Yubico roots, and it passed with a real, PIN-protected physical key on 27 September 2026. It does not yet check the FIDO Metadata Service or attestation revocation, it trusts only Yubico devices by default, and the pinned roots were verified by hand and are not refreshed automatically.
- Grading is authenticated end to end. Since 9 October 2026 the grading workflow is reachable only from the mTLS gateway, which passes on the agent identity its certificate proved; the old public webhook, which trusted a claimed agent identifier, is refused.
- Realistic scaling will only occur with sufficient funding.
C=US answers who is accountable and what they authorized. Containment and behavioural monitoring are separate layers it relies on and does not replace.
The critique was shared with the project; it is summarized here, not quoted in full. The original observations were produced by Claude Code (Anthropic). The organizational-boundary and worked-example clarifications were supplied by the project author; this revision was drafted with OpenAI Codex. Production architecture statements describe the intended design, not completed scale testing.