In this article
Missing prompt text in one log does not prove it is absent from telemetry. Inspect actual exports across normal and error paths.
Inference diagnosis usually needs timing, outcome, model and safe identifiers. Full prompts should not enter every technical channel merely because an SDK supports capture. Removing one logger field also does not remove it from traces, exceptions or exporters. Providers need a verifiable policy with explicit allowed data and an end-to-end pipeline check.
Define a minimal record
The OpenTelemetry sensitive-data guide describes minimization, filtering and redaction as distinct measures. Begin with an allowlist: endpoint, agreed model name, duration, outcome and bounded technical fields. Give every value a purpose and destination. “Might be useful” is too broad for automatic user-content capture.
Request IDs help correlation, but provenance matters. A client-generated ID can contain arbitrary text and is not safe merely because of its field name. Internal test identifiers and external payloads require different trust assumptions.
Separate metadata from content
The GenAI span conventions discuss capturing instructions, inputs and outputs separately. Content can appear in multiple nested forms. Cover messages, tool arguments, tool results and error details rather than only one prompt string.
If content capture is needed for a bounded diagnostic scenario, define separate access, conditions and retention. Do not silently enable it through one general production-export setting. This is an architectural boundary, not a claim about every external service’s data policy.
Check propagation
OpenTelemetry context propagation links operations across components, but baggage and headers can carry more metadata than needed. Preserve propagation allowlists and removal points, particularly at external boundaries. Trace context does not authorize copying user content throughout infrastructure.
Safe-ID relationships are generally enough for correlation. Do not introduce secrets in span names or metric labels. Even with a cleaned main payload, those strings can reach another system with different permissions and retention. Inspect all observable exported fields.
Build a marker fixture
Place a synthetic SYNTHETIC_SECRET marker in an ordinary message, nested tool argument and controlled error path. Collect actual output from a test exporter. Expect allowed metadata to remain and the forbidden marker to be absent at the specified outputs.
Testing only the redaction function is insufficient. Middleware may log the original body before filtering or include input fragments in exceptions. Integration fixtures should observe the path through a final test receiver, preserving SDK version and configuration with the result.
Preserve evidence boundaries
Marker absence at an observable output establishes that path and fixture set, not universal absence across external systems. If part of the export chain is invisible, retain that unknown region rather than claim nothing is stored.
Related guides cover gateway DLP and access security. The focus here is the owned telemetry pipeline: minimal data, actual-export validation and honest conclusions without unsupported company privacy promises. Retain both normal and failure fixtures after updates so improved ordinary-path filtering does not conceal a new exception handler that exports the original input.