When a vendor sells MCP guardrails, ask where enforcement happens, what it can block versus only log, how it identifies the agent and the user, what happens when it fails, and what evidence it keeps. Those five answers separate a control that protects you from a dashboard that watches you.
Start with the threat, not the feature
The MCP security best practices page describes attacks such as confused deputy flows, token passthrough, SSRF during OAuth discovery, session hijacking, local server compromise and over-broad scopes. Ask the vendor which of these their product addresses and which it leaves to you. A good answer is specific. A vague answer about protecting AI usage is a warning sign.
Twelve questions
-
Where does enforcement run: client, proxy, server or network?
-
Can it block a call, or does it only alert?
-
If the guardrail is unreachable, does traffic fail open or fail closed, and can I choose?
-
How does it identify the agent, the user and the tool in each call?
-
Does it inspect tool arguments and results, or only tool names?
-
How are policies written, tested and versioned?
-
Can I run in observe mode first and see what would have been blocked?
-
What does it log per call, and where does that log live?
-
How does it handle tool lists that change after approval?
-
Does it help with local servers, remote servers, or both?
-
What credentials does it hold, and how are they scoped?
-
What does an exit look like: can I export policies and logs?
How to test the answers
Ask for a live run with a deliberately bad case. Point an agent at a test server whose tool description tries to instruct the model, and see whether the guardrail notices. Try an over-broad token. Try a tool that changes its description after approval. Vendors who welcome this test are usually confident for good reason. Record what was blocked, what was logged, and what passed unnoticed.
Do you need a product at all?
For a handful of approved servers and a small team, a written allowlist, least privilege scopes and client side approval prompts may be enough for now. A dedicated guardrail pays off when many people connect many servers and you need central policy and evidence. Be honest about which situation you are in.
Also ask about change over time. MCP servers update, tools are added, and descriptions change. A guardrail that approves a server once and never rechecks leaves a gap that attackers like. Ask how the product detects a changed tool list and what the user experience is when it does. Finally, ask for a reference from a customer with a similar number of servers and users, and ask that customer what they wish they had known before buying.
Try it yourself
Click through the demo and watch how the results change as you move through each step.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard offers an MCP Guardrail with policies, plus agent identity and asset discovery for MCP servers and agents, and the same demo flow shows how a server is connected.
Quick check
What is the most important single question?
Whether the control blocks or only observes, and what it does when it fails. That decides the real protection level.
Sources
Last reviewed: 19 October 2026.
