Open Cybersecurity Schema Framework (OCSF)

OCSF is an open, vendor-neutral schema for security events, published by the OCSF project and licensed Apache 2.0. Events are JSON objects that belong to one class inside one category, built from shared objects and attributes, and optionally extended with profiles and extensions. With this skill the agent maps application audit logs to valid OCSF 1.9.0 events and validates them.

Follow the workflow below step by step. Every rule here comes from a source in Sources, with the section it cites. When a rule and the pinned source disagree, the source wins; when the source has a newer revision than the pin, follow the refresh steps.

Inputs (fill in, or ask before starting)

• Role: producer (an application emitting OCSF), mapper (converting existing logs), or consumer (querying or validating OCSF).
• Source events: the audit log entries to map, for example logins, permission grants, API calls, user and role changes.
• Revision: OCSF 1.9.0, the version https://schema.ocsf.io/api/version returns, unless the user names another. metadata.version carries this value.
• Sources: when refreshing this skill or when a rule looks out of date, re-read every URL in Sources first, call https://schema.ocsf.io/api/version and the GitHub releases page for a newer release, and update the pins.

Invariants

1. Every event has the required base attributes: activity_id, category_uid, class_uid, metadata, severity_id, time and type_uid (schema API, class definitions).
2. type_uid is computed. Producers and mappers compute it as class_uid * 100 + activity_id (schema API, type_uid attribute). The validator reports type_uid_incorrect otherwise.
3. metadata.version and metadata.product are always set. metadata.version is the OCSF schema version in SemVer; product needs at least one of name or uid (schema API, metadata and product objects).
4. Enums use 0 for Unknown and 99 for Other. When the _id is 99, the sibling string (for example activity_name or auth_protocol) carries the source value (white paper, enum conventions; schema API, activity_id).
5. Class-specific required attributes and constraints hold. For example, Authentication requires user and at least one of service or dst_endpoint; API Activity requires actor, api and src_endpoint (schema API, class definitions).
6. Do not use deprecated classes for new mappings. In 1.9.0, Account Change (3001) and User Access Management (3005) are deprecated in favour of User Management (3007) (schema API, 1.9.0 release notes).
7. time is the time the event occurred, as a timestamp_t in milliseconds since the epoch (schema API, time attribute and timestamp_t type). original_time, logged_time and processed_time record the other moments (white paper).
8. Source fields with no OCSF attribute go in unmapped, or better, in a registered extension (schema API, unmapped; white paper, extensions).
9. Applied profiles are listed in metadata.profiles, and their attributes then follow the profile's requirements (white paper, profiles).

Workflow

1. Inventory the source events. List each audit event type with its fields: who acted, on whom or what, outcome, time, source address and product. ✓ Every event type has a one-line description and a sample record.
2. Pick the category, class and activity. Map each event type to a 1.9.0 class and an activity_id, and prefer the non-deprecated class. -> references/classes.md ✓ Each event type has category_uid, class_uid, activity_id and a computed type_uid.
3. Fill the base and class attributes. Set the required attributes, then the recommended ones you have data for (status_id, status, message, actor, src_endpoint, session and others). -> references/attributes.md ✓ Required attributes and at_least_one constraints are satisfied for every class used.
4. Set metadata. Fill version, product, and where available uid, original_event_uid, correlation_uid, tenant_uid and log_name. -> references/attributes.md ✓ metadata.version is 1.9.0 and metadata.product.name or uid is set.
5. Decide on profiles and extensions. Apply a profile only when you fill its attributes; put leftover source fields in unmapped or an extension. -> references/profiles-extensions.md ✓ metadata.profiles lists every applied profile; no field is silently dropped.
6. Validate. Send each sample event to the schema server's validator, first plain and then with missing_recommended=true. -> references/validation.md ✓ error_count is 0 for every sample; remaining warnings are known and accepted.

Verify before done

• Every event validates with error_count: 0 at POST https://schema.ocsf.io/api/v2/validate.
• type_uid equals class_uid * 100 + activity_id in every event.
• metadata.version is the pinned OCSF version and metadata.product is set.
• No new mapping uses Account Change (3001) or User Access Management (3005).
• Enum values of 99 carry the matching string attribute.
• time is in milliseconds since the epoch.
• Personal data in message, unmapped and raw_data has been reviewed before the events leave the application.

Reference index

• references/classes.md: categories, the Identity & Access Management and Application Activity classes, activity IDs, deprecations in 1.9.0, and an audit-event-to-class mapping table. Load for step 2.
• references/attributes.md: required, recommended and optional base attributes, the enums for severity_id and status_id, and the metadata, product, user, actor and iam_role objects. Load for steps 3 and 4.
• references/profiles-extensions.md: the 1.9.0 profiles, how to apply them, extensions and their registry, and unmapped. Load for step 5.
• references/validation.md: the schema server API, the validator's response format and error codes, and four example events that validate against 1.9.0. Load for step 6.

Related skills

• cloudevents to carry OCSF events in a CloudEvents envelope: npx skills add ScaleDockHQ/scaledock-skills --skill cloudevents.
• opentelemetry-genai for the OpenTelemetry side of AI agent activity: npx skills add ScaleDockHQ/scaledock-skills --skill opentelemetry-genai.

Sources

Status uses the publishing body's own maturity term. Checked is the date the source was last read.

• OCSF Schema 1.9.0 release: Released, 1.9.0 (published 2026-08-03), checked 2026-10-02.
• OCSF schema server: current version: schema server API, 1.9.0, checked 2026-10-02.
• OCSF 1.9.0 categories: schema server API, 1.9.0, checked 2026-10-02.
• OCSF 1.9.0 Authentication class: schema server API, 1.9.0, checked 2026-10-02.
• OCSF 1.9.0 metadata object: schema server API, 1.9.0, checked 2026-10-02.
• OCSF 1.9.0 profiles: schema server API, 1.9.0, checked 2026-10-02.
• OCSF Schema API (OpenAPI): schema server API description, served alongside 1.9.0, checked 2026-10-02.
• Understanding the Open Cybersecurity Schema Framework: white paper, main branch, checked 2026-10-02.
• OCSF extensions registry: registry, main branch, checked 2026-10-02.