Notifications
Clear all
Topic starter
14/09/2026 10:10 am
TL;DR: Claude Code and Codex telemetry can be normalized into OCSF security events so teams can query agent actions, denials, and outcomes alongside existing security data, according to TENZIR. The bigger issue is governance: if agents can act with user access, security teams need consistent records, privacy controls, and session context to make those actions auditable.
NHIMG editorial — based on content published by TENZIR: AI agent telemetry mapped to OCSF for security investigation
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
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
👉 Read TENZIR's analysis of AI agent telemetry mapped to OCSF →
AI agent telemetry and OCSF mapping: what security teams should know?
Explore further
14/09/2026 10:11 am
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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent telemetry mapped to OCSF closes an observability gap
