> ## 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.

# Add your first gateway rule

> A hands-on MCP Manager lesson: add a gateway rule that detects sensitive data in tool traffic, run it in a non-blocking alert configuration, trigger it with a test call, and see the alert and rule activity in your logs.

This tutorial puts a guardrail on a gateway and then watches it fire. You'll add a [gateway rule](/features/gateway-rules/overview) 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.

<Info>
  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](/deployment/rbac-and-roles/capabilities).
</Info>

## What you'll need

* A gateway you can connect to and call a tool through. The **Engineering** gateway from [Build a team gateway](/tutorials/team-gateway), or the **Quickstart** gateway from [Your first governed tool call](/tutorials/first-tool-call), is ideal.
* Your AI client connected to that gateway.
* About 10 minutes.

## 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

<Steps>
  <Step title="Open the Rules tab">
    Open your gateway from [Gateways](https://app.mcpmanager.ai/settings/gateways) and go to its **Rules** tab. Click **Add new rule**.
  </Step>

  <Step title="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:

    ```text Matching pattern theme={null}
    [a-zA-Z0-9._%+-]+@example\.com
    ```

    Using the `example.com` domain keeps this test from matching real addresses in live traffic.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Tip>
  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.
</Tip>

## 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:

```text theme={null}
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

<Steps>
  <Step title="Open the logs">
    Go to [Logs](https://app.mcpmanager.ai/settings/logs) and find the `tools/call` entry you just generated.
  </Step>

  <Step title="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>`.
  </Step>
</Steps>

<Check>
  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.
</Check>

## 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](/features/pii-filtering) and the [Presidio rule](/features/gateway-rules/presidio).
* To send traffic to an external classifier such as AWS Bedrock Guardrails or Lakera Guard, use a [custom rule engine](/features/gateway-rules/custom-rules-engines).
* When you're ready to enforce, change the action to **Block** or a redacting action and keep **Alerts** on.

## Further reading

<CardGroup cols={2}>
  <Card title="Trace a call in your logs" icon="magnifying-glass" href="/tutorials/trace-in-logs">
    Read the rule activity you just generated in full detail.
  </Card>

  <Card title="Gateway Rules Overview" icon="shield-halved" href="/features/gateway-rules/overview">
    The complete reference for detection methods, actions, hooks, and alerts.
  </Card>

  <Card title="PII Filtering" icon="user-shield" href="/features/pii-filtering">
    Detecting and redacting personal data with Microsoft Presidio.
  </Card>

  <Card title="Alerts" icon="bell" href="/features/alerts">
    Where rule alerts surface and how to act on them.
  </Card>
</CardGroup>