How to stop LLM agents from nuking your filesystem with AST

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 thefind

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.

Terminal Bench 3 is finally here to stop the data contamination 15d ago

Next How AI providers' throttling backfires — and a tool to prove it →

these real-world AI monetization case studies, with plenty of directly applicable cases.