An AI assistant that can call tools can read data, change settings and start scans. Safeguard controls that in two independent layers. Knowing which layer does what avoids a lot of confusion.
Layer one: tool gating on Safeguard's own MCP server
Safeguard hosts its MCP server at mcp.safeguard.sh. It registers hundreds of tools, but not every workspace sees all of them. Each tool has a feature flag of the form mcp:tool:tool_name, and the server resolves the enabled set per tenant.
That set is used twice: tools/list only advertises enabled tools, and tools/call rejects anything not enabled. Both come from the same source, so an assistant cannot see a tool it cannot call, or call one it cannot see.
A rejected call does not break the connection. It returns a normal tool result with an error flag and a message saying the tool is not enabled for this tenant.
Defaults are strict. A new workspace starts with six read-only tools: list products, list projects, get project, list vulnerabilities, get vulnerability and list findings. Everything else ships off and is enabled by an administrator under Feature Flags. If tool resolution fails, the server falls back to that small default set instead of widening access.
Gating is per tenant, not per user. For finer control, use Guard.
Layer two: Guard policies on live MCP traffic
Guard is a separate product that enforces policy on MCP tool calls in general, including servers and agents you build or operate. A policy lives in your Safeguard workspace, not in a file in source control. Guard pulls the saved default policy live.
Each rule can match on:
- the MCP method, such as tools/call
- the tool name, with glob wildcards
- the agent ID
and resolves to one of three actions: allow, deny (with a reason returned to the caller) or monitor (let it through but flag it). Rules are evaluated highest priority first and the first match wins. If nothing matches, Guard flags the request for monitoring rather than silently allowing or blocking it.
Rules can add input filters (block a pattern, cap request size, check encoding, catch known jailbreak phrasing) and output filters (mask common PII patterns, redact named columns, cap rows, mask a regex). A rule can also carry a rate limit.
Every evaluated request, whether allow, deny or monitor, is written to an append-only audit trail with the rule that matched and the scores Guard produced.
Two ways to deploy Guard
Guard Proxy is a self-hosted reverse proxy in front of MCP servers. You point the agent at the proxy URL instead of the upstream server, and each JSON-RPC call is evaluated before it is forwarded. This suits servers whose code you do not control.
Guard SDK embeds enforcement in your own server or agent process. The MCP docs state the SDK is not published yet, so there is nothing to install today. Treat any package claiming to be it as untrusted.
What not to confuse
Turning a tool off under Feature Flags does not create or change a Guard policy. A Guard policy does not touch Safeguard's feature flags. And Guard policies are a different system from Guardrails and Enforcement, the YAML policy-as-code for CI, registries and admission with BLOCK, WARN and AUTO_FIX effects.
The runtime enforcement point for Guard inside applications is listed in the guardrails docs as early access.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
What happens when no Guard rule matches a request?
Guard falls back to monitor: the request is flagged for review rather than silently allowed or blocked.
Is tool gating per user?
No. It resolves per tenant. Use Guard for per-agent control.
