AI agent security · effect-path assurance
Declared, Not Wired
An early lesson from building with AI: a clearly specified control does not prove that every path to the effect passes through it.
If you can point to a control, can you prove a request ever passes through it?
The moment
In some of my early work with agents, I followed a sensible sequence; I would start with an idea, work it through design, turn it into architecture and quick specifications, then ask an agent to help build it.
That sequence gave me something useful very quickly: structure I could inspect, names for the important parts, and enough of a system to keep moving. It also let me carry an assumption much farther than I realized.
If I had described a control clearly, and the build could show me where that control lived, I sometimes treated the behavior as present. I was checking whether the design had made it into the system, but was not always following every path far enough to prove that the system actually used it.
The gap became easier to see after a short Anthropic engineering presentation on a recurring coding-agent failure: an application can look finished while core interactions or backend behavior remain missing or stubbed. Anthropic's application-harness writing describes the same pattern.
What stayed with me was not that AI could produce unfinished software. Humans do that too. It was how easily a polished surface—and my own clear intent—could become a proxy for proof.
A request is not a test, an architecture is not an execution path, and a specification does not prove that every effect travels through the control it names.
The claim that did not survive
I started calling that state Declared, Not Wired: a control exists in the interface, configuration, policy, or documentation, but one or more known paths that produce the effect never cross it.
For a while I thought the phrase might name a new vulnerability class. I checked it against 21 current sources, and the territory is well established. MITRE describes a protection mechanism that is active but not applied in some code path (CWE-693); complete mediation has its own entry (CWE-638); a 2026 advisory describes an agent server whose auth_token setting was never checked on any route (GHSA-7g3p-92qq-8wvh).
So I retired the novelty claim and kept the name as a working term with that lineage attached. The smaller question survived:
For the consequence I care about, which known paths can produce it, and where does the control intervene on each path before the effect occurs?
Enabled is not a path
Presence ≠ mediation.
OpenAI's Agents SDK documents separate guardrail pipelines for function tools and handoffs, and notes that hosted and built-in tools do not use the function-tool pipeline (Guardrails). The MCP specification requires authorization on every request (authorization). Neither is a defect. Both are why "guardrails enabled" is too broad until someone names the route.
The test
Four routes. One harmless receiver.
- Declare Every route to
message_sendrequires a matching approval token before the effect. - Enumerate A function tool, a hosted-tool stand-in, a specialist handoff, and a recovery step, all reaching an in-memory receiver that cannot leave the test.
- Pair Each route runs twice: once with permission, once without, holding the consequence constant.
- Observe Evidence comes from the receiver itself, because a transcript saying "blocked" is not an unchanged receiver.
- Report Per path, never promoted to a platform claim.
The receiver record
Only one denied route stopped the effect.
Inspect the receiver test
The fixture records the control binding, whether each twin reached the control, and whether the receiver observed the effect. The comparison below is taken from the synthetic v0.2 fixture.
function_tool.deny_twin: reached_control=true; effect_observed=false
hosted_surrogate.deny_twin: reached_control=false; effect_observed=true
specialist_handoff.deny_twin: reached_control=true; effect_observed=true
recovery_adapter.deny_twin: reached_control=true; effect_observed=trueA warning is not a block; a post-effect evaluation is not pre-effect mediation.
The declared control never saw the effect-capable path.
The boundary produced information, not intervention.
The evaluation arrived after the action crossed.
The correction
Then the detector failed its own test.
The original version checked enforcement carefully, but it accepted the three failure names as the test file declared them. When I swapped two of the labels, it still reported a valid result.
The tool I built to catch declared-but-not-wired had a declared state in it.
The second version derives every path's state from the paired runs and treats any declared label as a claim to check. Its suite runs one exact base case, the same case with every label removed, one fully wired version that must come back conformant, and eight hostile cases built to catch easy false greens.
The honest limit
Wiring is one layer of the answer.
This is evidence about one synthetic fixture and one detector, not a benchmark, a certification, or proof that I can find every path in a real platform. A wired control can still make the wrong decision, and path discovery is never complete by default. The method keeps three questions apart: did the path reach the control before the effect, did the control decide well, and what did the receiver actually observe?
Next credible question
What would we need to observe before calling this control wired?
The public companion repository lets you run the four-route example, inspect the corrected detector, and challenge it with the hostile tests. If you adapt the method to your own system, the useful question is what changed: a route you had not listed, a control that held, or a correction to the method.