The default security playbook is: monitor inputs, log outputs, fire alerts when something looks wrong. That model works for servers. It doesn't work for agents.
With a web app, you can detect a SQL injection attempt and block the query before it hits the database. The detection layer and the execution layer are different systems — there's space to intervene. With an AI agent, that gap doesn't exist the same way. The agent decides to act, and then it acts. If you're running detection on the output side, you're not doing security. You're doing forensics.
Why Post-Execution Detection Fails for AI Agents
Here's what that looks like concretely. A prompt injection slips into a document your agent is summarizing.
It instructs the agent to forward your .env file to an external URL.
Your detection system flags the outbound request — after the tool call fires, after the credentials
leave the machine. You get an alert. Your secrets are already gone.
Or: an injected instruction tells your agent to clean up a directory. The agent issues a shell command. By the time your monitoring system logs the event, the files are deleted. Detection at that point is just a better incident report.
This isn't a criticism of logging or observability — those have real value for post-mortems and compliance. But in agentic AI security, the only moment that actually matters is the one where the agent has formed its intent and hasn't executed yet. That window is small. It's also the only window that counts.
What Is Pre-Execution Blocking for AI Agents
We call it the decision gate. It sits between intent and execution — after the model decides what tool to call and with what arguments, but before the runtime fires the call. That's where pre-execution blocking lives.
At the gate, you have the full picture: what tool, what arguments, what the agent was instructed to do, and what policy says about it. You can inspect, evaluate, and — if something looks wrong — halt. Not log. Not alert. Halt.
This is why Shoofly is built around pre-execution blocking rather than detection. We intercept tool calls before they fire. We evaluate them against rules — open, auditable rules you can read and modify. If a call violates policy, it doesn't execute. Full stop.
Prompt injection blocking follows the same logic. We don't just flag that an injection might have occurred. We catch the resulting tool call at the gate and prevent it from doing damage — whether that's file access, network egress, or anything else your policy doesn't allow.
Pre-Execution Blocking vs. Detection: The Key Difference
Detection isn't wrong. It's just the wrong layer for agents. Use it for forensics, compliance, post-incident review. But don't confuse a good alert system with actual prevention.
Our bet is on the gate. Not because we think blocking is more elegant — it's often messier to implement — but because it's the only architectural choice that actually prevents damage in an agentic AI security context. The threat model for agents is different. The response has to be too.
Shoofly runs on OpenClaw and Claude Code (Cowork/Dispatch). Basic tier is free. Advanced is $5/month. Rules are open and auditable — no black-box decisions at your gate.
Install Shoofly Basic free — pre-execution blocking for Claude Code and OpenClaw agents:
curl -fsSL https://shoofly.dev/install.sh | bashRelated reading: OpenClaw FAQs · Claude Code FAQs · Shoofly pricing