Most AI security tools operate at the wrong layer. They scan inputs before the model sees them, or they log and alert after a tool call completes. Neither approach stops an attack that's already in motion. Pre-execution agentic AI security is different: it intercepts threats at the exact moment an agent has decided to call a tool — before that call executes.
This distinction matters more than it might look. Agents don't just process text. They write files, run shell commands, fetch URLs, read credentials, and interact with live systems. A prompt injection that reaches your agent's planning step can produce a valid tool call — one your runtime will happily execute unless something stops it first.
Why is agentic AI security different from traditional application security?
Traditional application security protects deterministic code paths. An agent's execution path is non-deterministic — its next action depends on model output, which depends on all context in the conversation window, including untrusted content the agent just fetched. A user injecting malicious instructions into a web page that your agent reads can redirect what your agent does next.
According to Bessemer Venture Partners (March 2026), "securing AI agents has become the defining cybersecurity challenge of 2026." The numbers back that up:
- HiddenLayer 2026 AI Threat Landscape: One in eight AI breaches is linked to agentic systems.
- Gartner: 40% of enterprise apps will embed task-specific AI agents by 2026, up from under 5% in 2025.
- IBM 2025 Cost of Data Breach: Shadow AI breaches cost $4.63M on average — $670K more than standard breaches.
- Dark Reading: 48% of cybersecurity professionals identify agentic AI as the most dangerous current attack vector.
NIST has issued a formal Request for Information on AI agent security considerations, signaling that the gap between agent capability and runtime security controls is being recognized at the policy level.
What's wrong with input guardrails for agentic systems?
Input guardrails — tools like NVIDIA NeMo Guardrails or Meta's LlamaFirewall — operate at the model boundary. They scan content before it enters the LLM context, looking for prompt injection patterns, policy violations, or sensitive data. For chatbots, this is reasonable. For agents, it's structurally insufficient.
The problem is timing. Agents aren't just ingesting single user prompts — they're consuming continuous streams of tool output, web content, file contents, and API responses during execution. An injection that arrives in the output of a web search, inside a README file in a cloned repo, or embedded in a CSV your agent was asked to process — none of these pass through the initial input filter. They enter the agent's context post-ingestion, after the guardrail has already passed the session.
Even the best prompt injection detection at the input layer cannot stop a threat that arrives as tool output two steps into an agentic workflow. The model processes it as context. The agent acts on it. The damage happens.
Why is post-execution detection too late?
Post-execution detection approaches — logging tool calls after they complete, running anomaly detection on agent behavior histories, sending alerts when suspicious patterns emerge — share a fundamental flaw: they're forensics, not prevention.
If an agent runs rm -rf ~/.ssh, a post-execution log tells you what happened.
It doesn't give you your SSH keys back. If an agent exfiltrates ~/.aws/credentials
to an external server, an alert fires after the data is already gone. Detection latency measured
in seconds is too slow when the damage from a single tool call is permanent.
Agents also tend to chain tool calls quickly. By the time a post-execution system fires an alert, three or four subsequent actions may have already completed. You're not stopping an attack — you're doing incident response.
How do the three approaches compare?
| Approach | When it acts | What it stops |
|---|---|---|
| Input guardrails (NeMo, LlamaFirewall) | When content enters the model | Prompt injection reaching the LLM |
| Post-execution detection | After tool call completes | Alerts on damage already done |
| Pre-execution blocking (Shoofly) | When agent requests a tool call | Stops the action before it fires |
The three approaches are not mutually exclusive — but pre-execution blocking is the only one that can prevent a destructive action from completing. The others are useful complements; they're not substitutes.
What is pre-execution blocking and why does the decision gate matter?
Pre-execution blocking intercepts a tool call after the agent decides to make it but before it executes. This is the decision gate: the agent has formed intent, the tool call parameters are fully specified, but nothing has happened yet. That's the only moment where you can evaluate the action and block it without side effects.
At this gate, you can inspect:
- The tool being called (is this
exec?write?web_fetch?) - The exact parameters (what path? what command? what URL?)
- Whether the call matches a known threat pattern
- Whether the call is consistent with the original task context
If the tool call violates policy, it's blocked. The agent gets an error. No file was deleted. No credential was sent. The session can continue with the problematic action suppressed.
How does Shoofly implement pre-execution blocking?
Shoofly installs as a plugin layer in OpenClaw and as a hook in Claude Code. Every tool call passes through Shoofly's evaluation engine before it executes. The evaluation is synchronous — if Shoofly blocks, the tool call never fires.
Rules are open: you can read them, edit them, and write your own. The default ruleset covers:
- Credential path access: blocks reads of
~/.ssh,~/.aws,~/.gnupg, and credential directories unless explicitly permitted - Dangerous shell patterns: blocks commands matching known destructive patterns
- Unexpected outbound transfers: flags
curl/wgetcalls to unapproved domains with file pipe patterns - Exec with untrusted input: catches shell execution where agent-controlled content flows into a command string
- MCP tool call anomalies: detects tool calls inconsistent with the tool's declared purpose
Shoofly Basic is free. The threat policy is open and auditable. Shoofly Advanced upgrades detection to full pre-execution blocking, adds real-time alerts via Telegram and desktop notifications, and policy linting.
Who is pre-execution blocking for?
Any developer running agents with real system access — specifically:
- Claude Code users who clone untrusted repos, process third-party content, or run Cowork/Dispatch sessions
- OpenClaw users running agents with exec, file, browser, and web tools
- Teams running unattended agents (heartbeat agents, cron agents, multi-agent pipelines)
- Anyone who wants to audit what their agent is actually doing before it does it
Add pre-execution blocking to your agent stack
Shoofly Basic is free. No API key, no account required.
curl -fsSL https://shoofly.dev/install.sh | bash