# Shape Tool Data with Data Policies

> For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [agentic-data-plane-full.txt](https://docs.redpanda.com/agentic-data-plane-full.txt)

---
title: Shape Tool Data with Data Policies
latest-operator-version: v26.2.1
latest-console-tag: v3.10.0
latest-connect-version: 4.105.0
latest-redpanda-tag: v26.2.1
docname: data-policies
page-component-name: agentic-data-plane
page-version: master
page-component-version: master
page-component-title: Agentic Data Plane
page-relative-src-path: data-policies.adoc
page-edit-url: https://github.com/redpanda-data/adp-docs/edit/main/modules/connect/pages/data-policies.adoc
description: Add data policies to an MCP server to mask, drop, or filter the data its tools send and return, restrict argument values, and preview the effect before saving.
page-topic-type: how-to
personas: platform_engineer, agent_builder
learning-objective-1: Create a data policy that masks, drops, or filters the data a tool returns
learning-objective-2: Restrict the argument values that callers can send to a tool
learning-objective-3: Preview the composed effect of a server's data policies before saving
page-git-created-date: "2026-07-29"
page-git-modified-date: "2026-08-10"
---

<!-- Source: https://docs.redpanda.com/agentic-data-plane/connect/data-policies.md -->

Data policies shape the data an MCP server exposes. Use them to mask, drop, or hash sensitive fields in the results a [tool](https://docs.redpanda.com/agentic-data-plane/reference/glossary/#tool) returns, restrict the argument values a caller can send, and filter whole records out of list results, all before the model sees the data. Sensitive data stays protected without turning tools off.

After reading this page, you will be able to:

-   Create a data policy that masks, drops, or filters the data a tool returns

-   Restrict the argument values that callers can send to a tool

-   Preview the composed effect of a server’s data policies before saving


## [](#how-data-policies-work)How data policies work

A data policy belongs to one MCP server. It binds a set of transforms to the tools they shape and the people they apply to:

-   **Tools**: The tools on this server the policy shapes. An empty list means every tool.

-   **Principals**: Who the policy applies to, as `User:<email>` entries. An empty list means every caller.

-   **Transforms**: What the policy does to tool-call arguments on the way to the server and to results on the way back.


Data policies complement permissions. Permissions decide _whether_ a caller can invoke a tool. A server’s data policies decide _what the data looks like_ for the callers they match. See [Control Who Can Do What](https://docs.redpanda.com/agentic-data-plane/control/permissions-overview/).

The [AI Gateway](https://docs.redpanda.com/agentic-data-plane/reference/glossary/#ai-gateway) enforces data policies on live traffic in both directions. A server can carry several data policies, and every policy that matches a call applies. Policies compose most-restrictively: adding a policy can only narrow what a caller sees, never widen it.

Data policies fail closed. If a rule cannot be enforced, matching calls are denied rather than served unshaped data.

## [](#prerequisites)Prerequisites

You need an MCP server with discovered tools. To create one, see [Create an MCP Server](https://docs.redpanda.com/agentic-data-plane/connect/create-server/).

## [](#open-the-data-policies-tab)Open the Data Policies tab

1.  Open **MCP Servers** in the sidebar.

2.  Select a server.

3.  Open the **Data Policies** tab.


The **Tools** list shows every tool the server exposes. A colored dot marks each tool’s status: green when at least one data policy shapes it, yellow when the tool handles data but no policy covers it, and gray when there is nothing to protect. A legend at the bottom of the list counts the tools in each status.

When a server exposes many tools, use the filter box to narrow the list by tool name, title, or description; the count next to **Tools** shows how many tools match.

## [](#create-a-data-policy)Create a data policy

1.  In the **Tools** list, select the tool you want to shape.

2.  Click **+** to start a new policy. The policy gets a suggested name, which you can edit.

3.  On the **Configuration** tab, choose a treatment for each request or response field:

    -   **Keep**: Preserve the field. In allowlist mode, only kept fields survive.

    -   **Mask**: Replace the field’s value but keep the field present. Choose one of the [mask methods](#mask-methods).

    -   **Drop**: Remove the field entirely.


4.  Save the policy.


A new policy applies only to the tool you created it from until you widen its targeting. See [Target tools and people](#target-tools-and-people).

You can also edit the policy as YAML. The form and the YAML editor are two views of the same draft: switch between them at any time.

### [](#mask-methods)Mask methods

| Method | What it does |
| --- | --- |
| Redact | Replaces the value with a fixed placeholder. The default placeholder is [REDACTED]. |
| Partial | Keeps the first or last characters and masks the rest. For example, keeping the last four characters turns 123-45-6789 into *6789. |
| Hash | Replaces the value with a salted SHA-256 digest. Equal inputs produce equal digests, so values stay correlatable without exposing the plaintext. The salt comes from a secret you reference by name, never from the policy itself. |
| Pattern | Rewrites the value with an RE2 regular-expression substitution. The replacement text can reference capture groups, such as $1. |

### [](#select-fields)Select fields

A rule selects fields with a JSONPath expression, such as `$.user.email` (you can omit the leading `$.`). To match a field wherever it appears, use a descendant selector such as `$..ssn` with mask and drop rules. Wildcard, index, and filter expressions are not supported: you can’t save a policy that uses them.

For list results, selectors evaluate against each record. For single-object results, they evaluate against the whole payload.

By default, a mask or drop rule whose selector matches nothing denies the call. This protects you when an upstream API renames a field: the renamed field fails the call instead of silently leaking. If a field is legitimately optional, mark its rule absence-safe so a missing field is acceptable.

### [](#allowlist-mode)Allowlist mode

By default, fields you don’t select pass through unchanged, and only your mask and drop rules take effect. Switch a policy’s field rules to allowlist mode to invert this: only fields with an explicit **Keep** survive, and everything else is dropped.

## [](#restrict-argument-values)Restrict argument values

A policy can tighten the allowed values of a tool-call argument. The AI Gateway rejects a call whose argument falls outside the limits, with an error that names the violated argument.

Address the argument with a JSONPath into the tool’s arguments, such as `$.query.limit`, then apply any of these limits:

| Limit | Applies to |
| --- | --- |
| Minimum and maximum value | Numbers |
| Minimum and maximum length | Strings |
| Pattern (RE2 regular expression) | Strings |
| Format, such as email, date, or uuid | Strings |
| Allowed values | Strings |
| Minimum and maximum item count | Arrays |

The gateway also merges these limits into the input schema the tool advertises, so agents see the tightened contract up front instead of discovering it through failed calls.

## [](#filter-records-out-of-results)Filter records out of results

A row filter drops whole records from a list-shaped result. It names the record array and the condition a record must satisfy to survive:

-   **Path**: Where the record array is in the result, such as `$.body` for an OpenAPI server’s response envelope, `$.result` for a ServiceNow-style wrapper, or `$` when the result is a bare array. If the path is absent or not an array, the filter does nothing.

-   **Condition**: A comparison of a record field against a literal value, such as `@.priority >= 8`. Supported operators are `==`, `!=`, `<`, `<=`, `>`, and `>=`. The literal can be a string, number, boolean, or null.


A record that doesn’t have the compared field never survives the filter. Conditions on the same array combine across rules and policies, so a record must satisfy all of them.

## [](#target-tools-and-people)Target tools and people

By default, a saved policy applies to the tool you created it from. Widen or narrow its targeting on the **Configuration** tab:

-   **Tools**: List the tools the policy shapes. Clear the list to shape every tool on the server.

-   **Principals**: List the people the policy applies to, as `User:<email>` entries with the caller’s full email address, for example `User:alice@example.com`. Clear the list to apply the policy to every caller.


## [](#preview-the-effect)Preview the effect

Before you save, check what a policy actually does:

-   The **Configuration** tab shows the composed effect for the selected tool across all of the server’s policies, including your unsaved edits, with each field’s winning treatment and which policy contributed it.

-   The **Preview** tab runs sample arguments and a sample result through the same code that shapes live traffic and shows the shaped data an agent would receive.


If matching calls would be denied, a banner explains why, for example an unenforceable rule or a strict selector that matches nothing.

## [](#limitations)Limitations

Data policies are a preview capability with these limitations:

-   Principals accept individual users only. Group-based targeting is not supported.

-   Field selectors support named paths and descendant selectors only. Wildcard, index, and filter expressions are rejected.

-   On a self-managed server that uses the legacy Server-Sent Events (SSE) transport, results stream past response shaping. Calls that match a policy with response rules are denied on those servers. Request rules still work.

-   If your gateway does not enforce data policies, the tool header shows a **Not enforced here** badge: rules save but don’t apply to live traffic.


To read a server’s data policies through the API, get the individual server. List responses omit data policies to keep payloads small.

## [](#next-steps)Next steps

-   [Test an MCP Server’s Tools with the Inspector](https://docs.redpanda.com/agentic-data-plane/connect/test-tools/)

-   [Control Who Can Do What](https://docs.redpanda.com/agentic-data-plane/control/permissions-overview/)

-   [See What Your Agent Did](https://docs.redpanda.com/agentic-data-plane/monitor/transcripts/)