Skip to content

AI Agent Security

Your Coding Agent Can Be Tricked by Boring Shell Commands

MOSAIC shows a quieter coding-agent risk: ordinary CLI commands can become dangerous when one command writes state that a later command consumes. Here is the stealable trace audit.

July 7, 2026 · Dominic Hückmann

Short Answer

The MOSAIC paper shifts the coding-agent security question from hostile prompts to command traces. The practical move is to audit producer-consumer state across shell commands before generated state crosses into privileged work.

Short answer

Most coding-agent security advice watches for the obvious thing: a hostile instruction, a suspicious tool call, a prompt injection hidden in a file.

The MOSAIC paper points at a quieter failure mode. A coding agent can run a sequence of commands where every command looks boring in isolation, but the sequence becomes dangerous because command two consumes state created by command one.

That is the uncomfortable part. The attack is not “please exfiltrate my secrets.” It is normal Unix composition: files, caches, environment variables, sockets, config, package state, process state. The same mechanism that makes developer tooling useful also gives agent traces a hidden data-flow layer.

2,525
MOSAIC evaluation trials
5
real-world CLI coding agents tested
5
backend LLMs tested
96.59%
reported attack success under benign developer tasks

What changed

When humans review an agent run, they usually scan the final diff and maybe the most suspicious command. MOSAIC says that is the wrong unit.

The unit is the command trace.

A command that writes a config file is not just a command. It is a producer. A later command that runs a build, package manager, test harness, or deploy script may be a consumer. If the produced state is untrusted and the consumed action is privileged, the risk lives in the edge between the two commands.

Command trace as data flow

the risky part is often the edge, not the individual command

  1. 01
    Command writes state
  2. 02
    State persists
  3. 03
    Later command reads it
  4. 04
    Trust boundary crossed
  5. 05
    Privileged action runs

This is why prompt-only defenses feel too narrow. The malicious intent does not need to appear as text in the model context. It can be distributed across a workflow that looks like ordinary development.

The workflow to steal

Before letting a coding agent run a longer shell sequence, audit the trace like a tiny state machine:

Audit this agent command trace as a state machine.

For each command, list:
1. state produced: files, env vars, caches, sockets, processes, config
2. state consumed later
3. trust boundary crossed
4. privileged action reached
5. cheapest mitigation: isolate, confirm, hash, reset, or block

The goal is not to ban shell composition. That would make agents useless. The goal is to add gates around the few transitions that matter:

Transitions worth gating

  • Generated files moving into tests, builds, package publishing, deploys, or git history.
  • Untrusted config moving into a command that loads plugins, hooks, aliases, or shell profiles.
  • Agent-written package state moving into install scripts, postinstall hooks, or executable paths.
  • Any produced state that can touch credentials, network calls, releases, or customer data.

What this replaces

Reviewing commands vs. reviewing state

Per-command review

  • Looks for one obviously bad command.
  • Asks whether `npm test` is safe.
  • Treats files as final artifacts.
  • Reviews the final diff after the run.

Trace-state review

  • Looks for producer-consumer links across commands.
  • Asks what generated state `npm test` will load.
  • Treats files as inputs to later privileged actions.
  • Reviews trust-boundary crossings before the run.

The practical shift is small but sharp: stop asking only “is this command allowed?” and start asking “what state does this command make available to the next command?”

Where it fails

This can become performative paranoia if you apply it to every ls, pwd, and harmless read-only inspection. The useful version is targeted. Spend attention where generated or untrusted state crosses into authority: credentials, deploys, package hooks, git history, network calls, CI, browser sessions, or persistent config.

It also does not cover every agent surface. Browser agents have cookies, local storage, tabs, downloads, and app-side state. SaaS agents have tokens, webhooks, queues, and database rows. The same idea applies, but the state map changes.

Command-trace security for coding agents

Do

  • ✓ Log commands with declared intent, reads, writes, and later consumers.
  • ✓ Reset or isolate state before package installs, tests with hooks, deploys, and git operations.
  • ✓ Require confirmation when untrusted/generated state reaches credentials, publishing, or production.
  • ✓ Keep hashes or proof bundles for artifacts the agent creates before privileged steps.

Don't

  • × Assume a command is safe because it looks normal in isolation.
  • × Review only the final diff when the shell trace created hidden intermediate state.
  • × Let agent-written config, hooks, or package state flow into privileged commands unnoticed.
  • × Turn this into blanket shell panic; target the trust-boundary crossings.

Sources

FAQ

What is CLI command-composition risk?

It is the risk that individually benign shell commands become dangerous as a sequence because one command writes files, environment, cache, process, or other operating-system state that a later command consumes.

What did MOSAIC evaluate?

The paper evaluates realistic developer workflows against five real-world CLI coding agents and five backend LLMs over 2,525 trials.

What is the practical workflow?

Review the command trace as a data-flow graph: list what each command produces, what later commands consume, where trust boundaries are crossed, and which transitions need sandboxing or confirmation.

Need AI-first architecture support?

Send me a short note about your project or technical bottleneck.

Get in touch