Guard checks each MCP request against your policy's rules from the highest priority down and applies the first rule that matches. A rule resolves to allow, deny or monitor. If nothing matches, Guard flags the request for monitoring instead of allowing or blocking it silently.
What a policy is
A Guard policy belongs to your organization and holds an ordered list of rules. You edit it in your Safeguard workspace, not in files in source control. Several policy records can exist, but exactly one, the one marked default, is enforced. A policy that is saved but not marked default is never evaluated against live traffic.
Keep exactly one default per organization. The documentation warns that the lookup does not break ties between several defaults.
What a rule can match on
A rule combines any of these conditions, and all stated conditions must hold:
- Method. The JSON-RPC method, such as tools/call. Case insensitive.
- Tool name. Glob wildcards work: a star for any run of characters, a question mark for one. Case insensitive.
- Agent ID. An exact agent identifier.
A condition you leave out matches anything. There is no separate server name condition. To scope to one server, match on the tool names it exposes, or on the agent that calls it.
The three actions
| Action | Effect |
|---|---|
| allow | The request proceeds. |
| deny | The request is blocked before reaching the tool, with a reason shown to the caller. |
| monitor | The request proceeds and is flagged for later review. |
Monitor is the useful one while you are tuning. It lets you see what a new rule would catch before you start blocking.
Evaluation order in practice
Suppose rule A, priority 100, denies tools matching a pattern for support. Rule B, priority 10, masks personal data on export tools. A request for a support tool meets A first and is decided there. A request for an export tool does not match A, falls to B, and is decided there.
Mistakes to avoid
Equal priorities. If two rules share a priority, order between them is not guaranteed. Give distinct values wherever order matters.
Typos in field names. Unknown fields are ignored without an error. A misspelled match field simply does nothing, so a rule can look present and be inert.
Sending a partial rule list. Create and update calls take the whole policy including every rule. There is no endpoint to edit a single rule.
Forgetting the default. With no default policy at all, all traffic is flagged for monitoring.
How changes reach running systems
Guard instances pull the live policy in the background, so a saved edit reaches them within moments with no restart. If an instance cannot reach Safeguard, it keeps enforcing the last policy it fetched.
Writing your first policy
- Start with one monitor rule that matches tools/call for every tool.
- Read the audit trail for a week. See what the audit trail records.
- Add deny rules for patterns you are sure about.
- Add output filters where responses can carry personal data. See Guard input and output filters.
Quick check
Why did my deny rule not fire?
Check priority order, a higher priority rule matching first, field name typos, and whether this policy is marked default.
Is Guard policy the same as pipeline policy?
No. Pipeline gates use block, warn and auto fix effects against SBOM, CVE and license rules. Guard policies govern live MCP calls.
Sources
Last reviewed: 19 October 2026.
