Record opaque internal identifiers that mean nothing outside your systems, such as an account ID or tenant ID. Avoid emails, names, tokens and session values. Anything that would help an attacker or identify a person on its own should stay out of trace attributes.
Why attributes need rules
Trace backends are searched, shared and kept for weeks. Their access list is usually wider than the production database, since developers use them daily. An attribute written once is copied to every span that carries it and to any export.
The OWASP Logging Cheat Sheet recommends not logging session identification values, access tokens, passwords, connection strings and keys directly, and suggests a hashed value for sessions if tracking is needed. The same logic applies to span attributes. It also says personal data may need pseudonymization where identity is not required.
A practical table
| Attribute | Verdict | Notes |
|---|---|---|
| Internal account ID | Record | Opaque, stable, useful |
| Tenant ID | Record | Essential for multi tenant investigations |
| User ID, internal and random | Record | Prefer over email |
| Email address | Avoid | Personal data, searchable by humans |
| Full name, phone | Avoid | Personal data |
| Session ID | Avoid, or record a hash | Raw value can be replayed |
| Access token, API key | Never | Credential |
| Request path template, such as users slash id | Record | Template, not the filled value |
| Raw URL with query | Review | May contain tokens, see redacting query strings in spans |
| SQL statement with values | Avoid | Use the parameterized form |
| IP address | Decide | Often personal data, see IP addresses in logs |
Baggage versus attributes
OpenTelemetry documents that baggage is separate from span attributes and is not copied to spans automatically. You choose which baggage keys become attributes, usually through a processor your SDK provides. That is a good checkpoint to apply the table above. See can OpenTelemetry baggage leak sensitive data.
Steps
- Write an attribute list: name, type, allowed or not, reason. Keep it in the repository.
- Add a lint or review rule: new attribute names need a reviewer from security or the platform team.
- Use an allow list in the collector, so unlisted attributes are dropped. See OpenTelemetry collector redaction and filter processors.
- Scan a day of spans for emails, tokens and card patterns. Fix what you find at the source.
- Set trace retention to match your needs, not the maximum.
A note on correlation
You rarely need an email to correlate. A random user ID joined with your user table, in a place with tight access, gives investigators the link when needed, without spreading the identity across the trace store.
Quick check
Can I hash an email and put it in a span?
A hash of a guessable value like an email can often be reversed by trying candidates. Prefer a random internal ID.
Is a tenant ID sensitive?
Usually an opaque tenant ID is fine. If tenant names reveal customers you cannot disclose, use the ID.
Safeguard scans dependencies and builds SBOMs, covering the instrumentation libraries you ship. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
