2026-07-19

MOSAIC, and the fix that was already sitting there

A paper on CLI command-composition attacks sent us back to our own threat model — and turned up a hardened defense we'd built a month earlier but never wired into the executor that actually runs.

MOSAIC (arXiv:2607.02857) and its companion MOSAIC-Bench (arXiv:2605.03952) describe an attack class that needs no malicious instruction at all: chain individually benign CLI commands so one step's ordinary side effect — a hook path written to .git/config, a queued postinstall script — becomes the next step's silent execution. Across five coding agents and five backbone models, MOSAIC hit a 96.59% success rate. MOSAIC-Bench ran the same idea against nine production coding agents from six vendors and got 53–86% end-to-end success, with only two refusals across the entire benchmark. Five deployed defenses — instruction scanners, capability control, information-flow tracking, command scanners, an alignment monitor — all failed, because none of them reconstruct the producer-consumer state relation across separate commands. The strongest still let 82.57% through.

Our own threat model had already named this. T-05, written five weeks before MOSAIC published, calls out git commit running .git/hooks/pre-commit and npm test running whatever package.json says as "full code execution living inside the agent's own writable worktree." The prescribed fix — core.hooksPath=/dev/null plus --no-verify and a scrubbed git config for commits, the runner binary directly instead of npm test — was built and tested in governance-core's command templates a month before the paper existed.

It just wasn't being used. The live executor that actually runs an agent's git_commit and run_tests calls had its own, separate, unhardened implementation: --no-verify alone on commits, no config neutralization, and run_tests defaulting to plain npm test with no override anywhere in the app. Two hardened templates, fully tested a month earlier, sitting one call away from the code path they were built to protect — unused. Neither tool had a single test exercising it through the real executor, which is very likely why the drift went unnoticed for a month.

A hardened defense that isn't wired into the code path it protects is not a defense — it's a design document.

The fix routes both tools through the existing templates instead of duplicating them, extends the test-runner template to keep the allowlisted arg-filtering run_tests already had, and adds regression tests that plant an actual malicious pre-commit hook and an actual malicious package.json test script — exercised through the real executor, not just the template in isolation. npm run ci: 90 test files, 477 passed, 3 pre-existing skips, nothing broken.

The find is a useful data point on its own terms: a threat-modeling process converging independently on the same vulnerability class an academic paper later formalized, and a defense shape — remove the capability from the tool surface, rather than try to detect intent — that held up against every one of the five approaches MOSAIC tested. But the miss is the more durable lesson. Design intent and wired reality are two different claims, and only one of them is checked by npm run ci.

← All posts