Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt

Use this file to discover all available pages before exploring further.

This tutorial puts a guardrail on a gateway and then watches it fire. You’ll add a gateway rule that detects a sensitive pattern in tool traffic, run it in a configuration that alerts without blocking so it can’t disrupt anything, trigger it with a test value you control, and find the result in your logs. It’s the gentlest possible introduction to the part of MCP Manager that does data-loss prevention.
This tutorial uses Basic gateway management (to add and edit rules). If a gateway has no Rules tab or no Add new rule button for you, your role lacks that capability — access depends on the capability, not on a role name. See the capabilities reference.

​
What you’ll need

​
How a rule is built

Every gateway rule pairs a detection method (how it recognizes something) with an action (what it does when it matches), and fires on a detection hook (when it runs). Gateway rules inspect tool traffic — tools/call requests and their results — not prompts or resources.
  • Detection methods: a built-in Regular expression, Microsoft Presidio (a managed add-on tuned for PII), or a Custom rule engine (a webhook, with templates for AWS Bedrock and Lakera Guard).
  • Actions: Block stops the message entirely; the non-destructive actions — Redact, Replace, Mask, Hash — transform the matched text and let the message through.
  • Detection hook: Request (before the server sees it), Response (after the server replies), or Both.
The key to a safe first rule is the independent Alerts toggle: when it’s on, MCP Manager raises a real-time alert every time the rule acts — separately from whether it blocks. Pair Alerts on with a non-destructive action and you get full visibility with zero disruption.

​
Step 1: Add a rule to your gateway

1

Open the Rules tab

Open your gateway from Gateways and go to its Rules tab. Click Add new rule.
2

Name it and pick the detection method

Give it a Rule name like Email guard (test). Choose Regular expression as the detection method, and enter a pattern that matches an email address:
Matching pattern
[a-zA-Z0-9._%+-]+@example\.com
Using the example.com domain keeps this test from matching real addresses in live traffic.
3

Fire it on the request

Set the Detection hook to Request, so the rule inspects what your client sends to the server. Selecting Response would have the rule run on the response from the server. That’s what lets you trigger it on demand in Step 2.
4

Choose a non-blocking action

Set the Action to Replace, which swaps the matched text for a constant such as <REDACTED> and lets the request continue. Because it’s non-destructive, this rule can’t break anyone’s workflow while you test it.
5

Turn on alerts and enable it

Switch the Alerts toggle on, make sure the rule is Enabled, and save. The rule is now live on this gateway.
This — a non-destructive action with Alerts on — is the recommended way to roll out any new rule. Watch what it catches against real traffic first, then switch the action to Block (or a redacting action) once you trust it. You see the impact before you enforce it.

​
Step 2: Trigger the rule

In your connected AI client, make a tool call whose input contains the pattern. The simplest way is to ask for something that puts the test address into the tool arguments: 
Use the connected tools to look up anything related to test@example.com.
When the client sends that tools/call request through the gateway, the rule matches test@example.com on the request hook, replaces it with <REDACTED>, lets the (now-sanitized) request through, and raises an alert.

​
Step 3: See that it fired

1

Open the logs

Go to Logs and find the tools/call entry you just generated.
2

Read the rule activity

Open the entry’s Log details. Because the rule modified the message, the entry is recorded as a policy_enforced_mutation, and the Rule engine type and rule comment fields identify which rule acted. (Had you used Block, you’d instead see a policy_enforced_abort.) The Body shows the matched text replaced with <REDACTED>.
You added a detection rule, ran it where it couldn’t disrupt anyone, made it fire on demand, and confirmed both the alert and the rule’s effect in the audit trail. That alert-but-don’t-block configuration is exactly how to introduce real guardrails — PII redaction, secret detection, topic blocking — with confidence before you turn on enforcement.

​
Where to take it next

  • For production PII detection across many entity types, swap the regex for the Microsoft Presidio detection method — see PII Filtering and the Presidio rule.
  • To send traffic to an external classifier such as AWS Bedrock Guardrails or Lakera Guard, use a custom rule engine.
  • When you’re ready to enforce, change the action to Block or a redacting action and keep Alerts on.

​
Further reading

Trace a call in your logs

Read the rule activity you just generated in full detail.

Gateway Rules Overview

The complete reference for detection methods, actions, hooks, and alerts.

PII Filtering

Detecting and redacting personal data with Microsoft Presidio.

Alerts

Where rule alerts surface and how to act on them.