AI observability is shifting from logs to agent execution traces

At a glance

What this is: This is a HoneyHive analysis of why AI agents outgrow traditional observability, with distributed tracing, schema flexibility, and unstructured enrichment emerging as the key requirements.

Why it matters: It matters to IAM and security teams because AI agents introduce execution paths, tool use, and decision points that must be governed, traced, and audited like high-risk identity-bearing systems.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read HoneyHive's analysis of observability for AI agents and execution traces

Context

AI observability is now a governance problem as much as an engineering one. Traditional logs, metrics, and traces were built for deterministic services, but agentic systems combine model reasoning, tool calls, nested state, and unstructured inputs in ways that make post-incident reconstruction much harder. That is why primary keyword AI observability needs to be understood as an execution-control issue, not just a telemetry challenge.

The article's core claim is that AI agents need a hybrid observability model: distributed tracing for the execution path, schema flexibility for rapidly changing interaction formats, and enrichment for semantic failures such as hallucinations or incorrect reasoning. That intersection matters to IAM, NHI, and agentic AI security because the same runtime path that explains behaviour also exposes where identities, secrets, and delegated tool access must be controlled.

HoneyHive's starting position is typical of teams building production AI systems today. The real gap is not whether they can store logs, but whether they can explain and govern a multi-step agent decision chain fast enough to trust it in production.

Key questions

Q: How should security teams govern AI models that can call tools and access data?

A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization. The critical shift is to treat every tool call, data read, and update path as a privileged action that can be logged, revalidated, and revoked. Without that discipline, model risk becomes identity risk.

Q: Why do AI agents make observability and incident response harder than traditional applications?

A: Agents can change their plan, retrieved context, and tool arguments on each run, so two similar traces may lead to very different outcomes. That means teams need evidence of intent, memory state, policy, and downstream effects, not just logs and metrics. Without those layers, investigators can see symptoms but not causality.

Q: How do teams know if AI observability is actually working?

A: It is working when teams can show which change caused a quality shift, which dataset surfaced the issue, and whether the regression was contained before users were affected. If the team cannot trace behaviour across versions, observability is producing logs, not governance evidence.

Q: How do organisations reduce risk when agent schemas and workflows keep changing?

A: Use a flexible event model that captures raw data first and enriches it later. This preserves nested tool arguments, long context windows, and multimodal payloads without forcing early decisions about structure. It also prevents telemetry from becoming stale every time the agent architecture changes.

Technical breakdown

Why distributed tracing is the baseline for AI agents

AI agents rarely complete work in a single request-response cycle. They often chain model calls, retrieval steps, tool invocations, retries, and state updates across services. That creates an execution graph, not a simple transaction. Traditional observability breaks when it cannot correlate those steps into one trajectory. Distributed tracing gives each hop a shared context so teams can reconstruct how the system reached a result, where latency accumulated, and where delegation or tool use changed the outcome.

Practical implication: instrument every agent hop with trace context before you allow the system to operate on live data.

Why schema flexibility matters more as prompts become workflows

Agent telemetry is not just more data. It is structurally different data. A single interaction can contain nested tool arguments, large context windows, multimodal inputs, and variable metadata across calls. Fixed schemas force teams to choose what to keep before they understand what matters, which slows debugging and blocks new use cases. Schema-flexible storage lets organisations preserve the full record of execution and then shape it for analysis later, rather than losing detail at ingest time.

Practical implication: avoid rigid event models that discard nested agent context before enrichment and investigation.

Unstructured enrichment is what makes AI failure visible

AI systems fail in ways that code-centric observability does not capture well. Hallucinations, unsafe refusals, prompt drift, and reasoning errors are semantic failures, not syntax failures. An enrichment layer converts raw interaction data into usable signals such as response quality, tone, or policy deviation. That is the bridge between runtime telemetry and evaluation-driven development, because it allows teams to measure behaviour against expected outcomes instead of only checking whether the service returned successfully.

Practical implication: add enrichment rules for semantic failure classes so evaluation can run against live production traces.

NHI Mgmt Group analysis

AI observability is now part of identity and access governance for agents. Once an AI system can call tools, retrieve data, or delegate work, its traces become evidence of privilege use. That makes observability adjacent to NHI governance because the same runtime record must show who or what the agent was allowed to act as, what it touched, and whether that access stayed within policy. For identity teams, traceability is no longer separate from authorisation.

Schema rigidity is a control failure when AI systems evolve weekly. Agentic applications change faster than most telemetry pipelines do, especially when prompt formats, tool chains, and response structures are still in flux. A fixed event schema turns observability into partial memory. The named concept here is agent execution opacity, meaning the gap between what the system did and what the team can still reconstruct. Practitioner conclusion: retention without reconstructability is not governance.

Semantic failure detection must sit alongside infrastructure monitoring. CPU and latency metrics will not tell you whether an agent hallucinated, misrouted a tool call, or produced a policy-violating answer. That is why AI observability needs evaluation signals as well as system signals. In governance terms, this aligns more closely with NIST AI Risk Management Framework thinking than with classic uptime monitoring alone. Practitioner conclusion: measure behaviour quality, not just service health.

Agentic AI expands the attack and abuse surface even when the code is stable. The model may be unchanged while prompts, tools, context, and external data sources introduce new failure modes. That means runtime governance has to track execution path, delegated action, and response validation together. For security architects, the important shift is that observability becomes a prerequisite for control evidence, not just troubleshooting.

Production AI programmes will be judged on how quickly they can explain failure. The organisations that can correlate traces, inputs, and semantic outcomes will move faster on safe deployment, because they can distinguish model weakness from orchestration weakness. The governance lesson is simple: if you cannot explain an agent's path, you cannot credibly approve its use in high-risk workflows.

What this signals

AI observability is becoming an operational dependency for any programme that plans to run agents in production. The next control discussion will not be about whether the system can produce traces, but whether those traces are sufficiently rich to prove safe tool use, delegated access, and policy compliance. For teams already managing NHIs, that same evidence model will increasingly be expected for agents that behave like dynamic machine identities.

Agent execution opacity: this is the governance gap that appears when teams can see uptime but cannot reconstruct behaviour. As agentic systems proliferate, the control question shifts from log collection to explainability under pressure. Teams should expect observability requirements to converge with access review, secrets governance, and incident response workflows.

The practical signal for security leaders is that evaluation and observability are converging into one control plane. If the agent path cannot be traced, enriched, and scored in near real time, then approval decisions for higher-risk workflows should remain constrained. That is the same logic behind stronger governance for machine identity and delegated automation, including the controls discussed in the OWASP Agentic AI Top 10.

For practitioners

• Trace every agent action end to end Instrument prompts, retrieval, tool calls, model outputs, and state updates with shared trace context so investigators can rebuild the full execution chain.
• Preserve nested agent data before normalising it Store raw structured and unstructured payloads at ingestion time, then enrich later, so changing schemas do not erase evidence needed for debugging and governance.
• Define semantic failure classes up front Create labels for hallucination, tool misuse, policy deviation, and unsafe response patterns so evaluation rules can run consistently across production traffic.
• Tie agent telemetry to delegated access reviews Map every tool, dataset, and action boundary back to the identity or service account that authorised it, then review those grants against actual runtime behaviour.

Key takeaways

• AI observability for agents is less about dashboards and more about reconstructing decisions across tools, models, and state.
• The main failure mode is not missing logs, but losing the ability to explain semantic behaviour after the fact.
• Teams that want to trust AI agents in production need traceability, enrichment, and evaluation as part of governance.

Key terms

• Agent Execution Graph: The full chain of steps an AI agent takes from input to output, including model calls, retrieval, tool use, retries, and state updates. It matters because the security and governance record depends on reconstructing behaviour across multiple runtime actions, not a single transaction.
• Enrichment Layer: The data layer that adds context to raw vulnerability findings, such as severity, exploitability, asset mapping, and prioritisation hints. If this layer fails, downstream scanners and workflows may still function technically while making poorer decisions.
• Agent Execution Opacity: The gap between what an AI agent actually did and what the organisation can still reconstruct after the fact. It grows when schemas are rigid, traces are incomplete, or context is discarded before enrichment, leaving teams unable to explain decisions or prove control effectiveness.

What's in the full article

HoneyHive's full article covers the technical implementation detail this post intentionally leaves for the source:

• The ClickHouse schema choices used to separate heavy and light fields for faster query performance.
• The OpenTelemetry ingestion path for mapping spans into the observability data model.
• The write-time and read-time aggregation pattern used to support real-time analysis at scale.
• The enrichment workflow for semantic evaluation signals such as hallucination detection and response quality.

👉 HoneyHive's full article covers the architecture choices, schema design, and enrichment workflow in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security practitioners a common foundation for governing delegated access across modern identity programmes.