Skip to main content
Your security team already runs a SIEM. LangWatch governance events (per-user spend, per-source activity, anomaly alerts) belong in that SIEM alongside your other audit feeds — not in a separate tab they only check after an incident. The OCSF (Open Cybersecurity Schema Framework) v1.1 read API gives your SIEM a cursor-paginated source it can pull on a cron schedule. Six platforms supported as cron-pull targets out of the box (any platform with a generic JSON pull adapter works the same way).

Wire shape

The tRPC procedure api.governance.ocsfExport:
OCSF event shape (per the v1.1 spec):

Authentication

Auth is scoped to org admin or auditor role. Both roles map to project-membership of the hidden Governance Project; customer-visible project members do NOT inherit OCSF read access. Use either:
  • Personal access token (PAT) — for org admins running ad-hoc pulls
  • Bearer access token from langwatch login --device — for SIEM cron-pull integrations (the recommended path)
Each pull cycle:
  1. Read your SIEM’s last successful cursor from local state (sinceMs)
  2. Call api.governance.ocsfExport({organizationId, sinceMs, limit: 1000})
  3. Forward events[] into your SIEM’s ingest pipeline (Splunk HEC, Datadog Logs API, etc.)
  4. Persist nextCursor for the next cycle
  5. If nextCursor came back non-null, the result was a full page — schedule another pull immediately to drain the backlog. Otherwise wait the cron interval (typically 5-15 minutes).

Supported SIEM platforms

Other SIEM platforms with generic JSON-pull integrations (CrowdStrike NG-SIEM, Securonix, Exabeam, etc.) follow the same pattern.

What’s in scope vs deferred

In this PR:
  • ✅ Cursor-paginated read API (api.governance.ocsfExport tRPC procedure)
  • ✅ OCSF v1.1 shape (Actor / Action / Target / Time / Severity / Event ID)
  • ✅ Org-tenancy isolation (cross-org reads return 404)
  • ✅ Auth-scoped to org admin + auditor role
  • ✅ Empty-state safe (returns {events: [], nextCursor: null} for orgs with no governance ingest yet)
  • ✅ Anomaly alerts surface with elevated severity (severity = 5 when anomaly_alert_id is non-null)
Named follow-ups:
  • Heavyweight SIEM push infrastructure (per-org SIEM push UI, DLQ + replay, managed Splunk/Datadog HEC integrations) — the OCSF read API + lightweight cursor-pull cron pattern covers the common case; rich push integrations land per-customer when sales pipeline justifies them
  • OCSF schema versioning — v1.1 cooked into the fold today; v1.2 is in draft. When v1.2 lands the fold gets an OcsfSchemaVersion column for graceful upgrade
  • Cryptographic signing of exported rows — deferred to the tamper-evidence follow-up; see Compliance architecture / Tamper-evidence

Data shape per source type

OCSF events are derived from recorded_spans + log_records via the governance_ocsf_events fold projection. The mapping per origin source-type: When a source’s expected fields are missing, the OCSF mapping falls back gracefully (Action → unknown, Target → unknown, Actor → system). The fold logs a warning so operators can fix the source’s wire shape.

Example: Splunk pull worker (pseudocode)

Replace the splunk_hec_send shim with your SIEM’s appropriate HTTP-pull or ingest API. The OCSF event shape is identical regardless of destination.

Cross-references

  • Compliance architecture — how the unified substrate underwrites SOC 2 / ISO 27001 / EU AI Act / GDPR / HIPAA-most-uses
  • Per-origin retentionthirty_days / one_year / seven_years retention classes; OCSF events are subject to the same retention as their source spans
  • Anomaly rules — how AnomalyAlerts propagate into OCSF events with elevated severity
  • Trace vs governance ingestion — picking the right OTel URL for your scenario