A Control That Silently Removed the Capability It Was Protecting
The sampler runs a headless agent and asks it to search a social platform. The obvious hardening is a tool allowlist: name the four search tools, exclude everything else, done. It reads like a textbook least-privilege configuration.
What actually happened is that naming those tools left them unwired in the session. The agent ran, produced a confident, well-formatted answer, and never searched anything. A session with no restriction flag at all used the same tools without difficulty. The lockdown had removed the very capability it was meant to permit, and nothing anywhere reported a problem.
Why This Class of Failure Is So Dangerous
Consider the two possible states. In the first, the allowlist works: the agent searches, and returns an answer grounded in what it found. In the second, the allowlist has broken the tools: the agent cannot search, and returns an answer from its own prior knowledge. Both produce a successful run with plausible output. The exit code is the same, the format is the same, and the content is confident either way.
So the general rule is uncomfortable but simple: a control that restricts capability needs a positive check that the capability survived. Verifying the restriction is not enough — you have to verify what remains still works, or an over-restrictive configuration is indistinguishable from a correct one.
The Denylist, and Why It Is Not a Downgrade Here
The replacement inverts the shape: keep the tools available, and explicitly remove the dangerous ones — anything that runs commands, reads or writes files, spawns further agents, or schedules work. That looks like weaker security by the usual argument, since a denylist cannot cover what you have not thought of.
Two things make it the right trade. First, the allowlist did not work, and a control that does not function offers no security at all. Second, the actual threat here is specific and enumerable: the danger is a tool that acts on the machine, and that set is small, known, and checkable. Meanwhile the capability being preserved — search — is verified separately by a purity gate, which is the positive check the allowlist version never had.
Probe Before You Trust the Configuration
The process fix is a live probe. Before building on any capability-restricting flag, run one invocation with it and confirm the restricted capability actually functions — not that the command exits zero, but that the specific thing you allowed happened. Here, that means checking the response contains a real citation from the platform. Ten minutes of probing replaced an assumption that had already shipped.