Agentic control plane · identity and runtime, together
An agent needs to prove who it is, and separately needs to be contained. One system does not do the other's job.
This page walks through a real, hands-on result: running the maple sugar grading agent's actual identity check through NVIDIA's OpenShell sandbox runtime, watching it fail in an informative way, and what that failure revealed about how C=US's identity layer and a runtime-containment layer like OpenShell actually divide the work.
Nothing here is a claim that OpenShell is built for or endorses C=US, or the reverse. This describes one local demonstration, run once, on one machine, with one project's own code. It is offered as a concrete architecture note, not a product endorsement.
Two different questions
“Who is this, and are they allowed?” is not the same question as “what can this process actually touch?”
Every agent in the C=US model answers two separate questions before it can act, and until this demo they had always been described separately, not run against each other. Putting a real runtime sandbox and a real identity check in the same request made the boundary between them concrete instead of theoretical.
C=US: identity and authorization
An agent holds a state-verified identity — wimse://cequs.com/agents/vt-maple-quality-001, bound to an mTLS certificate and a directory entry (cn=maple-quality-agent,ou=AI-Agents,o=Cequs,c=US).
A policy gateway checks that certificate against a directory-backed grant: is this specific identity authorized for this specific scope (maple.lot.grade.propose), right now, inside a valid grant window? This is a decision about who is asking and what they're allowed to claim — it has no opinion about what the agent's own code can do on the machine it runs on.
OpenShell: runtime containment
OpenShell enforces, at the kernel level (Landlock LSM, seccomp BPF), what a running process can actually do — which files it can read, what network it can reach, what syscalls it can make. It doesn't know or care about C=US's directory; it only cares about the process in front of it.
In this demo, that included something we didn't expect going in: OpenShell would not let any process — not even the agent's own, legitimate, authorized process — read raw private-key content off disk. Not denied with an error. The bytes just didn't come through.
What actually happened
The identity check needed the one thing the sandbox wouldn't hand over
The maple grading agent's real client script authenticates to a policy gateway using its own mTLS private key — that's the whole mechanism C=US's identity layer rests on. Running that script inside an OpenShell sandbox produced this sequence:
- Sandbox created, agent code uploaded
A fresh OpenShell sandbox, with the agent's actual authentication script, its certificate, and its private key placed on disk exactly as the demo expects.
- Certificate reads: normal
The public certificate read back fine — correct size, correct
-----BEGIN CERTIFICATE-----header, no issue. Nothing about the sandbox interfered with public material. - Private key reads: silently empty
wc -creported the real file size (246 bytes, matching the original exactly). Reading the same file's content — bycat, or by the agent's own Python process trying to load it for the TLS handshake — returned nothing usable. The file was there. Its content wasn't. - Conclusion, tested and confirmed
This wasn't file corruption (the byte count matched) and it wasn't a naming coincidence (renaming the directory away from anything that looked like “private” didn't change the result). OpenShell was declining to hand a sandboxed process the actual bytes of anything that pattern-matches as private key material — for any process, regardless of what it was authorized to do.
Why this is the correct outcome, not a bug to route around
Standard PKI practice says only the private key needs protecting — and that's exactly the line OpenShell drew
Everything else the agent's process touched inside the sandbox worked normally: its own script, the directory-grant fixture, the certificate, the CA certificate. Only the private key was ever affected. That's a narrowly, correctly scoped protection — not OpenShell being overcautious about the whole demo, just about the one thing in it that actually needed protecting.
The fix wasn’t to fight the sandbox until it gave up the key. It was to run the identity-proving step where raw key access is normal and expected — outside the general-purpose sandbox — and let OpenShell's containment apply to everything else an agent's own reasoning and logic might do. That split is already a working principle elsewhere in this project: the demo's own authentication script is commented “the browser never receives this key” for exactly the same reason, one layer up the stack.
| Layer | Answers | Should hold the private key? |
|---|---|---|
| C=US directory + policy gateway | Is this identity authorized for this specific action, right now? | The gateway holds its own key to prove its identity in the handshake — never the agent's. |
| Agent's identity-proving step | Prove this specific agent is who it claims to be. | Yes — this is the one place raw key access is the actual job, run in a narrow, purpose-built context. |
| OpenShell sandbox (agent reasoning/logic) | What can this process's own code actually do on this machine? | No — and per this demo, it won't let you, even if you try. |
The resulting control pattern
What an agentic control plane looks like when both layers are doing their own job
- Register: an agent's identity, sponsor, and declared scope live in the directory (C=US) before it ever runs — this doesn't change based on where the code executes.
- Contain: the agent's own reasoning and logic run inside a sandboxed runtime (OpenShell or equivalent) that constrains file access, network egress, and syscalls, independent of what the identity layer would otherwise permit.
- Prove identity narrowly: when the agent needs to authenticate, that step happens through a purpose-built path with real key access — not inside the general sandbox, and not by handing the sandbox a raw key file.
- Authorize centrally: a policy gateway checks the proven identity against the directory's live grant — scope, status, and time window — and returns a single allow/deny, the same way regardless of which runtime the agent used.
- Log what happened, not what was claimed: the decision record (like the one captured above) reflects the gateway's own check, not anything the agent asserted about itself.
Sources and further reading
What this page draws on
- NVIDIA/OpenShell (GitHub): the runtime used in this demo, Apache 2.0, announced at GTC San Jose 2026.
- OpenShell default policy documentation: the declarative file-access baseline referenced above.
- Control-plane architectures vs. real compliance standards: a follow-up comparison of OpenShell, c=US, and three other candidates against NIST, OWASP, and ISO/CIS standards — including OpenShell and c=US scored together, not as competitors.
- C=US technical FAQ: what the mTLS and directory demonstration does and doesn't establish.
- Maple quality demo: the live, captured result of the identity check described on this page.