Keep content off the management plane

Enterprise Tier

Prompt and response content never travels through the management plane on the request path, but content can still reach it as telemetry. At default settings, request logs and guardrail trigger records carry content. This page lists the settings that remove it, in the order an operator applies them, and then lists everything that still reaches the management plane when every setting is at its tightest.

---

This page covers the Self-Hosted Data Plane deployment, and rows state where hosted or managed deployments differ. It is the one page that names the exact settings for this posture. Other pages and customer documents should describe the outcome and link here, so that a setting rename changes one page.

Persona: Platform operator working with security or legal stakeholders.

Estimated time: 15 to 30 minutes to apply and verify the settings.

What the posture achieves

With the settings below applied:

• Prompt and response bodies, request headers, and caller-supplied values stay inside the customer's cluster or reach only destinations the customer operates.
• Matched guardrail text stays inside the cluster.
• The management plane still receives the identifiers, counts, and costs listed in What still reaches the management plane.

The settings govern telemetry. They do not change where requests are routed: the request path never passes through the management plane.

Apply the settings

Apply the settings in this order.

Order	Setting	Where	Value	Detail
1	Request logs	Admin Console, Settings → Request logs	Metadata only	Control request log data
2	Guardrail trigger content	Admin Console, Settings → Guardrails, Guardrail triggers card	Metadata only	Guardrail trigger content mode
3	AI tracing spans	Helm values, global.observability.managementPlane.contentMode.traces	metadata-only	Export telemetry to an observability stack
4	Signals sent to the management plane	Helm values, global.observability.managementPlane.signals	Leave out traces to send no spans	Export telemetry to an observability stack
5	Full records for the customer's own stack	Helm values, backends.custom[] subscribed to requestlog	Customer-operated backend	Control request log data

Notes on the table:

• Request logs. The default is Full, which sends request and response bodies. Off sends no request_log record, but also stops new usage and budget spend data, so Metadata only is the usual choice.
• Guardrail triggers. The default is Full, per deployment. Off stops verdict reports, so the Console's verdict counts stay empty. Data plane guardrail metrics are unaffected.
• Traces. A span from a failed request can carry the upstream error body in its exception event, and providers commonly echo the request into that body. The metadata-only content mode clears the exception text on spans produced by the gateway's external processor. Envoy gateway spans are not covered by that mode, and signals.traces.capture alone does not clear the exception text. The open defect is tracked as fraser#9644. Until it ships, keep traces away from the management plane (step 4) when no content may reach it.
• Customer-operated backends. A backends.custom[] destination receives the full record under every mode above. These settings scope only what crosses the cluster boundary toward Tetrate.

What still reaches the management plane

With every setting above applied, the following data still reaches the management plane.

Data	Why it is sent	Can the customer turn it off?
SSO identity: name, email, groups	Sign-in to both consoles	No
request_log metadata: identifiers, token counts, costs, timing, routing decisions	Usage analytics and budgets	Yes, with request logs set to Off, at the cost of new usage and budget data
Billing transactions: user, API key, request id, model, tokens, amount, BYOK flags	Billing	No. Rejected, failed, and zero-cost requests send nothing.
Guardrail trigger records: ids, scores, check types, actions, durations, content counts	Admin Console verdict views	Yes, with the trigger content mode set to Off
Envoy access log entries for MCP requests, with peer address and X-Forwarded-For	MCP request logging. Entries for other traffic are discarded on arrival.	Self-managed: not without losing MCP request logs. Managed: chosen once at provisioning, and the MCP path is always on.
Access log entries for LLM and MCP requests, with peer address and X-Forwarded-For	Delivered when the logs signal is sent. Errors, upstream failures, and requests of 10,000 or more tokens are kept for 1 day.	Yes, by leaving logs out of managementPlane.signals
Data plane health reports	Admin Console status views	No
Metrics	Admin Console views	Yes, per signal in managementPlane.signals
Audit log: admin identity, IP address, user agent, and the request and response bodies of admin calls	Record of administrative actions	No
tare-doctor diagnostic bundles	Support diagnostics	See Diagnostic bundles
Cluster telemetry (managed data planes only)	Operation of the managed service	Only through a Tetrate template change

Health reports

A health report carries status, issues, cluster health, resource inventory, the serve URL, doctor state, certificate readings, and declared hostnames. The data plane version is sent on every configuration fetch. None of these can be turned off.

Two checks also contact Tetrate:

• License check. A data plane stops serving after 12 consecutive "service account not found" responses.
• CLI update check. The tare CLI checks tare.tetrate.ai for updates. Setting TETRATE_NO_UPDATE_CHECK disables it.

Operational logs

The data plane's own logs lane to the management plane is empty: the external processor exports only metrics and traces, and the liaison component exports no logs. Log content can still reach Tetrate in two other ways.

Diagnostic bundles

tare install enables tare-doctor. A bundle holds up to 256 KiB of the first container log of each pod, including Envoy, unredacted. The Envoy per-request line includes the user id, request id, model, token counts, and cost. Disabling tare-doctor is the way to keep these logs inside the cluster.

Cluster telemetry on managed data planes

A managed data plane runs a telemetry DaemonSet that ships stdout from every container, unredacted, to Tetrate's internal observability collector. This includes the Envoy per-request line described above. It cannot be changed from the customer side.

Retention of what is sent

Retention differs by record type and deployment type. The defaults, and what happens to the records when a tenant closes, are in Manage log retention and purge.

Verify the posture

1. Send a prompt containing a distinctive word through the gateway.
2. In the Admin Console, open Request logs and confirm that the row shows no bodies or headers.
3. Open the guardrail trigger view and confirm that no matched text is shown.
4. Confirm that no spans for the request are visible in the Console, or that their exception events are empty.
5. Confirm in the customer's own collector that the full record arrived there.