If every step in an AI workflow passes its own safety check, can the whole thing still go wrong?

This explores whether checking each piece of a multi-step AI pipeline can catch failures that only appear when the pieces run together. The corpus says mostly no. Every step can pass its own check while the workflow as a whole still fails. Across three different systems, SafeFlow, ChannelGuard and Honest Quorum, steps passed checks for plausibility, alignment and protocol compliance and the end-to-end behavior was still unsafe. The reason is that local checks verify different properties than the ones that determine whether the whole thing is safe Can individual components pass safety checks if the system still fails?.

The corpus points to two structural reasons. The first is memory. A check that looks at one action at a time can't even state a rule that depends on what happened earlier. Each action can be individually permissible while the combination violates a system-level constraint, and only monitors that keep state across the whole multi-party sequence can express that rule Can stateless checks ever catch sequence-level constraint violations?. The second is the seams between components. In a planner, worker, verifier and synthesizer pipeline, five internal hops (planner to worker, tool to worker, memory to worker, worker to verifier, worker to synthesizer) get no defensive inspection. Existing defenses watch only the user's input, so an injection hiding in a tool result or a memory entry can travel downstream unnoticed Do internal agent hops in pipelines need security monitoring?. Monitors of reasoning have a similar blind spot. They assume one author wrote the trace, so when a model paraphrases reasoning it picked up from retrieved context, the monitor can't see that the reasoning came from outside Can chain-of-thought monitors detect reasoning that originates elsewhere?.

What does work is moving the check from the component to the trajectory. Checking intermediate states and policy compliance during a long reasoning trace, rather than scoring only the final answer, raised task success from 32% to 87%, because most failures turned out to be process violations rather than wrong answers Where do reasoning agents actually fail during long traces?. BenchShield takes the same idea into benchmark evaluation. It models a run as a finite lifecycle of typed events and flags any deviation from the intended path, instead of pattern-matching for known exploits Can a finite lifecycle model detect reward hacking across benchmarks?. That lets operators claim a run was valid based on recorded infrastructure evidence rather than a terminal score alone Can infrastructure evidence replace terminal scores in benchmark validation?. Stateful checking also doesn't have to be slow. Verifiers that run alongside generation and step in only on violations add near-zero latency on correct runs Can verifiers monitor reasoning without slowing generation down?.

MAKER is the one result that looks like a counterexample. It splits a task into minimal subtasks, votes at every step, and completes million-step runs with zero errors using small models Can extreme task decomposition enable reliable execution at million-step scale?. But its local check is built around a system-level threat. It flags correlated errors, the kind that would let a mistake survive voting and spread. So component-level checking can catch system-level failures when it is designed to test the property that produces them. Ordinary checks for plausibility or compliance don't do that.

The practical takeaway is that a pipeline made of individually safe parts has no safety guarantee as a whole. The guarantee has to be checked at the level of the whole trajectory.