Telemetry-Based Agent Discovery With OpenTelemetry

You can't govern an agent you don't know exists. Before a security team can assign an owner, apply guardrails, or classify risk, it has to find the agent in the first place. That sounds simple until you count how many agents are actually running across a large enterprise, and how few of them anyone registered on purpose.

Manual inventories don't keep pace. Agents enter through new applications, third-party tools, and vendor updates to software you deployed years ago. A company that had dozens of agents last quarter can have thousands this one. Asking teams to self-report what they've built is a losing game, because the agents you most need to find are the ones nobody thought to declare.

Automated discovery is the only approach that scales, and OpenTelemetry is the signal that makes one of the most reliable discovery techniques possible.

Why OpenTelemetry is the right signal

OpenTelemetry (OTEL) is the vendor-neutral standard for emitting traces, metrics, and logs. It has become the default instrumentation layer for agents, which matters for discovery: agents that follow the standard produce a consistent, machine-readable record of what they do, in a format you can watch centrally instead of chasing per-team logging conventions.

Its distributed tracing model is what makes it useful here. Agents rarely run in isolation. A single request can cross services, APIs, databases, and other agents. OTEL follows that execution end to end, even as it moves across system boundaries, so the trace reveals not just that an agent ran but what it called and where.

The enabling move is standardization. When you establish one enterprise-wide OTEL standard and route telemetry to centralized destinations, you get a single place to watch for everything emitting traces. That single stream is what turns telemetry from an observability convenience into a discovery capability.

How telemetry-based discovery actually works

Telemetry-based discovery puts listeners on your OTEL streams and watches for signals that a new agent has come online or an existing one has changed.

A few signals reveal a previously unknown agent. A new service or trace signature shows up in the stream. Spans carry LLM call patterns that weren't there before. Tool-call spans point to capabilities no registered agent claimed. A framework signature, the fingerprint of a known agent library, appears where you weren't expecting one.

The same listeners catch change on agents you already know about. A new tool the agent can now invoke. A new subagent it started delegating to. A model swap or configuration change that alters its risk surface. Each of these is worth surfacing, because an agent's risk profile is only as current as your last look at it.

The output is a queue of unregistered agents flagged for triage. From there, a security or governance team can assign an accountable owner, classify the agent's risk, and organize it into a governed application, turning something detected in a telemetry stream into something managed.

Standardize telemetry before you try to scale

Telemetry-based discovery only sees what emits telemetry to a place you're watching. That makes the precondition non-negotiable: you need an enterprise-wide OTEL standard and centralized destinations before discovery can do its job.

This is the same investment that pays off downstream in governance. As we covered in the best practices for agent discovery and governance, governance tooling discovers agents by finding their telemetry, so agents that emit traces to standard, centralized locations get discovered and inventoried automatically, without manual registration. An agent that emits nothing is invisible to the organization. Setting the standard early is what makes both discovery and later oversight possible.

Telemetry alone won't find everything

Telemetry-based discovery is the foundation, not the whole strategy. An agent that emits no telemetry, or sends it somewhere you aren't watching, stays invisible to this technique. That gap is exactly why a real discovery program runs several methods in parallel.

Three others cover what telemetry misses. MCP server monitoring watches the Model Context Protocol interfaces through which agents expose capabilities, catching agents as they come online and flagging capability changes even when the agent itself isn't instrumented. Network-layer analysis inspects traffic for LLM API call signatures, through a dedicated proxy or general monitoring, which surfaces AI usage on non-standard frameworks that never emit a recognizable trace. API-driven discovery queries cloud AI platforms like AWS Bedrock and Google Vertex AI that advertise running agents through their own endpoints, useful coverage for managed-cloud agents you'd otherwise have to instrument yourself.

Telemetry is the layer that catches the most and gives the richest detail. The other three close the blind spots it leaves. You need all four because agents enter the enterprise through too many doors for any single technique to cover them all.

From discovery signal to governance

Discovery is step one, but the same telemetry that reveals an agent keeps working long after you've found it. The traces that flag a new agent also feed ownership assignment, risk triage, and continuous monitoring once the agent is under management. The foundational work of instrumenting agents and centralizing their traces, described in the best practices for observability and tracing, is what later supports continuous evals, guardrails, and audit review. Set up telemetry well once, and it serves the entire lifecycle rather than just the moment of discovery.

How Arthur fits

Arthur runs listeners on your OTEL streams to detect new agents, tools, and configuration changes as they appear, then routes unregistered agents into a governed application with an accountable owner. It's one of four discovery techniques Arthur runs in parallel, alongside MCP monitoring, network-layer analysis, and API-driven discovery, so coverage doesn't depend on any single signal.

The data plane runs inside your VPC, so telemetry never leaves your environment, while the control plane gives security, audit, and governance teams org-wide visibility from one place. You can see how the full discovery and governance model works on Arthur's agent security and governance platform.

TL;DR

• You can't govern an agent you can't see, and manual inventories don't keep pace with agent sprawl.
• OpenTelemetry is a vendor-neutral standard whose distributed tracing follows an agent across service boundaries, which makes it a reliable discovery signal.
• Telemetry-based discovery puts listeners on OTEL streams to detect new agents, new tools, new subagents, and configuration or model changes, then queues them for triage.
• The precondition is standardizing OTEL enterprise-wide and centralizing where traces land. Agents that emit nowhere stay invisible.
• Telemetry is the foundation, but it works alongside MCP monitoring, network-layer analysis, and API-driven discovery to close the gaps it leaves.
• The same telemetry that surfaces an agent supports ownership, monitoring, evals, and audit for the rest of its lifecycle.

Want to see telemetry-based discovery running against your own environment? Book a demo with an AI expert. If you're building agents and want to instrument them for discovery from day one, start with the Agent Development Toolkit.

‍