Attackers Are Using AI. Should Your AI Agents Be Auto-Approving Their Next Move?

By Viral Trivedi, Director of Solution Engineering and Customer Success, Tuskira

Attackers are using AI to move faster. At the same time, enterprises are giving AI agents more autonomy. That combination creates a dangerous imbalance. An attacker needs to manipulate the agent once. An auto-approved agent may execute the remaining attack steps without interruption.

New research puts a number on it.

Auto-approve took attack success from 29.2% to 95.6%

HarnessSecurity-Bench, published this month on arXiv, evaluated six major coding-agent harnesses across 2,500 trials and five attack surfaces. The harnesses were Claude Code, Codex CLI, Gemini CLI, GitHub Copilot, Qwen Code, and gptme. The researchers recorded 81,155 tool calls.

With the default confirmation prompts in place, attacks succeeded 29.2% of the time. With auto-approve enabled, attacks succeeded 95.6% of the time.

Two more findings from the study matter as much as the headline number.

Roughly half of the confirmed security mechanisms were optional. They exist in the product, and they do nothing until someone turns them on. A harness that lists sandboxing, allow-lists, and path restrictions in its documentation may be running with none of them active.

And attackers sometimes reached restricted operations through alternative tools or commands. Blocking one tool did not block the effect. An operation denied through the file-write tool stayed reachable through the shell, a script, or a package manager.

Auto-approve changes the math

A coding-agent harness sits between the model and the machine. It decides which tools the agent can call and whether a person has to confirm before a call runs. Auto-approve removes the confirmation. Teams turn it on because approving every file write and shell command is slow, and the agent is more useful without the interruptions.

The study shows what else it removes. With confirmation gone, an attacker who gets one malicious instruction into the agent gets the rest of the attack for free. The agent carries out each step itself. Nobody is asked.

Three things to do now

Prohibit auto-approve for production agents. The utility gain is real and the study measures it. The security loss is larger, and the study measures that too.

Validate the effective runtime configuration, not the product’s feature list. Ask which mechanisms are on in your deployment, not which ones the vendor ships. If half of them are opt-in, assume half of them are off until someone shows otherwise.

Test whether the same sensitive effect remains reachable through shells, scripts, package managers, or alternate tools. If an agent must not write to a production config, confirm it cannot do so through any tool it holds. The paper shows that blocking one path and declaring the operation restricted is not enforcement.

Securing the model is not enough

At Tuskira, we believe securing the model alone is insufficient. A coding agent with a cloud credential, a CI token, or write access to a repository is one more identity in the environment, and the question that matters is the same one that matters for any identity. If this one is compromised, what does it connect to, and does a control already stop it?

Organizations must understand the complete attack path connecting the agent, the identity it holds, the tools it can call, the vulnerabilities it can reach, the exposures those create, and the defensive controls in between. Tuskira’s Security Context Graph helps teams evaluate that broader environment and determine whether an agent-driven action creates a meaningful path to compromise.

Five controls before you flip the switch

• Least privilege. Each agent holds only the credentials and tools its job requires.
• Effect-based authorization. Authorize the outcome, not the tool. Blocking one tool is not enforcement.
• Execution isolation. Sensitive operations run in a contained environment with a bounded blast radius.
• Continuous validation. Test whether the restricted effect is still reachable through any other path.
• Visibility into actual downstream changes. See what the agent changed, not just the calls it was allowed to make.

Source: Zhu et al., “HarnessSecurity-Bench: Do Security Mechanisms Really Protect Coding Agent Harnesses?” arXiv:2610.07639, October 2026.