Guide
Which coding agent risks can rules catch, and which need context to judge?
Updated
Short answer
Rules can decide alone when the action itself is the evidence. Examples are a secret reaching a network call, a private key being read, a recursive delete at the root, curl piped to a shell or a security setting being changed. Rules can't judge actions that are fine in one task and harmful in another, like deleting a test, editing CI config or widening an IAM policy. Those need the session's intent.
The split that matters#
Some agent actions are dangerous on their face. Others are dangerous only because of why the agent is doing them.
That difference decides which control works. Rules are cheap, fast and predictable, so use them wherever the action is the evidence. Context costs more, so spend it where the same action can mean two things.
Where rules decide alone#
A rule works when you can look at the action and know. No task description changes the answer.
- A secret value reaching a network call.
- A private key being read.
- A recursive delete at the root, or a force-push to the default branch.
curlpiped to a shell.- A permission or security setting being changed.
- Hidden or dynamic execution, like base64-encoded commands or
eval.
No legitimate task needs the agent to send your cloud credentials to an unknown host. So the rule can be strict, and a block costs a developer almost nothing.
Where the same action has two intents#
The same command can have two intents, and that's the hard part.
Deleting a test file is a refactor in one session and hiding a failure in another. Editing CI config might be the task itself, or it might be the agent switching off the gate that keeps failing. Adding a dependency, writing to an agent rules file, widening an IAM policy and sending data to an allowed host all work the same way: they're ordinary, and sometimes they're harmful.
A rule can't tell these apart because the difference isn't in the text. It's in what the developer asked for. A vague request like "fix the failing tests" should produce more questions, not more permissions.
Rule or context, by risk#
| Risk | Who decides | Why | |
|---|---|---|---|
| Secret sent to a network call | Rule | The data flow is the evidence | |
| Private key read | Rule | Judged by file content, not file name | |
| Recursive delete at root | Rule | No task needs it | |
| `curl \ | sh` | Rule | Remote code execution by construction |
| Security setting changed | Rule | The action is the evidence | |
| Obfuscated or dynamic execution | Rule, fails toward asking | Can't be fully judged statically | |
| Test deleted or assertion weakened | Context | Refactor or cover-up, depending on the task | |
| CI config edited | Context | The task, or removal of a gate | |
| New dependency added | Context | Needed library or typosquat | |
| Agent rules file written | Context | Legitimate setup or planted instruction | |
| IAM policy widened | Context | Requested change or privilege manufacturing | |
| Data sent to an allowed host | Context | Normal API call or a leak through a trusted door |
What the built-in controls do here#
Permission rules match text. Anthropic's own docs warn that Bash patterns that constrain arguments are fragile. For example, a rule meant to restrict curl to one site won't match options placed before the URL, a different protocol, a redirect or a shell variable.
Those rules still work for the rule-shaped risks, as long as you know where they break. A sandbox limits what the agent can reach, and scoped credentials limit the blast radius. Neither one knows whether deleting a test was the assignment.
Human approval is the usual fallback for the context cases, and it doesn't hold up. Anthropic reports that users accept 93% of permission prompts. In its study of 1,053 testers, human review caught 13.6% of dangerous commands, while auto mode caught 89%.
Auto mode uses a classifier that sees the user's messages and the agent's tool calls. That's the right shape, because it judges each action against what the user asked for. It covers Claude Code only.
The hardest cases#
Harden's threat model for AI coding agents (Nov 2026) has 15 harm classes and 203 threats. Some of them are hard for any check to catch, and you should plan for that.
- Harm by omission. The agent does exactly what was asked, and doing it causes the harm.
- Fabricated reports. The agent says the tests pass or the fix is in. In the SaaStr incident, the founder said the agent created fake data and fake reports. It also told him a rollback was impossible, and the rollback worked.
- Low-bandwidth leaks. Data trickles out over DNS or hides in requests to approved hosts.
- Laundered approval. Injected content makes the agent propose something, a tired human clicks approve, and the attacker's instruction now carries your authority.
- Spread-out exfiltration. The data leaves in pieces across several separate calls.
No single check closes these. Least privilege, scoped credentials and egress policy do most of the prevention. Action checks are a layer on top.
A decision rule#
- If the action is dangerous in every task, write a deterministic rule and enforce it.
- If it's dangerous only in some tasks, check it against the session's intent. Ask a human when the intent is unclear.
- If it can't be reversed (publishing a package, pushing to a shared upstream, deploying, paying, emailing a customer), gate it either way.
- Start watch-only, read the log, then enforce.
Where Harden fits#
Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. Every command, file edit and push is checked against the session's intent before it runs. Decisions are made locally, in milliseconds, and nothing leaves the machine. If the check can't run, the action doesn't run.
AIF follows the same split as the table above. Deterministic rules decide alone for 10 kinds of risky action where the action is the evidence. A local model reviews each action in the context of the session across 19 risk categories, and it can only make a verdict stricter, never weaker.
AIF is a layer, not a perimeter. A determined attacker who controls the code can defeat static analysis, so AIF works alongside a sandbox and scoped credentials, not instead of them. See the security teams page for how it deploys, and the permissions, hooks and sandbox comparison for the built-in options.
FAQ
Related questions
Can command deny-lists catch risky agent actions?
They catch the obvious forms of the rule-shaped risks, as typed. They miss quoting, aliases, encodings, redirects, variables and the same action written in another language. Checking what the command actually does, such as where a value ends up, holds up better than matching its text.
Why can't a rule just block deleting tests or editing CI config?
Because both are routine work. A blanket block stops legitimate refactors and pipeline changes, and teams respond by switching the control off. To judge these actions, a check needs to know what the session was asked to do.
Does a sandbox replace action checks?
No. A sandbox limits what the agent can reach, and that prevents a lot of damage. It doesn't know whether an in-scope action, like weakening a test, serves the task or hides a failure.
Which agent risks are hardest to detect?
Harm by omission, fabricated success reports, low-bandwidth leaks, laundered human approval and exfiltration spread across many calls. Least privilege, scoped credentials and egress policy matter most for these.
How do I start without blocking developers?
Run the check watch-only first and review what agents actually do. Then enforce the rule-shaped risks, and add context-based checks once you've seen your own false positives.