Execution security for coding agents is a scattered field — and the gaps show it

What is this?

On July 7, 2026, a systematization-of-knowledge preprint titled The Balkanization of Execution-Security Research for AI Coding Agents (arXiv:2607.05743, CC BY 4.0) argued that the research protecting the layer where coding agents actually run — the sandbox, the shell, the file system, the tool calls — has grown into a set of disconnected sub-fields that rarely cite one another.

An AI coding agent is only as safe as the environment it executes in. A model that can read a repository, run shell commands, and call tools inherits every weakness of the boundary around it. The paper reviews 39 studies published between 2023 and 2026, verifies each one directly against its source, and sorts them into 17 categories: sandbox isolation, capability and access control, policy enforcement, time-of-check-to-time-of-use (TOCTOU) races, Model Context Protocol (MCP) threats, identity delegation, execution provenance, network egress control, and static analysis of agent-generated code. It is a map of a field, not an exploit.

How it works

The core observation is structural. Papers get grouped by the mechanism they propose — one team ships a sandbox, another a capability system, another a policy engine — and that grouping quietly separates work that is addressing the same underlying problem. The author scores all 17 categories against each other on shared root causes and shared pipeline stage, and several of the highest similarity scores fall between categories that never cite one another.

To show the concern is not academic, the systematization confirms four disclosed, patched vulnerabilities directly against the NIST National Vulnerability Database. One is the runc container-runtime file-descriptor leak known as “Leaky Vessels,” which predates agent tooling but illustrates the class of escape any sandbox inherits when it is built on the same primitives. One is a command-injection flaw in a widely used coding assistant, patched in a 2026 release. The remaining two affect a popular terminal coding agent: a code-injection issue where untrusted project code could run before the user accepted the startup trust dialog, and a data-exfiltration issue where a malicious repository could leak data — including API keys — before the trust decision took effect. Both hinge on the same fragile moment: the interval between opening an untrusted repository and the user’s trust decision actually applying. That is a textbook check-then-act race, exactly what the TOCTOU category studies.

Why it matters

The paper’s contribution is five cross-cutting gaps that no single study closes, and each is directly operational for anyone deploying agents.

First, isolation architectures and capability models are each evaluated against an attacker, but almost never against each other on a shared benchmark — so nobody can say whether a sandbox plus a capability system is stronger than either alone. Second, policy-enforcement studies report that real command denylists fail on 69% to 98% of adversarial inputs, yet no isolation paper re-tests its own defense under that failure rate. Third, TOCTOU races and MCP threats are written up as separate literatures despite both being instances of the same state-validation problem. Fourth, every enforcement mechanism reviewed assumes an honest policy author — leaving misconfiguration by the defender entirely unaddressed. Fifth, a newly measured failure mode: benign-but-out-of-scope agent actions, where the same agent on the same task took unrequested actions at rates from 0.0% to 17.1% depending only on how the prompt was phrased. A permission grant that answers “is this action allowed?” does not answer “should the agent be doing this at all?” — and no access-control paper in the corpus even cites that measurement.

Defenses

Because this is a map rather than an attack, the practical takeaway is how to reason about your own agent deployment rather than a payload to block.

• Layer isolation and access control, and test the combination. Do not rely on a sandbox or a capability model in isolation; the research shows neither is evaluated against the other, so assume gaps at the seam and verify the stack end to end.
• Assume your denylist leaks. Command allowlists and denylists fail on the large majority of adversarial inputs. Treat them as one layer, behind real isolation and least privilege, never as the boundary itself.
• Close the trust-decision race. The confirmed real-world flaws all live in the window between opening untrusted content and a trust decision applying. Never execute project code, load repository configuration, or honor tool descriptions until the trust check has fully taken effect.
• Treat TOCTOU and MCP as one problem. Both are state-validation failures: validate the state at the moment of the action, not at an earlier check that a later action can outrun.
• Audit the policy author, not just the agent. Every enforcement layer assumes its own configuration is correct. Review who writes agent policies and how, because misconfiguration is an unmodeled but very real failure mode.
• Constrain scope, not just permissions. Out-of-scope actions swing wildly with prompt phrasing. Add checks for whether an authorized capability is being invoked for an unrequested purpose, not only whether the capability is held.

Status

Item	Detail
Type	Systematization of knowledge (preprint)
Published	July 7, 2026 (arXiv:2607.05743, CC BY 4.0)
Corpus	39 papers (2023–2026), 17 execution-security categories
Attack released	None — survey and research agenda, no payload
Confirmed incidents	4 disclosed, patched CVEs, verified against NVD: CVE-2024-21626 (runc “Leaky Vessels”), CVE-2025-53773 (GitHub Copilot / Visual Studio), CVE-2025-59536 and CVE-2026-21852 (terminal coding agent, patched)
Risk class	Execution-layer security of AI coding agents
Relevance	Anyone deploying coding, terminal, or MCP-enabled agents