Custom policies and custom rules in MCP Trail are how security and platform teams align the Guardian proxy with real governance: policy packs set org-wide defaults (which tools default to HITL, how DLP behaves), while rules catch company-specific data patterns that no generic detector will know. Together they sit alongside catalog allowlists, tool sequencing, and audit—see the feature overview for the full gateway surface.
Why two layers: policies vs rules
- Policies (and policy packs) answer: What is our organizational stance? Which tools are disabled, log-only, HITL, or auto? What is the default DLP posture for this server or environment?
- Custom rules answer: What exact patterns must we catch? That is where regex, keywords, and tool-class conditions come in—beyond generic detectors.
If you only have rules without policy, you get noisy alerts. If you only have high-level policy without rules, you miss company-specific data (internal project IDs, contract numbers, region-specific PII).
Finance org
Goal: Allow read-only MCP tools for market data; no outbound email or Slack without HITL; block payment-card-shaped data in any argument.
Configuration shape:
- Policy pack: “Finance – production” → HITL on
send_*,post_*,transfer_*; DLP block on PCI-like patterns. - Custom rules: Add IBAN or internal wire reference formats your bank uses in test data.
- Audit: Full trail for who approved what HITL item.
Healthcare / regulated data
Goal: Stricter redaction on tool results returned to the client; monitor mode first, then block after tuning.
Configuration shape:
- Policy: DLP redact on tool results for certain servers; log mode for new tools before rolling to block.
- Custom rules: MRN- or internal patient ID patterns your compliance team provides (synthetic examples in staging only).
Engineering / DevOps
Goal: Developers use Git and CI MCPs; block private PEM and long-lived cloud tokens in arguments; rate limit noisy repos.
Configuration shape:
- Custom rules: Keywords for “BEGIN PRIVATE KEY” (often already in default detectors—confirm in dashboard).
- Argument protection: Tight payload limits for
tools/callso accidental huge pastes do not DoS the gateway. - Abuse limits: Per-server token bucket on
tools/call.
How this connects to “suspicious sequences”
Policies and rules operate on individual calls and results. Sequence and risk policies operate on ordered behavior over time (e.g. export → delete). In production you typically use both: rules for content, sequences for workflow abuse.
Honest limits
Guardian does not replace upstream server security or IAM inside your SaaS tools. It does give you a single place on the MCP path to enforce what your security and platform teams agreed on.