Notifications
Clear all
Topic starter
14/09/2026 10:10 am
TL;DR: Agent harnesses for Claude Code and Codex already emit security-relevant telemetry such as tool calls, approvals, command output, and permission decisions, but most of it is only visible if OpenTelemetry export is enabled, according to TENZIR. The operational gap is not data absence but collection, normalization, and retention across local sessions, model APIs, and MCP paths.
NHIMG editorial — based on content published by TENZIR: agent telemetry, approvals, and OpenTelemetry export for Claude Code and Codex
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read TENZIR's analysis of agent telemetry, approvals, and OpenTelemetry export →
Agent telemetry in OpenTelemetry: what security teams should capture?
Explore further
14/09/2026 10:10 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Agent telemetry in OpenTelemetry gives security teams usable evidence
