Can defenses stop attacks on agentic AI systems?

Testing three CIK-aligned defenses against Sonnet 4.5 (chosen because it "exhibited the highest attack ASR across dimensions"), the paper finds none closes the gap. The Capability defense, a security skill called GuardianClaw that runs a "pre-action checklist covering intent verification, reversibility, scope, labeling, and coherence," is "the most effective defense tested, reducing baseline ASR to 1.7% and attack ASR to 9.2–63.8%" — yet "Capability-based attacks still achieve 63.8% success rate." The Identity defense (added safety principles in AGENTS.md) cuts baseline ASR to 13.3% but leaves attack ASR at an average 59.9%; the Knowledge defense (safety facts added to MEMORY.md) cuts baseline ASR to 8.3% but leaves attack ASR at 49.6%. Separately, a file-protection mechanism "blocks 97% of malicious injections but also prevents legitimate updates" at nearly the same rate.

The paper's own explanation for why Capability resists defense is architectural: "executable payloads bypass the LLM's reasoning loop entirely, evading the checklist" — a text-based safety instruction cannot inspect code that "runs directly on the host without LLM inspection." It also reports that GuardianClaw only works if "actively loaded at session initialization"; passively installing it in the workspace has little effect because "the agent does not spontaneously invoke the skill." The file-protection result is read as a tradeoff rather than a fix: "as long as the persistent files that enable evolution are also the attack surface, separating legitimate updates from injections remains an open problem."

This sharpens How vulnerable are deployed AI agents to poisoning attacks? by showing the vulnerability survives the obvious countermeasures, not just the unpatched baseline. It also qualifies How do agent security layers connect across the stack?: here, even a defense built to span a specific layer (Capability) of the stack still fails against that same layer's own attack, because the executable-code path sits outside the LLM's reasoning loop that every other defense relies on. And it is a further instance of the pattern in Do internal agent hops in pipelines need security monitoring?: a checklist or a file guard watches the door it was built for, not the channel — here, raw executable code — that bypasses the LLM reading it at all.

The defense evaluation is run only against Sonnet 4.5, so whether the same 63.8%/59.9%/49.6% pattern holds for the other three backbone models in the main study is not shown in the excerpt. The excerpt also does not describe how the file-protection mechanism distinguishes — or fails to distinguish — a legitimate owner edit from an injected one, only that it cannot yet do so reliably; the open problem is named, not solved.