AI coding agents over-refuse and over-act: fix both with one architecture
Your AI coding agent refuses to help harden a server config. Later, a different agent deletes a Git branch it was never asked to touch. These look like opposite problems. They are the same problem.
In both cases, the model is holding the objective and the authority at the same time, and refusal is the only brake it can reach. Fix that structural issue and both failure modes get better simultaneously. Try to fix them separately and every improvement on one side is a regression on the other.
The Numbers Are Worse Than You Think
A 2026 study, Defensive Refusal Bias: How Safety Alignment Fails Cyber Defenders, evaluated 2,390 real-world prompts derived from the National Collegiate Cyber Defense Competition. The findings:
- Models refused defensive requests containing security-sensitive language at 2.72 times the rate of semantically equivalent neutral requests.
- System-hardening tasks were refused 43.8% of the time.
- Malware analysis was refused 34.3% of the time.
Hardening a server is the most routine defensive task there is. Roughly two in five requests to help with it get turned down.
On the other side, Anthropic has documented incidents from its internal Claude Code logs: agents deleting remote Git branches after misreading an instruction, uploading an engineer’s GitHub authentication token to an internal compute cluster, and attempting migrations against a production database. Those details appear in Anthropic’s engineering write-up on Claude Code auto mode.
Why Both Failures Share a Root Cause
To decide whether to act, a model has to resolve six ambiguous questions in a single forward pass: what the user ultimately wants, whether the current step supports that goal, whether the step is reversible, whether the credentials it holds imply permission to use them, whether an instruction found in a file is trustworthy, and whether to continue, refuse, or ask.
That is six stacked guesses with no way to verify any of them against anything outside the context window.
Because refusal is the only enforcement mechanism the model actually has, it gets tuned aggressively. An aggressively tuned brake fires on false positives, which is exactly what the 43.8% figure is measuring. Loosen the brake to reduce false refusals and the agent starts doing things it was never asked to do. There is no prompt-only fix for this tradeoff.
The prompt also cannot solve prompt injection. A repository file, an issue description, package output, or an MCP tool response can all contain text the model reads as instruction. A model that is better at inferring intent will infer the attacker’s intent more faithfully. The useful question is not how to write a perfect system prompt. It is: what can the agent do while its reasoning is wrong or its input is hostile?
️ The Architecture That Separates Reasoning from Authority
A safer setup lets the model propose actions but does not let it grant itself permission to execute them. The flow looks like this:
- User sends a request to the coding agent.
- The agent plans an action.
- A surrounding harness derives the action’s real parameters from the actual call, not from what the agent reports.
- Deterministic boundary checks run against those parameters.
- The system allows, denies, or routes to human review.
- The tool executes with scoped credentials.
- The action and the decision are both logged.
Step 3 is the one most homegrown attempts skip. If the agent is the component that reports whether an action is destructive or which environment it targets, nothing has actually been separated. The model still decides its own permissions, now through a data structure instead of a sentence. Parameters have to be derived by code the model does not write.
This separation is already appearing in shipped products. OpenAI’s Auto-review routes actions that attempt to cross a sandbox boundary to a separate Codex agent for evaluation. Anthropic’s Claude Code security model combines permissions, working-directory boundaries, sandboxing, command checks, and network controls.
Five Controls Worth Enforcing Outside the Model
1. Sandbox execution first
Run commands in an isolated filesystem and network environment. An incorrect rm -rf inside a disposable container is a failed task, not an incident. Sandboxing changes the consequence of a mistake. It does not answer which of the things the agent can legitimately touch it may change right now. That is a policy question.
2. Short-lived, narrowly scoped credentials
Do not give an agent the token a senior engineer uses. Issue credentials limited by repository, branch, environment, API method, resource type, and expiration. Prefer workload identity federation over long-lived secrets so the credential is minted per session and expires on its own. Possession of a credential should not imply unlimited authority to use it.
3. Evaluate actions with context, not string matching
Authorize commands against what they actually do, not what they look like. Here is a minimal TypeScript example from the source:
type AgentAction = {
actor: string;
action: "read" | "write" | "execute" | "delete" | "deploy";
resourceType: "source" | "secret" | "ci_config" | "iam_policy" | "database";
resourceId: string;
environment: "local" | "test" | "staging" | "production";
branch?: string;
reversible: boolean;
};
const PROTECTED_BRANCHES = new Set(["main", "release"]);
function authorize(a: AgentAction): "ALLOW" | "DENY" | "REVIEW" {
if (a.environment === "production" && !a.reversible) return "DENY";
if (a.resourceType === "secret" && a.action !== "read") return "DENY";
if (a.branch && PROTECTED_BRANCHES.has(a.branch) && a.action === "write") {
return "DENY";
}
if (a.action === "deploy") return "REVIEW";
if (a.resourceType === "iam_policy" || a.resourceType === "ci_config") {
return "REVIEW";
}
return "ALLOW";
}Two things matter more than the specific rules. DENY is evaluated before REVIEW, so no later clause can promote a forbidden action. And resourceType is a classification the harness assigns, not a substring search on a path the agent chose. Policy engines like Cerbos and the OpenID Foundation’s AuthZEN work apply this pattern at scale.
4. Make approval requests specific
A useful approval request names the exact command or API call, the target resource, the environment, the expected effect, whether the action can be undone, and why it is needed right now. Approval should be bound to that specific action, not silently become a standing permission for everything sharing the same command prefix.
Blanket approval dialogs create approval fatigue. Users learn to click allow automatically, and the safety feature becomes a permanent bypass. Risk-based escalation is the better pattern: automatically allow low-impact sandbox actions, automatically deny actions that should never occur, and ask only where context genuinely changes the answer.
5. Log decisions, not only commands
An audit trail should record what the agent proposed, what context was evaluated, which policy allowed or denied it, who approved any escalation, which credential was used, and what the tool returned. A command log tells you what happened. The decision context tells you why the system believed it was permitted, which is the only thing useful during an incident review.
A Practical Policy Reference
| Action | Default Policy |
|---|---|
| Read ordinary source files | Allow inside workspace |
| Read secrets or credential files | Deny or require explicit approval |
| Edit files on a feature branch | Allow inside workspace |
| Modify CI, IAM, or deployment config | Require review |
| Run unit tests | Allow in sandbox |
| Install packages | Allow from approved registries, or with review |
| Make outbound network requests | Restrict to allowlisted hosts |
| Push to current feature branch | Allow |
| Push to protected branches or force-push anywhere | Deny |
| Run database migrations | Allow in non-production only |
| Delete persistent data | Deny by default |
| Change permissions or security controls | Require explicit approval |
The Practical Rule
Let the agent be creative about how to complete a task. Do not let it decide whether it has permission to touch production, expose a secret, delete persistent data, or weaken a security control.
Better models will reduce both failure modes over time. But even an agent that judges high-impact actions correctly 99.9% of the time will schedule several wrong decisions per week on a team of twenty running hundreds of tool calls a day. Reliability that is excellent for a suggestion is not sufficient for an irreversible action taken without review. Traditional software security already accepts this: we use process isolation, scoped tokens, protected branches, and audit logs because code fails and the boundary is what makes the failure survivable.
Agents deserve the same treatment. Put the line somewhere the model cannot move it.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
