Tool gating controls which of Safeguard's own MCP tools an assistant can see and call, using per tenant feature flags. Guard is a separate product that enforces live policy on MCP tool calls in general, including servers and agents you build yourself. If you only connect an assistant to Safeguard, tool gating is enough.
The two mechanisms
| Tool gating | Guard | |
|---|---|---|
| Covers | Safeguard's own MCP tools | Any MCP server or agent you route through it |
| Decision | Enabled or disabled per tool | Allow, deny or monitor per rule |
| Scope | Per tenant | Per rule: method, tool name, agent |
| Where it runs | Safeguard's hosted MCP server | In your process (SDK) or in front of servers (proxy) |
| Content filters | No | Input and output filters |
Safeguard's documentation is explicit that they are independent. Turning off a Safeguard tool under Feature Flags does not create or change a Guard policy. A Guard policy does not touch Safeguard's tool flags.
When tool gating is enough
You use Claude, ChatGPT or Cursor to ask Safeguard about your own projects. The only MCP server involved is Safeguard's. Your question is "which of Safeguard's tools can the assistant call?" Tool gating answers it, and the default is the six read-only tools.
When you need something like Guard
- You build or operate your own MCP servers.
- Your agents call third party MCP servers you do not control.
- You want to mask personal data in tool responses, cap row counts, or block calls that look like prompt injection.
- You want a record of every decision, including allowed ones.
- You want to block or quarantine one specific agent.
None of these are questions about Safeguard's own tool list.
A note on maturity
The Guard SDK page in Safeguard's documentation describes Guard as early access, with SDK packages installable only from Safeguard's own registry using a pull token. Check the current state with Safeguard before you plan a rollout around it. The documentation also says tool poisoning detection is not available yet, and that alert rule evaluation is not wired up yet.
How the layers combine
Think of three layers for an agent that uses MCP: what the client is allowed to connect to, what the server exposes, and what each call is allowed to do. Gating handles the second for Safeguard. Guard targets the third. The first is a client or organization setting, such as a managed connector list.
For deeper background on the risk Guard aims at, see our post on layered access control for MCP tools.
Quick check
If I disable a tool in Feature Flags, is it blocked in Guard too?
No. They are independent. Guard policy does not read the feature flags, and the flags do not create Guard rules.
Do I need Guard to use Safeguard with Claude?
No. Connecting an assistant to Safeguard does not require Guard.
Sources
- Safeguard docs: Tool availability and gating
- Safeguard docs: MCP integrations overview
- Safeguard docs: Guard SDK
- Safeguard docs: Audit trail and alerts
Last reviewed: 19 October 2026.