Kastra Enforces Policies for Claude Code, Codex, and Codex

Policy enforcement for Claude Code, Codex, and Codex is the Show HN project Kastra, built by Fernando and a co-builder for developers running Claude Code, Anthropic's coding agent, Codex, Anysphere's AI code editor, and Codex, OpenAI's coding agent and CLI. It deals with the awkward moment when an agent is about to run a real tool call, like a database command, and nobody has encoded whether that action is allowed. The takeaway for Codex users is simple: use Codex to review code changes, but put dangerous tools behind deterministic checks before execution, not after the chat looks convincing. That is the practical core behind an openai codex cli review code changes workflow too: review the diff, then verify what the agent can actually touch.

What Kastra actually intercepts

Kastra sits in the path between an AI coding agent and the tools it wants to call. According to the project page, it intercepts agent tool calls and evaluates them against deterministic policies before they execute.

Runtime authorization is a pre-execution decision about whether a specific tool call is allowed right now. It is different from asking the model to “be careful.” The check happens at the boundary where shell commands, database calls, MCP tools, or other actions leave the chat and touch the real world.

The story behind the project is easy to understand. The builders said they started after a Codex agent almost ran a destructive SQL statement against a production database. They caught it, but the scary part was not the SQL syntax. The scary part was that the stack had no hard answer to “is this agent allowed to do that?”

That is why the project landed with developers. It names the missing layer between helpful agent and dangerous operator.

Why the Hacker News thread got lively

The Hacker News reaction was not just “cool tool.” A lot of the discussion circled around a sharper objection: why was an agent anywhere near production access in the first place?

That objection is fair. Sandboxing is still the first move. Short-lived credentials, isolated workspaces, read-only defaults, and separate permissions for orchestrators and worker agents all matter.

Kastra’s useful claim is narrower. Sandboxes reduce the blast radius, while policy checks decide whether a specific action should run at all. Those are complementary controls, not substitutes.

A concrete example makes the distinction clearer. A sandbox can keep a Codex agent inside a dev container. A policy layer can still block DELETE FROM customers when the requested database tool points at production, or require a human handoff before a write-capable MCP server is used.

The trap is treating chat instructions as permission boundaries. “Never touch prod” in a prompt is a good convention. It is not authorization.

Use policy checks around Codex review

A Codex review works best when it has two loops: review the code diff, then review the actions the agent wants to take. The first catches bad patches. The second catches bad tool use.

For a practical Codex CLI workflow, start with repository instructions in AGENTS.md, then verify with ordinary developer commands after Codex changes the tree. Keep the repo rule small and blunt:

# AGENTS.md
- Never execute SQL against production databases.
- Treat MCP tools named prod, billing, payments, customers, or admin as high-risk.
- For schema or data changes, produce a migration plan and rollback plan before suggesting commands.
- Prefer read-only inspection commands unless a human explicitly asks for a write.

Then run the boring loop that good engineers already trust:

git diff --stat
git diff
npm test
npm run lint

Ask Codex to explain the risk in the diff, not just summarize what it changed. A useful openai codex cli review code changes pass asks: what files changed, what behavior changed, what external systems are touched, and what command or MCP call would be risky if executed automatically.

The trap is letting a clean diff distract you from a dangerous next step. A migration file can be correct and still be unsafe to apply against the wrong database.

For more Codex-specific workflow patterns, keep the local review loop close to the related training topic, especially when you are mixing AGENTS.md rules, CLI sessions, and MCP access.

Know when Kastra is worth trying

Kastra is most interesting when agents have access to tools that can mutate shared state. Databases, cloud consoles, billing systems, customer records, and write-capable MCP servers are the obvious cases.

It may be overkill for a local-only repo where the agent can edit files, run tests, and do nothing else. If the worst realistic outcome is a bad patch in a branch, Git and code review are already strong boundaries.

The middle ground is where most teams live. A Codex agent starts local, then someone adds a GitHub MCP server, a database helper, a deployment script, or a private docs connector. Each integration makes the agent more useful and less hypothetical.

This is the same tension developers keep raising in agent sandbox debates: the interesting tools are exactly the ones you do not want called casually. The related discussion in Ask HN: What Agent Sandboxes Are Missing is useful context if you are deciding where sandboxing ends and runtime checks begin.

Try it safely: a Codex review checklist

Use this checklist before giving a Codex agent access to any tool that can write, deploy, delete, charge, email, or change permissions.

Codex code review and tool-call checklist

Diff review
- [ ] I inspected `git diff --stat` and the full diff.
- [ ] Tests and lint run locally, or I know exactly why they do not.
- [ ] Codex explained behavior changes, not only file names.
- [ ] Migrations include rollback notes or a safe revert path.

Tool boundary review
- [ ] Every MCP server is labeled read-only or write-capable.
- [ ] Production databases are not reachable from the agent session.
- [ ] Destructive commands require an explicit human approval step.
- [ ] Secrets are scoped to the smallest environment possible.
- [ ] The agent cannot reuse long-lived credentials after the task.

Policy review
- [ ] High-risk tool names are covered by deterministic rules.
- [ ] Database writes are blocked unless the environment is non-production.
- [ ] Deployments, billing changes, and permission changes are separate approvals.
- [ ] The policy fails closed when context is missing.

Keep this checklist next to your Codex review, not inside a vague “AI safety” doc. The closer it is to the diff, the more likely someone will use it.

Common questions

• Does Kastra replace sandboxing?

  No. Kastra-style runtime authorization should sit beside sandboxing, not replace it. A sandbox limits what an agent can reach; a policy check decides whether a specific tool call should run. The safer pattern is read-only by default, isolated credentials, and deterministic blocks around writes, deletes, deployments, and production data.

• How should a codex code review handle risky tool calls?

  A codex code review should inspect both the patch and the agent’s execution path. Review git diff, run tests, then list every external system touched by commands, scripts, or MCP tools. The important artifact is a short permission table: tool name, environment, read/write status, and whether human approval is required.

• Can AGENTS.md enforce these rules by itself?

  No. AGENTS.md is repository guidance for Codex, not a security boundary. It is still valuable because it tells the agent what the repo expects before work starts. Treat it as the instruction layer, then use sandboxing, scoped credentials, and runtime policy checks for actions that can affect shared systems.

• When is policy enforcement overkill?

  It is probably overkill when the agent only edits files in a disposable branch and runs local tests. It becomes worth trying when the agent can call write-capable tools, reach production-like data, trigger deployments, or operate across multiple MCP servers. The line is not model intelligence; it is real-world blast radius.

Best ways to use this research

• Best for: Codex users who already trust the CLI for code edits but are starting to connect agents to MCP servers, databases, deployment scripts, or internal tools.
• Best first artifact: A one-page permission table for agent tools. Include tool name, environment, read/write capability, allowed actions, blocked actions, and approval owner.
• Best comparison angle: Compare sandboxing and runtime authorization by failure mode. Sandboxing answers “what can this session reach?” Policy enforcement answers “should this exact call execute?”
• Best trap to avoid: Do not confuse a good prompt with a hard stop. Instructions help the agent choose better actions; policy checks decide whether risky actions run.

Further reading

• OpenAI Developers — Codex CLI
• OpenAI Developers — Codex CLI features
• Policy enforcement for Claude Code, Codex, and Codex — source

Next step

Pick one dangerous tool your Codex workflow can reach, and write the rule you wish had existed before the agent called it. If that rule cannot be enforced outside the prompt, you have found the boundary Kastra is trying to make visible.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.