MCP Guard vs static allowlists and denylists

An allowlist or denylist says exactly which tools, commands, paths, hosts or argument patterns an agent may use. It has properties no model can match:

• Deterministic. A denied command is always denied.
• Free and instant. A string match costs nothing.
• Auditable. The rule is its own explanation, which reviewers and auditors like.
• Not persuadable. No prompt can argue a regex out of its decision.

Combined with least privilege (credentials that simply cannot do the dangerous thing), rules remove whole categories of risk. You should never replace them with a model.

Rules judge the shape of a call. Many dangerous calls have a perfectly ordinary shape:

• DELETE FROM sessions WHERE created_at < now() - interval '30 days' is routine cleanup on a scratch database and a serious incident when the agent was connected to production and the user asked for a report.
• send_email(to="partner@example.com", body=...) is fine when the user asked for it, and is data exfiltration when the recipient and body came from an instruction hidden in a document the agent just read.
• refund(order_id, amount) is allowed, but not with an amount the customer never mentioned.

To catch these with rules you need to encode intent, provenance and environment into patterns. Rule sets that try grow long, brittle and full of exceptions, and they still miss the next variation. This is the gap OWASP's Top 10 for LLM Applications describes under excessive agency: the agent has legitimate permissions and uses them in a way nobody intended.

MCP Guard reads the action together with the user's request, what triggered the action (the user, or a tool result), any constraints you pass ("staging only", "never email outside acme.com") and recent conversation. It returns a verdict and nine scores, including blast radius, whether the call looks injected, and whether the arguments are grounded in what the user asked.

That lets it flag calls that match no rule. It is also probabilistic: it will sometimes allow something it should not and ask about something harmless. That is why it sits behind the rules, not in place of them.

A simple order that works for most agents:

1. Hard deny from rules: commands and targets that are never acceptable (rm -rf /, production credentials in a dev agent, unknown outbound hosts).
2. Hard allow from rules, optionally: read-only calls you are certain are harmless, if you want to save the check.
3. MCP Guard on everything else. Allow runs; ask goes to a human or a slower reviewer; block is refused.
4. Fail closed. If the guard cannot be reached, fall back to ask or block for anything that writes, rather than letting it through. See fail-closed.

Feed incidents back into both layers: an exact pattern becomes a rule; a contextual miss becomes a labelled example and possibly a tighter threshold.

If your agent has a small, fixed set of tools, all read-only or trivially reversible, rules plus least-privilege credentials may be all you need. The same holds when every write already goes through a human approval step. A guard earns its place when agents have write access to things that matter and make more calls than a human can review.