Agent telemetry in OpenTelemetry gives security teams usable evidence

At a glance

What this is: This is an analysis of how agent telemetry becomes security evidence when OpenTelemetry export is enabled, and the key finding is that harnesses already expose approval, command, and tool-use records.

Why it matters: It matters because identity, privilege, and approval decisions around AI agents are only governable if security teams can see which actions were allowed, by whom, and under what session context.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read TENZIR's analysis of agent telemetry, approvals, and OpenTelemetry export

Context

Agent telemetry is the operational record of what an AI system did, what it asked permission for, and what was approved or denied. In this case, the issue is not whether agents generate useful data. They already do. The governance problem is that those records are often trapped in harness-specific session files unless teams deliberately export them into a security pipeline.

That creates a direct identity and privilege angle for AI operations. Tool approvals, sandbox outcomes, and command-level activity are effectively control events for an AI system acting through human-granted access. For IAM and PAM teams, the practical question is whether those events can be tied back to identity, authorisation, and audit requirements in a way that survives across multiple harnesses and agent runtimes.

Key questions

Q: How should security teams decide what telemetry to collect in AI-driven environments?

A: They should collect telemetry based on the security, detection, and compliance decisions the data must support, not on source availability alone. That means defining required fields, retention needs, and enrichment points for each use case. If the data cannot support a specific action, it should not be ingested by default.

Q: Why does PQC planning matter to IAM and PAM teams?

A: Because authentication, privileged access, and workload trust all depend on cryptographic primitives that may need post-quantum replacement. IAM and PAM teams own many of the systems that will break first if trust assumptions are not mapped early. PQC is therefore an identity architecture issue, not only a cryptography issue.

Q: What breaks when agent telemetry stays only on the local machine?

A: Security teams lose the approval trail, the command context, and the ability to correlate actions across a session. Without export, the agent may still run commands and call tools, but defenders cannot reconstruct who permitted what or whether the action ever reached the collector. That creates an audit gap, not just an observability gap.

Q: Should organisations prioritise agent telemetry export before expanding agent permissions?

A: Yes. If the organisation cannot see what an agent did, widening its authority only increases risk. Export and retention should come before broad permissions because the first control question is visibility, then scope. Once those records exist, teams can decide whether approval modes, prompt retention, or command logging need tighter limits.

Technical breakdown

How agent telemetry is split between session files and OpenTelemetry

Agent harnesses typically produce two telemetry streams. One stays local in session files, which can hold detailed transcripts, reasoning traces, command output, and file activity. The other is exported through OpenTelemetry, usually as spans, logs, and metrics. The security value differs sharply: local transcript data is rich but hard to operationalise, while OTLP export is easier to collect, normalise, and join with SIEM or data pipelines. The key point is that the same action can appear in multiple records, but with different levels of fidelity depending on harness settings and export defaults.

Practical implication: Treat OpenTelemetry export as the security-grade source and decide which local session artifacts, if any, need separate retention or redaction.

Why tool decisions matter more than raw prompts

For security teams, the most important records are often not the prompts themselves but the decisions around tool use. A tool approval tells you whether a human, a policy, or a sandbox allowed an action, while the corresponding tool result or sandbox outcome tells you what actually happened. In agentic environments, that distinction matters because permission is not the same as execution. The control signal is the approval trail, the operational signal is the command or tool output, and together they show how agent authority was exercised in practice.

Practical implication: Correlate approval events with tool results so you can prove who authorised sensitive agent actions and whether they completed.

Why MCP and model APIs only show part of the picture

The article makes a useful architectural distinction: model APIs see model traffic, and MCP servers see only the tool calls they serve. Neither layer sees the full session on its own. That means local shell commands, file edits, approvals, and harness-level decisions can be invisible if teams rely only on upstream service logs. This is the same problem security teams face whenever a workflow is distributed across multiple control planes. Visibility improves only when telemetry is preserved across the harness, transport, and service boundary.

Practical implication: Use the harness as the primary control point and enrich it with upstream model and MCP logs rather than assuming either source is complete.

Threat narrative

Attacker objective: The objective is to use agent activity and approval gaps to access, move, or disclose sensitive data without leaving a usable audit trail.

1. Entry occurs when an agent is granted access to run shell commands, edit files, or call third-party services inside a harnessed session.
2. Credential and approval abuse occurs when sensitive prompts, commands, or tool arguments carry secrets or when permissive approval modes allow risky actions without review.
3. Impact follows when those actions are not logged into a security pipeline, leaving security teams unable to reconstruct what the agent touched or why it was allowed.

NHI Mgmt Group analysis

Agent telemetry is becoming an identity control surface, not just an observability feed. Once an agent can request commands, file access, and external calls, every approval event becomes part of the identity story for that session. That shifts the problem from pure logging to governance of delegated action. In practice, security teams should treat approval records as evidence of authorisation, not just operational metadata.

OpenTelemetry export exposes the gap between agent behaviour and human oversight. The article shows that the most security-relevant data often exists, but in harness-specific stores that security teams do not automatically see. That means governance depends on export discipline, not just model or tool capability. The practitioner conclusion is simple: if the telemetry cannot reach the security stack, the control did not exist.

Agentic AI creates a new form of privilege sprawl that looks familiar to IAM but behaves differently. These sessions blend human approval, machine execution, and tool delegation in one workflow, which means conventional access reviews can miss the operational context of each action. The named concept here is approval-event visibility gap: the failure to connect an AI agent's permission decision to its executed action in a way auditors and defenders can actually use. Teams should close that gap before agent use scales further.

Harness-level telemetry should be aligned to NHI governance, because the agent is acting through non-human access paths. Even when a human starts the session, the security question is what the agent was allowed to do with machine-like authority. That makes NHI lifecycle thinking relevant to session-scoped agent controls, especially around approval, scope, and revocation. The field should stop treating agent output as a novelty and start treating it as governed delegated identity.

What this signals

Approval-event visibility gap: as agent usage expands, security teams will need to treat approval telemetry as a control artifact, not a debugging artifact. If those records are not ingested, correlated, and retained, the organisation loses the ability to explain why a sensitive command ran and whether it was properly authorised. That is especially relevant for programmes already struggling to see their non-human identity estate.

The operational signal is clear: teams that standardise on harness-level export, redaction, and correlation will be able to govern agent sessions more like privileged workloads. Teams that leave the data in local session stores will likely discover the gap only after an investigation. For identity programmes, the next step is to align agent telemetry with NHI lifecycle, privilege review, and audit workflows rather than treating it as a separate observability stream.

For practitioners

• Enable OTLP export across all agent harnesses Turn on telemetry export in every supported agent runtime and send it to your collector rather than leaving useful records only in local session files.
• Correlate approvals with command execution Join tool_decision, sandbox outcome, and tool_result events so investigators can see who allowed an action, what ran, and whether the sandbox blocked it.
• Redact or hash sensitive prompt content before ingestion Treat prompt text, command lines, URLs, and tool arguments as potentially sensitive and apply redaction or hashing in the pipeline before broader distribution.
• Retain upstream model and MCP logs as supporting evidence Keep model API and MCP server logs for correlation, but do not rely on them as complete session records because each sees only part of the workflow.

Key takeaways

• Agent telemetry only becomes defensible security evidence when approval, command, and tool-result records are exported and correlated.
• The largest risk is not missing data but missing visibility into who authorised an agent action and what the agent actually executed.
• AI agent governance should inherit NHI-style thinking about scope, approval, and revocation because these sessions behave like delegated machine access.

Key terms

• Agent telemetry: Operational data describing what an AI agent did, which tools it called, how much it consumed, and what resources it touched. Telemetry is essential for audit, incident response, and behavioural governance because agent decisions are otherwise difficult to reconstruct.
• Approval Event: An approval event is the point in an access workflow where a request has been authorised and can trigger follow-on action. In this context, it acts as the signal that starts provisioning, ticket creation, or another downstream process. It is the handoff between decision and execution.
• OpenTelemetry: An open standard for collecting and moving traces, metrics, and logs in a consistent format. It helps teams avoid re-instrumenting every system when tools change, and it supports cross-platform analysis by keeping telemetry structured and portable.
• Harness: The harness is the layer of instructions, policies, and approval logic wrapped around an AI agent. It is where organisations try to constrain behaviour, but it only works if the rules are explicit, current, and enforced outside the model itself.

What's in the full article

TENZIR's full article covers the operational detail this post intentionally leaves for the source:

• Exact Claude Code and Codex configuration examples for enabling OpenTelemetry export
• Field-by-field examples of tool decision, sandbox outcome, and tool result events
• Practical guidance on what remains in local session files versus what reaches the collector
• How to map agent telemetry into OCSF and adjacent security pipelines

👉 The full TENZIR article shows the event shapes, settings, and collection paths for Claude Code and Codex.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners building controlled access models. It helps security teams translate identity principles into operational governance for human, machine, and agentic workflows.