How do you keep AI coding agents from doing something you'll regret?

A year ago an AI coding assistant mostly suggested the next line. Today the agent opens a terminal, installs what it thinks it needs, reads your config files to understand the project and connects to tools through MCP. That is what makes it useful for a founder without a development team. It also means one confused or manipulated step can delete data, leak an API key or pull in a malicious package.

Layer 1: keep the built-in approvals on

Claude Code, Cursor, Codex and the other agents all let you require approval before commands run or files change, and most let you allow safe commands permanently while still asking about the rest. Use that. The real weakness is not the feature, it is fatigue: after a long session it is easy to approve everything without reading. That is where a second, more specific check helps.

Layer 2: HOL Guard, a local firewall for coding agents

HOL Guard sits on your own machine between the agent and the system. It can pause shell commands, reads of secrets and sensitive files, changes to MCP servers and package installs, and ask you before they happen. It keeps a record of what it decided and why, so security decisions don't disappear into terminal history. It supports Claude Code, Cursor, Codex, OpenCode, GitHub Copilot CLI, Antigravity and several other agent harnesses.

It came out of a very practical worry. Michael Kantor, who leads HOL, told us Guard grew out of running 10 to 20 coding agent sessions at once and asking what could go wrong when they could read files, install packages and run commands. If you run more than one agent at a time, that will sound familiar.

It is open source under the Apache-2.0 licence, so the rules can be inspected, and the local version is free. Setup is two commands: pipx install hol-guard and hol-guard init. It also works offline, and HOL says your files, prompts and passwords never leave the machine. Guard Cloud is optional: the Solo plan keeps your decision history across up to two devices ($4.99/month after a 3-day trial), and Pro and Team add shared policy, dashboards and evidence export. Enforcement still happens locally on each machine either way. If you want it gone again: hol-guard daemon stop, then pipx uninstall hol-guard.

Its makers are refreshingly direct about the limits: a scan is not a safety guarantee, and it is not a web application firewall, an endpoint security product or a cloud MCP gateway. That is the right way to think about it: one strong layer, not the whole wall.

Layer 3: make the worst case small

Assume something will eventually slip through, and make sure it costs little when it does. Keep real secrets out of the folder your agent works in, or in a file it is told never to open. Give every API key the lowest limits and a spending cap. Use a separate test account for anything that can send email or move money. And for experiments you don't trust, run the agent in a container or a throwaway environment instead of your main machine.

How we'd actually decide

• If you only use an agent for small edits and read every prompt: built-in approvals plus the habits in layer 3 are enough.
• If your agent runs commands, installs packages or touches API keys on your own machine: add HOL Guard. It's free and takes minutes.
• If several people or machines run agents against the same systems: look at Guard Cloud for shared policy and visibility.

Product details checked against the makers' own descriptions and public listings in October 2026. StackIndex has no affiliate relationship with HOL.