The Shell Command Is the Action

Of all the tools you can hand an agent, a shell is the one where the gap between "said something" and "did something" disappears entirely. A model that writes a paragraph about deleting a directory has done nothing. A model that emits rm -rf to a tool that runs it has deleted the directory. The shell is not a place where an agent describes an action. It is the action, and that makes it the tool most worth governing and the one where governing after the fact is worth nothing.

Why the shell is the high-blast-radius tool

A shell command composes. One line can read a file, encode it, and send it somewhere in a single pipe. It can reach the network, the filesystem, the process table, and the credential store without any of those being a separate, inspectable step. The same expressive power that makes the shell useful to a developer makes it dangerous in the hands of an agent following instructions that may not be entirely its operator's, because a single string can carry an entire attack from read to exfiltration with nothing in between for a per-tool allowlist to catch.

And the consequential commands do not look exotic. They look like the commands a developer runs all day, which is the point. The dangerous ones sit on a spectrum with the ordinary ones, and telling them apart is a judgement about what the command does, not about whether it is a shell command at all.

What a command scan is actually looking for

The classes that matter are the ones with irreversible or exfiltrating consequences:

• Destructive operations that cannot be undone: recursive deletes, disk overwrites, dropping a database, formatting a volume.
• Data exfiltration: reading something sensitive and piping or posting it out, often in one line that ends in a URL or an address.
• Remote code execution: the download-and-run pattern, a fetch of a remote script piped straight into a shell, which is how a single command becomes arbitrary code you never saw.
• Secret exposure: reading key material, environment files, or credential stores, whether to print them or to carry them somewhere.
• Privilege escalation: attempts to become root or to widen the permissions the command runs with.
• Reconnaissance and anti-forensics: mapping the environment, or clearing the logs and history that would otherwise record what happened.

The trap: scan the command you were given, not the one you cleaned up

There is a specific mistake that is easy to make and expensive to keep. A scanning pipeline often normalises input first, decoding, de-obfuscating, tidying, before it inspects. On prose that is correct. On a shell command it can erase the very thing you were looking for. A normaliser that rewrites characters can turn a base64-decode-and-pipe-to-shell one-liner into something the decoder no longer recognises, so the pipeline inspects a laundered version and passes it, while the original, unmodified command is what actually runs.

The rule that follows is: judge the raw command first, exactly as it will execute, and only then look at a cleaned copy for anything the surface form hid. The command that runs is the command that matters, and it is the one an attacker has already shaped to survive whatever tidying they expect you to do. This is not a hypothetical; it is the kind of thing that gets found the first time a canary probe runs against the real entry point rather than an inner helper.

Before, not after

All of this only helps if the verdict arrives before the command executes. A log of dangerous commands the agent already ran is an incident report, not a control. Governing the shell means the command is evaluated at the boundary, in line, and a blocked one never runs, while a borderline one can be held for a person who is given the command, the reason it was flagged, and what it would touch. The agent, on a block, receives the reason and a legitimate next step rather than a dead end, so it can correct course instead of retrying blindly.

The uncomfortable summary is that the most useful thing you can give an agent and the most dangerous thing you can give it are the same thing, and the difference is entirely in whether each command is judged before it runs. An agent without shell access is limited. An agent with ungoverned shell access is an incident waiting for the right instruction.

Shrike evaluates shell commands as actions before execution: the raw command first so normalisation cannot hide a payload, across the destructive, exfiltration, and code-execution classes above, with a blocked command stopped in line and a borderline one routed to a person. The related reading goes deeper: what action governance is, why a valid credential does not make an action safe, and the full map of surfaces an agent acts on.