Inspiration
If an AI coding agent can read, write, run commands, and touch production, something outside the agent has to decide what's allowed. You can't put that decision inside the agent's own reasoning, because that's the exact thing you don't trust yet. A prompt telling the model "don't do risky stuff" is just a suggestion. A model that's smart enough eventually talks itself past it. We wanted an actual firewall, not a nicer prompt.
What it does
Custodian Guard for Codex sits between Codex and anything consequential it tries to do. Before a real action runs, Codex proposes it through an MCP tool called guard_action. The kernel looks at what the action actually is, not what Codex calls it, and decides: proceed, stop and ask a human, or deny outright.
Try to sneak a production deploy past it labeled as a harmless "read"? Doesn't work. It's reclassified by its real shape and escalated anyway. And escalation isn't permission. Codex can create a request, but only a human, outside the model's own tool access, can approve it: once, tied to that exact action, expiring automatically. Every decision gets written to a tamper-evident, hash-chained receipt.
One thing we think matters more than it sounds: Codex itself can't read that receipt log by default, not even its own history. If the agent could see everything it's been caught doing, it could learn the rules and route around them. So visibility is something a human operator grants, never a starting default.
How we built it
It's built on custodian-kernel, a policy engine that already existed before this week and doesn't know or care which agent it's protecting. What we built during Build Week is the Codex-specific piece on top: the MCP server, the risk classifier, the receipt chain, the approval flow, and the Codex plugin itself.
We built this with Codex the whole way through. It wrote the MCP server and the classifier, then we had it attack its own classifier with mislabeled and disguised commands to see what would slip through. What we found got fixed. The demo script that proves all of this (scripts/codex-guard-demo.py) needs zero credentials and makes zero network calls; anyone can run it and see the real behavior in about a minute.
Challenges we ran into
The kernel code this depends on was itself built this same week, and it had never been installed anywhere outside our own dev setup. Splitting this into its own installable package meant actually proving it worked from scratch, not just "it imports fine," but a genuinely fresh clone, fresh virtual environment, zero manual steps, full test suite green. That process caught three real bugs before they could've blocked anyone: a dependency pinned to a package version that didn't exist yet, a bundled credential library that had quietly never made it into the kernel package at all, and an install command that assumed python means python3, which isn't true everywhere.
Accomplishments we're proud of
The classifier holds up against adversarial mislabeling every time we've thrown it at, including in a real, live Codex session, not just scripted tests. The receipt chain is genuinely tamper-evident: change one byte in one old receipt and verification catches it immediately.
What we learned
Deterministic rules a model can't argue with are a stronger guardrail than a smarter model doing the judging; there's nothing for a prompt injection to talk its way around. And an audit log is only as trustworthy as who's allowed to read it. The same logic that says "the kernel decides, not the agent" should also say "the operator watches the log, not the thing being logged."
What's next
Getting Windows independently re-verified, extending the same enforcement to other coding agents (OpenCode already shares this core), and bringing every integration's receipts into one unified ledger instead of separate ones per adapter.
Log in or sign up for Devpost to join the conversation.