Checking an AI's finished plan for danger may come too late if the attacker already tampered with how it planned.

The core failure is timing. A defense that inspects only the generated workflow looks at the plan after it has already been shaped. A FLOWSTEER-style attack crafts a prompt that biases the planner's signals before any workflow exists, so by the time the workflow reaches inspection the contamination is baked in and can look like a perfectly reasonable plan. Can prompts alone reshape multi-agent workflows without system access? shows this needs no system access at all, only a prompt, and it raised malicious success by up to 55 percent. Can inspecting generated workflows catch planning-time attacks? names the gap directly: the inspector arrives after the damage.

The same note also points to a fix that moves the defense earlier. Instead of judging the output plan, it separates the incoming instruction into task, methodological, and framing intents, which intervenes at the boundary where instructions get organized into a plan. That cut malicious success by up to 34 percent. That is a real reduction, not a solution, and it leaves roughly two-thirds of the attack's gain in place.

Inspection also fails for a second reason: harm can be spread across steps. Can task decomposition hide harmful intent across agents? points out that multi-agent systems get their strength from splitting tasks and specializing roles, and that same design lets a malicious goal be cut into pieces that each look harmless, with the harm appearing only when they combine. [[scanner-feedback-lets-an-attacker-blunt-each-sub-skill-while-chain-planning-hold]} shows the same pattern in skill scanners. Because each skill is scored alone, an attacker can use scanner feedback to make every piece look less suspicious while the chain's overall meaning stays intact, reaching 96 percent average attack success. Per-item inspection, whether of steps or skills, misses what only exists in the composition.

The corpus suggests no single checkpoint is enough, because each placement sees what the others miss. Where should workflow validation gates be placed for safety? puts validation at the commit point, just before an irreversible action, where the assembled workflow lets a global risk picture be rebuilt that no single step holds. Do internal agent hops in pipelines need security monitoring? covers the hops between components: five internal channels, such as tool results and memory feeding a worker, get no inspection, since existing defenses watch only user input. Can stateless checks ever catch sequence-level constraint violations? adds that per-action checks cannot express rules that depend on history, so tracking sequences needs stateful monitors. Should defence units span multiple executions and agents? pushes this further, arguing the thing to defend is a revisable set of linked actions across agents and executions, not one isolated review.

So the answer to "where do they fail" is that they fail at the planning boundary, where the attack enters before there is anything to inspect. They also fail at the seams between agents, and wherever harm exists only in the combination of steps. The corpus gives no single defense that closes all three. It gives a layered picture: an input-side check at planning, hop-level monitoring in between, and a stateful validation at the point of no return.