Telemetry With No Owner: Attributing Unowned Agent Traces

A stream of spans lands in your backend. 18,432 events over the last hour, each one well-formed, timestamped, and complete. Every span parses. Then you look for the one field that would tell you what to do with any of it, and it isn't there. No service.name. No owner. No repo, no team, no purpose. You have detected an agent, and you have learned almost nothing about it.

This is the gap between detecting telemetry and being able to act on it. A signal you can't trace back to an owner, a purpose, and a risk surface is a dead end. It fills a dashboard without answering the only question that matters: what is this, and who is responsible for it?

Detecting a signal is not the same as attributing it

Most discovery conversations assume that once telemetry is flowing, the hard part is over. In practice, flowing telemetry is where a second problem starts. Getting an agent to emit spans is one thing. Receiving those spans with enough context to identify what produced them is another, and the second one is where teams get stuck.

An unattributed span is worse than a blind spot. A blind spot is honest about what you don't know. Telemetry with no owner looks like coverage. It shows up in your inventory count, it inflates your sense of visibility, and it gives you nothing to govern. You can watch it run for weeks and still not know whether it touches customer data, calls an external model, or belongs to a team that left the company.

Why OTEL payloads lose provenance

OpenTelemetry captures what happened. Preserving who did it depends on a chain of context that breaks in predictable places.

Missing or default service.name. The single most common cause. An agent that ships without an explicit service name reports as unknown_service or a generic runtime label. Every span it emits is technically valid and functionally anonymous. When several agents do this, they collapse into one indistinguishable pile.

Proxied LLM calls collapse to the gateway. Many enterprises route model traffic through a shared LLM gateway or proxy. From the telemetry's point of view, every agent behind that gateway looks like the same caller: the gateway. The originating agent's identity never makes it into the span unless something upstream attached it first.

Collector and sidecar rewrites. Resource attributes get dropped or overwritten in transit. A collector reprocessing spans, or a sidecar batching them, can strip the very fields that carried provenance before they ever reach your backend.

MCP and multi-hop execution. When an agent calls another agent, or reaches a tool over the Model Context Protocol, spans cross service boundaries. Without explicit context propagation, the originating identity gets lost at the first hop, and downstream spans read as if they came from nowhere.

Auto-instrumentation defaults. Framework instrumentation is good at capturing the mechanics of a call: the model, the tokens, the latency. It rarely knows the business identity of the agent making that call. You get a perfect record of an LLM request with no idea which application it belongs to.

Most of these have the same root fix, and it lives at the emitting end. Setting service.name and propagating context correctly, the kind of discipline that comes with instrumenting agents to emit traces from day one, is what keeps provenance intact before it ever reaches your backend.

From an unnamed task to an owned application

You can't always fix instrumentation retroactively, and you rarely control every agent emitting into your environment. So the receiving end needs a way to resolve an anonymous stream into something governable.

Fingerprinting. Cluster spans by their observable characteristics: the model called, the tool signatures, the endpoints hit, the shape and timing of requests. An agent that queries a specific vector database, calls three named tools in a recurring order, and hits a known internal API has a signature, even without a name. That signature is often enough to infer what the task actually does.

Correlation. Tie orphaned spans back to a deployment, a repository, or a team using whatever surrounding metadata survived: network origin, container labels, IAM identity, the gateway credentials used. Any one of these narrows an anonymous stream to a candidate owner.

Promotion. Resolve the inferred task into a registered application with a named owner. This is the step that converts an unattributed signal into an entry you can govern, the same move as turning a discovered inventory into a governable agent with an accountable owner behind it.

Attribution is the precondition for governance

Every governance control assumes you know what you're governing. Without an owner, there is no one accountable and no one to route a review to. Without a purpose, there is no basis for risk classification. Without an identity, policy has nothing to attach to.

The runtime controls fail the same way. Guardrails that intercept bad inputs and outputs have to be scoped to a specific agent, and so do continuous evals. You can't apply a PII filter or a hallucination check to a stream you can't name. Attribution is the step that turns raw telemetry into a governable inventory. Everything downstream depends on it.

Designing for attributable telemetry from the start

The cheapest attribution problem is the one you prevent.

Set service.name and resource attributes as an enterprise-wide standard, not a per-team choice. An agent that names itself is an agent that resolves on arrival.

Preserve provenance through proxies and collectors. Attach the originating identity before traffic reaches a shared gateway, and audit your collector pipeline so it isn't stripping the fields you depend on.

Send traces to centralized, well-known locations. Discovery tooling can only resolve telemetry it can see, and scattered destinations mean scattered provenance.

Turn unowned telemetry into a governed inventory

Arthur resolves anonymous telemetry into governed applications, each with a named owner, an applied policy, and continuous monitoring against it. Detection is where it starts. Attribution is what makes it useful.

Book a demo to see how Arthur attributes and governs agents across your environment, or explore the Agent Development Toolkit to get started.

‍