# Your Coding Agent Can Be Tricked by Boring Shell Commands

Canonical URL: https://huecki.com/en/blog/coding-agent-command-composition-risk/
Markdown URL: https://huecki.com/en/blog/coding-agent-command-composition-risk.md
Language: English
Published: 2026-07-07
Updated: 2026-07-07
Author: Dominic Hückmann
Topic: AI Agent Security
- Agent topics: Agent Security, Context Engineering
- Tags: AI Agents, Coding Agents, Security, Developer Workflow, Failure Mode
Content status: field-note

## Summary

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.

## Description

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.

## Body

## 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.

## 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.

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:

```txt
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:

## What this replaces

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.

## Sources

- [MOSAIC: Knowledge-Guided CLI Command Composition Attack in LLM Coding Agents](https://arxiv.org/abs/2607.02857)
- Huecki AI radar, 2026-07-07 — `/root/website/content-research/radar/2026-07-07.md`

## 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.