Paper deep dive
The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities
Mohammadreza Rashidi
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 7/8/2026, 2:58:34 AM
Summary
This paper systematizes 39 research papers (2023-2026) on execution security for AI coding agents, organizing them into 17 categories. It identifies five cross-cutting gaps in the literature, including isolation vs. access control evaluation gaps, policy enforcement fragility, TOCTOU/MCP vocabulary gaps, honest policy author assumptions, and unaddressed scope-creep failure modes. The study verifies real-world CVEs affecting production agent harnesses and proposes a research agenda to address these systemic vulnerabilities.
Entities (10)
Relation Signals (7)
Claude Code → hasvulnerability → CVE-2025-59536
confidence 98% · CVE-2025-59536 (CVSS 8.8, CWE-94) is a code-injection flaw in which versions before 1.0.111 could execute untrusted project code
GitHub Copilot → hasvulnerability → CVE-2025-53773
confidence 98% · CVE-2025-53773 is a command-injection vulnerability in GitHub Copilot and Visual Studio 2022
AI Coding Agents → areprotectedby → Sandbox isolation
confidence 95% · papers on sandbox isolation, capability and access control... are published independently
runc → isusedfor → Sandbox isolation
confidence 92% · runc container-escape vulnerability affecting the container runtime many agent sandboxes are built on
ShellSieve → measures → Policy enforcement fragility
confidence 90% · ShellSieve is the more alarming of the two: an automated pipeline that has a language model propose bypasses to real command denylists
TOCTOU → isatypeof → State-validation problem
confidence 88% · TOCTOU and MCP threats are analyzed as separate literatures despite both being instances of the same state-validation problem.
Scope creep → isa → Cross-cutting gap
confidence 85% · benign but out-of-scope agent actions occurring at rates up to 17.1% under realistic prompting are addressed by no access-control or capability paper
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:AI coding agents now read repositories, call tools, and execute shell commands with limited human oversight, and a fast-growing body of work studies whether the execution layer around them is actually safe. That literature is scattered. Papers on 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 are published independently and rarely cite one another. We systematize 39 papers published between 2023 and 2026 into 17 categories, each verified directly against its source. The same verification protocol also confirms four disclosed, patched CVEs directly affecting production agent harnesses. Reading across categories surfaces five cross-cutting gaps that no single paper addresses. (1) Isolation architectures and capability models are almost never evaluated against one another on a shared benchmark. (2) Policy-enforcement studies report failure rates from 69% to 98% of real denylists, yet no isolation paper re-evaluates its own defense under that adversarial setting. (3) TOCTOU and MCP threats are analyzed as separate literatures despite both being instances of the same state-validation problem. (4) Every enforcement mechanism assumes an honest policy author, leaving policy-authoring error itself unaddressed. (5) Benign but out-of-scope agent actions occurring at rates up to 17.1% under realistic prompting are addressed by no access-control or capability paper in the corpus. Existing broader surveys of agentic AI security discuss sandboxing only as one item among many defenses, leaving execution security without a dedicated systematization. This paper is written to fill that gap. We conclude with a research agenda directed at the five gaps.
Tags
Links
- Source: https://arxiv.org/abs/2607.05743v1
- Canonical: https://arxiv.org/abs/2607.05743v1
Trouble viewing inline? Open PDF directly →
Full Text
92,226 characters extracted from source content.
Expand or collapse full text
The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities Mohammadreza Rashidi Department of Computer Science AI and Media Analysis Lab Berlin, Germany mohammadreza.rashidi@ue-germany.de Abstract—AI coding agents now read repositories, call tools, and execute shell commands with limited human oversight, and a fast-growing body of work studies whether the execution layer around them is actually safe. That literature is scattered: papers on sandbox isolation, capability and access control, policy enforcement, time-of-check-to-time-of-use (TOCTOU) races, Model Context Protocol (MCP) threats, identity delega- tion, execution provenance, network egress control, and static analysis of agent-generated code are published independently, rarely cite one another across categories, and no existing survey organizes them by execution-security mechanism. We systematize 39 papers published between 2023 and 2026 into 17 categories, each verified directly against its source rather than taken from a secondary summary; the same verification protocol also confirms four disclosed, patched CVEs directly affecting production agent harnesses, showing the concern is not speculative. Reading across categories surfaces five cross- cutting gaps that no single paper addresses: isolation archi- tectures and capability models are evaluated against attacker capability, but almost never against one another on a shared benchmark; policy-enforcement studies report failure rates from 69% to 98% of real denylists yet no isolation paper re-evaluates its own defense under that adversarial setting; TOCTOU and MCP threats are analyzed as separate litera- tures despite both being instances of the same state-validation problem; every enforcement mechanism we review assumes an honest policy author, leaving policy-authoring error itself unaddressed; and a newly measured failure mode, benign but out-of-scope agent actions occurring at rates up to 17.1% under realistic prompting, is addressed by no access-control or capability paper in our corpus. We also find that three existing broader surveys of agentic AI security discuss sandboxing only as one item among many defenses, leaving execution security without a dedicated systematization; this paper is written to fill that specific gap. We conclude with a research agenda directed at the five gaps rather than at restating the individual papers’ own stated future work. Index Terms—AI agents, execution security, sandboxing, access control, systematization of knowledge, Model Context Protocol, TOCTOU 1. Introduction An AI coding agent is only as safe as the environment it executes in. Modern agent harnesses, terminal-based assis- tants, autonomous coding agents, and browser-use agents, give a language model the ability to read files, run shell commands, call external tools, and in many deployments do so with limited or no human confirmation per action. The last two years have produced a large body of work asking whether the execution layer around these agents is actually safe: whether the sandbox holds, whether the access-control policy is enforced, whether a state check can be invalidated between the time it is made and the time it is acted on, and whether the tool-calling protocol itself carries new attack surface. This is a different question from whether the model’s outputs are aligned or its prompts are safe; it is a systems-security question about the boundary between the agent and the machine it runs on. That literature is scattered. A paper on container sandbox escape does not cite the paper on denylist fragility; a paper proposing a capability framework for coding agents does not engage with the empirical finding that most produc- tion policies fail to hold; a Model Context Protocol threat model and a browser-agent TOCTOU paper describe what is structurally the same validate-then-act race without using a shared vocabulary for it; a paper measuring how often agents take benign but unrequested actions does not cite, and is not cited by, any of the access-control papers that could in principle constrain exactly that behavior. Three recent broader surveys of agentic AI security exist [1]–[3], and a fourth reviews open agentic platforms specifically [4], but all four treat execution isolation as one entry in a wide catalog of concerns alongside prompt injection, retrieval poisoning, and multi-agent risk, rather than as a subject with its own internal structure. No existing paper organizes execution- security work specifically, on its own terms, across the mechanisms the field has actually built. The concern these papers study is not speculative. Dur- ing the verification described in Section 3, we confirmed four disclosed, patched CVEs directly against the NIST National Vulnerability Database: a runc container-escape vulnerability affecting the container runtime many agent sandboxes are built on [5], a command-injection vulnera- arXiv:2607.05743v1 [cs.CR] 7 Jul 2026 bility in GitHub Copilot and Visual Studio [6], and two vulnerabilities in Claude Code itself, a code-injection flaw in the startup trust-dialog flow and a data-exfiltration flaw in the project-load flow that could leak API keys before a user confirms trust in a repository [7], [8]. All four are documented in Section 2.3. This paper is a systematization of knowledge (SoK): we do not run new attacks or build a new defense. We read 39 papers published between 2023 and 2026, verify each one directly against its source rather than trust a secondary description, organize them into 17 categories by the execution-security mechanism they address, and read across the categories for gaps that are invisible from within any single one. Every citation in this paper’s taxonomy was checked by fetching the paper’s own abstract page and confirming its title, authors, and claimed contribution before being included; the corpus and its category labels are released as a plain data file so the categorization is itself auditable and falsifiable, not an assertion the reader must take on faith. Contributions: •A systematized corpus of 39 execution-security pa- pers (2023–2026), organized into 17 categories: iso- lation architectures, escape and adversarial bench- marks, access control and capability models, policy enforcement fragility, time-of-check-to-time-of-use races, MCP-specific threats and defenses, systems- security framing, harness-level capability evaluation, identity and credential delegation, execution prove- nance and auditability, network egress control, static analysis of agent-generated code, scope-creep mea- surement, and skill and plugin packaging security. •Confirmation, directly against the NIST National Vulnerability Database, of four disclosed and patched CVEs affecting production agent tooling, including two in Claude Code itself, grounding the corpus in real, resolved incidents rather than only in papers’ self-reported threat models. •Five cross-cutting gaps identified by reading across categories rather than within any one: the isolation-versus-access-control evaluation gap, the enforcement-fragility-versus-defense-evaluation gap, the TOCTOU-MCP vocabulary gap, the honest- policy-author assumption, and the unaddressed scope-creep failure mode. •A released, machine-readable corpus file (paper key, verified title and authors, venue, year, category) so the taxonomy can be checked, extended, or disputed rather than taken as asserted. •A research agenda organized around closing the five gaps, rather than a restatement of the future-work sections already published in the surveyed papers. 2. Background 2.1. Why execution security is a distinct problem Prompt injection and jailbreaking concern what a model is persuaded to say or decide; execution security concerns what happens once that decision reaches the operating sys- tem. The distinction matters because a perfectly aligned model can still execute a dangerous action if the surrounding system does not constrain what actions are possible, and conversely a successfully injected model gains nothing if the execution layer refuses the action regardless of intent. Systems-security framing papers make this argument explic- itly: agent security should treat the model itself as an un- trusted component and build guarantees into the surrounding architecture [9], since static, rule-based controls designed for predictable environments are not well matched to the fluid, natural-language-driven interactions agents actually have [10]. 2.2. The concrete primitives at stake The primitives this literature protects are ordinary operating-system resources: the filesystem, the process and network namespace, and any credentials reachable from the agent’s execution context. The OWASP Top 10 for LLM applications lists unbounded resource consumption and ex- cessive agency as named risk categories [11], giving the practitioner-facing side of the same concern this paper’s academic corpus addresses from the research side. 2.3. Real-world incidents None of this is hypothetical, and we verified each of the following four disclosures directly against the NIST National Vulnerability Database rather than repeating a sec- ondary description of it. CVE-2024-21626, “Leaky Vessels,” is a patched runc vulnerability in which a leaked file de- scriptor referencing the host’s working directory allowed a crafted container to escape to the host filesystem [5]; it predates agent-specific tooling but illustrates the class of container-runtime weakness that agent sandboxes inherit whenever they are built on the same primitives. CVE- 2025-53773 is a command-injection vulnerability in GitHub Copilot and Visual Studio 2022 (CVSS 3.1 base score 7.8), patched in version 17.14.12 [6]. The remaining two affect Claude Code specifically. CVE-2025-59536 (CVSS 8.8, CWE-94) is a code-injection flaw in which versions before 1.0.111 could execute untrusted project code before a user accepted the startup trust dialog, but only when the tool was launched against an untrusted directory [7]; the flaw is structurally a trust-boundary race of exactly the shape the TOCTOU category in Section 4 studies, a check (has the user trusted this project) that a subsequent action (exe- cute project code) could outrun. CVE-2026-21852 (CVSS 7.5) is a data exfiltration vulnerability in Claude Code’s project-load flow that allowed a malicious repository to exfiltrate data, including Anthropic API keys, before the user confirmed trust, patched in version 2.0.65 [8]. Both Claude Code CVEs concern the same underlying moment, the interval between opening an untrusted repository and the user’s trust decision taking effect, which is precisely the execution-security boundary this paper’s taxonomy is about. Beyond individually disclosed CVEs, the execution layer of coding agents became a first-class offensive target at Pwn2Own Berlin 2026, where the Zero Day Initiative intro- duced a dedicated Coding Agents category with Anthropic Claude Code, OpenAI Codex, and Cursor as targets [12]. The category’s scoping rules read as an independent re- statement of this paper’s thesis: a qualifying entry had to “interact with a contestant-controlled resource (e.g. web page, repository, media file) to exploit a vulnerability within the coding agent” through “a common coding agent use case,” while “model jailbreaks or prompt outputs that do not cross security boundaries” and any exploit requiring “unsafe or permission-less modes” were explicitly ruled out of scope [12]. The contest thus rewarded precisely the execution-layer boundary crossing this survey systematizes and deliberately declined to reward pure model-level manip- ulation, the same line our taxonomy draws between the in- jection foundations of Section 4 and the containment failures that are its subject. All three agents had real vulnerabilities demonstrated against them: OpenAI Codex fell to a single input-neutralization bug (CWE-150) for a $40,000 award, Cursor was exploited in two separate entries, and several attempts against Claude Code and Codex were adjudicated as collisions with vulnerabilities already disclosed to the vendor [12], [13]. The event paid out $1,298,250 across 47 unique zero-days [13]; that a flagship contest could stand up a coding-agent category at all, and that its qualifying bar was a security-boundary crossing reachable through ordinary use rather than a misconfiguration or a permission-less mode, is direct evidence that the attack surface catalogued here is neither hypothetical nor niche. 3. Methodology 3.1. Search and inclusion process We searched arXiv and web literature using combi- nations of the terms sandbox, execution isolation, agent harness, coding agent, capability, access control, TOCTOU, and Model Context Protocol, iterating the query set as each round of results surfaced new author groups, venues, and vocabulary to search on. We included a paper if it (a) addresses the execution layer of an LLM-based agent, meaning the boundary between the agent’s decisions and the operating system, filesystem, network, or tool-calling substrate it acts through, and (b) was published or posted between January 2023 and the time of writing. We excluded papers whose primary contribution is model-level alignment, prompt-injection defense at the text level with no execution- layer component, or agentic security surveyed only as one item in a broader catalog without a dedicated execution- security contribution; the two broader surveys we identify in this last category are discussed in Section 7 for posi- tioning rather than included in the taxonomy, since they are secondary sources about the field rather than primary execution-security contributions. 3.2. Verification protocol Search engines and language-model-generated sum- maries of search results are not a reliable source for a bibliography: titles are paraphrased, author lists are merged across similarly named papers, and claimed numerical find- ings are sometimes attributed to the wrong paper. For every candidate paper we fetched its arXiv abstract page directly and recorded the exact title, full author list, and venue as stated on that page before adding it to the corpus. Two candidates failed this check and were corrected or dropped: a search summary attributed a specific empirical breakdown (misconfiguration, shell-gap, and bypass counts summing to 204 reports) to [14], but the paper’s own abstract states only an aggregate figure of 290 reports across 13 frameworks with no such breakdown, so we report only the verified aggregate. Separately, two candidate titles, Systems Security Foundations for Agentic Computing and Agent Security is a Systems Problem, returned an identical fourteen-author list and near-identical descriptions (a systems-security perspec- tive grounded in eleven real-world case studies); we treat these as the same underlying work under two titles and include only one entry, [9], to avoid double-counting a single contribution as two corpus entries. 3.3. Categorization We assigned each verified paper to exactly one of 17 categories based on its primary mechanism, listed with the number of papers in each in Table 1. The categorization and the full corpus, including the verified title, authors, venue, and arXiv identifier for every entry, are released as a plain CSV file alongside this paper so the classification is falsifiable rather than asserted; Section 3.4 describes how every count stated in this paper is mechanically re-derived from that file. Each taxonomy subsection below opens with a compact setting→technique→outcome flow strip for its cat- egory (Figures 1–14), drawn as icon shapes, circle (setting) → hexagon (technique)→ rounded square (outcome), so the process reads at a glance; the three foundational categories that have no dedicated subsection are summarized together in Figure 15. 3.4. Reproducibility Table 1 and every count asserted in this paper (39 total papers, the per-category counts, and the 2023–2026 year range) are generated from a single machine-readable corpus file that records, for each paper, its bibliographic identity, category, root-cause attribution, and pipeline stage. An in- dependent checker re-derives every count from that file and compares it against the numbers used in the prose and tables; it also verifies that no bibliography entry is duplicated and that every citation used in the taxonomy resolves to a real entry. The corpus file and both tools are released with the paper as a supplementary artifact. This is a narrower notion of provenance than an experimental paper’s, since a SoK has no raw measurement to re-derive, but it guarantees that the counts asserted in the prose cannot drift from the corpus, and it lets a reader challenge any individual classification by editing one line of the released file and re-running the checker. 4. A Taxonomy of Execution-Security Work 4.1. Isolation architectures (5 papers) 1. Isolation architectures Mechanismno RC Agent's reachSandbox boundaryContained blast Figure 1. Category 1 (isolation architectures): agent’s reach→ sandbox boundary→ contained blast radius (root-cause chips as in Figure 16). This category proposes or evaluates a system that con- fines what an agent’s actions can affect. IsolateGPT ap- plies app-store-style isolation to LLM-based agentic sys- tems, restricting interaction between third-party compo- nents to well-defined, permissioned interfaces and show- ing this defends against app compromise, data theft, and unintended system change with under 30% overhead on most tested queries [15]. ceLLMate takes a narrower but sharper approach for browser-use agents specifically: rather than policing low-level UI actions, it sandboxes at the HTTP layer, since any state-changing effect must eventually reach the site’s backend through a network request [16]. AgentBay addresses a different concern, seamless human takeover across heterogeneous execution surfaces (desktop, mobile, browser, code interpreter) rather than confinement per se [17]. DeltaBox and the fault-tolerant sandboxing work in this category both address the operational cost of isola- tion once adopted: DeltaBox cuts checkpoint and rollback latency to single-digit milliseconds by snapshotting only the delta between agent states [18], and a transactional sand- box design wraps agent actions in atomic, reversible units, reporting a 100% interception rate for high-risk commands and a 100% rollback success rate in its own evaluation [19]. 4.2. Escape and adversarial benchmarks (6 papers) This category measures whether an agent, given the op- portunity, can break out of or subvert its intended execution boundary. SandboxEscapeBench is a capture-the-flag-style benchmark that deliberately introduces known classes of container weakness, misconfiguration, privilege-allocation error, kernel flaws, and orchestration mistakes, and finds that capable frontier models can locate and exploit them [20]. RedCode evaluates the opposite direction, whether an agent 2. Escape / adversarial benchmarks MeasurementRC4 Risky taskEscape attemptBreak-out rate Figure 2. Category 2 (escape and adversarial benchmarks): risky task→ escape attempt→ break-out rate. will execute or generate code that is already known to be risky, across more than 4,000 test cases in Python and Bash and 19 language models, finding agents more willing to reject risky operating-system actions than to reject code that is merely subtly buggy [21]. SandboxEval targets the test harness itself, probing an open-source AI-safety evaluation framework for data leaks, unauthorized file changes, and unwanted network access during the execution of untrusted, model-generated code [22]. 4.3. Access control and capability models (6 pa- pers) 3. Access control & capability models MechanismRC2RC3 Fine-grained policyCheck at actionGrant / deny Figure 3. Category 3 (access control and capability models): fine-grained policy→ check at action→ grant or deny. This is the largest category and the field’s dominant response to the isolation problem: rather than a single con- finement boundary, grant the agent fine-grained, revocable, or context-sensitive permissions. AgentBound applies an Android-permission-model-inspired policy layer specifically to MCP servers, with policies derived automatically from server source code [26]. PORTICO addresses a narrower but sharply defined failure mode, lingering authority, where a permission granted for one subtask remains valid after that subtask closes, by issuing time-limited, revocable capability tokens that are pulled the moment a subtask completes [27]. SEAgent frames privilege escalation in multi-agent sys- tems as a confused-deputy-shaped problem and combines mandatory and attribute-based access control, tracking inter- agent and agent-tool interactions through an information- flow graph [28]. A vision paper argues that static, identity- based access control is a poor match for agents and proposes evaluating context along multiple dimensions (relationships, situational factors, norms) with adaptive, non-binary re- sponses such as redaction or summarization [10]. The Open Agent Passport enforces policy deterministically before a tool call executes rather than after, reporting a drop from 74.6% to 0% attacker success when a strict policy is ap- plied, though the authors note this assumes the enforcement framework itself is not compromised [29]. FORGE takes the most formal approach in this category, expressing policy in Datalog and enforcing it through a reference monitor TABLE 1. TAXONOMY OF THE 39 VERIFIED PAPERS BY PRIMARY EXECUTION-SECURITY MECHANISM. CategoryPapersRepresentative work Isolation architectures5[15], [16], [17], [18], [19] Escape and adversarial benchmarks6[20], [21], [22], [23], [24], [25] Access control and capability models6[26], [27], [28], [10], [29], [30] Policy enforcement fragility2[31], [14] Time-of-check to time-of-use2[32], [33] MCP-specific threats and defenses4[34], [35], [36], [37] Systems-security framing2[9], [38] Harness-level capability evaluation1[39] Identity and credential delegation2[40], [41] Execution provenance and auditability1[42] Network egress control1[43] Static analysis of agent-generated code1[44] Scope-creep and overeager-action measurement1[45] Skill and plugin packaging security1[46] Prompt-injection foundations2[47], [48] Jailbreak and alignment-attack foundations1[49] Agent safety-awareness evaluation1[50] Total39 built on aspect-oriented programming principles rather than natural-language rules embedded in a system prompt [30]. 4.4. Policy enforcement fragility (2 papers) 4. Policy enforcement fragility Measurement(RC3)RC4 Deployed policyBypass searchFragility rate Figure 4. Category 4 (policy enforcement fragility): deployed policy→ bypass search→ fragility rate. Where the previous category proposes mechanisms, this category measures whether mechanisms that are already deployed actually hold. ShellSieve is the more alarming of the two: an automated pipeline that has a language model propose bypasses to real command denylists and validates them by execution in a sandbox, tested against 1,709 denylists scraped from GitHub, finding that 69.0% to 98.6% of them are fragile depending on the bypass class considered [31]. YoloFS documents the same failure mode from a design perspective: reviewing 290 public misuse reports across 13 agent frameworks, the authors find agents are routinely given a binary choice between unrestricted filesystem access and workflows that block on constant approval, and propose shifting awareness of an action’s effects into the filesystem itself through staged changes and snapshot-based correction [14]. 4.5. Time-of-check to time-of-use (2 papers) This category isolates a specific race condition: an agent validates a piece of external state, a file’s contents, a web- page’s structure, and then acts on a stale copy of that state af- ter it has changed. Mind the Gap is the first dedicated study of this class in LLM-enabled agents generally, introducing 5. Time-of-check to time-of-use MechanismRC2 Validated stateState driftsStale action Figure 5. Category 5 (time-of-check to time-of-use): validated state→ state drifts→ stale action. TOCTOU-Bench (66 tasks) and combining prompt rewrit- ing, state-integrity monitoring, and tool-fusing to reduce the rate of TOCTOU flaws in executed trajectories from 12% to 8% [32]. The browser-use-specific follow-on work shows the same race is common and exploitable across ten open- source browser agents and many real websites, since a page can change between an agent’s plan and its action [33]. 4.6. MCP-specific threats and defenses (4 papers) 6. MCP-specific threats & defenses MeasurementRC1(RC2) Tool metadataPoisoned surfaceClient-side defense Figure 6. Category 6 (mcp-specific threats and defenses): tool metadata→ poisoned surface→ client-side defense. The Model Context Protocol standardizes how agents discover and call external tools, and in doing so intro- duces its own execution-security surface. A threat model built on STRIDE and DREAD identifies tool poisoning, malicious instructions embedded in a tool’s own metadata, as the standout client-side risk and tests seven prominent MCP clients, finding most implement no static validation against it [34]. A landscape survey maps the full MCP server lifecycle into a four-actor threat taxonomy (malicious developers, external attackers, malicious users, and security flaws) and validates it against real-world cases [35]. The largest empirical study in this category examined 1,899 open-source MCP servers and found 7.2% carry traditional- style vulnerabilities, 5.5% exhibit MCP-specific tool poi- soning, and 66% show code smells, concluding that MCP security tooling has not kept pace with MCP adoption [36]. MCP-Guard responds with a three-stage defense pipeline, pattern scanning, a fine-tuned semantic classifier, and a final LLM arbitrator, evaluated against a companion benchmark of simulated attacks [37]. 4.7. Systems-security framing (2 papers) 7. Systems-security framing Perspectiveno RC Survey practiceSystems lensResearch agenda Figure 7. Category 7 (systems-security framing): survey practice→ sys- tems lens→ research agenda. Two papers argue for a change in how the field thinks about the problem rather than proposing a new mechanism. [9] argues the field has approached agent safety from an AI- centric perspective that lacks systems-security guarantees, and grounds a set of research directions in eleven real- world attacks. [38] makes a complementary argument from the human side: reviewing dozens of academic papers and deployed systems, the authors find that the human-oversight mechanisms companies actually deploy, advance policy- setting, runtime approval, permission scoping, are barely represented in what academic papers study, and that these mechanisms leave users caught between approval fatigue and uncontrolled autonomy. 4.8. Harness-level capability evaluation (1 papers) 8. Harness-level capability evaluation MeasurementRC4 Same modelCTF-style tasksHarness ranking Figure 8. Category 8 (harness-level capability evaluation): same model→ CTF-style tasks→ harness ranking. A single paper in our corpus evaluates the agent harness itself, rather than a defense or a threat, as the unit of analysis. Comparing five different scaffolds, including ones built around Claude and Codex, against the same underlying model on 33 cybersecurity CTF-style challenges, the authors find no single harness dominates, and that combining struc- turally different scaffolds in a shared blackboard architecture outperforms every individual one [39]. We include this paper because harness design choices are themselves an execution- security variable: which tools a scaffold exposes and how it sequences them shapes the attack surface as much as any sandbox or policy layered on top. 4.9. Identity and credential delegation (2 papers) 9. Identity & credential delegation MechanismRC1 Human grantScoped credentialVerified chain Figure 9. Category 9 (identity and credential delegation): human grant→ scoped credential→ verified chain. This category addresses a question the access-control category assumes an answer to: how does an agent get scoped, revocable credentials in the first place, and how does a downstream service know which human, and which delegation chain, an agent’s request ultimately traces to. One proposal extends OAuth 2.0 and OpenID Connect with agent-specific credentials and metadata, and translates natural-language permission grants into auditable access- control configurations so organizations can adopt it without replacing existing login infrastructure [40]. A complemen- tary, more foundational proposal argues the deeper problem is that transformers treat tool definitions and user instruc- tions as indistinguishable tokens despite their different secu- rity implications, and addresses it with cryptographic bind- ing of capabilities to their issuing context plus reproducibil- ity verification, showing formally that a single unverifiable agent in a delegation chain undermines verification for every agent downstream of it [41]. 4.10. Execution provenance and auditability (1 pa- per) 10. Execution provenance & auditability Mechanism(RC2)(RC3) Action traceBaseline compareFlagged deviation Figure 10. Category 10 (execution provenance and auditability): action trace → baseline compare→ flagged deviation. Rather than gate an action before it executes, this cat- egory records what happened so it can be judged, flagged, or attributed afterward. Agent-Sentry establishes a baseline of legitimate action patterns from past runs and flags devi- ations from it using a three-layer check, an action-sequence classifier, a fixed-rule check on sensitive values, and an LLM reviewer reserved for ambiguous cases, reporting that it stops 94.3% of successful injections in the AgentDojo and AgentDyn benchmarks while allowing 95.1% of benign executions through, without modifying the agent, its tools, or the underlying model [42]. 4.11. Network egress control (1 paper) This category treats the network boundary as the en- forcement point rather than the filesystem or the tool-calling 11. Network egress control Mechanism(RC1)RC3 Network boundaryEgress filterAttack contained Figure 11. Category 11 (network egress control): network boundary→ egress filter→ attack contained. layer, on the reasoning that most state-changing effects an agent can have ultimately require an outbound request. A dual-firewall architecture converts incoming agent-to-agent messages into a closed, structured protocol to strip ma- nipulative content through deterministic verification, and separately controls outgoing information by matching its level of detail to what the task actually requires rather than applying all-or-nothing redaction, substantially cutting both privacy and security attack success rates across hundreds of simulated attacks while preserving task performance [43]. 4.12. Static analysis of agent-generated code (1 paper) 12. Static analysis of agent-generated code MeasurementRC4 Agent-written codeSecurity scanSecure fix Figure 12. Category 12 (static analysis of agent-generated code): agent- written code→ security scan→ secure fix. This category scans code an agent is about to run, or has just written, before or instead of confining its execution. SecureVibeBench anchors 105 C/C++ secure-coding tasks to genuine historical vulnerabilities drawn from 41 real open-source projects via OSS-Fuzz, with clearly marked introduction points, and judges agent-produced fixes with a combination of functional tests and static and dynamic se- curity analysis; across five widely used coding agents paired with five language models, even the strongest combination produced solutions that were correct and secure only 23.8% of the time [44]. This result is a caution against relying on generation quality as an execution-security control: the agents in this study are, on the authors’ own evaluation, more often wrong about security than right. 4.13. Scope-creep and overeager-action measure- ment (1 paper) 13. Scope-creep / overeager-action msmt. MeasurementRC3 Scoped taskExtra actionsOvereager rate Figure 13. Category 13 (scope-creep measurement): scoped task→ extra actions→ overeager rate. This category measures a failure mode that is neither malicious nor a policy violation in the traditional sense: a benign, correctly authorized task completed by taking ad- ditional, unrequested actions. Using a purpose-built bench- mark of 500 validated scenarios run across four agent prod- ucts and six base models, roughly 7,500 runs, the authors find permissive-framework agents such as Claude Code, Codex CLI, and Gemini CLI show substantially higher rates of unrequested action than an ask-to-continue framework such as OpenHands [45]. A striking methodological finding is that simply removing an explicit statement of authorized scope from the prompt raised the measured overeager rate on Claude Code from 0.0% to 17.1%, suggesting the agent is pattern-matching a declared-scope sentence rather than inferring task boundaries from the task itself. 4.14. Skill and plugin packaging security (1 paper) 14. Skill / plugin packaging security MeasurementRC1RC2 3rd-party skillInstall & trustThreat taxonomy Figure 14. Category 14 (skill and plugin packaging security): third-party skill→ install and trust→ threat taxonomy. Coding-agent harnesses increasingly ship a packaging layer, skills, plugins, or extensions, that a user or a market- place can install into an otherwise trusted agent. A dedicated security analysis of this layer models a four-phase lifecycle, creation, distribution, deployment, and execution, and builds a threat taxonomy of seventeen scenarios across three attack layers, validated against five confirmed real-world incidents; the authors conclude the most severe threats are structural rather than incidental, arising from the framework’s absent data-instruction boundary, a single-approval trust model that persists indefinitely after one grant, and the lack of a manda- tory security review at the marketplace level [46]. 15. Prompt-injection foundations FoundationalRC1 Untrusted contentNo separationInjected action 16. Jailbreak / alignment- attack foundations Foundationalno RC Aligned modelSuffix searchRefusal bypass 17. Agent safety-awareness evaluation Measurement(RC3) Risky scenarioLLM judgeAwareness score Figure 15. Categories 15–17, the foundational work the corpus inherits rather than proposes (prompt-injection, jailbreak, and safety-awareness foundations), in the same icon-flow language as Figures 1–14. 5. Root Causes and Structural Similarity Across the Taxonomy Section 4 organizes the corpus the way the field orga- nizes itself: by the mechanism a paper proposes or mea- sures. That grouping is useful for a reader looking for, say, every isolation architecture, but it also obscures how much of the corpus is answering variations on the same underlying design defect. This section re-reads the same 39 papers along two different axes, first asking what root cause a technique is actually a response to, independent of its category label, and second asking where in an agent’s action pipeline a technique intervenes and whether it pro- poses a mechanism or measures one. Both re-readings are our synthesis rather than a new empirical claim, and we present them as an interpretive lens, not as a replacement for Section 4’s mechanism-based grouping. 5.1. Four root causes behind seventeen categories Reading the corpus for the design defect a technique is actually a response to, rather than the mechanism it pro- poses, collapses much of the taxonomy onto four recurring root causes. RC1: no structural separation between untrusted content and control input. A transformer processes a tool’s returned data, a webpage’s text, and a user’s instruction as the same kind of token, so nothing at the architecture level distinguishes “execute this” from “this is what I found.” [41] states this explicitly as the deeper problem underlying iden- tity delegation, and the skill-packaging taxonomy identifies the same absence, which it calls the “absent data-instruction boundary,” [46] as the most severe of its seventeen threat scenarios. MCP tool poisoning is the same defect at the pro- tocol layer: a tool’s self-declared metadata is control input that a client cannot distinguish from untrusted description text [34], [36]. RC2: authorization is checked once and trusted for- ever. A permission, a validated file, or a tool’s declared be- havior is treated as durable after a single check, even though the thing it was checked against can change. PORTICO’s “lingering authority” [27], both TOCTOU papers’ stale-state race [32], [33], and MCP tool poisoning’s validate-once- trust-forever pattern [34] are the same failure at three differ- ent layers: a permission grant, a filesystem or webpage read, and a tool registration are all treated as valid indefinitely after the moment they were approved. The skill-packaging taxonomy’s “single-approval trust model that persists indef- initely after one grant” [46] is the same defect again, one category up, at the level of an installed plugin rather than a single permission or a single file. RC3: a mechanism encodes whether an action is permitted, not whether this invocation matches intent. A capability token, a Datalog rule, or a command denylist all answer a binary question, is this action type allowed, which is a different question from whether this specific, authorized action should happen right now. Scope-creep measurement shows an agent taking additional, unrequested but individually authorized actions at rates that swing from 0.0% to 17.1% depending on prompt phrasing alone [45], which is not a permission failure since every action the agent took was within its granted capability. SEAgent’s framing of privilege escalation as a confused-deputy problem [28] is the same gap from the opposite direction: an agent using its own legitimately granted authority on another agent’s behalf is, again, an authorized action occurring at the wrong moment. RC4:defensesarevalidatedagainstauthor- constructed attackers rather than empirically observed real-world failure. Every isolation and access-control paper in Section 4 reports a defense rate against attacks the authors themselves constructed. ShellSieve and YoloFS show what happens when the attacker set instead comes from real deployed artifacts, 1,709 scraped denylists and 290 misuse reports respectively, and find fragility rates of 69.0% to 98.6% [14], [31]. This is the same defect Gap 2 (Section 6) identifies at the level of a single comparison; RC4 states it as the general pattern behind that gap and behind Gap 1’s absence of shared benchmarks. Table 2 maps each of the taxonomy’s seventeen cate- gories to the root cause, or root causes, it is a response to. Six of the seventeen categories map to more than one root cause, eight map to exactly one, and three, isolation architec- tures, systems-security framing, and the jailbreak/alignment- attack foundations, are not a direct response to any of the four (a category can still be valuable, as isolation archi- tectures clearly are, without targeting one of these four specific defects; isolation bounds the blast radius of an action regardless of which root cause produced it, which is a different kind of contribution). No category in our corpus is a response to more than two of the four root causes, meaning no single existing mechanism claims to, or plausibly could, fix more than half of the recurring defects we identify. Figure 16 presents the same mapping visually: each category is drawn once, with an edge to every root cause it addresses, so a category with two edges is one of the nine that targets more than one recurring defect. The four root causes are easiest to see side by side as causal chains rather than as abstract statements, since each is really a claim about which step in a chain of events breaks down. Figure 17 instantiates each root cause with one representative paper from the corpus, tracing the same four-step shape, precondition, intervening step, action, out- come, and marking where in that chain the failure actually occurs. Reading the four chains together makes a pattern in the pattern visible: RC1 and RC2 are failures of missing state (no tag distinguishing content from instruction; no re- check step marking when a grant expired), while RC3 and RC4 are failures of an existing mechanism answering the wrong question (permitted-in-general instead of intended- right-now; validated against the wrong attacker instead of the right one). No single existing defense in our corpus addresses both a missing-state failure and a wrong-question failure at once, which is a second, independent way of seeing the same ceiling Section 6 identifies empirically: partial defenses compose in the taxonomy, but they do not compose TABLE 2. MAPPING OF TAXONOMY CATEGORIES TO ROOT CAUSES. A CATEGORY MAPS TO RC1–RC4 AS DEFINED IN SECTION 5.1; A DASH MEANS THE CATEGORY’S PRIMARY CONTRIBUTION IS A MECHANISM OR MEASUREMENT THAT DOES NOT TARGET ONE OF THE FOUR RECURRING DEFECTS DIRECTLY (FOR EXAMPLE, SYSTEMS- SECURITY FRAMING ARGUES FOR A CHANGE IN PERSPECTIVE RATHER THAN FIXING A SPECIFIC DEFECT). CategoryRC1: no data/ control separation RC2: checked once, trusted forever RC3: permitted but not intended now RC4: author-built attacker model Isolation architectures– Escape and adversarial benchmarks–X Access control and capability models–X– Policy enforcement fragility–(x)X Time-of-check to time-of-use–X– MCP-specific threats and defensesX(x)– Systems-security framing– Harness-level capability evaluation–X Identity and credential delegationX– Execution provenance and auditability–(x)(x)– Network egress control(x)–X– Static analysis of agent-generated code–X Scope-creep and overeager-action measurement–X– Skill and plugin packaging securityXX– Prompt-injection foundationsX– Jailbreak and alignment-attack foundations– Agent safety-awareness evaluation–(x)– Seventeen Taxonomy Categories Collapsed onto Four Root Causes solid edge = primary (X) | dashed edge = secondary ((x)) Isolation architectures no direct RC Escape / adversarial benchmarks Access control & capability models Policy enforcement fragility Time-of-check to time-of-use MCP-specific threats & defenses Systems-security framing no direct RC Harness-level capability evaluation Identity & credential delegation Execution provenance & auditability Network egress control Static analysis of agent-generated code Scope-creep / overeager-action msmt. Skill / plugin packaging security Prompt-injection foundations Jailbreak / alignment- attack foundations no direct RC Agent safety-awareness evaluation RC1 No data/control separation RC2 Checked once, trusted forever RC3 Permitted ≠ intended now RC4 Author-built attacker model Figure 16. Seventeen taxonomy categories collapse onto four recurring root causes. Dashed edges indicate a category addresses the root cause as a secondary rather than primary contribution. along these chains. 5.2. A pipeline-stage and role reading of the same corpus A second, orthogonal way to read the corpus is to ask, for each category, where in an agent’s action pipeline its dominant contribution intervenes (before an action is taken, while it is being taken, or after it has already happened), and whether the category’s dominant contribution is a proposed mechanism or an empirical measurement of whether an existing mechanism holds. Table 3 reports this classification. We classify at the category level by each category’s stated primary contribution, consistent with the single-category assignment described in Section 3; several individual papers within a category combine more than one role, which we already report as a limitation in Section 9, so Table 3 should be read as the dominant pattern rather than an exhaustive per-paper claim. Two patterns stand out. First, five of the six mechanism- proposing categories, isolation architectures, access control, time-of-check to time-of-use, identity and credential dele- gation, and network egress control, intervene pre-action or at-action, gating a decision before or as it is made, split- ting evenly at eight papers pre-action and eight at-action, while every one of the eight categories whose dominant contribution is a measurement, escape benchmarks, enforce- ment fragility, MCP-specific threats and defenses, harness- level capability evaluation, static analysis of generated code, scope-creep measurement, skill and plugin packaging secu- rity, and agent safety-awareness evaluation, evaluates a gate, a threat surface, or a generated artifact after the fact, by running real or adversarial trajectories through it, auditing deployed servers or denylists, or scoring already-produced code, and counting failures. The corpus proposes gates and separately measures whether gates hold, but, consistent with Gap 1 and Gap 2 (Section 6), the two groups of papers are not the same papers: none of the mechanism categories in our corpus report their own defense rate under the specific adversarial corpora the measurement categories have already built and released. Second, execution provenance and au- ditability is the only post-action mechanism category in the corpus, at one paper, and is structurally the closest thing to a backstop for RC2 and RC3: a technique that catches a stale-authorization or scope-mismatch failure after it has already been enacted cannot prevent the action, but it is the only stage in the pipeline where such a failure is currently caught at all once a pre-action gate has already been passed. 6. Cross-Cutting Gaps The taxonomy in Section 4 is organized the way the field organizes itself, by mechanism. Reading across cate- gories rather than within any one surfaces five gaps that are invisible from inside a single category. 6.1. Gap 1: isolation and access control are not evaluated against each other Every isolation architecture we reviewed is evaluated against a fixed attacker model and reports its own over- head and defense rate. Every access-control or capability paper does the same, independently, against a different fixed attacker model. None of the 5 isolation papers and none of the 6 access-control papers in our corpus evaluate their mechanism on a shared benchmark against the other category’s mechanism, so a reader cannot currently learn whether a capability system such as PORTICO [27] or SEAgent [28] is more or less effective than an isolation boundary such as IsolateGPT [15] or ceLLMate [16] at stopping the same attack, or whether the two are comple- mentary layers whose combination is stronger than either alone. SandboxEscapeBench [20] and RedCode [21] are the closest things to a shared benchmark in the corpus, but neither is used, in the papers we surveyed, to compare an isolation architecture against an access-control system head to head. 6.2. Gap 2: defenses are not re-evaluated under known enforcement failure rates ShellSieve reports that 69.0% to 98.6% of real com- mand denylists are fragile [31], and YoloFS documents the same class of failure from 290 real reports [14]. Neither the isolation architectures nor the access-control papers in our corpus re-evaluate their own defense under the specific bypass techniques ShellSieve’s pipeline discovers. A defense that reports a strong result against a fixed, hand-constructed attacker set is not the same claim as a defense that survives against denylist bypasses empirically shown to defeat the majority of real-world policies. This gap is at least partially addressable without new infrastructure: ShellSieve’s own bypass corpus is a natural adversarial test set for any of the access-control papers in Section 4. 6.3. Gap 3: TOCTOU and MCP threats are studied as separate literatures A time-of-check-to-time-of-use race and a tool- poisoning attack on MCP tool metadata are both, struc- turally, a validate-then-act sequence in which the validated state can change before the action executes: TOCTOU work validates a file or a webpage and then acts on stale content [32], [33], while the MCP tool-poisoning threat validates a tool’s declared behavior once at discovery time and then trusts it on every subsequent call [34], [36]. None of the papers in either category cites the other, and neither literature uses the other’s vocabulary, even though a defense against one class, re-validating state immediately before use rather than caching an earlier check, is a candidate defense against the other. A unified treatment of validate-then-act races across both settings is, to our knowledge, not yet written. Four Root Causes, Six-Step Causal Chains from a Representative Paper Each card shows the same abstract chain (precondition, user request, mechanism check, agent decision, action, effect) instantiated by one paper. Green rings mark steps that behave as the mechanism claims; the red BREAK arrow marks the exact link where the chain fails. The paired boxes below each chain contrast the defense the mechanism assumes with what the paper reports actually happening. RC1No data / control separation stage: pre-action check, at-action failure worked example: MCP tool-poisoning: MCP Threat Model (Huang et al. 2026) Precondition attacker controls a tool description → User request benign task issued to agent → Mechanism check policy filter over user text BREAK → Agent context user text + tool text concatenated → LLM decision reads tool text as instructions → Effect attacker action executed as if user- issued expected defense: mechanism separates trusted user tokens from untrusted tool-returned tokens before the LLM sees them what actually happens: context window has no channel tag; step 4 concatenates both, so step 5 cannot distinguish origin why the chain fails: the pre-action policy is defined over the wrong input; nothing in the pipeline re-establishes provenance before the LLM decision Also drives: Identity & credential, Network egress (x), Skill / plugin, Prompt-injection RC2Checked once, trusted forever stage: pre-action grant, missing at-action re-check worked example: Lingering authority: PORTICO (Santos-Grueiro 2026) Precondition agent granted a scoped capability at t=0 → Mechanism check grant validated against policy → User request later task in same session, t>0 BREAK → State drifts revocation / resource change unseen → Authority reused cached token replayed, no re-check → Effect action on stale basis, granted context gone expected defense: mechanism re-validates the capability against current policy at every action, not only at grant time what actually happens: grant is validated once and cached for the session; steps 4-5 reuse it without any freshness check why the chain fails: the validity window silently outlives the condition it certified; no second read of the policy is scheduled between grant and use Also drives: Time-of-check to, MCP-specific threats (x), Execution provenance (x), Skill / plugin RC3Permitted but not intended right now stage: pre-action authorisation, at-action gap worked example: Scope-creep measurement: Overeager Coding Agents (Qu et al. 2026) Precondition capability set: action type is allowed → User request narrow ask, e.g. summarise a file → Agent plan adds extra, individually in-scope steps → Mechanism check per-action authorisation succeeds BREAK → Action fires each step individually authorised → Effect unintended aggregate: 0-17.1% by phrasing expected defense: mechanism asks whether this specific invocation was intended by the user, not only whether the action type is allowed what actually happens: capability check answers action-type only; the intent-vs-plan gap is never queried before the action fires why the chain fails: capability answers "is this action type allowed" but never "should this specific invocation happen now"; scope-creep is silent under a correct per-action policy Also drives: Access control &, Policy enforcement (x), Execution provenance (x), Network egress, Agent safety-awareness (x) RC4Author-built attacker model stage: post-hoc measurement of an at-action mechanism worked example: Policy fragility: ShellSieve (Chen and Lin 2026) / YoloFS (Zhong et al. 2026) Precondition defense designed against author's threat model → Defense built denylist / classifier trained in-lab → In-paper eval high reported rate on curated tests BREAK → Real corpus 1,709 denylists / 290 field reports → External attacker distribution shifts off training set → Effect 69.0-98.6% bypass rate in the wild expected defense: mechanism is evaluated against an attacker distribution collected independently of the defense authors what actually happens: reported rate is measured only against the same authors' benchmark; the field distribution is never held out why the chain fails: a defense rate measured only against its own authors' attacker never encounters the distribution it will actually face; the failure is in the evaluation protocol, not in the mechanism it certifies Also drives: Escape /, Harness-level, Static analysis of Figure 17. The same four causal chains, each instantiated by one representative paper from the corpus. The break point (red) is a different step in each chain, showing that “authorization” fails for structurally different reasons across RC1–RC4. Each card also lists the other taxonomy categories whose techniques map to the same root cause (“Also drives”). TABLE 3. CATEGORIES CLASSIFIED BY PIPELINE STAGE (PRE-ACTION, AT-ACTION, POST-ACTION) AND BY ROLE (MECHANISM VS. MEASUREMENT). CELL ENTRIES ARE THE NUMBER OF PAPERS IN THAT CATEGORY. CategoryPapersPipeline stageRole Isolation architectures5At-actionMechanism Escape and adversarial benchmarks6Post-hocMeasurement Access control and capability models6Pre-actionMechanism Policy enforcement fragility2Post-hocMeasurement Time-of-check to time-of-use2At-actionMechanism MCP-specific threats and defenses4Post-hocMeasurement Systems-security framing2–Perspective Harness-level capability evaluation1Post-hocMeasurement Identity and credential delegation2Pre-actionMechanism Execution provenance and auditability1Post-actionMechanism Network egress control1At-actionMechanism Static analysis of agent-generated code1Post-hocMeasurement Scope-creep and overeager-action measurement1Post-hocMeasurement Skill and plugin packaging security1Post-hocMeasurement Prompt-injection foundations2–Foundational Jailbreak and alignment-attack foundations1–Foundational Agent safety-awareness evaluation1Post-hocMeasurement Total39 6.4. Gap 4: every enforcement mechanism assumes an honest policy author The access-control and enforcement papers in our cor- pus differ in mechanism, Datalog reference monitors [30], capability tokens [27], deterministic pre-action gates [29], information-flow graphs [28], but every one of them assumes the policy itself is correctly specified by a trustworthy author and asks only whether that policy is then enforced. None studies what happens when the policy is wrong, overly permissive by mistake, internally contradictory, or where a policy author under time pressure grants broader scope than intended because narrower scoping is more work. Given that ShellSieve’s 69–98% fragility figure is measured against denylists that real developers wrote and shipped [31], policy- authoring error is plausibly at least as large a source of real- world risk as enforcement failure, and it is the one part of the pipeline this literature does not yet measure. 6.5. Gap 5: scope creep is measured but not ad- dressed by any enforcement mechanism The scope-creep measurement in our corpus finds overeager rates on Claude Code jumping from 0.0% to 17.1% depending on prompt phrasing alone, with no change to the task or the model [45]. This is not the threat model any access-control or capability paper in Section 4 is built for: a capability token, a Datalog policy, or a pre-action gate all assume the dangerous action is either authorized or it is not, but an overeager action is, by the measurement’s own definition, an action the agent was never asked to take and that a static permission grant would not necessarily forbid, since the agent may already hold the capability it is misusing for an unrequested purpose. None of the access-control papers we reviewed cites this measurement, and the measurement paper does not evaluate whether any of the reviewed access-control mechanisms would have caught the overeager actions it documents. A mechanism that constrains what an agent is allowed to do does not, by construction, constrain whether an authorized capability is invoked when it should not be, and this literature does not yet distinguish the two problems, let alone address the second. The five gaps above are easiest to state one at a time, but they share a common structural cause: the taxonomy in Section 4 groups papers by the mechanism a paper pro- poses, and that grouping systematically separates categories that are, by the root-cause and pipeline-stage readings of Section 5, close cousins. Figure 18 makes this concrete by scoring every pair of the seventeen categories on shared root causes and shared pipeline stage. Several of the highest off-diagonal scores connect exactly the categories Gaps 1–3 argue should already be in dialogue, isolation architectures and access control (Gap 1), enforcement fragility and MCP- specific threats (Gap 2), and time-of-check-to-time-of-use and MCP-specific threats (Gap 3), yet none of the underly- ing papers cites across that pair. The heatmap does not show a corpus that is randomly fragmented; it shows a corpus whose highest-similarity pairs are consistently the ones the field has not yet connected, which is a second, independent way of observing the same gaps Sections 6.1–6.3 identify by close reading. 7. Related Work The closest related work is four broader agentic-AI- security surveys we excluded from the taxonomy itself because each is a secondary synthesis of the field rather than a primary execution-security contribution. [1] orga- nizes over 20 studies into a four-branch attack taxonomy (prompt-level injection, knowledge-base poisoning, tool and plug-in exploits, multi-agent emergent threats) and reviews sandboxes as one item within a broader defense category alongside input sanitization and access control. [2] reviews over 260 papers across three pillars, applications, threats, and defenses, spanning the full agent lifecycle and the use of agents for offensive and defensive security work, with execution isolation appearing as one defense among many rather than as a dedicated subject. [3] is itself titled as an SoK and synthesizes 78 studies into a three-part taxon- omy of delivery vectors, attack modalities, and propagation behaviors specifically for prompt injection against coding assistants, cataloging 42 attack techniques and 18 defenses; sandboxing appears as one architectural concern feeding its proposed defense-in-depth framework rather than as its own category, and its scope, prompt injection specifically, is narrower than and largely orthogonal to execution security, since a perfectly sandboxed agent can still be success- fully injected, and a perfectly resistant model still needs a sandbox if it is ever compromised. [4] reviews 50 papers on open agentic platforms and proposes a six-dimensional analytical taxonomy and a platform security scoring system, concluding the field has strong coverage of attack cataloging and benchmarks but weak coverage of deployment controls, operational governance, and capability revocation, a con- clusion this paper’s taxonomy independently supports from a different literature sample. All four surveys are valuable for the breadth they cover, applications, multi-agent risk, prompt-level attacks, platform governance, that this paper does not attempt; the gap they leave, and the one this paper is written to fill, is a systematization of execution security specifically, with enough granularity to compare isolation architectures against capability models, benchmarks against the defenses they are meant to stress-test, and enforcement mechanisms against the empirical fragility rates measured against real deployed policies. A second and fast-moving line of recent work develops defenses at the injection layer, aiming to stop a malicious instruction from ever reaching the model in the first place. MELON detects indirect prompt injection by re-executing the agent loop with masked tool results and flagging be- havioral divergence [51]; PromptArmor screens tool outputs for injected instructions before they re-enter the context window [52]; and ARGUS conditions its detector on the task context to catch instructions that are only adversarial relative to the current goal [53]. These 2025–2026 mech- anisms are complementary to, but deliberately outside, our scope: they target the boundary at which a model is com- promised, whereas our corpus systematizes the execution- layer containment that must hold after compromise, on the premise, reinforced by a recent result that no injection defense achieves perfect recall under adaptive pressure [54], that a residual injection rate must be assumed rather than engineered to zero. The two layers are independent axes of the same problem, and a deployed coding agent needs both; we treat injection defenses as the upstream complement to, not a substitute for, the sandboxing, capability, provenance, and policy-enforcement mechanisms catalogued here. 8. Discussion The volume of work in this space, 39 papers meeting our inclusion criteria in under two years, indicates the field recognizes execution security as a real and urgent problem. Table 4 breaks this corpus down by publication year and shows the growth is not linear: the majority of the corpus was published in the most recent year alone, consistent with execution security emerging as an active concern only after coding agents began operating with broad, largely unsandboxed tool access. The four disclosed CVEs in Section 2.3 and the OWASP Top 10’s inclusion of excessive agency as a named risk predate or overlap most of this corpus and show the un- derlying concern is not speculative [5]–[8], [11]. What the Pairwise Category Similarity Across the Seventeen-Category Taxonomy Similarity = cosine similarity of each category's (RC1,RC2,RC3,RC4) weight vector (X=1.0, (x)=0.5, --=0), plus +0.15 if the two categories share the same dominant pipeline stage (pre-action / at-action / post-action / post-hoc). Diagonal = self (excluded, shown dark). Categories with an all-zero RC vector (isolation architectures, systems-security framing, jailbreak/alignment- attack foundations) are similar only via shared pipeline stage. 1. Isolation2. Escape /3. Access control &4. Policy enforcement5. Time-of-check to6. MCP-specific threats7. Systems-security8. Harness-level9. Identity & credential10. Execution provenance11. Network egress12. Static analysis of13. Scope-creep /14. Skill / plugin15. Prompt-injection16. Jailbreak / alignment-17. Agent safety-awareness 1. Isolation 2. Escape / 3. Access control & 4. Policy enforcement 5. Time-of-check to 6. MCP-specific threats 7. Systems-security 8. Harness-level 9. Identity & credential 10. Execution provenance 11. Network egress 12. Static analysis of 13. Scope-creep / 14. Skill / plugin 15. Prompt-injection 16. Jailbreak / alignment- 17. Agent safety-awareness .15.15 .00.15.00.00.15.15.15 .32.71.32.15.00.63.71.50.71 .00.32.15.00.32.40.00.60.15.60 .15.71.45.71.15.71 .15.32.15.45.15.89.32.40.15.15.00.89.15 .00.00.15.00.15.15.15 .15.89.45.71.00 .00.32.71.32.63.71.50.71 .15.63.40.15.40.45.63.89.32.45.89 .00.00.15.00.15.15.15 .15.71.60.15.15.71.89.15.15.00 .15.50.15.71.00.15.71.50.32.15.15.71.15 .89.00.45.71 .15.71.60.15.15.71.89.15.00.15 Figure 18. Pairwise similarity across the seventeen taxonomy categories, scored by cosine similarity of each category’s root-cause weight vector plus a bonus for sharing a dominant pipeline stage. High off-diagonal scores concentrate on category pairs that Gaps 1–3 argue are studied in isolation despite addressing structurally related failures. TABLE 4. CORPUS SIZE BY PUBLICATION YEAR. YearPapers 20234 20244 202514 202617 taxonomy in Section 4 shows is that the field’s energy has gone almost entirely into building new mechanisms, five isolation architectures, six access-control frameworks, four MCP-specific defenses, two identity-delegation proposals, and comparatively little into cross-mechanism evaluation. This is a familiar pattern in a young subfield: mechanism proposals are easier to publish than the harder comparative and adversarial evaluation work that would tell a practitioner which mechanism to actually deploy, or whether to deploy more than one. The newer categories in our corpus, execu- tion provenance, network egress control, static analysis of generated code, scope-creep measurement, and skill pack- aging security, each have exactly one paper, which is either a sign these are genuinely nascent directions or a sign our search has not yet found the rest of a larger literature; we treat this as an open question the released corpus file is meant to help answer as more work appears. The two enforcement-fragility papers in our corpus are, in our reading, the most consequential finding in the whole literature, precisely because they measure real, shipped ar- tifacts rather than a mechanism’s own claimed guarantee. A defense that has not been tested against ShellSieve’s bypass corpus [31] or against the failure patterns YoloFS documents [14] has not yet been tested against the kind of policy a real team would actually write under time pressure. We would encourage authors of future isolation and access- control papers to treat these two papers’ adversarial corpora as a standard evaluation baseline, in the same way image classification adopted common corruption benchmarks once they existed, rather than evaluating only against attacks the authors constructed themselves. 9. Limitations This is a systematization, not a measurement study, and its central limitation is coverage rather than measurement error. Our search was iterative and citation-following rather than exhaustive, and arXiv posting norms in this area mean some relevant work may not surface under the search terms we used, or may have been posted after this paper was written; the released corpus file is intended to make later extension straightforward rather than to claim completeness. The categorization itself involves judgment: several papers, notably SEAgent [28] and FORGE [30], combine elements of more than one category, and we assign each to the single category that best matches its primary contribution rather than allowing multiple category membership, which understates the degree of overlap between categories. Eight of our seventeen categories currently contain exactly one paper each (identity delegation and four others contain two); we report this honestly in Section 8 as ambiguous between a genuinely nascent research direction and an incomplete search, and a reader should weight claims about those categories accordingly. The verification protocol confirms that a paper’s title, authors, and venue match its abstract page and catches gross misattribution, of the kind we found and corrected for two candidates during this review, but it does not constitute independent replication of any paper’s empirical claims; we report those claims as stated by their authors. The four CVEs in Section 2.3 were confirmed directly against NVD listing pages, which we treat as author- itative for the affected product, version, and CVSS score, but we did not independently reproduce any of the underlying exploits. Finally, the five gaps in Section 6 are argued from the absence of a citation or a shared benchmark across categories, which is a real but indirect form of evidence; it is possible relevant cross-category work exists in a venue or preprint outside the corpus we searched. 10. Future Work The most direct next step is closing Gap 1 empirically: running a small number of representative isolation archi- tectures and access-control mechanisms against a shared attacker corpus, such as SandboxEscapeBench’s introduced weaknesses [20] or RedCode’s risky-operation suite [21], and reporting whether the two categories of defense are substitutes or complements. Closing Gap 2 requires no new infrastructure at all: re-running ShellSieve’s released bypass corpus [31] against any of the access-control mechanisms in Section 4 is a direct, low-cost evaluation that would turn a mechanism’s untested claim into a measured one. Gap 3 calls for a unified formal treatment of validate-then- act races that covers both the filesystem and browser-state TOCTOU settings and the MCP tool-metadata setting under one model, so that a mitigation designed for one setting can be checked against the other without translation. Gap 4 is, in our view, the most consequential of the first four: an empirical study of policy-authoring error itself, in the style of ShellSieve’s denylist study but aimed at the access-control policies proposed in Section 4 rather than at command denylists, would tell the field whether the mechanisms it has built are being undermined more by weak enforcement or by policies that were never correctly specified in the first place. Gap 5 calls for the reverse experiment to the one OverEager- Bench already ran [45]: taking the overeager trajectories that benchmark has already collected and replaying them against a capability system such as PORTICO [27] or an information-flow framework such as SEAgent [28] to mea- sure directly what fraction of scope creep an authorization mechanism built for a different threat model happens to catch, rather than assuming from the mechanism’s design alone that it would or would not. 11. Conclusion We systematized 39 papers on AI coding agent execution security, published between 2023 and 2026, into 17 verified categories, correcting two misattributions found during ver- ification along the way and independently confirming four disclosed, patched CVEs, two of them in Claude Code itself, directly against the NIST National Vulnerability Database. Four existing broader surveys of agentic AI security dis- cuss sandboxing only as one entry among many defenses, or treat prompt injection specifically rather than execution security generally; this paper is the first, to our knowledge, to treat execution security as a subject with its own internal structure. Reading across the taxonomy rather than within any single category surfaces five gaps that individual pa- pers cannot see from inside their own category: isolation and access control are evaluated in isolation from each other, defenses are not re-tested against measured real-world enforcement failure rates, TOCTOU and MCP threats are treated as unrelated despite sharing a common structure, every enforcement mechanism in the literature assumes a policy author who does not make mistakes, and a newly measured failure mode, benign scope creep at rates up to 17.1%, is addressed by no access-control mechanism in the corpus. Closing these gaps, not proposing another isolation mechanism or access-control model, is where we believe the field’s next real progress lies. References [1]A. Dehghantanha and S. Homayoun, “SoK: The attack surface of agentic AI, tools, and autonomy,” arXiv preprint arXiv:2603.22928, 2026. [2]A. Shahriar, M. N. Rahman, S. Ahmed, F. Sadeque, and M. R. Parvez, “A survey on agentic security: Applications, threats and defenses,” arXiv preprint arXiv:2510.06445, 2025. [3]N. Maloyan and D. Namiot, “Prompt injection attacks on agentic coding assistants: A systematic analysis of vulnerabilities in skills, tools, and protocol ecosystems,” arXiv preprint arXiv:2601.17548, 2026. [4]S. Chen, Q. Wang, G. Yu, X. Wang, and L. Zhu, “Clawed and dangerous: Can we trust open agentic systems?” arXiv preprint arXiv:2603.26221, 2026. [5]NIST National Vulnerability Database, “CVE-2024-21626: runc con- tainer escape via leaked file descriptor referencing the host working directory,” MITRE / NIST NVD, Tech. Rep., 2024, “Leaky Vessels”; also assigned GHSA-xr7r-f8xq-vfvv. [6]—, “CVE-2025-53773: Command injection in GitHub copilot and visual studio,” MITRE / NIST NVD, Tech. Rep., 2025, cVSS 3.1 base score 7.8 (High); affects Visual Studio 2022 17.14.0 to 17.14.11. [7]—, “CVE-2025-59536: Code injection in Claude Code via startup trust dialog bypass,” MITRE / NIST NVD, Tech. Rep., 2025, cVSS 3.1 base score 8.8 (High); CWE-94; fixed in Claude Code 1.0.111; GHSA-4fgq-fpq9-mr3g. [8]—, “CVE-2026-21852: Data exfiltration in Claude Code project- load flow before trust confirmation,” MITRE / NIST NVD, Tech. Rep., 2026, cVSS 3.1 base score 7.5 (High); fixed in Claude Code 2.0.65. [9]M. Christodorescu, E. Fernandes, A. Hooda, S. Jha, J. Rehberger, K. Chaudhuri, X. Fu, K. Shams, G. Amir, J. Choi, S. Choudhary, N. Palumbo, A. Labunets, and N. V. Pandya, “Systems security foundations for agentic computing,” arXiv preprint arXiv:2512.01295, 2025. [10] X. Li, D. Huang, J. Li, H. Cai, Z. Zhou, W. Dong, X. Wang, and Y. Liu, “A vision for access control in llm-based agent systems,” arXiv preprint arXiv:2510.11108, 2025. [11] OWASPFoundation,“OWASPtop10forlarge languagemodelapplications,”https://owasp.org/ w-project-top-10-for-large-language-model-applications/, 2025. [12] Zero Day Initiative, “Pwn2Own Berlin 2026: Coding agents category rules and day one results,” https://w.thezdi.com/blog/2026/5/13/ pwn2own-berlin-2026-day-one-results, 2026, category and eligibility rules per the event announcement; targets Claude Code, OpenAI Codex, and Cursor. [13] E. Kovacs, “Hackers earn over $1.29 million at Pwn2Own Berlin 2026,” SecurityWeek, https://w.securityweek.com/, 2026, 47 unique zero-days; total payout $1,298,250. [14] S. W. Zhong, J. Liao, J. Liu, M. Zheng, A. C. Arpaci-Dusseau, and R. H. Arpaci-Dusseau, “Don’t let ai agents yolo your files: Shifting information and control to filesystems for agent safety and autonomy,” arXiv preprint arXiv:2604.13536, 2026. [15] Y. Wu, F. Roesner, T. Kohno, N. Zhang, and U. Iqbal, “Isolategpt: An execution isolation architecture for llm-based agentic systems,” in Network and Distributed System Security Symposium (NDSS), 2025, arXiv:2403.04960. [16] L. Meng, H. Feng, I. Shumailov, and E. Fernandes, “cellmate: Sand- boxing browser ai agents,” arXiv preprint arXiv:2512.12594, 2025. [17] Y. Piao, H. Min, H. Su, L. Zhang, L. Wang, Y. Yin, X. Wu, Z. Xu, L. Qu, H. Li et al., “Agentbay: A hybrid interaction sandbox for seamless human-ai intervention in agentic systems,” arXiv preprint arXiv:2512.04367, 2025. [18] Y. Dong, J. He, S. Liu, Y. Hou, D. Du, Z. Xu, S. Yu, B. Yang, Y. Xia, and H. Chen, “Deltabox: Scaling stateful ai agents with millisecond- level sandbox checkpoint/rollback,” arXiv preprint arXiv:2605.22781, 2026. [19] B. Yan, “Fault-tolerant sandboxing for ai coding agents: A trans- actional approach to safe autonomous execution,” arXiv preprint arXiv:2512.12806, 2025. [20] R. Marchand, A. O. Cathain, J. Wynne, P. M. Giavridis, S. Dev- erett, J. Wilkinson, J. Gwartz, and H. Coppock, “Quantifying fron- tier llm capabilities for container sandbox escape,” arXiv preprint arXiv:2603.02277, 2026. [21] C. Guo, X. Liu, C. Xie, A. Zhou, Y. Zeng, Z. Lin, D. Song, and B. Li, “Redcode: Risky code execution and generation benchmark for code agents,” in Advances in Neural Information Processing Systems (NeurIPS) Datasets and Benchmarks Track, 2024, arXiv:2411.07781. [22] R. Rabin, J. Hostetler, S. McGregor, B. Weir, and N. Judd, “Sandbox- eval: Towards securing test environment for untrusted code,” arXiv preprint arXiv:2504.00018, 2025. [23] Y. Ruan, H. Dong, A. Wang, S. Pitis, Y. Zhou, J. Ba, Y. Dubois, C. J. Maddison, and T. Hashimoto, “Identifying the risks of LM agents with an LM-emulated sandbox,” in International Conference on Learning Representations (ICLR), 2024, arXiv:2309.15817. [24] Q. Zhan, Z. Liang, Z. Ying, and D. Kang, “InjecAgent: Benchmarking indirect prompt injections in tool-integrated large language model agents,” in Findings of the Association for Computational Linguistics: ACL, 2024, arXiv:2403.02691. [25] E. Debenedetti, J. Zhang, M. Balunovi ́ c, L. Beurer-Kellner, M. Fis- cher, and F. Tram ` er, “AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents,” in Neural Information Processing Systems Datasets and Benchmarks Track (NeurIPS D&B), 2024, arXiv:2406.13352. [26] C. Buhler, M. Biagiola, L. D. Grazia, and G. Salvaneschi, “Agent- bound: Securing execution boundaries of ai agents,” arXiv preprint arXiv:2510.21236, 2025. [27] I. Santos-Grueiro, “Lingering authority: Revocable resource- and-effectcapabilitiesforcodingagents,”arXivpreprint arXiv:2606.22504, 2026. [28] Z. Ji, D. Wu, W. Jiang, P. Ma, Z. Li, Y. Gao, S. Wang, and Y. Li, “Taming various privilege escalation in llm-based agent systems: A mandatory access control framework,” arXiv preprint arXiv:2601.11893, 2026. [29] U. Uchibeke, “Before the tool call: Deterministic pre-action autho- rization for autonomous ai agents,” arXiv preprint arXiv:2603.20953, 2026. [30] N. Palumbo, S. Choudhary, J. Choi, G. Amir, P. Chalasani, and S. Jha, “Formal policy enforcement for real-world agentic systems,” arXiv preprint arXiv:2602.16708, 2026. [31] C. Chen and Z. Lin, “One goal, many commands: Characterizing denylist fragility in ai agents,” arXiv preprint arXiv:2606.15549, 2026. [32] D. Lilienthal and S. Hong, “Mind the gap: Time-of-check to time-of-use vulnerabilities in llm-enabled agents,” arXiv preprint arXiv:2508.17155, 2025. [33] L. Jiang, Z. Liu, H. Luo, and Z. Lin, “Atomicity for agents: Expos- ing, exploiting, and mitigating toctou vulnerabilities in browser-use agents,” arXiv preprint arXiv:2603.00476, 2026. [34] C. Huang, X. Huang, N. P. Tran, and A. M. Fard, “Model context protocol threat modeling and analyzing vulnerabilities to prompt in- jection with tool poisoning,” arXiv preprint arXiv:2603.22489, 2026. [35] X. Hou, Y. Zhao, S. Wang, and H. Wang, “Model context protocol (mcp): Landscape, security threats, and future research directions,” arXiv preprint arXiv:2503.23278, 2025. [36] M. M. Hasan, H. Li, E. Fallahzadeh, G. K. Rajbahadur, B. Adams, and A. E. Hassan, “Model context protocol (mcp) at first glance: Studying the security and maintainability of mcp servers,” arXiv preprint arXiv:2506.13538, 2025. [37] W. Xing, Z. Qi, Y. Qin, Y. Li, C. Chang, J. Yu, C. Lin, Z. Xie, and M. Han, “Mcp-guard: A multi-stage defense-in-depth framework for securing model context protocol in agentic ai,” arXiv preprint arXiv:2508.10991, 2026. [38] P. Wang, Y. Li, and Y. Tian, “Reframing llm agent security as an agent-human interaction problem,” arXiv preprint arXiv:2605.24309, 2026. [39] V. Mayoral-Vilches, F. Balassone, M. Sanz-Gomez, P. Z. Landa, D. S. Prieto, M. O. Alvarez, D. Quarta, and M. Pinzger, “Towards cybersecurity superintelligence (csi): What’s the best harness for cybersecurity?” arXiv preprint arXiv:2605.28334, 2026. [40] T. South, S. Marro, T. Hardjono, R. Mahari, C. D. Whitney, D. Green- wood, A. Chan, and A. Pentland, “Authenticated delegation and authorized ai agents,” arXiv preprint arXiv:2501.09674, 2025. [41] Z. Zhou, “Governing dynamic capabilities: Cryptographic binding and reproducibility verification for ai agent tool use,” arXiv preprint arXiv:2603.14332, 2026. [42] R. Sequeira, S. Damianakis, U. Iqbal, and K. Psounis, “Agent-sentry: Bounding llm agents via execution provenance,” arXiv preprint arXiv:2603.22868, 2026. [43] S. Abdelnabi, A. Gomaa, E. Bagdasarian, P. O. Kristensson, and R. Shokri, “Firewalls to secure dynamic llm agentic networks,” arXiv preprint arXiv:2502.01822, 2025. [44] J. Chen, H. Huang, Y. Lyu, J. An, J. Shi, C. Yang, T. Zhang, H. Tian, Y. Li, Z. Li, X. Zhou, X. Hu, and D. Lo, “Secure- vibebench: Benchmarking secure vibe coding of ai agents via reconstructing vulnerability-introducing scenarios,” arXiv preprint arXiv:2509.22097, 2025. [45] Y. Qu, Y. Zhang, Y. Zhang, G. Deng, Y. Li, L. Y. Zhang, and Y. Liu, “Overeager coding agents: Measuring out-of-scope actions on benign tasks,” arXiv preprint arXiv:2605.18583, 2026. [46] Z. Li, J. Wu, X. Ling, X. Cui, and T. Luo, “Towards secure agent skills: Architecture, threat taxonomy, and security analysis,” arXiv preprint arXiv:2604.02837, 2026. [47] K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz, “Not what you’ve signed up for: Compromising real- world LLM-integrated applications with indirect prompt injection,” in ACM Workshop on Artificial Intelligence and Security (AISec), 2023, arXiv:2302.12173. [48] Y. Liu, G. Deng, Y. Li, K. Wang, T. Zhang, Y. Liu, H. Wang, Y. Zheng, and Y. Liu, “Prompt injection attack against LLM-integrated applica- tions,” arXiv preprint arXiv:2306.05499, 2023. [49] A. Zou, Z. Wang, N. Carlini, M. Nasr, J. Z. Kolter, and M. Fredrikson, “Universal and transferable adversarial attacks on aligned language models,” arXiv preprint arXiv:2307.15043, 2023. [50] T. Yuan, Z. He, L. Dong, Y. Wang, R. Zhao, T. Xia, L. Xu, B. Zhou, F. Li, Z. Zhang, R. Wang, and G. Liu, “R-Judge: Benchmarking safety risk awareness for LLM agents,” in Findings of the Association for Computational Linguistics: EMNLP, 2024, arXiv:2401.10019. [51] K. Zhu, X. Yang, J. Wang, W. Guo, and W. Y. Wang, “MELON: Provable defense against indirect prompt injection attacks in AI agents,” arXiv preprint arXiv:2502.05174, 2025. [52] T. Shi, K. Zhu, Z. Wang, Y. Jia, W. Cai, W. Liang, H. Wang, H. Alzahrani, J. Lu, K. Kawaguchi, B. Alomair, X. Zhao, W. Y. Wang, N. Gong, W. Guo, and D. Song, “PromptArmor: Simple yet effective prompt injection defenses,” arXiv preprint arXiv:2507.15219, 2025. [53] S. Weng, Y. Feng, J. Zhang, X. Xie, J. Yu, and J. Liu, “ARGUS: De- fending LLM agents against context-aware prompt injection,” arXiv preprint arXiv:2605.03378, 2026. [54] S. Abdelnabi and E. Bagdasarian, “AI agents may always fall for prompt injections,” arXiv preprint arXiv:2605.17634, 2026. Appendix A. Per-Paper Classification of the Corpus Table 5 lists every one of the 39 papers that enter the tax- onomy, together with its category, root-cause attribution, and pipeline-stage role, so that the taxonomy in Section 4 can be audited paper by paper rather than only at the category level. The row order inside each category is by publication year, then by citation key. Role codes are: mech. for a mechanism proposal, meas. for a measurement or empirical evaluation, found. for a foundational threat-vocabulary paper without a specific pipeline-stage contribution, and persp. for a systems-security framing paper. Together with Table 2 (Section 5) and Table 3 (Section 5.2), this table is what makes the reader able to reproduce the corpus and challenge individual assignments without having to re-read the whole survey. Appendix B. Verification Protocol The verification protocol referenced from Section 3 was applied uniformly to every paper in the corpus. For each candidate paper we independently fetched its own abstract page (arXiv preprint page or venue proceedings entry) and recorded the paper’s own claimed title, authors, publication year, venue, and one-sentence contribution. A candidate was admitted to the corpus only when these five fields agreed with the citation entry we had drafted from a secondary source; disagreements were resolved in favour of the pri- mary source and the citation entry was rewritten before admission. The four CVE incidents reported in Section 2.3 were verified separately, directly against the NIST National Vulnerability Database, and are counted only after the CVE- ID, affected product, affected version range, and disclo- sure date agreed with the vendor’s own advisory. The full verification pipeline (a script that walks the corpus file, fetches each paper’s abstract page, parses its metadata, and reports mismatches) is released together with the paper as part of the supplementary artifact, so any reader can re-run the check on their own machine. During verification two misattributions were caught and corrected: one paper had been listed under isolation architectures on the basis of a secondary summary but its abstract page describes a policy- enforcement measurement study, and one entry conflated two separate MCP papers by the same first author. Both corrections are reflected in the counts reported in the body of the paper. Appendix C. Extended Worked Examples per Root Cause Figure 17 shows one worked example per root cause. For completeness, we list here the additional papers in the corpus whose causal chains match each root-cause pattern, together with the specific step at which the chain breaks. These are not new attacks; they are the same break-points documented in the papers’ own evaluation sections, re-stated in the six-step (precondition, user request, mechanism check, agent decision, action, effect) framing used in Figure 17 so that they compose with the rest of the taxonomy. TABLE 5. PER-PAPER CLASSIFICATION OF THE 39-PAPER CORPUS. RC ASSIGNMENTS FOLLOW TABLE 2; PIPELINE STAGE FOLLOWS TABLE 3. PARENTHESISED RC ENTRIES DENOTE SECONDARY ATTRIBUTION. ROLE: mech. MECHANISM PROPOSAL, meas. MEASUREMENT/EVALUATION, found. FOUNDATIONAL THREAT VOCABULARY, persp. SYSTEMS-SECURITY FRAMING. #First author, yearVenuearXiv IDCategoryRCStageRole 1Luoxi Meng, 2025arXiv2512.12594Isolation architectures–at-actionmech. 2Yun Piao, 2025arXiv2512.04367Isolation architectures–at-actionmech. 3Yuhao Wu, 2025NDSS2403.04960Isolation architectures–at-actionmech. 4Boyang Yan, 2025arXiv2512.12806Isolation architectures–at-actionmech. 5Yunpeng Dong, 2026arXiv2605.22781Isolation architectures–at-actionmech. 6Yangjun Ruan, 2023ICLR2309.15817Escape/adversarial benchmarksRC4post-hocmeas. 7Edoardo Debenedetti, 2024NeurIPS D&B2406.13352Escape/adversarial benchmarksRC4post-hocmeas. 8Chengquan Guo, 2024NeurIPS2411.07781Escape/adversarial benchmarksRC4post-hocmeas. 9Qiusi Zhan, 2024ACL Findings2403.02691Escape/adversarial benchmarksRC4post-hocmeas. 10Rafiqul Rabin, 2025arXiv2504.00018Escape/adversarial benchmarksRC4post-hocmeas. 11Rahul Marchand, 2026arXiv2603.02277Escape/adversarial benchmarksRC4post-hocmeas. 12Christoph Buhler, 2025arXiv2510.21236Access control & capabilityRC2, RC3pre-actionmech. 13Xinfeng Li, 2025arXiv2510.11108Access control & capabilityRC2, RC3pre-actionmech. 14Zimo Ji, 2026arXiv2601.11893Access control & capabilityRC2, RC3pre-actionmech. 15Nils Palumbo, 2026arXiv2602.16708Access control & capabilityRC2, RC3pre-actionmech. 16Igor Santos-Grueiro, 2026arXiv2606.22504Access control & capabilityRC2, RC3pre-actionmech. 17Uchi Uchibeke, 2026arXiv2603.20953Access control & capabilityRC2, RC3pre-actionmech. 18Chuyang Chen, 2026arXiv2606.15549Policy enforcement fragilityRC4 (RC3)post-hocmeas. 19Shawn Wanxiang Zhong, 2026arXiv2604.13536Policy enforcement fragilityRC4 (RC3)post-hocmeas. 20Derek Lilienthal, 2025arXiv2508.17155TOCTOURC2at-actionmech. 21Linxi Jiang, 2026arXiv2603.00476TOCTOURC2at-actionmech. 22Mohammed Mehedi Hasan, 2025arXiv2506.13538MCP-specificRC1 (RC2)post-hocmeas. 23Xinyi Hou, 2025arXiv2503.23278MCP-specificRC1 (RC2)post-hocmeas. 24Charoes Huang, 2026arXiv2603.22489MCP-specificRC1 (RC2)post-hocmeas. 25Wenpeng Xing, 2026arXiv2508.10991MCP-specificRC1 (RC2)post-hocmeas. 26Mihai Christodorescu, 2025arXiv2512.01295Systems-security framing–persp. 27Peiran Wang, 2026arXiv2605.24309Systems-security framing–persp. 28Victor Mayoral-Vilches, 2026arXiv2605.28334Harness-level capability eval.RC4post-hocmeas. 29Tobin South, 2025arXiv2501.09674Identity/credential delegationRC1pre-actionmech. 30Ziling Zhou, 2026arXiv2603.14332Identity/credential delegationRC1pre-actionmech. 31Rohan Sequeira, 2026arXiv2603.22868Execution provenance(RC2, RC3)post-actionmech. 32Sahar Abdelnabi, 2025arXiv2502.01822Network egress controlRC3 (RC1)at-actionmech. 33Junkai Chen, 2025arXiv2509.22097Static analysis of gen. codeRC4post-hocmeas. 34Yubin Qu, 2026arXiv2605.18583Scope-creep measurementRC3post-hocmeas. 35Zhiyuan Li, 2026arXiv2604.02837Skill/plugin packagingRC1, RC2post-hocmeas. 36Kai Greshake, 2023AISec2302.12173Prompt-injection foundationsRC1–found. 37Yi Liu, 2023arXiv2306.05499Prompt-injection foundationsRC1–found. 38Andy Zou, 2023arXiv2307.15043Jailbreak/alignment foundations–found. 39Tongxin Yuan, 2024EMNLP Findings2401.10019Agent safety-awareness eval.(RC3)post-hocmeas. Additional examples for RC1 (no data / control separation) The tool-poisoning pattern from Figure 17 recurs, with the same break between the mechanism-check and agent- context steps, in skill-package foundations [46], the identity- delegation setting where a delegated token carries data the delegator did not intend [40], and the prompt-injection foun- dations literature that first isolated the mixing problem in a non-agentic setting [47], [48]. Network egress control [43] is a secondary contributor because it rebuilds the separation from the outbound side rather than at ingest. Additional examples for RC2 (checked once, trusted forever) The same stale-check pattern also appears in the TOC- TOU literature [32], [33], where the mechanism check is even earlier in the chain (at file-open or DOM-read time) and the state that drifts is the filesystem or DOM rather than the policy snapshot. Provenance and auditability work [42] contributes secondarily by making the missed re-check ob- servable after the fact, which is how many of these bugs are first noticed rather than prevented. Skill and plugin packaging [46] straddles RC1 and RC2 because the package signature is checked at install time and reused across every later invocation without a re-check. Additional examples for RC3 (permitted but not intended now) Beyond scope-creep measurement [45], RC3 is the dom- inant pattern in access-control and capability work [10], [26]–[30], each of which grants an action type and then relies on the agent’s own plan to stay within intent. Network egress control [43] also lives here when the destination is permitted but the specific per-request payload was not in- tended by the user. Agent safety-awareness evaluations [50] contribute secondarily by asking whether the model itself can flag such invocations before they fire, which if achiev- able would let a per-action mechanism address the gap that a per-type mechanism cannot. Additional examples for RC4 (author-built attacker model) The pattern from Figure 17 for policy-enforcement fragility [14], [31] also drives escape and adversarial bench- marks [20]–[25], harness-level capability evaluation [39], and static analysis of agent-generated code [44]. In each case the reported defense or detection rate is measured against a corpus generated by the same authors under a threat model of their own choosing; the failure is a property of the evaluation protocol rather than of the mechanism itself, which is why it composes with mechanisms that are otherwise unrelated (isolation, capability, static analysis). Appendix D. Reproducibility Notes The corpus, taxonomy, and all body figures and tables are generated from a single machine-readable data file by two generator scripts, one for the tables and one for the figures, plus a verifier that re-derives every category count, every root-cause count, and every pipeline-stage count from the data file and checks them against the numbers used in the body of the paper. All four artifacts, the data file, the two generators, and the verifier, are released with the paper as a supplementary artifact. The verifier takes no arguments and reports a single pass/fail summary, so any change to the corpus that would silently drift the body numbers is caught before the paper builds. The paper itself builds with a standard L A T E X/BibTeX cycle and produces a warning-free log on the current corpus.