Every governance program for agents runs into the same first problem: nobody knows how many there are. Teams built agents during experimentation, deployed them, and moved on. Security asks for an inventory and receives a spreadsheet that is a subset of reality.

Asking teams to register their agents produces partial compliance, because registration is work with no immediate benefit to the person doing it. The approach that works is finding them from signals they already emit — and for anything built on a modern agent framework, that signal is OpenTelemetry traces.

Why Telemetry Is the Right Discovery Source

Agent frameworks emit spans. Model calls, tool invocations, retrieval operations, and chain steps all appear as spans with attributes describing what happened. Most teams already ship this somewhere for debugging.

That data answers the inventory questions directly:

  • Which agents exist, from service names and agent identifiers on spans.
  • Which tools they actually call, from tool-call spans — the exercised surface rather than the configured one, which is more useful for scope reduction.
  • Which models and providers, from model-call attributes, including versions.
  • Which MCP servers, from server names on tool spans. This is how shadow MCP servers become visible.
  • Volume, cost, and latency, from span counts, token attributes, and durations.
  • Dependency structure, from parent-child span relationships across services — which agents call which.

And it requires nothing new from the teams being inventoried. They point an existing exporter at a new endpoint, or you receive a copy from your collector. That is a materially easier adoption story than "register every agent."

From Spans to an Inventory

Accepting the standard protocol rather than a proprietary format is what makes adoption a configuration change for the teams being inventoried, and every batch has to be attributed to a tenant on arrival — that attribution is where the security work is, covered below.

Two problems then have to be solved before spans become an inventory.

Normalization. Map framework-specific attribute names onto a canonical schema. Different frameworks name the same concepts differently, and semantic conventions for generative AI are still stabilizing, so a normalization layer with per-framework mappings is unavoidable. Keep the raw attributes alongside the normalized ones so a mapping gap is recoverable rather than lossy.

Entity resolution. Spans describe events; an inventory needs entities. Deriving stable agents, tools, servers, and models from a stream of events — with first-seen and last-seen timestamps and call counts — is the step that turns telemetry into something governable, and identity stability is what makes it hard.

Reconciling the result against whatever registry you keep is what produces the actual discovery output: the things running that governance does not know about.

Whatever the shape, keep acceptance separate from processing. Telemetry arrives in bursts, and an endpoint that does its analysis inline makes ingest latency a function of your storage layer.

The Tenant Isolation Trap

The ingest endpoint is the sharpest security surface in this design, and the failure is specific.

Telemetry ingest is authenticated with a long-lived key, because it is configured once into an exporter. That key must scope writes to exactly one tenant. If the ingest handler takes the tenant identifier from the payload — from a resource attribute, a header the client sets, or a service name — then any holder of any valid ingest key can write telemetry attributed to any tenant.

The consequences are worse than they first appear. Injected telemetry appears in another tenant's inventory and cost aggregates, so it corrupts billing data and operational dashboards. It can create observed entities that trigger governance workflows. And because telemetry is trusted infrastructure data, nobody looks at it skeptically.

The requirements:

The tenant comes from the credential, not the payload. The ingest key resolves to exactly one organization, and every span in the batch is attributed to that organization regardless of what the payload claims. Conflicting attributes in the payload are ignored or cause rejection — not honored.

Reads are scoped at the data layer. Discovery queries filter by tenant with a predicate enforced by the datastore rather than by application code. See tenant isolation with row-level security.

Cross-tenant reads are tested explicitly. A test that authenticates as organization A and requests organization B's observed agents must get a rejection, not an empty list — an empty list can pass while the query is actually unscoped and the data merely absent.

Ingest keys are narrowly scoped. Write-only, telemetry-only, unable to read anything. An exporter configured with a key that can also read your audit trail is over-privileged for its job. See organization API keys and scopes.

Bounding the Endpoint

Telemetry volume is unbounded by nature: a misconfigured exporter with sampling disabled on a busy agent can produce enormous volume, and the cost lands on you.

  • Per-tenant rate and volume quotas, enforced with rejection rather than degradation.
  • Payload size caps per batch.
  • Attribute count and value length caps — spans with megabyte-sized attributes are usually a bug and always a storage problem.
  • Retention tiers. Raw spans for a short window, aggregates for longer. Raw span data is the bulk of the volume and the least useful after a few days.
  • Backpressure that is honest. Return the standard throttling response so a well-behaved exporter backs off, rather than accepting and silently dropping.

Also treat span content as potentially sensitive. Prompt text, tool arguments, and retrieved content routinely appear in span attributes, which means your telemetry store now holds customer data. Apply redaction on ingest for known sensitive patterns, and restrict read access accordingly. See how to redact PII from agent prompts.

From Discovery to Governance

An inventory that only reports is a report. The value is in what happens next, and the pipeline should support it directly.

Adopt. Convert an observed agent into a registered one: assign an owner, attach it to a team, define its connections, and bring it under policy. This should be one action from the discovery view, pre-filled with what telemetry already revealed about its tools and models.

Reduce scope from observed usage. The exercised tool set is the empirical basis for tightening a registered agent's grants. An agent configured with forty tools and observed calling three has a concrete scope reduction available. See how to implement least privilege for agents.

Retire. Observed agents with no activity in 90 days are offboarding candidates. See secure agent offboarding and deprovisioning.

Investigate. New observed agents, new MCP servers, and new model providers are governance events worth a notification, not just a dashboard row.

Scope the adoption path as carefully as the read path: one organization must not be able to adopt another's observed entity.

Common questions

What if our agents do not emit OpenTelemetry?

Then telemetry ingest finds nothing, and you need the other discovery angles: egress logs, client configuration scanning, process inventory, and gateway traffic. Gateway traffic is the strongest of these, because agents routed through a proxy are inventoried by construction — the proxy sees every call whether or not the agent is instrumented. Telemetry ingest is the cheapest angle for instrumented fleets, not a complete answer on its own.

Is discovery from telemetry complete?

No. It finds agents that emit telemetry to an endpoint you receive. It misses agents with instrumentation disabled, agents on unmanaged devices, and agents whose teams point their exporter elsewhere. Treat it as one input, reconcile across several, and note that the intersection is informative: an agent in egress logs but not in telemetry is deliberately or accidentally uninstrumented, which is itself worth knowing.

Does this replace our existing observability stack?

No, and it should not try to. Your APM or tracing backend is for debugging, with the retention and query interface engineers need. Discovery ingest is for governance: inventory, attribution, cost, and policy reconciliation. The same OTLP stream can feed both — a collector can fan out to multiple exporters — which is the recommended configuration rather than choosing one. See observability for AI agents.

How do we handle span attributes that differ across frameworks?

Normalize on ingest with per-framework mappings, keep the raw attributes, and prefer the emerging generative-AI semantic conventions where a framework supports them. Expect to maintain the mapping layer — frameworks change attribute names between versions, and a silent mapping break shows up as agents disappearing from the inventory. Alerting on a sudden drop in normalized-entity extraction rate catches it.

How Praesidia approaches discovery

Praesidia accepts standard OTLP telemetry, so an instrumented fleet can be inventoried by pointing an existing exporter at it rather than by adopting anything new. Telemetry is tenant-isolated on ingest as well as on read: one organization's exporter cannot write into another's inventory, and cross-organization reads are rejected rather than silently empty.

Spans are resolved into observed agents, tools, servers, and models, and entities that were never registered can be adopted into governance — owner assigned, connections defined, policy attached — rather than only reported, and topology views derive from span relationships. See building an AI agent inventory, agent topology maps, and the Praesidia documentation.