Pre-tool-use hooks — the safety net that prevents agent disasters

Your agent just tried to delete your entire repository. Or send an email to your biggest client with half-finished thoughts. Or charge $500 to a credit card for something you never approved.

The problem isn't that your agent is malicious — it's that there's no pause button between "I think I should do this" and "I'm doing it right now."

Pre-tool-use hooks are the safety net you didn't know you needed. They sit between your agent's decision to use a tool and the actual execution, giving you a chance to intercept, modify, or cancel dangerous actions.

Here's the pattern that's saved me from dozens of near-disasters:

def pre_tool_hook(tool_name, args, context):
    # Financial safety net
    if tool_name == "stripe_charge" and args["amount"] > 100:
        return "REQUIRE_APPROVAL", f"Charge of ${args['amount']} needs approval"
    
    # Destructive action protection
    if tool_name in ["delete_file", "rm_command"] and "important" in args.get("path", ""):
        return "BLOCK", "Cannot delete files in important directories"
    
    # Communication guardrails
    if tool_name == "send_email" and "@client.com" in args["to"]:
        return "REVIEW", "Client email flagged for review"
    
    return "PROCEED", None

The hook returns three possible states: PROCEED (execute normally), REVIEW (show me first), or BLOCK (don't do this ever).

Real example: My coding agent tried to run git reset --hard HEAD~10 to "clean up the commit history." The pre-hook caught it because any git command with --hard gets flagged for review. Saved me two hours of recovery work.

You can implement this at different levels:

• Tool wrapper level: Intercept at the function call layer
• MCP server level: Build hooks into your MCP server responses
• Agent prompt level: Train your agent to describe actions before taking them

The prompt-level approach is surprisingly effective:

Before using any tool that could:
- Spend money (>$10)
- Delete or modify files
- Send external communications
- Make API calls to production systems

First describe what you're about to do and why, then ask: "Should I proceed?"

The key insight: your agent should be paranoid about three categories of actions — financial, destructive, and external communication. Everything else can probably run without intervention.

I've been running this pattern for six months across four different agents. The false positive rate is under 5%, but it's caught genuine disasters at least once a week. The peace of mind alone is worth the occasional interruption.

The best part? Your agent gets better at self-regulation. After seeing what gets flagged, it starts being more careful about how it approaches risky operations. It's like having a junior developer who learns from their safety net.

If you're running agents in production — especially coding agents with file system access or business agents with API keys — you need this pattern. The question isn't whether your agent will eventually try something dangerous. It's whether you'll catch it in time.