Bind, Don't Forbid; Prevent, Don't Detect: The Action-Open and Poisoned-Memory Residuals

The questions#

The two remaining #oq/now items in agent-security, which turn out to share one arc:

1. Task-Specification Effects in Prompt Injection (AutoDojo) — if action-open tasks are the injectable ones and the everyday default for non-expert users, is the practical prescription to forbid action-open delegation (force the user to name the action), pushing the security burden back onto task specification?
2. Memory and Context Poisoning — integrity hashing detects modification but not malicious-but-valid memory written through a legitimate (injected) interaction. What catches semantically-poisoned-but-cryptographically-intact memory?

Answer 1: No — bind by default, elicit when binding starves, authorize the remainder#

Forbidding is the wrong control class, on both of the corpus's axes. First, it is a discipline prescription aimed at the least-equipped party: action-open phrasing is the everyday default precisely because "most users are not security experts" (Task-Specification Effects in Prompt Injection (AutoDojo)) — a rule demanding they specify like security experts is user-side friction, the class that degrades under pressure and misallocates the burden the way the ADI confirmation dialog does (Does 'Impossible, Not Tedious' Kill Defense-in-Depth? Layered Friction, Agent-Relativity, and the Frequency Paradox). Second, it spends the product: open delegation is the value of an agent — "do the tasks on my TODO list" is the archetype of everyday delegated use, not an edge case to prohibit.

And forbidding is unnecessary, because the same measurement that exposed the action-open vulnerability also showed it inverts under the right defense. Action-open tasks are the worst case only for prompt- and filter-based defenses (up to 64% adaptive ASR); action-constraining system-level defenses grow stronger there — an under-specified request yields a conservative inferred trajectory containing no write action, so any injected write is blocked regardless of how the injection is phrased (Task-Specification Effects in Prompt Injection (AutoDojo): "real robustness comes from binding the agent's actions to the user's request — not from filtering its inputs"). The dangerous configuration is therefore not action-open-plus-user; it is action-open plus filters-only. With a binding layer, the user's under-specification becomes the defense's asset.

The honest residual is utility, and it dictates the rest of the prescription. Binding costs task completion (DRIFT gives up 18–30 utility points, Progent up to 11 — Task-Specification Effects in Prompt Injection (AutoDojo)), and a genuinely open task — one whose purpose requires consequential actions derived from attacker-reachable content ("pay the bill in this file") — is starved by a conservative trajectory. The ordered design that falls out:

1. Bind by default. The system derives the narrowest trajectory the request supports; under-specification defaults to read-only-ish conservatism.
2. When binding starves the task, the system elicits specification — clarification-before-commit, the channel HAS-Bench measures as best for ambiguity patterns (Configurable Human Participation). This is the crucial inversion of the question's framing: specification is not demanded of the user as a precondition; it is drawn out by the agent when the trajectory is too tight. And it is the same move unknown-elicitation prescribes for quality — the question's own noticed convergence, resolved in favor of one discipline with two payers: eliciting what the user actually wants both closes the injection surface and surfaces the unknowns that would have degraded the output anyway.
3. Route the safety-critical remainder through per-action authorization. For actions no inferred trajectory should ever auto-permit, the control-only channel is the one measured at 100% on protected actions (Configurable Human Participation), with identity-bound variants (Off-Host, Identity-Bound Authorization) where the approver must be cryptographically the owner — budgeted against the approval-fatigue ceiling the in-the-loop literature flags.

So: no forbidding anywhere in the stack. The burden lands on the system (bind, elicit, gate), not the user's phrasing discipline — which is where the impossible-not-tedious test says durable controls must live.

Answer 2: Nothing catches it — provably — so the question's premise retires#

The question asks what catches malicious-but-valid memory, and the strongest available answer is that the premise is wrong: no detector can, by theorem. The malicious-but-valid class is exactly a laundering attack — untrusted content paraphrased by the agent's own summarization, echoed by a trusted tool, or corroborated by manufactured sources until it reads benign and hashes clean — and TMA-NM's machine-checked separation theorem (T1) proves no content- or lineage-based detector is sound against it; the accompanying content-judge sweeps confirm no threshold reaches 0% ASR at full utility (Memory and Context Poisoning).

The replacement is prevention by construction: bind each memory item's authority-to-act to its true origin at write time, propagate that binding non-malleably, and gate elevation on genuinely independent trusted corroboration — so a laundered item, however benign it reads, carries act = none and simply cannot authorize a consequential action. Measured: 0% attack success on the direct attack and all three laundering channels across eight frontier models, at 100% legitimate utility, against content/lineage baselines failing at up to 68% (Non-Malleable Memory Authority (TMA-NM)). Integrity hashing keeps its real job — detecting tampering and supporting forensics/rollback (Memory and Context Poisoning's Phase-7 controls) — but the semantic-poisoning defense is authority architecture, not inspection.

The residuals are real and already tracked where they belong (on the TMA-NM page's own open questions): the retrieval-to-text path (answer bias surfaced with provenance is out of scope), corroborator availability in the wild, and value-level taint through nested payloads. None reopen this page's question; they bound the construction that answered it.

One consolidated takeaway#

Both answers are the same lesson the injection-defense corpus keeps teaching: when a threat class provably defeats inspection, stop inspecting and change what the artifact is allowed to do. Action-open text can't be reliably filtered — so bind the action space to the request and let the system elicit what's missing. Laundered memory can't be reliably recognized — so bind authority to origin and let plausible-looking items be powerless. In both, the user keeps their natural behavior (vague requests, accumulated memory), the attacker keeps their access, and the structure keeps the blast radius at zero — detection retires to forensics, where losing the race doesn't lose the game.