Wiki · Concept · Last reviewed July 10, 2026

Open Cybersecurity Schema Framework

Open Cybersecurity Schema Framework, or OCSF, is an open schema framework for normalizing cybersecurity event logs so tools and analysts can reason over common event classes, attributes, and taxonomy.

Category: Concept Published: July 10, 2026 Modified: July 10, 2026 Last reviewed: July 10, 2026 Tags: OCSF, cybersecurity schema, telemetry, AI agents, audit trails

Definition

OCSF is an open-source project for cybersecurity event logging and data normalization. The project site describes it as an extensible framework plus a vendor-agnostic core security schema. The schema repository calls it an open standard for event logging and normalization, made from categories, event classes, data types, and an attribute dictionary.

The point is not to replace every SIEM, endpoint tool, cloud log, or detection platform. The point is to give producers, mappers, data engineers, analysts, and storage systems a common language for events that would otherwise arrive as incompatible vendor logs. OCSF is agnostic to storage format, data collection, and ETL process; the framework definitions and normative schema are written as JSON.

For AI governance, OCSF is evidence infrastructure. When an agent reads a secret, calls a tool, changes a cloud role, queries a database, downloads a file, or triggers remediation, investigators need normalized records that survive product boundaries.

Taxonomy

The OCSF taxonomy includes data types, attributes, arrays, event classes, categories, profiles, and extensions. Event classes describe the semantics of a kind of event. Categories group event classes by domain. Profiles can overlay additional attributes across classes. Extensions allow schema growth without modifying the core schema.

The current schema category file names eight categories: System Activity, Findings, Identity & Access Management, Network Activity, Discovery, Application Activity, Remediation, and Unmanned Systems. The base event defines common fields used across event classes, including required classification attributes such as activity_id, category_uid, class_uid, severity_id, time, and type_uid, plus required metadata.

The metadata object is where pipeline accountability becomes visible. Its required fields include product and version. It also supports fields for correlation identifiers, original event identifiers, log source, log provider, logged time, processed time, ordered logger hops, tenant ID, source, labels, tags, truncation, and transformation information.

AI Agent Context

Agent security produces many ordinary-looking cybersecurity events: authentication, authorization, API calls, file activity, process activity, network flows, findings, and remediation actions. The unusual part is attribution. The same event may involve a human user, an AI agent, a tool runtime, a model provider, a service account, and a delegated authorization chain.

OCSF should therefore sit near AI Agent Observability, AI Audit Trails, AI Agent Identity, and AI in Cybersecurity. Observability shows run behavior. Audit trails preserve accountability. Identity says who or what acted. OCSF can normalize the security event record that those layers feed into.

The main-branch changelog is moving toward AI-shaped telemetry: its unreleased section lists an ai_agent object, an ai_operation profile, agent-hosting attributes, and prompt and response text attributes. Treat those entries as active schema work, not a stable deployed guarantee.

Evidence Record

A governance-grade OCSF record for an agent incident should identify the schema version, event class, event time, outcome, source product, original event ID, correlation ID, tenant, actor, account, agent or tool identity, touched resource, authorization path, raw record reference, processing timestamps, and transformation metadata.

The review question is whether the normalized record can answer contested questions: which agent initiated the action, which account granted authority, which tool or runtime executed it, which resource changed, which log source observed it, whether the event was translated, and which raw evidence remains available for dispute.

Limits

OCSF is not a detection engine, SIEM, access-control system, forensic guarantee, privacy review, or proof that an event was mapped correctly. A normalized event can still be incomplete, late, overbroad, duplicated, mistranslated, or stripped of context. The schema can make fields comparable; it cannot make the underlying logs honest.

Normalization also has surveillance risk. A clean cross-vendor schema can make it easier to correlate worker behavior, agent behavior, user identity, cloud activity, and content handling at large scale. Sensitive fields need minimization, access control, retention rules, redaction, and incident-specific disclosure limits.

Current Status

The public OCSF schema browser lists released schema versions through v1.8.0 and also lists v1.9.0-dev. The main repository's version.json reports 1.9.0-dev. OCSF says it became a Linux Foundation project on November 19, 2024, and the project is licensed under Apache License 2.0.

Source Discipline

Claims about OCSF should cite the project site, schema browser, schema repository, version file, taxonomy files, and specific event or object definitions. Product claims should name the mapper, schema version, event class, storage format, and validation path.

Spiralist Reading

Spiralism reads OCSF as a grammar for institutional memory under attack.

When machine actors multiply, one vendor console is not enough. Common names for actions, resources, identities, outcomes, timestamps, and evidence lineage let another tool, team, or audit inspect what happened.

Sources

Return to Wiki