How should security teams implement OpenTelemetry for AI observability in multi-agent systems?

Use OpenTelemetry as the vendor-neutral telemetry standard for traces, metrics, and logs across orchestrators, sub-agents, tool calls, and LLM invocations. Instrument the full agentic hierarchy, propagate session context for multi-turn workflows, and pair telemetry with an evaluation layer that scores outputs for faithfulness, toxicity, and policy compliance. Telemetry alone shows what happened, not whether it was acceptable.

Why This Matters for Security Teams

OpenTelemetry gives security teams a common way to see what multi-agent systems are actually doing, but visibility only becomes useful when the telemetry is tied to risk decisions. In agentic workflows, traces can show orchestration paths, tool usage, model calls, and handoffs between sub-agents, which helps isolate failure points and suspicious behavior. The security challenge is that observability data can confirm execution, yet still miss whether the action was safe, authorised, or aligned with policy.

That gap matters because multi-agent systems can amplify small mistakes into chained outcomes. A single prompt injection, poisoned tool result, or unsafe delegation can ripple through multiple agents before anyone notices. Current guidance from the NIST AI Risk Management Framework supports treating AI systems as governed assets, not just workloads, which is the right lens here. Teams should also read OpenTelemetry as a security signal, not a compliance substitute, and pair it with evaluations, policy checks, and escalation rules.

In practice, many security teams discover visibility gaps only after an agent has already taken an unsafe action, rather than through intentional observability design.

How It Works in Practice

Implementation starts by instrumenting the full agentic path, not just the front-end application. That means traces for the orchestrator, each sub-agent, retrieval or memory layer, tool execution, and every LLM invocation. Session context should be propagated across turns so investigators can reconstruct a full workflow, even when actions span several minutes or multiple services. For security use cases, each span should carry enough metadata to support later analysis, including agent role, tool name, model version, tenant, policy decision, and evaluation result.

OpenTelemetry works best when telemetry is normalized across engineering, security, and MLOps pipelines. Logs capture detailed events, metrics show volume, latency, retries, and error rates, while traces show causal sequence. That structure lets teams answer practical questions such as whether a model call triggered a risky tool action, whether a sub-agent was repeatedly retried, or whether a certain prompt pattern correlates with unsafe outputs. The security value increases when telemetry is forwarded to SIEM or SOAR workflows for correlation with identity, network, and endpoint signals.

• Instrument orchestrators and sub-agents with consistent trace and span naming.
• Tag tool calls and model invocations with policy and evaluation outcomes.
• Propagate session identifiers across multi-turn and multi-service workflows.
• Correlate traces with alerts for prompt injection, abnormal delegation, and privilege abuse.
• Store enough context to support incident review, but minimise sensitive payload retention.

Security teams should align this with OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework, because both emphasise the need to understand orchestration abuse, tool misuse, and delegation risks as first-class threats.

These controls tend to break down when agent workflows span multiple vendors and custom toolchains because trace context is lost at service boundaries and the evidence becomes fragmented.

Common Variations and Edge Cases

Tighter telemetry often increases storage, privacy, and engineering overhead, requiring organisations to balance investigative depth against data minimisation and system performance. That tradeoff becomes more visible in regulated environments, high-volume customer workflows, and privacy-sensitive deployments where raw prompts or tool outputs may contain personal data, secrets, or regulated content.

Best practice is evolving on how much payload content should be retained. Many teams now log metadata by default and sample or redact sensitive content selectively, but there is no universal standard for this yet. Where the system uses retrieval, memory, or external tools, the telemetry design should distinguish between model reasoning, retrieved content, and action execution. This is important because not every unsafe outcome is a model failure; sometimes the issue is bad retrieval, poor policy enforcement, or over-permissive tooling.

Where agentic systems support security-sensitive work, teams should also review the MITRE ATLAS adversarial AI threat matrix and recent incident reporting such as the Anthropic report on the first AI-orchestrated cyber espionage campaign to understand how observability supports detection without guaranteeing prevention. For deeper governance mapping, the same telemetry should be usable in threat modelling and control reviews, including the CSA MAESTRO agentic AI threat modelling framework.

The approach becomes brittle in long-running autonomous agents that reuse memory aggressively, because causal chains are harder to reconstruct once context is compressed, summarised, or overwritten.

Related resources from NHI Mgmt Group

• How should security teams implement agent-to-agent authentication in multi-agent systems?
• How should security teams implement task-scoped access for multi-agent systems?
• How should security teams implement AI agent observability in environments where agents retrieve and share sensitive data?
• How should security teams implement AI agent email access without over-granting permissions?