What OpenTelemetry Can Actually Tell You About Your AI Agents

The Four Questions Agent Telemetry Answers Well Today

‍

The distance between what OpenTelemetry was built for and what AI governance is asking of it shows up in a single number. Distributed tracing descends from Dapper, the 2010 Google paper that gave the industry the vocabulary of traces and spans. Dapper sampled one trace in 1,024. That is ample for finding a latency regression, because a regression recurs and the next sample catches it. As a record of who authorized a privileged action, the same rate leaves 99.9% of the record missing, and the missing part is where the one event that mattered lives.

‍

That gap is the subject of this series. This part covers the other half first, because it is real and it is worth having: four things AI agent telemetry answers well today, cheaply, in a format the industry is converging on. Part 2 covers where the same telemetry stops answering. Part 3 covers what to do about the difference.

‍

OpenTelemetry Is a Wire Format and a Vocabulary, Not a Product

‍

The 101, in one section, because the details that matter for governance are not the ones usually taught.

‍

OpenTelemetry emerged in 2019 from the merger of OpenTracing and OpenCensus, two projects solving the same problem: there was no standard way to instrument code and ship what it produced. It defines three signals. Traces are trees of timed spans, where a span is one unit of work with a start, an end, and a bag of key-value attributes. Metrics are numeric time series. Logs are timestamped records with attributes attached.

‍

Two further pieces do the real work. Semantic conventions are the agreed names, so that gen_ai.usage.input_tokens means the same thing coming from two vendors. Context propagation carries a trace identifier across process boundaries, which is how a span in one service links to a span in another.

‍

The project itself is unambiguously successful. CNCF graduated it on 21 May 2026, after a third-party independent security audit, with more than 12,000 contributors from over 2,800 companies and the second-highest project velocity of the 240-plus CNCF projects, behind only Kubernetes.

‍

The GenAI part of it is a different story, covered in Part 2, and the gap between those two facts is where planning errors start.

‍

The Standard Says What It Is For, and It Is Not This

‍

OpenTelemetry's own documentation defines its purpose plainly: "Observability is the ability to understand the internal state of a system by examining its outputs."

‍

Read that as a governance requirement and the mismatch is immediate. Observability is about understanding your system. Assurance is about verifying a system, often one built by someone else, sometimes one behaving in ways nobody intended. The first assumes the software is on your side. The second cannot.

‍

Dapper named its three design goals as low overhead, application-level transparency and scalability. It never overshot 0.3% of one core, which is a genuine engineering achievement and a statement of priorities. Completeness is not on that list. Neither is integrity, non-repudiation, or resistance to a component that would rather not be observed. None of that is a criticism of the design. It is a description of what the design was for.

‍

Governance Reached For It Anyway, and Was Right To

‍

The pull is real, and it is not just convenience.

‍

Regulation now asks for exactly this shape of record. The EU AI Act, Article 12(1), states that "high-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system", and Article 12(2) ties those logs to identifying risk situations or substantial modifications, supporting post-market monitoring, and monitoring operation. Article 26(6) puts the retention obligation on the deployer, at a minimum of six months. An organization running agents needs a log, and a standard log format is better than five proprietary ones.

‍

The EU AI Act is not the only framework asking for this. ISO/IEC 42001's Annex A.6.2.8 makes event-log recording a mandatory control across the AI system life cycle. MITRE ATLAS lists AI Telemetry Logging, mitigation AML.M0024, as a named defense specifically against agentic actions, tool use and data access, not just model input and output. Three different frameworks, three different audiences, converging on the same floor.

‍

There is also a technical reason, and it is the strongest argument for instrumenting agents at all. Agent telemetry is the only source that sees the action boundary.

‍

The Action Boundary Is Visible Nowhere Else

‍

An AI agent spends most of its time reasoning, and then it does something: runs a shell command, writes a file, calls an API, opens a pull request. The moment it stops thinking and starts acting is the moment a security team cares about, and it is nearly invisible to every control already deployed.

‍

Network inspection sees TLS to a model endpoint. It sees the same TLS whether the agent went on to summarize a README or to read a credentials file. Endpoint detection sees a process that spawned a shell, which is what developer tools do all day. Identity systems see a token that was already issued. None of them can distinguish an agent asked to tidy a config file that chose to exfiltrate one, because the distinguishing information is in the tool call, and the tool call exists in exactly one place.

‍

In a field test of five coding agents run for this research, four of the five recorded the executed shell command and its output. That is a genuine capability; it is new, and nothing else in the stack has it.

‍

Four Questions It Answers Well

‍

Which agents are running, operated by whom, at what volume. This is the population denominator most organizations cannot currently produce, and it is what a board asks for first. It is inventory rather than detection, and inventory is where every governance program starts.

‍

What an agent invoked, with which arguments. The action boundary above.

‍

What happened in one session, in order. Spans nest, so a well-instrumented agent yields the shape of a run: prompt, inference, tool call, result, next inference. For incident reconstruction, that sequence is the artifact.

‍

Whether a run is abnormal. Structured, comparable, high-volume records support ordinary baselining. Token spikes, unusual tool mixes, off-hours activity.

‍

Those four are worth the effort on their own. A team that only needs a usage inventory and session reconstruction can stop reading here and start instrumenting.

‍

That is a genuinely different position than the one Dapper's engineers were solving for. A trace sampled to catch a recurring latency regression was never going to answer who authorized a privileged action, and nothing about AI agents changes that math. What changed is that governance stopped asking Dapper's question and started asking a harder one, and four solid answers is a good place to start.

‍

The rest of this series is about the questions that look like they belong on that list and do not. Part 2 opens with a three-question test for any telemetry source claiming to support a security or compliance decision, agent or otherwise, and shows where AI agent telemetry fails all three.

‍

You can't govern the agents you can't see, and the four questions above are where every program starts. See Kovrr build the live inventory of every AI agent running across your enterprise: who's operating it, at what volume, and what it's invoking. Book a demo today. 

‍

About This Research 

‍

This series draws on a Kovrr Research field test of five production coding agents (Claude Code, OpenAI Codex CLI, Google Gemini CLI, GitHub Copilot CLI, and Claude Cowork), each instrumented and captured against a live OpenTelemetry collector on an identical task.

‍

Sources

• Sigelman et al., "Dapper, a Large-Scale Distributed Systems Tracing Infrastructure" (Google, 2010)
• "OpenTelemetry: The Merger of OpenCensus and OpenTracing" (Google Open Source Blog, May 2019)
• CNCF: OpenTelemetry's Graduation announcement (21 May 2026)
• "What is OpenTelemetry?" (opentelemetry.io docs)
• Regulation (EU) 2024/1689, Article 12: Record-Keeping
• Regulation (EU) 2024/1689, Article 26: Obligations of Deployers of High-Risk AI Systems
• ISO/IEC 42001, Annex A.6.2.8, "AI System Recording of Event Logs"
• MITRE ATLAS, AML.M0024, "AI Telemetry Logging"
• Field test of five coding agents (Kovrr Research)