Guide
What should a tool that checks coding agent commands before they execute actually do?
Updated
Short answer
It should sit at the agent's pre-execution hook, outside the agent, and check every command, file edit and push against the session's intent before it runs. It should decide locally and fast enough that nobody turns it off. If it can't run, the action shouldn't run either. It should apply one policy across every agent and record every decision for audit.
Why a pre-execution check at all#
Most teams start with human approval, and it doesn't hold up. In Anthropic's controlled study with 1,053 paid testers, human review caught just 13.6% of dangerous commands.
So the check has to move from a person's patience to a machine that looks at the action itself. Below is the list to hold any tool to.
Where it runs#
The check should run outside the agent, on the developer's machine, at the hook the agent calls before it acts. For how that hook behaves in Claude Code, read Claude Code hooks: what they enforce.
It needs to be outside the agent because the agent can talk itself past a control that lives in its own context or configuration. A long session can also drop that control when it compacts its context. The harness shouldn't grade its own homework.
What it sees#
Checking shell commands alone isn't enough. A coding agent also edits files, makes network calls and pushes code. Ask whether the tool covers all four:
- Shell commands, including ones wrapped in another language or encoded.
- File edits, including writes to CI config, agent rules files and hooks.
- Network calls, and whether a secret is about to go out with one.
- Pushes and any other action you can't take back.
How it decides#
Text matching is weak. A deny rule catches rm -rf as typed. It misses the same delete written through a variable, an alias, a script or another language.
A better check parses the pending action and follows where the data goes. If a secret reaches a network call, that's a dangerous flow, however the command is spelled.
Then it adds the session's intent. Deleting a test file is a refactor in one session and hides a failure in another. The same command can have two intents.
Ask the vendor how its decisions are split. Deterministic rules should decide alone when the action itself is the evidence. Anything that judges context, such as a model, should only be able to make a verdict stricter, never weaker.
How fast#
If a check adds seconds to every action, people turn it off. Then you have no check at all, so latency matters for security too.
Ask for the P99, not the average. Also ask where the decision is made. A round trip to a cloud service adds network time and sends your commands off the machine.
Wrong blocks#
A tool that blocks the wrong things gets turned off as fast as a slow one. Ask for the wrong hard-block rate and how many decisions it's based on. Then measure it on your own repos in watch-only mode before you trust anyone's number.
When a check blocks an action, it should tell the agent why. That way the agent can retry safely instead of looping.
Fail closed#
Most hook setups miss this one. In Claude Code, any exit code other than 0 or 2 is a non-blocking error and the tool call proceeds. Failures only block if you set onFailure: "block".
So if the script crashes or the binary is missing, the action runs unchecked. Whatever you deploy must fail closed: if the check can't run, the action doesn't run. Test this by breaking the check on purpose.
One policy, Records and rollout#
Your developers use more than one agent. Separate settings for each agent drift apart over time, and you end up with gaps wherever one agent's config is weaker. You want one policy across every agent that exposes a pre-execution hook.
Every decision should be recorded with the action, the verdict and the reason. You should be able to export those records to your SIEM. That's the audit trail you show an auditor.
Rollout should be boring:
- Start watch-only, so you see what agents do before you enforce anything.
- Push it through the MDM you already run, not by installing it laptop by laptop.
- Lock the config so neither a developer nor the agent can edit it.
Where Harden fits#
Harden Agentic Integrity Foundation (AIF) is built to meet this list. It runs on the developer laptop, outside the agent, at the pre-execution hook. Every command, file edit and push is checked against the session's intent before it runs. Decisions are made locally, so nothing leaves the machine.
The enforcement path is deterministic, and a local model that reviews context can only make a verdict stricter. Verdicts take about 28 ms (P99 about 70 ms). In our own internal use, 0.25% of 24,809 decisions were wrong hard blocks. AIF fails closed, applies one policy across agents, starts watch-only and deploys through your MDM. See the AIF trust page for data handling and limits.
AIF is one layer of defense and doesn't secure the whole perimeter. It doesn't replace least privilege, scoped credentials or a sandbox. Exfiltration spread across several separate calls is still hard to catch.
FAQ
Related questions
Can I build this myself with Claude Code hooks?
You can write a hook that blocks commands. The hard parts are judging intent rather than matching strings, failing closed on every error path, and keeping it fast enough that nobody turns it off.
Does a hook that fails still block the command?
Not by default in Claude Code. Exit codes other than 0 or 2 are non-blocking errors and the tool call goes ahead. Failures only block if you set onFailure to block.
Should the check run in the cloud or on the laptop?
On the laptop. Local decisions are faster, keep commands and code on the machine, and keep working when the network doesn't.
How do I roll it out without breaking developers?
Start in watch-only mode, so the check logs what it would have done. Review the records and tune the policy. Then push the enforcing config through your MDM.
Does a pre-execution check replace a sandbox?
No. A sandbox limits what the agent can reach, and a pre-execution check judges each action. Use both, along with scoped credentials.