Trace Baggage Can Travel to a Third Party

An AI service may carry a tenant or user identifier through internal calls by placing it in OpenTelemetry baggage. Baggage is a key-value store that travels with request context. The OpenTelemetry baggage guide lists account and user IDs among possible entries. The risk appears when that request also makes a call outside the service.

How the value can leave

Consider a worker that receives baggage containing a tenant ID, then calls a hosted model API. OpenTelemetry says automatic instrumentation includes baggage in most network requests. It also says baggage travels in HTTP headers and warns that sensitive entries can reach third-party APIs. If the worker injects baggage into the model request, that provider receives the tenant ID in a header. Removing the ID from the request body would leave this path open. Whether a particular client injects baggage depends on its instrumentation and configuration. The baggage guide describes the underlying risk.

An internal call can carry the value onward too. A downstream service may later make its own external request. The guide warns that keeping one connection inside your network does not ensure baggage stays there.

Why a clean trace is insufficient

Baggage is separate from span, metric, and log attributes. A service must explicitly copy a baggage entry into those records. Therefore, a trace without the tenant ID does not show whether an outgoing HTTP header carried it. OpenTelemetry explains this distinction. Redacting exported telemetry alone cannot establish what an earlier external request contained.

What to do

First, list the values your services put in baggage. Keep credentials, personal data, and other sensitive fields out of it. OpenTelemetry’s context propagation guidance recommends avoiding sensitive baggage and limiting propagation to external services.

Next, inspect the actual headers sent by a representative outbound model request in a safe test environment. Check clients and downstream services that can inject context. Configure outbound propagation so external endpoints receive only the context you intend to share. Test that boundary again when instrumentation changes.

Finally, collect only identifiers needed for observability and review them regularly. OpenTelemetry’s sensitive-data guidance recommends that approach. The transmitted header shows what left your service.