AI agent telemetry mapped to OCSF closes an observability gap

At a glance

What this is: This analysis shows how AI agent telemetry from Claude Code and Codex can be mapped into OCSF so security teams can investigate actions, denials, and outcomes in a standard event model.

Why it matters: It matters because AI agents can execute with user access and touch files, tools, and internal services, which creates an identity and audit problem for IAM, SOC, and governance teams.

👉 Read TENZIR's analysis of AI agent telemetry mapped to OCSF

Context

AI agent observability starts with a governance problem, not a parsing problem: if a tool-using system can launch commands, edit files, and touch internal services with user permissions, security teams need consistent evidence of what happened. In this article, the primary challenge is turning harness-specific telemetry into a form that can be investigated, correlated, and retained without losing the agent and session context.

The identity angle is real here because the agent is effectively operating under delegated access, even if it is not a human identity. That makes the boundary between user approval, agent action, and security control especially important for IAM, PAM, and SOC workflows. The article's starting point is typical for teams trying to operationalise AI telemetry across multiple harnesses and security stacks.

Key questions

Q: How should security teams investigate AI agent actions across different coding tools?

A: They should normalise tool telemetry into a shared security schema, preserve session IDs and action outcomes, and query the resulting records in the same workflows they use for other security events. That approach lets analysts compare behaviour across agents without writing separate logic for each harness.

Q: Why do AI agents create a governance problem for IAM teams?

A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access. If their actions are logged only as application activity, teams lose accountability, context, and revocation clarity. IAM must therefore extend to agent identity, delegated authority, and control-plane audit trails.

Q: What breaks when agent telemetry is not tied to a session identity?

A: Investigations lose the ability to connect a command, its approval source, and its result. Without session identity, the same action can look like isolated noise, which weakens detection fidelity, accountability, and post-incident reconstruction.

Q: Should organisations store raw agent prompts in security logs?

A: Only when privacy controls, retention policy, and access governance support that choice. Prompt text can be useful for investigations, but it should be minimised or redacted when the content is not needed, because observability data can easily become sensitive itself.

Technical breakdown

Why AI agent telemetry needs normalisation into security events

Claude Code and Codex expose actions in different telemetry formats, but investigators need stable fields that describe the operation, outcome, and context. Normalisation maps harness-specific records into OCSF so a command launch, denial, or result can be searched like any other security event. That matters because detections and investigations depend on consistent semantics, not raw tool output. In practice, the key design choice is whether the agent event is represented as a process, API, or control event, because that determines how well it joins with SIEM content and response workflows.

Practical implication: map agent telemetry to a standard event model before it reaches the SIEM or security lake.

How OCSF preserves agent identity, session context, and command lineage

The article uses OCSF profile fields to retain ai_agent.name, ai_agent.instance_uid, and process.uid so an analyst can tie a launch, result, and prompt back to a specific session. That linkage matters because the action alone is not enough. Without session correlation, a denied command or successful process run becomes isolated noise instead of reconstructable evidence. The article also shows why preserving user prompts and tool-call IDs in mapped fields is valuable when privacy controls allow it: it keeps the investigation coherent without forcing analysts to parse harness-specific JSON.

Practical implication: preserve session identifiers and command IDs so agent actions remain traceable across approval, execution, and investigation.

Why agent approvals and sandbox denials are security control signals

The article distinguishes between human approval, configuration-based approval, automated review, and sandbox denial. Those are not just workflow states. They are control signals that show whether a command was authorised, blocked, or constrained after approval. For security teams, that means telemetry needs to capture both the decision source and the final outcome, because an approved action can still be denied by runtime controls. This is where AI observability meets governance: the same operation may reflect policy, user intent, and environment enforcement all at once.

Practical implication: record both the approval source and the runtime outcome so control failures do not disappear into a single yes or no field.

Threat narrative

Attacker objective: The objective is to make agent-driven actions harder to distinguish from legitimate user activity, reducing visibility and increasing the chance of unsafe command execution.

1. Entry begins when an agent receives instructions that may be redirected by unvetted content, or when a user grants access for a tool action that the agent can execute with their permissions.
2. Escalation occurs when the agent uses approved tooling to run commands, edit files, or interact with services in ways that exceed the user's original intent.
3. Impact is the creation of potentially risky code execution, tool misuse, or investigation blind spots unless the telemetry is normalised and retained with session context.

NHI Mgmt Group analysis

Agent telemetry has become an identity governance problem as much as a detection problem. Once a coding agent can launch commands with user permissions, the core question is no longer just what ran. It becomes who authorised it, which session it belonged to, and whether the action stayed within delegated scope. That is why standardised event models matter: they let IAM, PAM, and SOC teams reason about agent actions as governed access events rather than opaque tool output.

Delegated access without stable lineage creates a traceability gap for AI operations. The article's OCSF mapping shows that session IDs, command IDs, and decision sources are the minimum viable evidence for reconstructing agent behaviour. Without that lineage, an organisation cannot cleanly separate human intent, automated approval, and runtime enforcement. For NHI governance, this looks like a nascent form of machine identity auditability, and the implication is clear: the audit trail must follow the session, not the model prompt alone.

Process Activity is the right abstraction when an agent launches a shell command, but only if the surrounding context survives the mapping. The distinction between a process event and a script event is more than taxonomy. It determines whether downstream detections can inspect cmd_line, correlate a launch with a termination, and join the activity back to the ai_agent instance. Practitioners should treat event-class accuracy as a governance control, because the wrong abstraction weakens both detection fidelity and accountability.

AI observability will converge with security operations only when privacy and redaction are built into the pipeline. The article correctly notes that prompt text and other sensitive content may be retained only under appropriate controls. That means observability programmes need data minimisation, redaction, and retention policy decisions alongside telemetry engineering. The named concept here is agent action lineage: the ability to tie a tool action to a specific session, approval source, and outcome without losing context. Teams that cannot preserve that lineage will struggle to govern agent risk at scale.

Existing control frameworks can absorb agent events, but only if teams are deliberate about the control semantics. OCSF gives the structure, while OCSF Security Control profile fields preserve the decision source and disposition. That makes the integration valuable for security operations, but it also raises the governance bar: teams must define what counts as approved, blocked, or policy-driven activity before they operationalise the feed. The practitioner conclusion is to standardise meaning first, then automate response.

What this signals

Agent action lineage: as AI coding tools become normal in development workflows, the practical security question will shift from whether an action was approved to whether the organisation can reconstruct the full chain of delegation, execution, and outcome. That is an IAM and SOC convergence problem, not just a logging problem.

Security teams should expect more pressure to treat AI agents as governed entities inside operational telemetry. The organisations that succeed will be the ones that can join session context, approval source, and runtime evidence before those events are routed to the SIEM or security lake.

For practitioners

• Standardise agent events before SIEM ingestion Map harness telemetry into a common security schema such as OCSF before routing it to the SIEM or security lake. Keep the agent name, session identifier, action, and outcome in fields that analysts can query consistently across tools.
• Preserve session lineage across approvals and results Retain ai_agent.instance_uid, process.uid, and the approval source so a launch, denial, and termination can be correlated without decoding vendor-specific payloads.
• Apply privacy controls to prompt and context fields Redact sensitive prompt text, command arguments, and other content before long-term storage unless your retention policy explicitly allows it for investigations.
• Separate authorisation from runtime enforcement Treat human approval, configuration approval, automated review, and sandbox denial as distinct control states so you can see where policy allowed an action and where execution was still blocked.
• Build detections around agent process activity Use process.cmd_line, process.uid, and termination status to detect risky shell usage, unusual command sequences, and repeated denials in agent sessions.

Key takeaways

• AI coding agents create a governance gap when their actions are not normalised into a shared security schema.
• Session context, approval source, and command lineage are the minimum evidence needed to investigate delegated agent activity.
• Teams should treat agent telemetry as a control plane for observability, accountability, and privacy at the same time.

Key terms

• Agent Action Lineage: The trace that connects an AI agent's session, approval source, tool invocation, and resulting outcome. It is the minimum evidence needed to explain what the agent did and whether the behaviour stayed within delegated access and policy boundaries.
• OCSF Normalisation: The process of translating different security events into a common schema so they can be searched and correlated consistently. For AI agents, this helps posture, detection, and response data sit beside cloud and identity telemetry instead of remaining isolated in a separate product view.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• 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.

What's in the full article

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

• The exact OCSF field mappings used to convert Claude Code and Codex telemetry into Process Activity and API Activity records
• The ClickHouse query examples for finding denied actions, command results, and prompt context across sessions
• The handling of unmapped fields such as tool_call IDs and duration values when source telemetry has no direct OCSF equivalent
• The raw event examples for configuration approvals, user approvals, automated reviewers, and sandbox denials

👉 The full TENZIR article shows the mappings, raw examples, and query patterns in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps security and identity practitioners build the governance foundations needed for delegated access and agent oversight.