Wiki · Concept · Last reviewed June 25, 2026

OpenTelemetry Redaction Processor

The OpenTelemetry Redaction Processor is a Collector Contrib processor for deleting or masking sensitive telemetry before export. For AI systems and agents, it is one of the practical controls between useful observability and a permanent archive of prompts, identifiers, credentials, tool payloads, database queries, and private user context.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: OpenTelemetry, redaction, observability, privacy, AI agents

Definition

The Redaction Processor is an OpenTelemetry Collector processor from the Collector Contrib repository. OpenTelemetry's Collector processor table lists it in the contrib and Kubernetes distributions, with beta stability for traces and alpha stability for metrics and logs. The security best-practices documentation describes processors as components between receivers and exporters, and says the redaction processor can obfuscate or scrub sensitive data before telemetry is exported to a backend.

It is not a privacy program by itself. OpenTelemetry's sensitive-data guidance is explicit that implementers remain responsible for knowing what data is sensitive in their context, protecting it, meeting applicable law, and reviewing what instrumentation emits. The Redaction Processor is a technical guardrail in that larger governance system.

How It Works

The processor's central model is an allowlist plus blocked-value matching. OpenTelemetry's security guidance says the processor deletes span, log, and metric datapoint attributes that do not match allowed attributes, then masks allowed attribute values that match a blocked-value list. The order matters: if a key is not allowed, its value is removed before blocked-value patterns are checked.

The upstream README documents additional controls. URL sanitization can remove sensitive or high-cardinality URL path material while preserving useful route structure. Database query sanitization can remove literal values or command arguments from SQL, Redis, Memcached, MongoDB, OpenSearch, and Elasticsearch telemetry. The processor can also add diagnostic audit attributes when summary mode is set to debug or info, recording counts and keys for allowed, removed, ignored, and masked fields.

AI Agent Telemetry

AI agent telemetry has unusual privacy density. A trace can include prompt text, retrieved document snippets, browser URLs, tool arguments, payment or account fields, authorization context, customer-support notes, file paths, source-code fragments, database statements, and model outputs. AI Agent Observability needs enough of that path to reconstruct failure, but general telemetry stores should not become uncontrolled copies of every sensitive interaction.

The Redaction Processor helps when telemetry is already moving through a shared pipeline. It can keep stable operational attributes such as route name, model class, service name, policy status, tool name, and error category while removing or masking values that should not leave the trust boundary. It also pairs naturally with OpenTelemetry Transformation Language for custom rewrites and with OpenTelemetry Tail Sampling for deciding which redacted traces deserve durable storage.

Governance Use

The governance value is fail-closed evidence design. A strict allowed-key set makes teams name what is necessary before export. Blocked-value patterns catch obvious secrets or regulated identifiers inside permitted fields. URL and database sanitizers reduce the chance that useful debugging metadata carries raw user, account, or query content.

This should be reviewed like production policy code. A change to allowed_keys, ignored patterns, blocked values, sanitizer settings, summary level, or processor order can change what evidence exists later and who is exposed by it. Privacy, security, legal, and incident-response teams should be able to read the configuration and understand the evidence boundary.

Limits

Redaction can fail quietly if patterns miss local formats, if sensitive data appears in unmodeled fields, if another exporter bypasses the processor, or if application code logs raw material after the pipeline boundary. It can also remove too much and destroy forensic value. The upstream README frames the processor as one line of defense, not the only compliance measure.

Hashing and masking are not magic. OpenTelemetry's sensitive-data guidance warns that hashes may be reversible in practice when the input space is small and predictable. A user ID, ticket number, or account code may still be re-identifiable if it is merely transformed without a realistic threat model.

Minimum Record

An AI deployment using the Redaction Processor should record the collector distribution and version, processor version, pipeline order, allowed keys, ignored keys, ignored patterns, blocked-value regexes, sanitizer settings, summary mode, export destinations, test fixtures, sample before-and-after records, and owner for updates. It should state which data classes are never allowed in general telemetry: raw prompts, credentials, private documents, tool secrets, full database statements, and regulated personal data.

Source Discipline

Use OpenTelemetry documentation and the Collector Contrib README for behavior, stability, configuration, and sensitive-data claims. Use vendor observability docs only for vendor-specific distributions or backend behavior. Treat redaction evidence as testable: source claims are not enough unless representative traces prove the configured pipeline behaves as intended.

Spiralist Reading

The Redaction Processor is a filter on institutional memory. It decides what the machine is allowed to remember after the live act has passed. A humane agent system does not choose between total blindness and total capture. It keeps the evidence needed for repair, appeal, and safety while refusing to turn every private exchange into a permanent observability artifact.

Sources

Return to Wiki