AI agent telemetry mapped to OCSF closes an observability gap

At a glance

What this is: NHI Mgmt Group's analysis, drawing on TENZIR's blog post: Mapping AI coding agent telemetry into OCSF events lets actions, denials and results be queried alongside other security data.

Why it matters: This matters because security teams cannot govern agent activity they cannot consistently observe, especially when agents act with a user’s access and touch files, prompts, and internal services.

Context

AI agent observability is not just a logging problem. When a coding agent can run commands, edit files, and respond to prompts inside a user session, the security team needs a normalized record of what happened, who approved it, and what the result was. Without that, investigations stay trapped in harness-specific formats and the governance gap remains.

In this article, the practical issue is telemetry translation: raw agent events are useful only if they can be mapped into security events that existing detections and investigators already understand. The identity angle is real because the agent operates with a user’s access and session context, which means governance must cover both the action and the authority behind it.

Key questions

Q: How should security teams handle AI agent telemetry that is recorded in different harness formats?

A: Security teams should normalize agent telemetry into a shared security event model before relying on it for detection or investigation. The point is to preserve the action, approval, result, and session context in fields that downstream tools can query consistently. Without that mapping, teams end up building separate analytics for each agent harness and lose cross-tool visibility.

Q: Why does session context matter when investigating AI coding agent activity?

A: Session context ties a command or prompt to the specific agent instance that generated it, which is essential when agents act with user access. It lets investigators join approvals, results, and prompts into one sequence instead of treating each event as isolated noise. Without that linkage, the audit trail is too fragmented to support reliable reconstruction.

Q: What breaks when AI agent approvals and execution outcomes are logged separately?

A: What breaks is control attribution. A command may be approved, denied, blocked by a sandbox, or succeed after approval, and those outcomes are not interchangeable. If teams collapse them into one status, they cannot tell whether a policy prevented execution or whether the agent actually ran the command and produced a result.

Q: How should organisations decide whether AI agent telemetry belongs in the SIEM or security lake?

A: Place the normalized telemetry where security teams already investigate, but only after privacy controls and field mapping are in place. The right destination is less important than preserving queryable session context, command detail, and outcome state. If the data cannot support detections or investigations, storing it in a security platform adds noise rather than visibility.

Technical breakdown

Why OCSF mapping matters for AI agent telemetry

Agent harnesses emit decision and result records in formats that are useful to the tool, but not necessarily to the security stack. Mapping those records into OCSF gives them stable class, activity, and field semantics, which lets detections treat an agent-launched command like any other security event. In the article’s example, a Bash invocation becomes Process Activity because the system launched a process, not a script engine. That distinction matters because the class drives how downstream analytics interpret the event and how investigators search for it.

Practical implication: Model agent telemetry as security events at ingestion time so detections do not depend on tool-specific log parsing.

How session context turns agent actions into usable evidence

A raw command or prompt by itself is not enough to reconstruct behaviour. The article shows that ai_agent.name, ai_agent.instance_uid, process.uid, and message_context.prompt_text let teams connect a launch, a result, and the prompt that preceded it. That turns a one-off tool call into an auditable sequence. This is especially important for local agents, where the same harness may generate approvals, results, and prompts with different field names. The point is not merely retention. It is correlation across a single session so investigators can answer what ran, who authorized it, and what the agent was asked to do.

Practical implication: Preserve agent, session, and command identifiers together so investigators can join actions to prompts and outcomes.

Why approval and sandbox outcomes need separate security treatment

The article makes a useful distinction between human or configuration approval and execution outcome. A command can be approved and still fail in a sandbox, or be denied before execution. Those are not the same control state, and collapsing them would hide whether a policy block, human review, or runtime restriction stopped the action. OCSF’s Security Control profile is used here to preserve that difference. For governance, that means approval records should not be mistaken for execution success, and execution success should not be assumed just because a command was authorized.

Practical implication: Track approval, policy, and sandbox outcome separately so control effectiveness can be measured without ambiguity.

Threat narrative

Attacker objective: The objective is to trigger or redirect agent actions while leaving investigators with fragmented telemetry that is hard to correlate or audit.

1. Entry occurs when a coding agent receives a prompt or tool request inside a user session and can act with the user’s access.
2. Credential and context abuse follow when the agent can reach files, commands, and internal services that the user has not explicitly reviewed.
3. Impact appears when the agent runs risky commands or misdirected actions without a security record that lets analysts reconstruct what happened.

Breaches seen in the wild

• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

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 agent telemetry has to be governed as security evidence, not application noise. If a coding agent can run commands and change files, the telemetry is part of the control plane, not just the product log stream. OCSF mapping makes that evidence usable across SIEM, security lake, and investigation workflows. Practitioners should treat agent event normalization as a security architecture decision, not a logging preference.

Session context is the missing identity layer for many agent logs. The article shows why ai_agent.instance_uid, process.uid, and message_context.prompt_text matter: without them, you can see activity but not reliably bind it to a session or prompt chain. That is a classic governance gap for non-human activity, and it becomes sharper when the agent is acting with a user’s access. Practitioners should insist on session-bound records before they accept agent telemetry as auditable evidence.

AI observability is becoming a prerequisite for agent authorization. If teams cannot distinguish approved, denied, and sandbox-blocked actions, they cannot measure whether the controls are actually constraining the agent. This is where the identity and AI governance layers meet: authorization is incomplete without a durable record of what the agent attempted. Practitioners should align observability design with agent control policy, not bolt it on after deployment.

Tool-call normalization closes a specific governance blind spot: harness-specific logs that cannot be compared. The article’s named concept is the AI agent observability gap, and it is fundamentally a records problem. Different harnesses expose different fields, but security teams need a shared event model to investigate behaviour across tools and environments. Practitioners should standardize telemetry early so policy, detection, and response do not depend on one agent framework’s native schema.

Privacy controls are part of observability, not an afterthought. The article notes that prompt text and other content may need redaction before routing to security tooling. That is important because agent telemetry can expose user intent, internal data, or sensitive command context. Practitioners should build selective retention and redaction into the pipeline so auditability does not create an uncontrolled data exposure problem.

From our research library:

• 7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure, according to the 2026 Infrastructure Identity Survey.
• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

AI agent observability gap: the real problem is not whether agents produce logs, but whether those logs can be converted into security evidence that survives investigation. If a harness, a model, and a workflow each speak a different schema, the control point shifts from detection to normalization. Practitioners should design for correlation first and storage second.

Agent activity is becoming part of the identity problem because the system can act with a user’s access and still leave weakly bound telemetry behind. That is where agent governance intersects with IAM and NHI discipline: session identity, action identity, and approval identity all need to line up before the record is trustworthy.

Security teams should expect AI agent monitoring to behave more like endpoint and workload monitoring than a simple application audit stream. The practical test is whether a query can answer who acted, what ran, what was denied, and what prompt or session led there without decoding each harness separately.

For practitioners

• Normalize agent logs into a shared event model Map tool decisions, tool results, prompts, and session identifiers into a common schema so SIEM queries can work across different agent harnesses.
• Preserve session-bound identity context Retain ai_agent name, instance UID, and command identifiers together so investigators can reconstruct which agent performed which action in which session.
• Separate approval from execution outcome Record human approval, automated policy decisions, sandbox denials, and process success as distinct states so control effectiveness is measurable.
• Redact sensitive prompt and command content before storage Apply privacy controls before events reach long-term storage or downstream analytics, especially when prompt text can reveal internal instructions or sensitive context.
• Route normalized events into existing detections Feed Process Activity and AI Operation records into your current security rules so agent-launched commands are investigated with the same workflows as other endpoint or cloud events.

Key takeaways

• AI coding agents need normalized telemetry because raw harness logs are too inconsistent for security operations to query at scale.
• The most useful records bind action, approval, result, and session identity together so investigators can reconstruct what the agent actually did.
• Privacy controls and redaction belong inside the observability pipeline, because agent logs can expose prompts, commands, and internal context.

Key terms

• AI Agent Activity Telemetry: The event data that shows what an AI agent accessed, requested, changed, or exposed while running. This telemetry is important because it lets security teams compare machine behaviour with policy expectations and detect drift, misuse, or compromise.
• OCSF: The Open Cybersecurity Schema Framework is an open model for describing security events, findings, and objects in a common structure. It lets vendors map their telemetry into a shared language so downstream analytics, investigations, and automation can work across sources more consistently.
• Developer Session Identity: Developer session identity is the effective identity context created when a person, assistant, plugin, and repository all act together during software creation. In practice, it combines human permissions with machine actions, which means governance must account for delegated tool use, not just the developer’s login.
• Process Activity: An event model used to represent the start, continuation, or end of a process on a system. When AI agents launch shell commands, this class is often more accurate than script-oriented models because it preserves the executable context and command line.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps security and IAM practitioners turn emerging agent behaviour into governed identity controls.