OpenTelemetry for LLM tracing exposes the gap in agent observability

At a glance

What this is: This is a guide to instrumenting LLM and agent applications with OpenTelemetry so traces can capture model calls, retrieval, tool use, and execution flow, with a separate evaluation layer for output quality.

Why it matters: It matters because IAM and security teams increasingly need visibility into AI-driven runtime behaviour, where tracing, governance, and identity controls overlap with tool use, delegated actions, and production risk.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Braintrust's guide to OpenTelemetry tracing for LLM and agent applications

Context

LLM tracing is fundamentally a governance problem as much as an observability problem. Traditional APM can tell you that a service responded quickly and without error, but it cannot tell you whether the model output was grounded, whether a tool call was appropriate, or whether the execution path matched policy.

In agentic workflows, the application itself becomes a chain of prompts, retrievals, model calls, and tool invocations. That creates a direct identity and access concern because the agent is acting through credentials, APIs, and delegated permissions, often with far less visibility than human-operated systems. The article is about instrumentation, but the security question is who or what is allowed to act, and how that action is traced.

This is a typical problem in modern AI engineering teams: the logging stack is often healthy while the governance stack is incomplete.

Key questions

Q: How should security teams govern AI agents that call internal tools from Kubernetes?

A: They should separate runtime containment from identity governance. Kubernetes can isolate execution, but the tool boundary still needs delegated identity, per-request authorization, and action-level logging. Without those controls, the agent behaves like an unscoped service account with model-driven output, which makes attribution and revocation much harder.

Q: Why do AI agents need identity and access governance if the model is already strong?

A: Because model strength does not control who or what the agent can touch in production. The real risk comes from standing permissions, weak supervision, and access to tools and data that the task does not require. Governance has to define runtime authority, not just model output quality.

Q: What breaks when teams rely on APM alone for AI applications?

A: APM alone breaks down when the system returns a technically successful response that is still wrong, unsafe, or unsupported. Latency, errors, and status codes do not reveal prompt quality, retrieval grounding, or tool misuse. Teams need structured traces plus evaluation logic to distinguish healthy infrastructure from unhealthy model behaviour.

Q: How should organisations use data observability for AI reliability and audit readiness?

A: Monitor the data feeding AI systems with the same discipline used for critical reporting data. Track freshness, schema, volume, distribution, and lineage so that model inputs are continuously validated and any anomaly can be traced to an owner, an upstream cause, and a potentially affected business process.

Technical breakdown

Why standard APM misses LLM execution paths

APM tools are built to assess request health, not reasoning quality. In an LLM application, the visible HTTP transaction may hide multiple internal steps, including retrieval, model inference, tool execution, parsing, and retry logic. A single successful response can therefore mask incorrect grounding, policy violations, or unsafe tool use. OpenTelemetry helps by turning those hidden steps into spans with a shared trace ID, so the full request path remains reconstructable across services and backends.

Practical implication: instrument the internal LLM workflow, not just the front door request, or you will miss the control points that matter.

How GenAI semantic conventions structure agent telemetry

The GenAI semantic conventions give LLM spans a shared vocabulary for model name, token usage, operation type, and related metadata. That matters because portability depends on consistent fields, not just on collecting traces. Once those attributes are emitted, different backends can interpret the same run in the same way, which avoids custom one-off schemas for each observability destination. The result is a trace that can be searched, compared, and scored across environments without changing the instrumentation code.

Practical implication: standardise on GenAI span attributes early so observability and evaluation remain portable as your stack changes.

Why multi-export routing changes the governance model

Routing one trace stream to multiple backends separates capture from interpretation. The OpenTelemetry Collector can batch, sample, redact, enrich, and forward spans to operational monitoring tools and to a quality-evaluation backend. That architecture is valuable for AI teams because the same event stream can support uptime monitoring, debugging, and output review without duplicating instrumentation. It also creates a governance obligation: once spans can flow to several systems, data handling, redaction, and retention become part of the tracing design, not an afterthought.

Practical implication: define redaction, retention, and destination policy before exporting agent traces broadly.

NHI Mgmt Group analysis

OpenTelemetry solves visibility, not governance. The article correctly shows that tracing can expose model calls, tool paths, and token usage, but trace fidelity alone does not answer whether the agent had the right to act. For IAM and NHI programmes, the real issue is that runtime observability and delegated authority often live in separate control planes. Teams should treat tracing as evidence of behaviour, not evidence of approval.

LLM tracing creates a new class of machine identity evidence. Each agent run emits a behavioural record that can be tied back to a workload, service account, or API credential. That makes trace data relevant to NHI governance, because it can show when a non-human actor crossed a policy boundary, retried a tool call, or used an unexpected execution path. The practical lesson is that agent telemetry should feed identity review, not sit only in engineering dashboards.

Output evaluation belongs in the same governance conversation as observability. The article’s distinction between APM and evaluation is important because a low-latency response can still be a bad outcome. That is the same structural problem identity teams face when access is technically valid but operationally unsafe. Quality control without authorisation control is incomplete. Practitioners should align trace review, policy enforcement, and delegated access governance as one operating model.

Named concept: trace-to-trust gap. This is the disconnect between being able to see what an AI agent did and being able to prove it was allowed to do it. The article demonstrates that modern telemetry can reconstruct execution paths, but governance still depends on identity, privilege, and policy decisions outside the trace layer. Teams that do not close this gap will have excellent visibility and weak accountability.

Agent tracing will increasingly shape audit expectations. As organisations use LLMs in production, auditors and risk teams will expect evidence of what the system did, which tools it called, and how exceptions were handled. That does not replace IAM, PAM, or NHI lifecycle controls; it makes them auditable at runtime. The direction of travel is clear: AI operational telemetry is becoming part of security governance, not just engineering diagnostics.

What this signals

AI observability is becoming a governance surface, not just an engineering toolset. As agent workflows expand, teams will need to reconcile trace data with identity records, access scopes, and evaluation policy so that runtime evidence can support security decisions rather than only debugging. The trace-to-trust gap is the real programme risk.

Trace-to-trust gap: the ability to see an AI action without being able to prove it was authorised. That gap widens when the same service account can trigger multiple tools, data sources, or model calls without a clear approval boundary. Programmes should prepare to join telemetry with workload identity controls and exception handling workflows.

For identity-led programmes, the implication is straightforward. AI agents will increasingly need the same lifecycle discipline as other non-human identities, including ownership, scope review, revocation, and auditability, while observability supplies the evidence layer that shows whether those controls are actually working.

For practitioners

• Trace the internal agent workflow, not just the API edge Instrument retrieval, model calls, tool invocations, retries, and post-processing as separate spans so you can inspect the full execution path.
• Standardise GenAI span attributes across runtimes Use the same semantic fields for model name, token counts, operation type, and metadata across Python, TypeScript, Java, and Go.
• Route traces through a controlled export layer Use the OpenTelemetry Collector to batch, sample, redact, and forward spans to approved monitoring and evaluation backends.
• Tie agent traces to workload identity records Map each production trace stream to the service account, API key, or workload identity that issued the action so reviews can follow accountability.
• Convert failed runs into regression cases When a trace shows a bad answer or unsafe tool path, capture the input and expected behaviour as a reusable evaluation case.

Key takeaways

• LLM tracing improves visibility, but it does not by itself prove that an AI action was authorised or safe.
• OpenTelemetry creates portable execution records that can support both observability and AI governance, especially when traces are tied to workload identity.
• Teams should treat trace data as evidence for evaluation, access review, and exception handling, not as a substitute for identity control.

Key terms

• OpenTelemetry GenAI semantic conventions: A shared set of attributes for representing model calls, token usage, tool invocations, and related metadata in a portable trace format. They let different observability backends read the same AI execution data without custom schemas or one-off instrumentation.
• Agent Trace: A structured record of an AI agent’s runtime activity, including model calls, tool calls, approvals, and subagent steps. In practice, traces support debugging, evaluation, and governance when they are retained, searchable, and tied to the permissions behind the agent.
• Output evaluation: The practice of scoring model or agent outputs against defined quality criteria such as correctness, grounding, policy compliance, or safety. Unlike infrastructure monitoring, evaluation asks whether the answer was fit for use, not simply whether the service returned successfully.
• Trace-to-trust gap: The difference between being able to observe an AI system’s actions and being able to prove those actions were authorised. It appears when telemetry is rich but the identity, privilege, and approval controls behind the action are not linked to the trace record.

What's in the full article

Braintrust's full guide covers the implementation detail this post intentionally leaves for the source:

• Runnable OpenTelemetry configuration for routing GenAI spans into Braintrust and other backends
• Framework-specific tracing examples for LangGraph, LangChain, OpenAI, and Anthropic instrumentation
• OTLP exporter settings, collector routing, and environment variable setup for production pipelines
• Evaluation recipe details for turning failing traces into reusable regression datasets

👉 The full Braintrust guide covers routing patterns, instrumentation examples, and eval setup in production.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security practitioners connect identity controls to the operational reality of modern automation and AI.