## MCP Policy

An **MCP Policy** governs what happens when a protection profile’s detections fire on **MCP tool calls** — the structured requests and responses that flow between AI agents and connected servers (Salesforce, ticketing systems, internal APIs, and so on).

At least one [Protection Profile](https://docs.barndoor.ai/how-tos/data-control-center/protection-profiles) must exist before you can create an MCP policy.

## View your MCP Policies

Navigate to **Data Control Center → MCP Policies**. 
The policy list shows each policy with:

- **Order** / **Priority** — policies run in priority order; lower numbers run first
- **Policy name**
- **MCP Server** — which server(s) this policy targets
- **Audience** — which groups or roles it scopes to (blank = everyone)
- **Protection Profiles** — the detection engines attached
- **Last Updated** — who changed it and when
- **Status** — Active or Dry Run
- **Action** — Block, Redact, Alert Only, etc.

Policies are grouped by their audience scope: **All Users** (unscoped) and **Audience-Specific** (scoped to groups or roles).

## Create a policy

1. Click **New policy** at the top of the MCP Policies tab.
2. **Name** — enter a clear, descriptive name that captures what the policy protects and why. For example:
   - _Block regulated customer identifiers across revenue and support tool calls_
   - _Redact credentials before MCP responses return to agents_
3. **MCP Server** — choose the server this policy applies to. You can also select **All Servers** to apply the policy globally.

Once the policy is saved, the MCP server cannot be changed. To target a different server, create a new policy.

4. **Protection Profiles** — select one or more profiles to run. All selected profiles run in parallel on matching traffic.
5. **Action** — choose what to do when any detection fires:

| Action | Effect |
| --- | --- |
| Block | Rejects the request or response entirely |
| Redact | Replaces detected spans with typed placeholders |
| Tokenize | Replaces detected spans with reversible tokens |
| Alert Only | Logs the detection and passes traffic through unchanged |
| Bypass | Explicitly exempts this traffic from enforcement |

6. **Scope (optional)** — add groups or roles to restrict who this policy applies to. Leave blank to apply the policy to everyone.
7. **Dry run** — toggle on to observe detections without enforcing the action. Useful for validating a policy before activating it.
8. Click **Save**.

## Edit a policy

1. Find the policy in the list.
2. Click **⋮ → Edit** on the policy row.
3. Update any field except the MCP Server.
4. Save the changes. The updated policy takes effect within seconds.

## Change policy priority

Policies run in priority order — lower numbers run first. When multiple policies match the same traffic, the first matching policy’s action is applied. To change priority, drag a policy row up or down using the **⠿** drag handle on the left. The updated order saves immediately.

## Delete a policy

1. Click **⋮ → Delete** on the policy row.
2. Confirm the deletion.

Deleted policies are removed immediately and stop enforcing. Historical detection events attributed to the policy remain in the audit log.

## Test a policy

### Using dry run

Enable **Dry run** on the policy before activating it. In dry run mode the policy evaluates traffic and logs detection events but does not block or modify anything. After a few minutes of real traffic, check **Detection Activity** to see what the policy would have caught. When you are satisfied with the coverage, edit the policy and disable dry run to activate enforcement.

### Using the Test Workbench

For controlled testing without live traffic:

1. Navigate to **Data Control Center → Test**.
2. Choose the **MCP** mode and select the server and tool to simulate.
3. Paste a sample tool payload.
4. Run the test and review which policies matched, which detection types fired, and what the redacted output would look like.

### Verifying in the Audit Center

After a policy has been active for some time:

1. Navigate to **Audit Center** from the main navigation.
2. Filter by **Event type → Data Protection** to see policy enforcement events.
3. Each event shows the policy name, detection type, action taken, the tool call involved, and the principal context.

To see all enforcement activity for a specific policy, click the policy name in the audit log — it links directly to the policy configuration.

## Common patterns

**Global block on secrets across all MCP traffic:**

- Server: All Servers
- Profiles: Your secrets detection profile
- Action: Block
- Scope: (none — applies to everyone)

**Audit-only monitoring for a new integration:**

- Server: the new integration’s MCP server
- Profiles: your PII and secrets profiles
- Action: Alert Only
- Dry run: on (initially)
- Promote to active enforcement after reviewing activity logs

**Scope a strict policy to a high-sensitivity team:**

- Server: Revenue Ops Salesforce
- Profiles: Regulated identifiers profile
- Action: Block
- Scope: Group `enterprise-customer-success-managers`

A separate, less-restrictive policy for the same server (scoped to everyone else) can use Alert Only — the stricter scoped policy runs first for matching principals.