Data handling and sensitive-data redaction

Horizon sits in the request path of every MCP server it serves, so it sees the traffic those servers handle. This page covers two things that follow from that position: what request and response data Horizon records for served traffic, and the experimental sensitive-data redaction feature, which can block or mask sensitive values in a tool result before it reaches the caller. For how stored values are encrypted and where secrets can appear, see Encryption and data protection.

​

Traffic records

Every MCP request passes through the gateway, which writes one record per request to Horizon’s traffic log. That record is what the Observability views read from, and it holds three kinds of data. Metadata is recorded for every request. Payloads are recorded by default, which is why a tool call’s arguments and its result appear in the request detail on the Logs page. That makes the Logs page useful for debugging a failed call, and it also means whatever your tools receive and return is stored there unless you turn payload logging off.

​

Payload logging

Whether payloads are stored is a per-project choice. Under the server’s Settings, the General tab has a Data Controls card with two switches: Both are on by default. Turning one off stops that payload from being recorded at all, so it never reaches the traffic record or the Logs page. Metadata is still recorded either way, and a failed request is still marked as an error, so turning payloads off narrows what is stored without hiding operational history. This control decides what Horizon stores. Sensitive-data redaction, below, decides what a caller receives, and masks detected values in what gets stored as a side effect. The two work independently.

​

Retention

Horizon currently retains traffic records indefinitely. Customers cannot set a retention period. Turning request or response payload logging off affects future requests only and does not delete existing traffic records.

​

Sensitive-data redaction

Sensitive-data redaction is a per-project gateway feature that scans each tool result after your server produces it and before it reaches the caller. When it finds sensitive data, it acts on the result: it either blocks the whole result or masks the matched spans. Detection combines managed PII detection with custom regex rules you define, and both run on every tool result while the feature is enabled.

​

How detection works

Automatic PII detection finds entities such as email addresses, phone numbers, and government identifiers in the result text. Each finding carries a confidence value, and a sensitivity setting decides how confident a finding must be to count. A higher sensitivity accepts lower-confidence findings, so it catches more but is likelier to flag safe text. Detection runs on the text in the result, including text inside embedded resources and string values in structured content. The scan operates on English text.

​

Custom rules

Custom rules match values that automatic detection would not recognize, such as an internal account number or record identifier. Each rule pairs a pattern with a label, uses Python’s regular-expression syntax, and runs in addition to automatic detection. A regex match always counts, regardless of the sensitivity setting. A project can define up to 10 custom rules.

​

What happens on a match

When a scan finds sensitive data, the project’s action decides what the caller receives. Detection fails closed. If a scan cannot complete, for any reason, the result is blocked rather than returned unscanned. A result whose text is too large to scan is treated the same way. Failing closed means a scanning problem withholds data rather than leaking it.

​

Enabling redaction

Redaction is configured per project, under the server’s experimental settings. Because it is experimental, it is gated: it may not be available for your organization yet. If the experimental settings do not offer it, contact horizon-support@prefect.io to request access.

​

What gets recorded

When redaction acts on a result, Horizon records a summary of what matched: a count per rule and per detected entity type, such as EMAIL. It never records the matched values themselves. Because redaction runs before the response is finalized, it also shapes what lands in the response payload when response logging is on. A blocked result stores the Tool result blocked placeholder, and a redacted result stores the masked text, so the sensitive values never reach the traffic record. Redaction acts only on responses. It does not change what a request payload records.

​

Security reviews

If your procurement or security review needs implementation detail beyond this page, such as the detection provider’s data handling or retention specifics, contact horizon-support@prefect.io to request a formal security review.

​

Related docs