An OpenTelemetry span is a time-bounded record of a single operation within a distributed trace. For AI systems, spans can describe model calls, authentication steps, or tool invocations, and they become highly sensitive when they include prompts, responses, or identity-linked metadata.
Expanded Definition
An opentelemetry span is more than a timing marker. It is the atomic unit of telemetry that records when an operation starts and ends, plus context such as service name, trace ID, attributes, and parent-child relationships. In practice, spans help security teams reconstruct how a request moved through services, which step failed, and where trust boundaries were crossed. For identity-heavy systems, that can include login flows, token exchange, policy checks, and tool calls made by an AI agent. The OpenTelemetry project defines spans within the broader trace model, and the specification is the clearest reference point for how they are structured and correlated. When spans carry prompt text, API keys, session identifiers, or user attributes, they stop being simple observability records and become sensitive security artefacts. Definitions vary across vendors on how much data should be attached to a span, so governance decisions matter as much as instrumentation choices. The most common misapplication is treating spans as harmless debug logs, which occurs when teams copy request data into attributes without reviewing identity data, secrets, or prompt content.
For a standards reference, NHI Management Group recommends starting with the OpenTelemetry traces overview and the instrumentation guidance around span attributes.
Examples and Use Cases
Implementing OpenTelemetry spans rigorously often introduces data minimisation constraints, requiring organisations to weigh diagnostic value against the risk of exposing credentials, personal data, or model prompts.
- A payment service creates spans for authentication, authorisation, and ledger writes, allowing teams to identify which step caused latency or failure.
- An AI agent pipeline emits spans for retrieval, prompt construction, model inference, and tool execution, so operators can trace where a harmful or incorrect action originated.
- A federated login flow records spans for redirect, token issuance, and policy evaluation, helping analysts map identity assurance steps without relying only on application logs.
- A cloud-native incident response workflow uses spans to connect API activity across services, which is useful when a compromised token moves laterally through microservices.
- A monitoring team suppresses high-risk span attributes such as full prompts or bearer tokens, retaining only redacted identifiers and security-relevant metadata.
For implementation discipline, the NIST Cybersecurity Framework 2.0 is useful for aligning telemetry collection with governance, logging, and detection objectives.
Why It Matters for Security Teams
Spans matter because they reveal behaviour, sequence, and dependency, which makes them invaluable during detection and response. They also create a governance problem: the same metadata that helps investigators may expose secrets, identity context, or sensitive model inputs if collected too broadly. In AI systems, spans can show whether an agent retrieved the right document, called the right tool, or escalated access unexpectedly. That makes them especially relevant to NHI and agentic AI security, where a single trace can expose both the acting identity and the action it performed. Security teams should define what is allowed in span attributes, who can query traces, how long they are retained, and which fields must be redacted or hashed. No single standard governs every span-content decision yet, so policy needs to be explicit and testable. The practical rule is to treat telemetry as production security data, not developer convenience data. Organisations typically encounter the operational cost of poor span design only after an incident review, at which point the missing or overexposed trace data becomes operationally unavoidable to address.
For identity and access context, NIST SP 800-63 Digital Identity Guidelines helps teams think about how identity events should be represented without over-collecting user data, while OpenTelemetry tracing guidance remains the operational baseline for span structure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM | Traces support continuous monitoring and detection activities within the framework. |
| NIST SP 800-63 | AAL2 | Identity events in spans can reflect authentication assurance and session handling. |
| OWASP Non-Human Identity Top 10 | Span data can expose NHI activity, secrets, and tool use in agentic workflows. | |
| OWASP Agentic AI Top 10 | Agent traces are often built from spans that expose tool calls and prompt flow. | |
| NIST AI RMF | AI risk governance depends on observability that does not overexpose prompts or outputs. |
Apply AI risk controls to telemetry design so model tracing supports oversight without unnecessary disclosure.
Related resources from NHI Mgmt Group
- How should security teams govern SaaS access when identities span many apps?
- How should security teams govern AI applications that span notebooks, pipelines, and runtime services?
- Who should own cryptographic trust when machine identities span multiple teams?
- How should security teams replace shared secrets for workloads that span multiple clouds?
