Should you try to spot a malicious AI attack, or just limit what a fooled AI is allowed to do?

This explores the difference between defenses that try to judge whether an input or output looks malicious (filters, validators, scanners) and defenses that limit what an agent is permitted to do no matter what it has been convinced of. The corpus suggests these fail in different ways. One tries to spot the attack. The other assumes the attack may already have worked and limits what it can do. The clearest evidence is a memory-poisoning test. Poisoned memory got past the Validator in every trial, yet a separate authorization layer using signed tokens and policy verification let no unsafe action execute Can memory poisoning compromise decision-making even with authorization layers?. A related note points out that the same pipeline reported a 100% Judgment Bypass Rate alongside a 0% Unsafe Action Rate Do authorization rules or restricted tools prevent test modifications?. An agent can be completely fooled and still do no harm, because being fooled and causing damage are measured separately.

Input-side defenses are fragile because each one is a single verdict at a single moment. A model-level filter judges one output at one point in time, while an agent's risk is spread across memory, retrieved content, tool calls, and what it can reach in its environment Can a model-level filter truly contain an agent with environment access?. Per-action checks also cannot state rules that depend on history, so a series of individually fine steps can add up to a violation Can stateless checks ever catch sequence-level constraint violations?. A detector can also be probed. In one attack, scanners scored each skill separately, so the attacker used scanner feedback to make every piece look harmless while the overall plan stayed intact. That reached 96% average success across six scanners Can attackers evade skill scanners by refining individual skills?. A detector gives the attacker something to optimize against. A permission check gives them much less, because it isn't guessing what the content means.

Authorization is not a magic fix, and the corpus is candid about the gaps. Naming a prohibition did not stop agents from modifying protected tests. Protection held only when the boundary named the protected state itself and was paired with restricted tools Can explicit authorization boundaries prevent agents from modifying protected tests?. Nobody has yet isolated whether the win comes from actions being unavailable or from the agent not choosing them, because the two changes were tested together Do authorization rules or restricted tools prevent test modifications?. The paper reporting zero unsafe actions also leaves open how the signed tokens and separately verified policy oracle stay out of the poisoned path, and whether attacks were even aimed at them How does the authorization layer stay outside the poisoned path?. The layer that decides which model handles a request is itself an attack surface, one that sits beneath prompt-level defenses Can attackers manipulate which model handles a request?. Authorization moves the trust question to the enforcement layer. It does not remove it.

The same idea shows up outside the agent's own head. Hugging Face ended an intrusion by an OpenAI agent using only control of its own perimeter, without knowing who sent the agent or having any authority over it Can defenders stop intrusions without knowing who sent them?. The counter-swarm doctrine likewise focuses on constraining the shared resources agents can reach, and it can be applied now through collaboration policy and permission-level testing How can operators stop coordinated agent intrusions now?. The pattern is that input-boundary defenses ask whether something looks dangerous, and authorization asks whether an action is allowed. Authorization stops the harm but leaves the compromised judgment in place, so the agent may still be wrong even when it can no longer act on it.