You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide a documented, tested mapping from ActionTrace (and the denial/expansion
records of ISSUE 7) to OCSF API Activity events as extended by the OWASP Agent
Observability Standard (AOS), plus a small exporter producing OCSF-shaped JSON.
Why this matters
Security teams consume agent activity through SIEMs, and OCSF is the cross-vendor
schema those pipelines speak. The planned OTel export (#125) serves the observability pipeline; OCSF/AOS serves the security operations pipeline — a
different consumer with different tooling. For a kernel whose differentiator is the
tamper-evident audit trail, "your agent audit events land in your SIEM in a standard
shape" is a high-credibility enterprise adoption story that costs only a mapping
module.
Current evidence
trace.pyActionTrace carries principal, capability, timestamps, outcome, error — the core fields OCSF API Activity (class 6003) expects.
otel.py exists for spans (extra-gated), establishing the exporter pattern to follow; no OCSF/SIEM-shaped output exists.
export/ocsf.py (or extend a future exporters package): pure function trace_to_ocsf(trace) -> dict with explicit field mapping table; no new
dependencies (plain dict construction).
Map: invoke success/failure → API Activity with agent extensions; denials
(ISSUE 7) → denied activity; include stable reason codes as enrichment.
Validate output against the published AOS/OCSF JSON schema in tests (vendored
schema fixture or schema-validation in a dev-only test).
Summary
Provide a documented, tested mapping from
ActionTrace(and the denial/expansionrecords of ISSUE 7) to OCSF API Activity events as extended by the OWASP Agent
Observability Standard (AOS), plus a small exporter producing OCSF-shaped JSON.
Why this matters
Security teams consume agent activity through SIEMs, and OCSF is the cross-vendor
schema those pipelines speak. The planned OTel export (#125) serves the
observability pipeline; OCSF/AOS serves the security operations pipeline — a
different consumer with different tooling. For a kernel whose differentiator is the
tamper-evident audit trail, "your agent audit events land in your SIEM in a standard
shape" is a high-credibility enterprise adoption story that costs only a mapping
module.
Current evidence
trace.pyActionTracecarries principal, capability, timestamps, outcome, error — the core fields OCSF API Activity (class 6003) expects.otel.pyexists for spans (extra-gated), establishing the exporter pattern to follow; no OCSF/SIEM-shaped output exists.External context
Proposed implementation
export/ocsf.py(or extend a future exporters package): pure functiontrace_to_ocsf(trace) -> dictwith explicit field mapping table; no newdependencies (plain dict construction).
(ISSUE 7) → denied activity; include stable reason codes as enrichment.
schema fixture or schema-validation in a dev-only test).
AI-agent execution notes
trace.py,otel.py(pattern),policy_reasons.py, AOS spec pages.Acceptance criteria
Test plan
Schema-validation tests over representative traces; golden-file mapping tests.
Run
make ci.Documentation plan
New
docs/integrations.mdSIEM/OCSF section with the mapping table; CHANGELOGAdded; cross-reference #125/#127.Migration and compatibility notes
Additive; not expected to require migration.
Risks and tradeoffs
AOS is young — version the mapping and isolate it in one module so spec movement is
contained. Low maintenance otherwise.
Suggested labels
ecosystem, security, integrations, reliability