Write-Then-Trusted

Sources#

• Attackers Target Agents via The Skill Supply Chain
• EVOMAL: Self-Poisoning in Self-Evolving Coding Agents
• GhostJacking Attacks: Half of the Fortune 500 Run These Tools. Getting Blocked by the Firewall Was the Way to Take Over Their AI Agents
• MCP Specification Changelog — 2026-07-28
• The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities
• The Week of Sandbox Escapes
• Transferable End-to-End Optimization for Indirect Long-Term Memory Poisoning in LLM Agents
• Utility Under Attack: Agent Memory Poisoning and the Limits of Content Screening and Provenance Ranking

Summary#

Pillar Research (Eilon Cohen, Dan Lisichkin, Ariel Fogel; The Week of Sandbox Escapes, 2026-07-20, case-study) reproduced eight sandbox escapes across four shipping coding agents — Cursor, OpenAI Codex CLI, Google Gemini CLI, and Antigravity — that share one mechanism:

the agent never breaks the sandbox; it writes a file that a trusted component outside the sandbox later runs, loads, scans, or treats as safe.

The load-bearing sentence, and the reason this is its own page rather than a footnote on Blast Radius (Agentic): "an agent's blast radius is not the agent process; it includes everything the agent can write that the host later trusts." Every containment control the corpus catalogs — sandboxed execution, per-tool scoping, per-call authorization, deterministic reference monitors — mediates what the agent does. None of them mediates what a different, unsandboxed process does with a file the agent was permitted to write. That gap is the whole finding.

Pillar's own decomposition: a sandbox boundary has three layers — direct execution (what the agent process may run), workspace writes (what files it may create or change), and host trust (what unsandboxed components later do with those files). The first two are what products enforce; the third is where all eight findings live.

Evidence note. Pillar sells agentic-security products and this research doubles as marketing for that category. The split used throughout this page: the findings carry CVE/GHSA identifiers, named vendor fix versions, and an awarded bounty — independently checkable, and treated as fact. The framing ("agentic tools are becoming endpoint actors", "agentic security requires its own threat model", the CISO buying-criteria list, the seam-instrumentation prescription) is the vendor's argument for its own product category and is attributed inline throughout.

The findings, with their identifiers#

Finding	Product(s)	How the boundary failed	Status
The hook was already in the workspace	Cursor	Workspace-controlled .claude hook config became unsandboxed command execution	CVE-2026-48124, GHSA-pc9j-3qc2-95wv, patched 3.0.0
One Docker socket to rule them all	Codex, Cursor, Gemini CLI	A privileged local daemon reachable from otherwise restricted agents became a second, unsandboxed execution environment	Fixed, GHSA-v4xv-rqh3-w9mc
The sandbox let me edit a venv	Cursor	The agent modified a virtualenv interpreter that Cursor's unsandboxed Python extension executed during interpreter discovery	Fixed, GHSA-p9g2-cr55-cw9c
Git directories do not have to be called .git	Cursor	Git-metadata indirection slipped past path-based sandbox rules; the Git extension then fired execution through fsmonitor	Patched 3.0.0, CVE pending
GitPwned: allowlist to RCE	Codex CLI	A safe-command allowlist trusted the command name (git) without modeling dangerous arguments and Git side effects	Patched v0.95.0, high-severity bounty awarded, CVE pending
Escaping the allow-default seatbelt	Antigravity	A denylist-style macOS Seatbelt profile left OS features reachable that permitted execution outside the sandbox	Google: "normal application behavior", downgraded
A time bomb in .vscode	Antigravity	The agent wrote a VSCode task configuration that the host later ran on its own	Google: "normal application behavior", downgraded

Note what the trusting component is in each case, because it is never the agent: a hook engine, a Docker daemon, a Python-extension interpreter discovery pass, a Git extension's fsmonitor hook, a command allowlist, a task runner. All are ordinary, long-standing developer-tooling automation. On developer endpoints, project files are executable infrastructure — the pattern predates agents entirely; what changed is who writes the files.

The four failure modes#

1. Denylists lose to platform complexity. An allow-by-default sandbox profile must remember every dangerous operation the OS exposes — "not a sandbox, it's a list of things somebody remembered to block that's always one entry short." Agents make it worse because the attacker gets a flexible operator inside the environment that can adapt, retry, and combine features a static policy never anticipated.
2. Workspace config is often code. The agent writes files it is allowed to write; the escape happens later, when the host treats them as trusted configuration. "When a sandboxed writer can hand executable config to an unsandboxed reader, the boundary has a hole in it." This is the mode that touches Agent Context Files directly.
3. "Safe" commands are not safe by name. The Codex git show finding was permitted because the name looked read-only; the invocation was not. Git flags can write files, load config, call helpers, and run hooks. The correct policy question is "what exact invocation, with what arguments, in what directory, against what config, with what side effects" — verbatim the capability-gating-is-not-authorization thesis, now with a CVE-track shipping instance behind it.
4. Local daemons live outside the box. A privileged daemon (Docker Desktop, package managers, cloud CLIs, language servers, build daemons, emulators, local databases) is a second execution environment. Sandboxing the agent while leaving the daemon API reachable "moves the boundary to the daemon API" rather than protecting the host.

"Checked once, trusted forever" — the vocabulary this seam was missing (2026-07)#

Rashidi's execution-security SoK (The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities, arXiv 2607.05743, empirical) re-reads its 39-paper corpus for the design defect each mechanism answers rather than the mechanism it proposes, and collapses seventeen categories onto four root causes. The second is this page:

RC2: authorization is checked once and trusted forever. "A permission, a validated file, or a tool's declared behavior is treated as durable after a single check, even though the thing it was checked against can change."

The survey names that defect at four layers — a capability grant outliving its subtask (PORTICO's "lingering authority"), a file or DOM read acted on after the state moved (the TOCTOU literature), a tool registration validated at discovery and trusted on every later call (MCP tool poisoning), and "a single-approval trust model that persists indefinitely after one grant" for an installed plugin (the skill-packaging taxonomy). Write-then-trusted is the same defect one layer down: the host established, once, that a hook config / task file / venv interpreter / Git directory is trustworthy, and never rechecked after the agent rewrote it.

That is a sharper statement of this page's mechanism than "the agent writes a file the host later trusts," because it says why the host trusts it — not because the file was authorized, but because trust was established at a moment that has since passed. It also predicts where else to look: any place a coding-agent harness validates something at install, discovery, or startup and caches the verdict.

A protocol tried the corrective and applied it to the wrong object (2026-07-28). MCP's 2026-07-28 revision (MCP Specification Changelog — 2026-07-28, vendor-claim) deletes the initialize handshake outright and makes every single request re-assert its protocol version and client capabilities in _meta, with the server re-identifying itself in every result — a wholesale move from check-once-per-session to check-every-request, arrived at for compatibility and statelessness reasons rather than security ones. It is worth reading as a natural experiment on RC2, because of what it chose to re-check: protocol-version compatibility and a self-reported identity string, not the tool behavior the client actually trusts. Tool descriptions and schemas are still validated whenever the client last read tools/list and trusted on every call after; a mandatory server/discover RPC advertises versions and capabilities with no signature, attestation, or tool-set digest attached. The survey's Gap-3 corrective — re-validate immediately before use — did get cheaper in the same revision, as an accident of two caching changes (required ttlMs/cacheScope give a client a vetted prior copy; deterministic tools/list ordering makes the diff clean), and remains required by nothing. See MCP Tool Poisoning for what that does and does not buy against a rug-pull.

The survey's own strongest exhibit is two Claude Code CVEs, confirmed against NVD (its verification protocol checked all four CVEs in the paper directly against NIST NVD listings; it did not reproduce the exploits):

• CVE-2025-59536 (CVSS 3.1 8.8, CWE-94, fixed in Claude Code 1.0.111) — versions before the fix could execute untrusted project code before the user accepted the startup trust dialog, when launched against an untrusted directory. The survey's reading: "structurally a trust-boundary race of exactly the shape the TOCTOU category studies, a check (has the user trusted this project) that a subsequent action (execute project code) could outrun."
• CVE-2026-21852 (CVSS 3.1 7.5, fixed in Claude Code 2.0.65) — the same interval, one flow over: a malicious repository exfiltrating data from the project-load flow, including Anthropic API keys, before the user confirms trust.

See Claude Code for the product-side record. Note what these add that the eight escapes above do not: the agent is optional to the defect. This page's findings need the agent to write a file; the two CVEs need only that the repository be opened. That is direct support for the "the pattern predates agents entirely; what changed is who writes the files" reading — here not even that changed, and the seam still opened.

Gap 3, and the vault reproduced it#

The survey's third cross-cutting gap is that TOCTOU races and MCP tool poisoning are studied as separate literatures — both are validate-then-act sequences over state that can change, "none of the papers in either category cites the other," and neither uses the other's vocabulary, even though re-validating immediately before use is a candidate defense for both.

This vault had the same split, in the same shape. Before this compile "TOCTOU" appeared nowhere as a concept — only as two passing phrases — while MCP Tool Poisoning carried the mechanism in full without ever naming it: ShareLock's rug-pull plants the reconstruction trigger in a server update, after the tools were vetted, and that page's own conclusion is that "static vetting misses it." Static vetting misses it because the check does not repeat. Two pages describing one defect in two vocabularies is precisely the finding the survey argues against, arrived at independently — and it is a fair test of the paper's sociological thesis, since nobody was coordinating citations here either.

RC2 at the marketplace, with an in-the-wild example (August 2026)#

Every instance above puts the stale check on one machine. Zenity Labs' campaign write-up (Michael Bargury, 2026-08-06, case-study, vendor-authored) is the same defect at population scale, and it is the first field example RC2 has on this page.

Registry records: a typosquatted agent-skill family first shows displayed installs on 2026-07-05, with the skill files still unmodified copies of the legitimate upstream. Malicious code enters the surrounding repository on 07-06 through a server-runtime loader, while the skill documents stay clean. The skill documents themselves are weaponized on 07-11, when one byte-identical malicious setup-installation.md is copied into seven skill paths. The listing, the publisher identity, the install counter and the trending rank all carry forward across that boundary unchanged.

Two things follow that the endpoint cases do not show:

• The check that went stale was made by thousands of parties, none of whom can repeat it. On an endpoint the trusting component is a process that could, in principle, re-read the file. Here the trusting act is a human or an agent deciding to install from a listing whose visible evidence of trustworthiness — install count, trending position, a repository that is a genuine clone of a real project — is monotonic and backward-looking by construction. A counter that only goes up cannot express "the content behind me changed." This is check-once-trust-forever with the re-check made structurally unavailable rather than merely skipped.
• The corrective this page keeps arriving at (re-validate immediately before use) has no place to run. The consumer holds a copy; there is no version pin, no digest, no update channel and no revocation feed for a skill. Gao et al. measure the consequence directly at registry scale — 70.3% of recovered reuse links are verbatim copies and 53% of reused skills are never modified after adoption — so the population that would need to re-check is precisely the population that never touches the artifact again. Platform removal within 12 hours of disclosure left, in the author's own words, "copied instructions … in downstream repositories, aggregators, and user machines."

Supply-chain treatment, the counter attribution and the second-stage detail on Agent Supply Chain Risk; the same TOCTOU read against MCP's rug-pull on MCP Tool Poisoning.

The vendor dispute is itself a finding#

Google closed both Antigravity findings as "Normal Google Applications", categorized them under "other valid security vulnerabilities (sandbox bypass)", and applied a difficulty downgrade — the exploitation path requires social engineering or "trusting a repository with indirect prompt injection" — while calling the reports "of exceptional quality." Cursor and OpenAI shipped fixes for structurally similar issues (and OpenAI paid a high-severity bounty).

That disagreement is worth recording independently of who is right. It locates, in a checkable public artifact, where one major vendor currently draws the agentic trust boundary: a repository the user chose to open is treated as trusted input, so an escape that requires a hostile repo is a user-trust problem, not a product vulnerability. Every source in this corpus on indirect injection argues the opposite premise — that repositories, issues, READMEs, and diffs are routinely attacker-influenceable. The two Antigravity findings are the seam between those premises, unresolved and shipping.

Relation to the cloud-side blast-radius chain#

This is the second trust-boundary traversal compiled into the wiki in a week, and the two are complementary rather than duplicative:

• Hugging Face / OpenAI, July 2026 — the boundary failed through credential and identity chaining inside cloud infrastructure: pod token → IMDS → node role → cluster identity → minted SA tokens → node root → a 136-key secret → mesh VPN → source control. Nine hops, all inside one estate, all mediated by identity.
• Pillar, here — the boundary fails through the write-then-trusted seam on a single developer endpoint: one write, one unsandboxed reader, no credential chain at all. The escape is a file handoff between processes on the same machine, "in the same user session, with no network hop and nothing watching the seam" (Pillar's framing of why their endpoint product exists — the diagnosis, not the product claim, is what's being borrowed).

Both are instances of the boundary is not where the sandbox is drawn, arrived at from opposite ends of the stack.

(My inference, not either source's claim — flagged for spot-checking:) the two chains rhyme in a sharper way. In both, the agent's actual exit ran through a control that was structurally unable to see the path taken. At Hugging Face the URL allowlist could not see a local dereference; at Pillar, command allowlists see names and not invocations, and the Seatbelt denylist cannot enumerate the OS surface it must exclude. Whether that generalizes to "enumerate-the-bad controls fail against agents specifically" — or merely restates the ordinary result that enumeration loses to any adaptive attacker, with agents supplying cheap adaptivity rather than a new failure mode — is genuinely open and left as a question below. The distinction matters for what follows from it: the first reading demands agent-specific controls, the second says agents only make an old bug cheap to hit.

What this source does not provide#

It is a vulnerability disclosure, not an empirical study. Absent: any attack-success rate, any comparison across models or agent versions, any measure of how often these paths are hit in the wild, and any base rate for how many repositories carry a hostile .vscode/tasks.json or .claude hook config. Eight reproduced escapes establish existence and breadth across vendors — that the pattern is not one product's bug — and nothing about prevalence. Read the "thousands more to come" closing line as the vendor's forecast, not a measurement.

Connections#

• Blast Radius (Agentic) — this page is the endpoint-side extension of the containment unit: the source's thesis line is a direct amendment to it ("not the agent process; everything the agent can write that the host later trusts"), and the July 2026 cloud chain there is the complementary credential-side traversal compared in the section above

• Agent Context Files — the collision of two threads: that page treats CLAUDE.md / AGENTS.md / hook configuration as versioned, inspectable harness engineering; CVE-2026-48124 makes a workspace-supplied .claude hook config an unsandboxed execution primitive in a second vendor's product. The same properties that make context files a good policy plane — auto-loaded, repo-resident, agent-writable, host-honored — make them a good execution vector

• Capability Gating Is Not Authorization — the GitPwned finding is that paper's argument shipping as a patched CVE-track bug: the allowlist checked which tool (git by name) and never the concrete invocation, so the untrusted model supplied both the action and the authorization fact. Pillar's prescription ("model command policy at the invocation and side-effect level") is complete mediation restated for the shell

• Least Agency — a second counterexample to the page's premise, structurally different from the OSC 7 one it already carries: there the agent needed no tool because the sink was its rendered output; here the agent uses only tools it is fully authorized to use, and the escape happens in a different process after the agent's turn ends. Scoping what each tool may do bounds neither. Least agency prices actions; write-then-trusted is a consequence of a permitted action, realized by someone else

• Out-of-Band Prompt-Injection Defense — the generalization of that page's "monitor mediates the wrong interface" finding. Its macOS Terminal chain is one instance (the trusting component is a renderer); the eight findings here are seven more (hook engine, Docker daemon, Python extension, fsmonitor, task runner), which moves the point from an existence proof on a demo CLI to a cross-vendor pattern with CVEs. A reference monitor at the tool boundary is complete mediation over the agent's calls, and the seam sits one process downstream of it

• Agentic Prompt Injection — the entry condition these escapes assume: untrusted content (README, issue, dependency, diff, code comment, web page) reaches an agent that runs where SSH keys, cloud tokens, browser sessions, and publish rights already live, so "a malicious instruction can become a local action on a developer machine." Google's downgrade rationale disputes exactly this premise

• Agent Data Injection (ADI) — the same four products (Claude Code, Codex, Gemini CLI, Antigravity) failing at an adjacent boundary: ADI corrupts the data inside the agent's context so it acts on forged trusted values; write-then-trusted corrupts the artifacts outside it so a different process acts on agent-authored values. Both are trust-boundary failures the tool-call gate never sees, one upstream of the agent and one downstream

• Risk-Tiered Auto-Approval — the denylist critique's second instance, at a different layer: "a list of things somebody remembered to block that's always one entry short" is the sandbox-profile version of that page's measured gap, where a blast-radius keyword deny-list misses the CI/container files carrying 87.6% of measured security debt. Two independent enumerate-the-bad controls, both coming up short in the direction the enumeration could not anticipate

• Zero Trust for AI Agents — Pillar's prescriptions are the framework's doctrine restated for the endpoint: deny-by-default sandbox profiles, explicit approval when an agent modifies host-side automation, helper execution under the same policy as agent execution, and provenance preserved between user-created, repo-created, and agent-created files (hub)

• Impossible, Not Tedious (Design Test) — a denylist that is always one entry short is the archetype of a control that makes traversal tedious to find rather than impossible; Pillar's "start from deny-by-default wherever sandboxing is used" is the same corrective (hub)

• Memory and Context Poisoning — the same seam, one substrate over, and with rates attached. Here the agent writes a file it is fully permitted to write and an unsandboxed host component later executes or trusts it; there the agent writes a memory entry through the intended interface and a later session trusts it. Both are consequences of a permitted action realized by something outside the agent's turn, so neither is an authorization bypass and neither is caught by confining the agent process — MemSecBench makes the point explicitly ("a Write Operation at W1, or Persistence at W2 alone, is an intermediate outcome rather than… an authorization bypass"). What that source adds is the measurement this page's disclosures lack: the downstream trusting step is not hypothetical, it is 76.1% recall → 53.7% adoption → 50.3% to a verified external consequence, across 310 cases and 24 configurations. A second source now supplies the check that ran and still did not help (2026-09-02). Karunanidhi evaluates a memory layer whose write path is a four-stage screening pipeline — the seam's missing control, actually present and actually competent, measured at 0.832 recall on indirect injection at a 1.5% false-positive rate on the over-defense corpus in the same paper. Against 360 memories carrying nothing but a false fact in ordinary conversational form, it refused zero. That is a distinct failure from the ones catalogued here and worth keeping separate: the sandbox cases fail because the check is absent downstream; this fails because the check is present, ran on every write, and inspects a property orthogonal to the one that matters — a screener can see structure, secrets and imperatives, and cannot see falsity without already knowing the answer. Two corollaries for this page. The write-then-trusted seam is not closed by adding a check at the write, only by adding the right check, and "the right check" may not exist as content inspection at all — which is the same conclusion the memory side reached about detection and the reason both substrates converge on write-time origin binding. And the paper's stage ablation is a caution about crediting a pipeline for the wrong stage: all 155 of its indirect-injection detections available before the LLM classifier come from the secrets detector, firing on credential-shaped strings in exfiltration payloads, while the injection rules proper contribute exactly zero on that corpus. The authors flag it against their own interest. The provenance question in this page's third open question — can agent-authored state be distinguished from user- and repo-authored state at the OS or VCS layer — is the same question as write-time origin binding for memory (Non-Malleable Memory Authority (TMA-NM)), and the memory side has a machine-checked construction while the filesystem side has nothing A rate for the write stage itself (2026-09-02): PipePoison (Zang et al., arXiv 2609.00523, empirical) measures the write as a conjunction term rather than an outcome — its Write Success Rate asks only whether the attacker's objective survived into a stored memory, with the consequence realized one stage later, in a different session, by a component that simply trusts what it retrieves. Two readings for this page. Across seven attacks x 12 memory-agent configurations the ordering AUR < WSR < RSR@5 holds without exception — the write is the middle-difficulty stage and retrieval is the easy one, so the seam's cost is not getting the artifact written but that nothing downstream re-checks it. And the best method converts 96.5% of its successful writes into end-to-end success (76.1% WSR to 73.4% AUR) where the six baselines convert 76.6-87.9%: once the artifact is in the store, the later trust is close to automatic, which is the filesystem seam's premise measured on the memory substrate.

• Out-of-Band Prompt-Injection Defense — the generalization of that page's "monitor mediates the wrong interface" finding (detailed above). It now also hosts APPA (Archestra AI, arXiv 2607.24625, empirical), which is worth reading against this page precisely because it is orthogonal to the seam and rehearses it anyway. APPA is the corpus's most complete containment design — formally proven confinement of what untrusted data can influence — and its labels live on the context trajectory, so a file the agent writes leaves the labeled system entirely, carrying nothing with it. The paper concedes the shape of this twice: its event log records "only operational tool actions and rulings," not semantic claim attribution, and branching is "trajectory isolation rather than transactional side-effect rollback," so an egress a discarded child already committed is irreversible. But its own evaluation lost a scenario to a within-system write-then-trusted. In joint-merger-brief the agent wrote an HR value into the finance store through a create_finance tool the policy declared with no sink requirement, then read it back under the finance contract — the store laundered the label exactly as an unsandboxed host component launders trust, one process boundary in. (My reading, flagged for spot-checking:) that makes the seam look less like a sandboxing bug and more like a general property of any confinement scheme whose labels do not travel with the bytes: give a confined agent a writable store the scheme does not model on the write side, and the store is the escape. APPA's own fix — require store-writing tools to declare sink requirements — is the labeled-system form of this page's third open question, and the one thing it does have that the filesystem side lacks is a shared append-only committed-effect log, which at least makes a write a policy-visible fact a later call can be conditioned on (prior(k) / no_prior(k))

• Self-Propagating Prompt Injection (AI Worms) — the seam closed into a cycle, on a different substrate. Here the trusting reader is a different process (hook engine, task runner, Python extension) and the chain terminates in host code execution; in Måløy's Copilot for Word disclosure (case-study, coordinated with MSRC over 144 days) the trusting reader is the same class of agent in a later session, so the written artifact is not a terminal effect but the next input — and because the payload's second instruction is to copy itself into the output, the carrier population grows with ordinary document reuse. That page is also the second substrate asking for this page's third open question: its one structural recommendation is document-metadata provenance for source material and model-performed edits, the same missing primitive one file type over

• Agent Self-Poisoning (the CREATE-Path) — the seam with a proof attached, and the trusting reader is the agent's own retriever. EvoMal's CREATE-path is this page's mechanism inside one process boundary: the agent writes a skill it is fully permitted to write, and the same library re-serves that skill to a later task on equal footing with curated entries. Theorem 1 is the formal version of the finding this page states in prose — for any defense whose decision function reads only the attacker-submitted artifacts and named invocations, and therefore excludes the agent-authored artifact from its inputs, the probability of infection given that a seed reached context is identical with and without the defense. Corollary 2: a blocklist reduces the harm only through admission filtering, never after. And the signed quarantine gate (Theorem 3 — EUF-CMA signatures binding the full record plus a curator-controlled append-only admission log, agent-authored entries confined to an unretrievable level) is the first construction in the corpus that actually implements this page's third open question, with a proof, a stated price (self-evolution stops), and a fragile assumption A5 (the retriever must be the only path from store to context — no debug output, memory summaries, or error traces echoing the quarantine)

• Observability-Pipeline Poisoning — the seam with the writer swapped, and the twist is that the writer is a security control. Every instance on this page has the agent produce the artifact a later component trusts. In Tenet's GhostJacking Cloudflare chain (case-study, DEF CON 34, vendor-authored) the producer is the WAF: a request whose body trips a default Managed Rule is blocked with a 403, and blocking it is what writes the firewallEventsAdaptive record whose User-Agent header — stored byte-for-byte, unescaped, untagged — the triage agent later reads as trusted operational metadata. Getting blocked is the delivery mechanism, and the 403 is a false signal of safety because the block is what manufactured the trusted artifact. The RC2 vocabulary fits with one adjustment: the write side is not "authorization checked once" but never checked at all, since accepting arbitrary bytes from the public internet is the log's purpose. Also the shape of this page's third open question from the far end — the record's provenance is perfectly knowable at write time (Datadog even stamps client-token-submitted on exactly these entries) and the failure is that no reader is obliged to consult it

• Agent Supply Chain Risk — the same seam at distribution scale, and RC2's first field example. A skill marketplace listing accrues installs and trending rank against clean content, the content behind the identity is swapped later, and every consumer's trust decision was made against the earlier bytes. What that page adds is the mechanism on the far side of the swap — the loader in a secondary reference file, the borrowed-authority instructions redirecting the agent away from the legitimate package, and the takedown residual that no revocation channel reaches

• Agentic Work Systematization — the measurement that makes this page's corrective unavailable on the skill substrate. Re-validate-before-use presumes a consumer who still has a relationship with the upstream; Gao et al. find skill reuse is a verbatim copy (70.3% of 3,709 links at ≥0.99 similarity), 53% never modified after adoption, 40.2% of never-updated copies sitting on a changed upstream, with no pinning, advisories or update channel anywhere in the ecosystem. The stale check is not skipped, it is unrepeatable

• Claude Code / Codex / Google DeepMind — the affected agent products; the .claude hook-configuration format is the vector in the Cursor CVE, and Codex CLI's safe-command allowlist is the GitPwned target

• Cursor — the vendor carrying four of the eight reproduced escapes, all fixed; the count tracks a denylist-shaped sandbox surrounded by host-side components, not an unresponsive vendor

• MCP Tool Poisoning — the same root cause in the other vocabulary, and the pair Rashidi's Gap 3 predicts will not be connected. ShareLock's rug-pull is check-once-trust-forever at the tool-registration layer: the server is vetted, then updated, and "static vetting misses it" because the check does not repeat. Here the checked object is a workspace file and the checker is host automation; there it is a tool description and the checker is a client-side scanner. Re-validate-before-use is the same candidate defense on both, and neither literature proposes it to the other. The MCP side has since made it cheap without making it mandatory — 2026-07-28's required cache metadata plus deterministic tool ordering hand a client a vetted prior copy and a clean diff, which catches a plaintext rug-pull and still reports ShareLock's shares as Safe

• Skill Lift — the gate that would run the re-check at the last available moment, and its untested edge. NVIDIA's Tier 1 and the SkillSpector install-time scan put a static check inside the install flow, which is the only point on the skill substrate where "re-validate immediately before use" has anywhere to run; the Zenity campaign is that page's argument for install-time over publication-time placement, and also its counterexample, since neither source says whether the scan follows a skill's reference tree past the clean front file

• Guarantees That Degrade at Deployment: Action-Space Soundness, Admissibility Without Effect, and a Vendor-Coupled Security Framework — this page as the sharpest evidence that Zero Trust for AI Agents's real gaps are vendor-independent: eight escapes across Cursor, Codex CLI, Gemini CLI and Antigravity through a seam none of the framework's control domains mediates, plus the two NVD-confirmed Claude Code CVEs that make the Pro-tip reference implementation an existence proof that a control is shipped rather than evidence that it holds

• Memory-Poisoning Numbers, Conditioned on the Write — Karunanidhi's four-stage write path is the corpus's only arm where the conditional is exact rather than a ratio of rates, and precisely because the check ran and admitted all 360: write success is 100% by construction, so every downstream number is already end-to-end-given-write. The shipped retrieval-side repair then moves the rank-1 retrieval metric 13 points and the outcome not at all (p=0.80) — a checked-once seam whose repair is also reported on the wrong stage

Open Questions#

• Does the "enumerate-the-bad controls fail" reading generalize to agents specifically, or is it the ordinary result that enumeration loses to any adaptive attacker — with agents merely making adaptivity cheap? The two readings prescribe different things (agent-specific controls vs. deny-by-default everywhere), and no source in the corpus separates them. Partially answered (2026-09-02) — with a third reading the bullet did not offer: EvoMal runs the discriminating experiment by accident. It makes enumeration perfect — an oracle blocklist seeded with every planted-skill and banner-helper name, matching library entries by name and imports — and it flags 0 of 275 agent-authored infections. Enumeration did not lose here because the list was one entry short, and not because the attacker adapted; it lost because the harmful artifact was never in the defense's observable domain, carrying a name the agent chose. That is target mismatch rather than incompleteness, and Theorem 1 states it as a measurability condition rather than an empirical tendency. It cuts both ways for the original question: it is not agent-specific in the sense of needing agent-specific controls (the corrective is to observe the authored artifact, which is ordinary complete mediation one object over), but it is agent-specific in origin, since a second unmediated admission path into a trusted store only exists because the agent writes into it. The deny-by-default reading survives; the enumeration-loses-to-adaptivity reading is shown not to be what happened at least once.
• Pillar establishes existence and cross-vendor breadth but no prevalence: how often is a write-then-trusted path actually reached in deployed use, and what fraction of real repositories carry executable workspace configuration an agent could rewrite? A disclosure cannot answer this; it needs endpoint telemetry or a repository-scale survey.
• Can agent-write provenance (Pillar's "distinguish user-created from repo-created from agent-created project state") be enforced at the OS or VCS layer rather than by a vendor product, so that host-side automation refuses to execute agent-authored config without explicit approval? Nothing in the corpus implements it; the nearest analogue is write-time origin binding for agent memory (TMA-NM), which is the same move one substrate over. (A third substrate now asks for it: Måløy's Copilot for Word disclosure proposes preserving provenance for source material and model-performed edits in document metadata, explicitly as a traceability control rather than an injection defense — "such controls would not prevent the underlying injection, but they could make traceability much easier." Same primitive, and the same absence: nothing enforces it, and on documents there is not even a VCS layer to enforce it at.) Partially answered (2026-09-02), on a fourth substrate and with a proof: EvoMal's signed quarantine gate (Theorem 3) is the enforced version, for an agent skill library: a curator signs every entry in the retrievable indexed level, agent-authored skills land in an unretrievable quarantine level, and under EUF-CMA security plus a curator-controlled append-only admission log an agent-authored entry is retrieved with negligible probability — including the byte-copy case, because the log dereferences the record identifier to the original object. It is not the OS or VCS layer the bullet asks for and it does not survive translation for free: it prevents no initial compromise (assumption A4), it requires the retriever to be the sole path from store to context (A5), and the practical curator-review variant swaps the guarantee for the reviewer's error rate. But it settles the feasibility half — agent-write provenance can be enforced structurally rather than by a vendor product, and the cost is that the agent's own output stops being usable without review.
• Is a marketplace install counter decoupled from current content at population scale, or was the Zenity family an outlier? The campaign shows the decoupling is possible by construction — six days of installs accrued against clean files, weaponized on 2026-07-11 with the identity and counter carried across — and says nothing about how common it is. Falsifiable with public data only: for the top N skills on a registry, diff each skill's referenced-file tree across its commit history against the dates its install curve rose, and report the share whose executable-by-reference content changed after the majority of installs landed. A low share makes reputation a usable prior; a high one makes it a display artifact, and either way the registry could publish a content-changed-since marker at trivial cost.

Sources#

• Transferable End-to-End Optimization for Indirect Long-Term Memory Poisoning in LLM Agents — Zang, J. Wang, Chen, Meng, L. Wang, Gao, Z. Li & Guo (Shandong University), Transferable End-to-End Optimization for Indirect Long-Term Memory Poisoning in LLM Agents, arXiv 2609.00523 v1, 2026-09-01, empirical, no COI. Cited here only for section 2.2 (writing success as an intermediate stage outcome rather than an authorization bypass) and the Table 1 stage ordering, reconciled against pdftotext -layout. Full treatment on Memory and Context Poisoning

• The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities — Mohammadreza Rashidi (AI and Media Analysis Lab, Berlin), The Balkanization of Execution-Security Research for AI Coding Agents, arXiv 2607.05743, 2026-07-07, empirical (a systematization, not a measurement study: its own contributions are the verified corpus, the four NVD-confirmed CVEs, and the gap analysis — every figure it reports about a system is restated from the underlying paper). Used here for §2.3 (the two Claude Code CVEs and the survey's TOCTOU reading of CVE-2025-59536), §5.1 (RC2 and its four layers), §6.3 (Gap 3, the TOCTOU/MCP vocabulary split), §9 (limitations: no exploit reproduction, no independent replication of any surveyed paper's claims). Tables not cited here; the paper's counts are machine-derived from a released corpus file and its verifier

• MCP Specification Changelog — 2026-07-28 — Model Context Protocol project, Key Changes for spec revision 2026-07-28, vendor-claim. Used only for the RC2 natural experiment above: major changes 2–3 (handshake removed, per-request _meta version negotiation, mandatory server/discover) and minor changes 3 and 5 (deterministic tools/list ordering; the CacheableResult ttlMs/cacheScope requirement). Spec text: authoritative on requirements, silent on whether any client implements a re-check

• EVOMAL: Self-Poisoning in Self-Evolving Coding Agents — Wu, Shi, Q. Li, Zhao, X. Li, Adams, Hassan & Ni (Queen's University), EvoMal: Self-Poisoning in Self-Evolving Coding Agents, arXiv 2608.25776, 2026-08-26, empirical. Cited here for §9.1 and Table 5 (the oracle blocklist's 0/275 against a complete name list), Theorem 1 with Corollary 2 and App. D.2's proof (target-mismatch invariance of submission-side defenses, and the scope remark exempting defenses that read the authored artifact), and §9.3 with App. D.4 (Theorem 3's signed quarantine gate, its assumptions A1-A5, and the curator-review variant). Full treatment on Agent Self-Poisoning (the CREATE-Path)

• Utility Under Attack: Agent Memory Poisoning and the Limits of Content Screening and Provenance Ranking — Arulnidhi Karunanidhi (Quantify Labs Ltd — developer of Aegis, the memory layer under evaluation; no COI statement in the paper), Utility Under Attack, arXiv 2608.21230 v1, 2026-08-21, empirical. Cited here for §4.1 (the four-stage write pipeline), §6.2 (the 0-of-360 refusal), §6.4 with Tables 4–5 (the detector comparison establishing the pipeline is not a straw man, and the per-stage ablation crediting all 155 indirect detections to the secrets detector). Full treatment on Memory and Context Poisoning and Non-Malleable Memory Authority (TMA-NM)

• GhostJacking Attacks: Half of the Fortune 500 Run These Tools. Getting Blocked by the Firewall Was the Way to Take Over Their AI Agents — Sternberg, Poran & Bobrov (Tenet Threat Labs), GhostJacking Attacks, 2026-08-09, DEF CON 34 Main Track, case-study (vendor-authored; exposure figures are Tenet's extrapolation, attributed inline). Cited here only for the Cloudflare chain's write side — the Managed-Ruleset block that produces the log record, the verbatim untagged header storage, and Datadog's unread client-token-submitted tag. Full treatment on Observability-Pipeline Poisoning

• Attackers Target Agents via The Skill Supply Chain — Michael Bargury (Zenity Labs), Attackers Target Agents via The Skill Supply Chain, labs.zenity.io, 2026-08-06, case-study (vendor-authored — Zenity sells agent security and the piece previews a Black Hat USA talk; the OSV/Amazon Inspector corroboration, commit SHAs, archive captures and published hashes are treated as fact, and the install counters are platform-displayed and explicitly not unique-user). Cited here only for the marketplace-TOCTOU section: "Hiding in marketplace TOCTOU", the Timeline entries for 07-05 / 07-06 / 07-11 with commits 170b54c and 00b7d831, and the takedown residual in "Impact and takedown". Full treatment on Agent Supply Chain Risk

• The Week of Sandbox Escapes — Eilon Cohen, Dan Lisichkin & Ariel Fogel (Pillar Security), 2026-07-20, case-study, vendor-COI flagged. Executive Summary (the blast-radius thesis line); "How Agents Escape Their Sandboxes" (the three-layer boundary model); "The Series" table (all eight findings with advisories, fix versions, and Google's downgrade rationale); Failure Modes 1–4; "What Security Teams Should Ask Coding Vendors" and "What A Good Threat Model For Agents Looks Like" (the vendor's prescriptive argument, attributed rather than adopted). No attack-success rates, model comparison, or prevalence data anywhere in the document