> ## Documentation Index
> Fetch the complete documentation index at: https://docs.barndoor.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Control Center

> Detect, block, redact, or observe sensitive data as it flows through AI agents and the MCP layer.

The Data Control Center is where platform administrators configure how sensitive data is handled as it moves through AI agents and the MCP layer. It gives security teams a single place to define **what** data is sensitive, **where** to enforce protection, and **what to do** when a detection fires.

<img src="https://mintcdn.com/barndoor/ycLd3Cg8QdOmsIcT/images/data-control-center/platform-data-protection-llm-policies--overview.png?fit=max&auto=format&n=ycLd3Cg8QdOmsIcT&q=85&s=89f66b540643f21a3b065fdedb458b3f" alt="Data Control Center overview" width="1600" height="629" data-path="images/data-control-center/platform-data-protection-llm-policies--overview.png" />

## How it works

Every prompt sent to an LLM, every response returned, and every MCP tool call — input and output — flows through the platform's inspection layer. The Data Control Center controls that layer through three building blocks:

1. **Protection Profiles** — define what to detect (email addresses, AWS keys, credit cards, custom patterns, etc.)
2. **MCP Policies** and **LLM Policies** — define where to enforce and what action to take when a detection fires
3. **Field Controls** — define which JSON fields to pass through or remove from specific tool outputs, independently of text-based detection

The flow is always the same: add profiles first, then attach them to policies.

## Core concepts

### Protection Profile

A **Protection Profile** is a named detection engine. It bundles together a set of detection types (e.g., "Social Security Number", "AWS Secret Access Key") with the runtime stages it scans and the actions it supports.

Profiles are reusable — create one and attach it to many policies. When the detection logic changes, update the profile and all policies using it inherit the change automatically.

**Built-in profile types:**

| Type                  | What it detects                                                                                       |
| --------------------- | ----------------------------------------------------------------------------------------------------- |
| Sensitive Identifiers | Social Security Numbers, credit cards, emails, phone numbers, passports, dates of birth               |
| Names & Locations     | Person names, organizations, addresses, locations                                                     |
| Secrets               | Cloud keys (AWS, GCP, Azure), API tokens, database credentials, CI/CD secrets, cryptographic material |
| Prompt Injection      | Prompt injection and jailbreak attempts                                                               |
| Custom Detections     | Patterns your organization defines using regex or literal rules                                       |

External providers (AWS Comprehend PII, AWS Bedrock Guardrails) are also available as catalog options.

### MCP Policy

An **MCP Policy** governs what happens when a protection profile's detections fire on **MCP tool calls** — the structured calls AI agents make to connected servers (Salesforce, ticketing systems, internal APIs, and so on).

Each policy specifies:

* Which **MCP Server(s)** to apply to (or all servers)
* Which **Protection Profiles** to run
* The **action** to take when a detection fires
* Optionally, which **groups or roles** the policy scopes to

MCP policies inspect both the agent's tool input (what it sends to the tool) and the tool's response (what the tool returns to the agent).

### LLM Policy

An **LLM Policy** governs what happens when detections fire on traffic between agents and **LLM providers** (OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Vertex AI, and others).

Each policy specifies:

* Which **LLM providers** to apply to (or all providers)
* The **runtime stage**: Requests (prompts), Responses, or both
* Optionally, a specific **model alias** to narrow scope
* Which **Protection Profiles** to run
* The **action** to take
* Optionally, which **groups or roles** to scope to

### Field Controls

**Field Controls** give you precise, field-level governance over structured tool output — independently of text-based detection. Instead of scanning free text for patterns, you name exact JSON field paths to either remove or allow through.

Each rule specifies:

* The **MCP Server** and **tool** it targets
* The **direction** (input or output)
* The **mode**:
  * **Redact listed** — the fields you name are removed; everything else passes through
  * **Allow only listed** — only the fields you name pass through; everything else is removed
* Optionally, which **groups or roles** the rule scopes to

Use field controls when you know the exact field paths — for example, always strip `AnnualRevenue` and `BillingAddress` from Salesforce Account records before an agent in the support group can read them.

## Policy actions

| Action         | Effect                                                                                                         |
| -------------- | -------------------------------------------------------------------------------------------------------------- |
| **Block**      | Rejects the entire request or response. The agent receives an error.                                           |
| **Redact**     | Replaces detected spans with a typed placeholder such as `[EMAIL_ADDRESS]`. The rest of the payload continues. |
| **Tokenize**   | Replaces detected spans with a reversible token the platform can detokenize later.                             |
| **Alert Only** | Records a detection event and passes the payload through unchanged. Use for monitoring without enforcement.    |
| **Bypass**     | Explicitly exempts matching traffic from further enforcement.                                                  |

### Dry run mode

Any policy can be toggled into **dry run**. In dry run the policy runs and logs detections but does not enforce them. Use this to validate a new policy before making it active. There is also a **global dry run** that applies to all policies at once.

## Runtime stages

| Stage           | What it covers                               |
| --------------- | -------------------------------------------- |
| **Request**     | The message an agent sends to an LLM         |
| **Response**    | The text the LLM returns to the agent        |
| **Tool Input**  | The arguments an agent passes to an MCP tool |
| **Tool Output** | The data the MCP tool returns to the agent   |

## Enabling the runtime

The global **Enabled** toggle at the top of the Data Control Center controls whether the inspection layer runs at all. When disabled, no policies execute and all traffic passes through uninspected. Changes take effect within seconds.

## In this section

<CardGroup cols={2}>
  <Card title="Protection Profiles" icon="search" href="/how-tos/data-control-center/protection-profiles">
    Create and manage detection engines that define what data to scan for.
  </Card>

  <Card title="MCP Policies" icon="plug" href="/how-tos/data-control-center/mcp-policies">
    Govern enforcement on MCP tool call traffic.
  </Card>

  <Card title="LLM Policies" icon="brain" href="/how-tos/data-control-center/llm-policies">
    Govern enforcement on LLM gateway traffic.
  </Card>

  <Card title="Field Controls" icon="sliders" href="/how-tos/data-control-center/field-controls">
    Field-level JSON redaction for specific tools.
  </Card>
</CardGroup>
