How to stop LLM agents from nuking your filesystem with AST

Running shell commands via an LLM agent feels like playing Russian roulette with your root directory. We’ve all seen the demos where an agent decides to rm -rf / or accidentally overwrites a critical config file because it misinterpreted a path variable. The problem isn't just "bad prompting"—it's that standard text-based safety checks can't actually understand the intent or the structural risk of a command before it hits the terminal.

I've been looking into a more robust way to handle this by combining Abstract Syntax Tree (AST) parsing with a dedicated subagent. Instead of just asking an LLM "Is this command safe?", we can actually break the command down into its logical components to see exactly what it's trying to do to the system.

The Architecture of a Safer Shell Agent

The workflow moves away from a single, monolithic loop and toward a multi-layered validation pipeline. Here is how a high-reliability deployment should look:

1. Command Generation: The primary LLM agent generates a shell command based on the user's natural language request.
2. AST Decomposition: Instead of passing the raw string to the shell, the command is piped into a parser. For bash or python-based execution, we use AST parsing to identify high-risk nodes. We look for specific patterns: redirection operators (>), destructive flags (-r, --force), or unexpected environment variable expansions.
3. Subagent Review: The parsed structure—not just the raw text—is sent to a specialized "Security Subagent." This agent is prompted with a very narrow scope: "Analyze this command structure for side effects."
4. Execution or Refusal: If the subagent flags a high-risk pattern (like a sudo command targeting a system directory), the loop breaks and asks for human intervention.

Why AST parsing beats simple regex

Most "safe" AI agents use regex to look for keywords like rm or chmod. This is incredibly brittle. A user could bypass this with simple obfuscation or complex piping. By using AST, we are looking at the actual execution logic.

If an agent generates:

find . -name "*.log" -exec rm {} \;

A regex might miss the danger if the pattern is slightly altered. An AST parser, however, identifies the find command, the exec action, and the rm subcommand as a single logical unit of destruction.

Implementing a basic validation step

If you are building your own AI workflow, you don't need a massive model to do the validation. A small, fast model (like a fine-tuned Llama or even a structured prompt in Claude) works best for the subagent role.

Here is a conceptual way to structure the subagent's prompt for a real-world scenario:

{
  "task": "Shell Command Security Audit",
  "input_structure": {
    "command": "rm -rf ./tmp/ old_logs",
    "parsed_components": {
      "action": "delete",
      "target_type": "directory",
      "flags": ["-r", "-f"],
      "scope": "relative_path"
    }
  },
  "safety_protocol": "Evaluate if the 'scope' could escalate to system-level directories or if 'flags' indicate irreversible actions without user confirmation."
}

By forcing the agent to reason about the parsed components rather than the raw string, you reduce hallucination. The subagent isn't guessing what the command does; it is auditing a structured report of the command's intent. This is a much more professional approach to prompt engineering for autonomous systems. It turns a "black box" execution into a verifiable, step-by-step process.