Yes, it can. OpenTelemetry baggage is a key-value store that rides along with trace context in HTTP headers, so anything you put in it can reach every service your request touches, including third-party APIs. Keep it to short, non-sensitive identifiers, and review which outbound calls carry it.
What baggage is
Baggage is a way to pass data alongside a request across service boundaries. A typical use is to set a user or account ID at the edge, so that a service three hops away can add it to its own spans, metrics or logs without a database lookup.
The OpenTelemetry documentation describes it as a key-value store that lets you propagate any data you like alongside context. Instrumentation libraries usually handle the propagation for you. That convenience is the source of the risk: you set the value once, and it is copied into outgoing requests automatically.
Why this is a leak risk
The OpenTelemetry baggage page lists several warnings itself:
- Sensitive baggage can reach unintended recipients, such as third-party APIs, because automatic instrumentation sends it on most outbound requests.
- Baggage travels in HTTP headers, which anyone inspecting network traffic can see.
- A downstream service could forward baggage outside your network.
- There are no built-in integrity checks, so a caller can send any baggage it likes and you should verify values before trusting them.
The last point matters for security decisions. If a service reads a role or a tenant from baggage and uses it for authorization, an attacker who can send a header can choose the value.
Baggage is not span attributes
Baggage is separate from span attributes. Setting a baggage entry does not add it to any span. You, or a span processor that your language SDK provides, must copy the value across. That gives you a useful control point: decide which baggage keys become attributes, and which stay as plain context.
| Question | Baggage | Span attribute |
|---|---|---|
| Who sees it? | Every downstream service and anything inspecting the headers | Whoever can read your trace backend |
| Crosses service boundaries? | Yes, automatically | No, stays on that span |
| Safe for a session token? | No | No |
| Safe for an opaque internal account ID? | Usually, if the ID is meaningless outside your systems | Usually |
Steps to use baggage safely
- List every baggage key your services set. Search your code for the baggage API calls and your gateway config.
- For each key, ask who receives it. Include egress to payment, email, analytics and AI providers.
- Remove anything that is a credential, a session value, an email address, a name or a free-text field. Use an opaque internal ID instead.
- Strip baggage on outbound calls to third parties. Many propagators and proxies let you drop or filter the header at the boundary.
- Never use baggage values for authorization. Treat inbound baggage as untrusted input.
- Cap the number and length of keys, so a hostile caller cannot bloat every request.
How to check what leaves your network
Capture outbound requests from a staging service to an external endpoint you control, or inspect them through your egress proxy. Look for a header named baggage. If it is present on calls to a third party, read the values. This takes about ten minutes and often finds a user ID or tenant name nobody meant to share.
Quick check
Does baggage show up in my traces automatically?
No. It is separate from span attributes. You must copy the values you want, or enable a baggage span processor if your language SDK offers one.
Is a user ID safe in baggage?
An opaque internal ID is usually acceptable. An email address, a name or anything that identifies a person outside your systems is not, especially when third parties receive the header.
Can I trust a role or tenant value that arrives in baggage?
No. There are no integrity checks, so any caller can set it. Derive authorization from your identity system.
Safeguard's dependency scanning and SBOM generation cover the libraries that implement propagation, so you can see which instrumentation packages you ship. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
