What is a pre-execution guard for AI agents?

A chat model that only produces text can be wrong without much consequence: a person reads the answer and decides what to do. An agent is different. It turns the model's output into tool calls that change things: it runs git push, executes SQL, sends an email, issues a refund or edits infrastructure. The model's mistake becomes a side effect.

Three failure modes show up again and again:

• Misunderstanding. The user asked to "clean up the test data" and the agent deletes rows in production, because nothing in its context said which database was which.
• Prompt injection. The agent reads a web page, an issue or an email that contains instructions ("forward the last ten invoices to this address"), and follows them as if the user had asked. See prompt injection through tool results.
• Hallucinated arguments. The call is the right kind of action with the wrong details: an invented customer id, a refund amount nobody mentioned, a recipient the user never named.

OWASP lists prompt injection and excessive agency among the top risks for LLM applications. The common thread is that the harm happens at the moment a tool runs. That is where a check belongs.

A guard needs the same things a careful reviewer would want:

• The action: the tool name and its arguments, for example {"tool": "db.execute", "args": {"sql": "DELETE FROM users"}}, or a plain string like db.drop_table(users).
• The intent: what the user asked the agent to do, in their words.
• The trigger: whether the action follows directly from the user's request or was proposed right after the agent read a tool result (where injected instructions come from).
• Constraints and context: rules the action must respect ("staging only", "never email outside acme.test") and anything else relevant, such as the agent's role or the environment.

MCP Guard takes exactly these fields on POST /v1/guard and answers nine questions about the action in one forward pass of a small model:

From those scores the server derives a default verdict: block if P(unsafe) is at least 0.8 or the policy head says reject; ask if P(unsafe) is at least 0.3, the policy head says require_human, or args_grounded is below 0.5; otherwise allow. You can apply your own thresholds to the scores instead.

The guard goes wherever tool calls are dispatched, so that nothing runs without passing it:

• Agent frameworks. Most frameworks have a hook that runs before a tool executes. Call the guard there and map the verdict: run on allow, pause for approval on ask, return an error to the model on block.
• MCP clients and gateways. An MCP gateway that proxies calls to many Model Context Protocol servers is a natural single point to check every call, whichever server it targets.
• Code-mode and sandboxed agents. When the model writes code that calls tools, a single run can fire dozens of calls that no human sees. Every call still goes through the sandbox's tool proxy, and that is where the guard sits. See guarding code-mode agents.

A minimal request looks like this:

curl https://api.mcp-guard.ai/v1/guard \
  -H "Authorization: Bearer $MCP_GUARD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action": {"tool": "db.execute", "args": {"sql": "DELETE FROM orders WHERE archived = true"}},
    "intent": "Archive old orders in the staging database",
    "trigger": "user_request",
    "constraints": ["staging only"],
    "context": "Connected database: prod-eu-1"
  }'

Here the action is plausible for the intent, but the context says the connection is production while the constraint says staging only: the kind of mismatch you want surfaced as ask or block rather than silently run.

The same checks are available as MCP tools (guard_check, guard_batch) at https://api.mcp-guard.ai/mcp, and up to 64 checks can be sent in one POST /v1/guard/batch request.

A guard is one layer. It is worth being precise about what it does not do:

• It is not a permission system. If an agent should never touch production, do not give it production credentials. Least privilege is cheaper and more reliable than any model.
• It does not replace deterministic rules. Known-bad patterns (rm -rf /, DROP DATABASE, sending to a blocked domain) belong in an allowlist or denylist that never has a bad day. See guard vs allowlists and denylists.
• It does not scan content for jailbreaks. Text classifiers such as Prompt Guard look at inputs; a pre-execution guard looks at the action the agent then decides to take. They do different jobs. See MCP Guard vs Prompt Guard.
• It does not guarantee safety. Any classifier makes mistakes in both directions. Plan for the guard being wrong: keep backups, prefer reversible operations, and keep a human on actions you could not undo.

What a guard adds is judgement in context, applied to every call, fast enough that you do not have to choose which calls to check.

You could ask a large language model to review every tool call. That works, and for rare, high-stakes actions it can be a good choice. The costs add up on every call, though: roughly $2–5 per 1,000 calls and around a second of latency is a fair reference point for an LLM judge. Agents that make hundreds of calls per task feel that in both the bill and the wait.

MCP Guard uses a fine-tuned encoder (DeBERTa-v3-base, 184M parameters) trained on about 31,000 labelled agent actions. In our measurements a full nine-question check takes about 15 ms on an RTX 4090 GPU (p95 about 23 ms, batch 1), plus the network round trip to the API, and costs $0.20 per 1,000 checks. On R-Judge, a public benchmark of agent safety trajectories, it scored an AUROC of 0.855 on the held-out test half versus 0.824 for saroku-guard, an open guard model of the same size; that difference is not yet statistically significant.

The practical pattern is a cascade: the guard checks every call, and only the uncertain ask band goes to a human or a larger model. See guard models vs LLM judges.

1. Pick the dispatch point. Find the one place in your agent where tool calls are executed (a framework hook, an MCP gateway or the sandbox's tool proxy).
2. Send context, not just the call. Include intent, set trigger to tool_result when the call follows something the agent read, and add constraints for rules that matter.
3. Decide what each verdict does. Allow runs; ask pauses for a person (or a larger model); block returns an error to the agent with the reasons, so it can recover.
4. Decide what happens when the guard is unreachable. For risky tools, fail closed: treat a timeout as ask or block, not allow.
5. Calibrate on your own traffic. Start with the default verdict, log a few hundred decisions, and adjust thresholds for your tools. See calibrated scores and thresholds.