Can a hacker sneak past AI safety checks by splitting one harmful job into harmless-looking pieces?

This explores whether an attacker can reach a harmful result by splitting it into pieces that each look fine (or pass review) on their own, so the harm only exists once the pieces are put together. The corpus says yes, and it treats this as a built-in weakness of multi-agent systems rather than an exotic trick.

The basic mechanism comes from what makes multi-agent systems useful: splitting work into subtasks and giving each agent a specialty. SafeFlow shows that this same design lets a malicious goal be spread across steps that each look benign, with the harm appearing only in the combination (Can task decomposition hide harmful intent across agents?). Any check that looks at one step at a time has nothing to flag, because no single step is the problem.

Two other notes show where in the pipeline this happens. ColluSkill attacks systems that use reusable skills. It plans a chain of skills, then uses feedback from security scanners to soften each skill until it no longer looks suspicious. It reaches about 96% average attack success across six scanners. The trick works because the scanners score skills one at a time, so the attacker can lower suspicion for each skill while the chain as a whole still does the harmful thing (Can attackers evade skill scanners by refining individual skills?). FLOWSTEER moves the attack earlier, to planning. A crafted prompt biases how a planner-executor system builds its workflow, before the defenses that inspect workflows have run. That raised malicious success by up to 55 percent (Can prompts alone reshape multi-agent workflows without system access?). In that case the harmful assembly happens when the plan is drawn up, not when the steps run.

The corpus has one clear answer on defense, and it follows from the same problem. If harm lives in the combination, the thing you inspect has to be the combination. One note argues that the unit of defense should be a set of actions linked by observed hand-offs, task authority, and response history, and that the set's membership should be revised as new evidence arrives. Reviewing each execution in isolation throws away the context that connects the pieces (Should defence units span multiple executions and agents?). A related note on the routing layer shows how much sits below prompt-level checks. Whatever decides which model handles a request can itself be manipulated, so safety measures may end up running against the wrong model (Can attackers manipulate which model handles a request?).

The evidence here is thinner than the question deserves. The attack side is well covered. The defense side is mostly one proposal for changing what gets reviewed, and the corpus has no tested method for catching a composed attack. It also talks about steps that look benign or score low, not steps that were formally authorized. The reasoning carries over, but the notes don't test it on permission systems directly.