AI observability splits into app tracing and incident investigation

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Logz.io's blog post: AI observability has split into app tracing for quality and cost, and agentic incident investigation across production telemetry.

Why it matters: IAM and platform teams need to treat AI observability as both a governance problem and an operational one, because the same AI system can affect outputs, telemetry, and automated incident response.

Context

AI observability now means two different control problems: one is evaluating what an AI application or agent did, and the other is using AI to investigate production signals. The first depends on prompt traces, tool calls, retrieval results, and output scoring; the second depends on logs, metrics, traces, and alert context so incidents can be triaged faster.

That split matters because a poor answer from an AI system can come from either model behaviour or a dependency failure behind the scenes. If the telemetry stack and the evaluation stack are isolated, teams miss the link between quality drift, runtime errors, and access decisions that shape what the system can see and do.

Key questions

Q: What is the difference between OpenTelemetry and an AI observability platform?

A: OpenTelemetry is the telemetry collection and export layer, while an AI observability platform is the system that stores, visualises, tests, alerts on, and operationalises that data. OTel is useful for vendor-agnostic instrumentation and portability. The platform turns raw traces into actionable governance for AI workloads, including metrics, tests, and alerts.

Q: Why do AI agents need least-privilege access to telemetry data?

A: AI agents need least-privilege access to telemetry data so they can read only the logs, metrics or traces required for their task, rather than broad observability data that may expose credentials, customer content or operational details. Limiting read scope reduces unnecessary data exposure, constrains prompt injection from poisoned telemetry, and makes revocation and audit of the agent’s access clearer.

Q: How should teams separate LLM evaluation from incident investigation?

A: Teams should separate LLM evaluation from incident investigation by using distinct datasets, permissions and workflows, so benchmark prompts and scored outputs do not mix with live forensic evidence. Incident work should rely on preserved logs, metrics, traces and chain-of-custody controls, while evaluation uses sanitised test data and isolated access, preventing contamination of evidence and accidental disclosure.

Q: What is MCP in the context of AI security?

A: MCP is a standard way for AI agents to connect to tools and data sources through a client-server pattern. For security teams, the important point is that MCP does not remove identity controls. It still relies on secrets, scopes, and lifecycle management for every connected system.

Technical breakdown

OpenTelemetry GenAI spans as the shared telemetry layer

OpenTelemetry’s GenAI semantic conventions create a common schema for AI systems, with spans for model inference, agent runs, tool execution, and retrieval. That matters because it lets teams instrument once and reuse the same telemetry in both evaluation tools and observability platforms. The practical value is not just standardisation. It is correlation: the AI trace can sit beside the infrastructure trace that explains latency, failure, or cost. The GenAI conventions are still evolving, so version pinning and capture controls are part of the design, not an afterthought. Read OWASP Agentic Applications Top 10.

Practical implication: Instrument AI workloads with a version-pinned OpenTelemetry path so evaluation and incident tooling can consume the same spans.

Why agentic observability needs runtime context, not just traces

Agentic observability differs from LLM evaluation because the question is not only whether the output was good. It is also whether the agent had the right context, saw the right dependency, and made the right operational decision at the right time. That requires logs, deployment markers, runbooks, and incident history around the trace. Without that runtime context, a slow or wrong tool call looks like an AI problem when the real cause may be throttling, stale data, or a bad deploy. Correlation is the mechanism that turns telemetry into investigation. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Feed agents deployment, log, and runbook context so root cause findings can explain the failure path, not just the symptom.

MCP extends observability into agent tool access

Model Context Protocol exposes external tools and data sources to AI clients in a structured way, which makes it relevant wherever coding assistants or homegrown agents need live operational data. In observability, that means the same AI system that interprets telemetry can also query logs, dashboards, and alerts through a governed interface. The governance issue is scope. If MCP clients can reach production signals, then access boundaries, audit trails, and approval controls become part of observability architecture, not separate IAM hygiene. The protocol only works safely when the exposed surface is deliberately limited. See the Agent Identity Standards Tracker.

Practical implication: Scope MCP access to the minimum observability surfaces an agent needs and audit every tool invocation.

Threat narrative

Attacker objective: The objective is to use AI telemetry access to accelerate investigation, or to abuse that same access path to reach sensitive operational data and control surfaces.

1. Entry occurs when an AI agent or assistant is connected to production telemetry, runbooks, and alerting channels without tight scope controls.
2. Credential access then determines which logs, metrics, traces, or incident records the agent can read and whether it can invoke tools through MCP or similar interfaces.
3. Escalation happens when the agent combines AI spans with operational context to infer more than intended or trigger actions beyond the original investigation scope.
4. Impact is faster triage, but also a larger blast radius if the telemetry feed, tool access, or audit trail is over-permissive.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI observability has become a governance split, not a single category: tracing AI applications and investigating production with AI solve different problems, use different data, and create different control boundaries. Teams that buy only one side of the stack will either see quality issues without operational context or see incidents without AI-specific evidence. The practical conclusion is that observability architecture now needs a policy model for what the agent can inspect, what it can do, and what gets retained.

OpenTelemetry is the real integration layer for AI operations: the important change is not a new dashboard, but a common span model that lets AI traces and infrastructure traces travel together. That creates a defensible basis for incident correlation, cost attribution, and offline evaluation. Without a shared telemetry grammar, the same failure gets measured twice and understood once, poorly.

Telemetry access is an identity problem as much as an observability problem: once AI agents can query logs, metrics, dashboards, or alerts, they become governed actors with runtime authority. The security boundary is no longer only the observability platform; it is also the identities, scopes, and approvals that let agents read or act on production data. Least-privilege AI access is the difference between useful automation and uncontrolled inspection.

Named concept: telemetry-to-action convergence: when the same AI system can both read operational signals and interpret them, the line between analysis and action collapses. That convergence is useful for MTTR, but it also means auditability, delegated authority, and change control must move into the telemetry pipeline itself. Practitioners should treat the pipeline as a governed runtime, not a passive reporting layer.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Telemetry-to-action convergence: AI observability is moving toward systems that can both inspect production signals and interpret them in real time. That increases MTTR potential, but it also means the telemetry plane itself becomes a governed runtime with access, audit, and retention decisions that security teams must own.

OpenTelemetry GenAI spans will likely become the practical boundary between AI engineering and operations because they let one instrumented path feed both evaluation and incident response. The risk is that teams adopt the schema before they define who can query, enrich, or act on those spans, which turns observability into a privileged data surface.

For practitioners

• Separate evaluation from operations on purpose Use one toolchain for prompt, trace, and dataset evaluation, and a different governed path for incident investigation so quality checks do not become ad hoc production access.
• Instrument AI workloads with OpenTelemetry GenAI spans Standardise spans for model inference, agent runs, tool calls, and retrieval so evaluation tools and observability platforms consume the same telemetry. Read OWASP Agentic Applications Top 10.
• Constrain agent access to observability data Limit which logs, metrics, traces, dashboards, and alerts an AI agent can read, and require audit trails for every tool invocation and response path.
• Pin GenAI instrumentation versions and opt in to content capture Treat schema drift and sensitive prompt content as operational risks, because the GenAI conventions are still changing and completions can carry private data.
• Correlate deploy markers with incident findings Join agent traces to deployment metadata, runbooks, and alert history so root cause analysis can explain whether a failure started in the model, the toolchain, or the infrastructure.

Key takeaways

• AI observability now spans both AI quality control and incident investigation, and treating those as separate problems leaves blind spots between model behaviour and runtime failure.
• The shared telemetry layer is OpenTelemetry’s GenAI schema, which makes AI traces usable by both evaluation tools and observability platforms.
• The governance issue is no longer only what the system observes, but which identities and agents are allowed to inspect or act on production telemetry.

Related NHI Mgmt Group resources: OWASP Agentic Applications Top 10 · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Identity Guide

Key terms

• AI observability: AI observability is the ability to see how AI systems are being used, what information they process, and what actions they trigger. In security programmes, it extends beyond uptime or model quality to runtime visibility, policy enforcement, and audit evidence across human and agent-driven use cases.
• OpenTelemetry GenAI semantic conventions: A shared set of attributes for representing model calls, token usage, tool invocations, and related metadata in a portable trace format. They let different observability backends read the same AI execution data without custom schemas or one-off instrumentation.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Agentic observability: Agentic observability is the practice of capturing enough execution detail to understand how an AI agent reasoned, retrieved context, and used tools. It goes beyond output logging by preserving the spans, decision lineage, and context needed for evaluation, audit, and behavioral drift detection.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and workload identity. It helps security and platform teams govern the identities behind AI systems and the telemetry paths they use.