The Open Cybersecurity Schema Framework (OCSF) was designed to solve a fundamental problem: security data fragmentation. By offering an open and shared format, OCSF brought a shared foundational understanding of what security data should be understood, driving consistency. But every security engineer who has implemented OCSF mappings encounters the same structural challenge within weeks: the unmapped object.

This is where normalization efforts stall.

The Unmapped Object, Defined

OCSF aims to resolve fragmentation in security data by providing a shared taxonomy, including categories, event classes, and a standardized attribute dictionary, so that telemetry from disparate sources can be queried, correlated, and analyzed consistently. But this structure runs into challenges for complex and unexpected security data which does not fall neatly into the framework.

OCSF defines the unmapped object as a catch-all container for source data that doesn't map cleanly to standardized attributes. When an engineer translates a firewall log into OCSF format, fields like source IP become src_endpoint.ip, usernames normalize to actor.user.name, and timestamps align to time. These are the wins.

But source telemetry routinely contains fields that have no standard home in the schema. An MFA status indicator from an identity provider. A proprietary risk score from an EDR vendor. A vendor-specific context field that detection logic depends on. These fields don't disappear, they land in unmapped.

The unmapped object preserves data. Technically, nothing is lost. But it creates a different kind of fragmentation: structured, queryable fields alongside unstructured data that requires custom parsing for every downstream consumer. Detection engineers writing correlation rules cannot rely on unmapped content without building source-specific logic. Analysts hunting for threats must know which unmapped fields exist and how to extract them. AI systems attempting to reason across security data cannot process unmapped content without additional transformation.

The richer the source telemetry, the more content ends up unmapped. As one industry analysis observed: "Data is custom, the richer the data the more unmappable it gets. Don't be surprised if the analyst goes digging into un-normalized fields rather than common normalized fields, because that's where the piece of information they needed was buried."

This is the structural tension at the heart of OCSF adoption.

Three Causes of Mapping Gaps

Three factors drive the unmapped problem.

Schema variability at the source. Security tools emit logs in formats designed for their own ecosystems, not for interoperability. Proprietary field names, nested structures, and vendor-specific semantics mean that mapping requires deep understanding of both source format and target schema. When a vendor changes their log format, adding fields or restructuring existing ones, transformation rules break. Fields that were previously mapped may suddenly require rework. The maintenance burden compounds across hundreds of data sources.

Partial schema coverage. Some security tools don't provide enough data or context to fully populate OCSF's structured fields. Missing event class identifiers, absent process metadata, incomplete user objects, these gaps force engineers to choose between extending the schema, dropping fields, or accepting degraded normalization fidelity. None of these options are cost-free.

Field conflicts and ambiguities. Different tools use the same field name for different purposes, or represent the same concept with incompatible structures. A "status" field in one product might indicate connection state; in another, it represents authentication outcome. Resolving these conflicts requires judgment calls that must be documented, maintained, and applied consistently across all pipelines handling that source.

Organizations adopt OCSF expecting unified telemetry. What they often get is a mix of cleanly mapped fields and growing unmapped buckets that require custom handling for every query, detection rule, and investigation workflow. Organizations report spending two to four months on comprehensive OCSF implementations, and that timeline assumes stable source schemas, which rarely hold.

Three Governance Approaches

Security teams handle unmapped content in three primary ways, each with distinct trade-offs.

Strict minimum mapping. Map only the fields explicitly required by OCSF for the chosen event class. Everything else goes to unmapped. This approach preserves data completeness and avoids over-engineering the mapping layer, but it pushes complexity downstream. Detection engineers must write custom parsers for unmapped content. Analysts lose the ability to correlate on fields that could have been standardized. This approach works for organizations with simple detection requirements or limited cross-source correlation needs. It fails when unmapped fields contain the precise context needed for threat hunting or incident response.

Schema extension. OCSF supports extensions, formal mechanisms to add custom attributes to existing event classes without breaking compatibility. For fields that are critical and represent long-term requirements, creating an organization-specific extension with dedicated attributes is the most robust solution. Extension requires registration to receive a unique identifier range, preventing conflicts with the core schema or other organizations' extensions. The process enforces governance but demands ongoing maintenance: schema registries to track which extensions exist, what they contain, and which pipeline versions support them. This approach fits organizations with mature data engineering capabilities and stable telemetry requirements. It struggles when sources change frequently or when teams lack resources for extension lifecycle management.

Dynamic classification. Rather than pre-defining every mapping or manually extending schemas, this approach uses intelligent systems to classify and route data in real time. The pipeline learns source schemas, identifies semantic equivalents, and maps fields dynamically, elevating what would be unmapped into structured, queryable attributes without manual rule creation.

This is where the architectural gap exists in most OCSF implementations. Static mapping rules cannot adapt to schema drift. Manual extension processes cannot scale to hundreds of sources. Unmapped buckets grow into ungovernable data graveyards.

Normalization as a Pipeline Problem

The unmapped field problem is fundamentally a pipeline architecture problem. Normalization happens in transit, not at rest. Decisions about what maps where, what extends the schema, and what falls into catch-all containers must be made in flight, at the speed of telemetry ingestion.

Traditional approaches treat parsing, normalization, and transformation as static configurations. Engineers write mapping rules, deploy them, and hope sources don't change. When they do, and sources always change, brittle pipelines break. Fields that should be normalized end up unmapped. Detection coverage degrades silently. No one notices until an investigation fails or a compliance audit surfaces gaps.

This is where Databahn comes in. The platform approaches OCSF normalization as a continuous, AI-assisted process rather than a one-time configuration exercise.

Cruz, Databahn's agentic AI, builds an understanding of source schemas as they evolve. It automatically detects schema drift and adapts transformations without manual intervention. When a vendor adds a new field or restructures an existing one, the pipeline doesn't break, it learns. Fields that would traditionally fall into unmapped buckets are intelligently classified and routed to appropriate schema locations, or flagged for extension when no suitable mapping exists.

The platform maintains schema consistency across heterogeneous data models in-line, rather than post-ingestion. This means SIEM correlation rules and detection logic operate on unified, structured data, not a mix of normalized fields and unmapped JSON blobs that require custom handling. Analysts spend time on investigations, not digging through catch-all containers for buried context.

For enterprises already navigating OCSF adoption with Amazon Security Lake, Microsoft Sentinel, or Splunk, Databahn provides the transformation layer that turns partial mappings into comprehensive normalization.

Governance Practices That Reduce Drift

Regardless of the approach chosen, governance practices reduce unmapped field accumulation over time.

Document every mapping decision. When a field goes to unmapped, record why. When an extension is created, define its scope and intended consumers. Detection engineers, data engineers, and analysts need to understand how data flows through the schema. Ambiguity compounds across teams and time.

Establish feedback loops with downstream consumers. The teams writing detection rules, hunting for threats, and investigating incidents are the first to know when unmapped fields contain critical context. Their pain points should drive mapping priorities and extension decisions.

Monitor unmapped field growth. If the unmapped object is expanding faster than structured fields, something is wrong architecturally. Either sources are changing faster than mappings can adapt, or the mapping strategy is too conservative for the organization's detection requirements.

Pin analytics and detection content to specific OCSF versions. Schema evolution is inevitable. Content repositories that reference explicit versions prevent breaking changes from silently degrading detection coverage when the schema updates.

The Architectural Choice

OCSF adoption is not a checkbox exercise. It is an architectural decision with downstream implications for every detection rule, investigation workflow, and AI application built on security data.

The unmapped field problem reveals a fundamental tension: static schemas cannot keep pace with dynamic telemetry. Organizations face a choice. Continue retrofitting manual mappings onto evolving sources, accepting growing unmapped buckets as inevitable. Or invest in infrastructure that treats normalization as a continuous, intelligent process, governance that happens in flight, not after storage.

The future of security data normalization is not more catch-all containers. It is pipelines that understand schemas, adapt to drift, and ensure that critical context reaches analysts and AI systems in structured, queryable form.

Overall Incident Trends

• 16,200 AI-related security incidents in 2025 (49% increase YoY)

• ~3.3 incidents per day across 3,000 U.S. companies

• Finance and healthcare: 50%+ of all incidents

• Average breach cost: $4.8M (IBM 2025)

Source: Obsidian Security AI Security Report 2025

Critical CVEs (CVSS 8.0+)

CVE-2025-53773 - GitHub Copilot Remote Code Execution

CVSS Score: 9.6 (Critical) Vendor: GitHub/Microsoft Impact: Remote code execution on 100,000+ developer machines Attack Vector: Prompt injection via code comments triggering "YOLO mode" Disclosure: January 2025

References:

• NVD Database: https://nvd.nist.gov/vuln/detail/CVE-2025-53773

• Research Paper: https://www.mdpi.com/2078-2489/17/1/54

• Attack Mechanism: Code comments containing malicious prompts bypass safety guidelines

Detection: Monitor for unusual Copilot process behavior, code comment patterns with system-level commands

‍

CVE-2025-32711 - Microsoft 365 Copilot (EchoLeak)

CVSS Score: Not yet scored (likely High/Critical) Vendor: Microsoft Impact: Zero-click data exfiltration via crafted email Attack Vector: Indirect prompt injection bypassing XPIA classifier Disclosure: January 2025

References:

• NVD Database: https://nvd.nist.gov/vuln/detail/CVE-2025-32711

• Analysis: https://medium.com/@jcapriola/when-hacks-go-awry-the-rising-tide-of-ai-prompt-injection-attacks-78c293d1b1e4

• Attack Mechanism: Malicious prompts embedded in email body/attachments processed by Copilot

Detection: Monitor M365 Copilot API calls for unusual data access patterns, particularly after email processing

CVE-2025-68664 - LangChain Core (LangGrinch)

CVSS Score: Not yet scored Vendor: LangChain Impact: 847 million downloads affected, credential exfiltration Attack Vector: Serialization vulnerability + prompt injection Disclosure: January 2025

References:

• NVD Database: https://nvd.nist.gov/vuln/detail/CVE-2025-68664

• Technical Analysis: https://cyata.ai/blog/langgrinch-langchain-core-cve-2025-68664/

• Attack Mechanism: Malicious LLM output triggers object instantiation → credential exfiltration via HTTP headers

Detection: Monitor LangChain applications for unexpected object creation, outbound connections with environment variables in headers

CVE-2024-5184 - EmailGPT Prompt Injection

CVSS Score: 8.1 (High) Vendor: EmailGPT (Gmail extension) Impact: System prompt leakage, email manipulation, API abuse Attack Vector: Prompt injection via email content Disclosure: June 2024

References:

• NVD Database: https://nvd.nist.gov/vuln/detail/CVE-2024-5184

• BlackDuck Advisory: https://www.blackduck.com/blog/cyrc-advisory-prompt-injection-emailgpt.html

• Attack Mechanism: Malicious prompts in emails override system instructions

Detection: Monitor browser extension API calls, unusual email access patterns, token consumption spikes

CVE-2025-54135 - Cursor IDE (CurXecute)

CVSS Score: Not yet scored (likely High) Vendor: Cursor Technologies Impact: Unauthorized MCP server creation, remote code execution Attack Vector: Prompt injection via GitHub README files Disclosure: January 2025

References:

• Analysis: https://nsfocusglobal.com/prompt-word-injection-an-analysis-of-recent-llm-security-incidents/

• Attack Mechanism: Malicious instructions in README cause Cursor to create .cursor/mcp.json with reverse shell commands

Detection: Monitor .cursor/mcp.json creation, file system changes in project directories, GitHub repository access patterns

‍

CVE-2025-54136 - Cursor IDE (MCPoison)

CVSS Score: Not yet scored (likely High) Vendor: Cursor Technologies Impact: Persistent backdoor via MCP trust abuse Attack Vector: One-time trust mechanism exploitation Disclosure: January 2025

References:

• Analysis: https://nsfocusglobal.com/prompt-word-injection-an-analysis-of-recent-llm-security-incidents/

• Attack Mechanism: After initial approval, malicious updates to approved MCP configs bypass review

Detection: Monitor approved MCP server config changes, diff analysis of mcp.json modifications

‍

OpenClaw / Clawbot / Moltbot (2024-2026)

Category: Open-source personal AI assistant Impact: Subject of multiple CVEs including CVE-2025-53773 (CVSS 9.6) Installations: 100,000+ when major vulnerabilities disclosed

What is OpenClaw? OpenClaw (originally named Clawbot, later Moltbot before settling on OpenClaw) is an open-source, self-hosted personal AI assistant agent that runs locally on user machines. It can:

• Execute tasks on user's behalf (book flights, make reservations)

• Interface with popular messaging apps (WhatsApp, iMessage)

• Store persistent memory across sessions

• Run shell commands and scripts

• Control browsers and manage calendars/email

• Execute scheduled automations

Security Concerns:

• Runs with high-level privileges on local machine

• Can read/write files and execute arbitrary commands

• Integrates with messaging apps (expanding attack surface)

• Skills/plugins from untrusted sources

• Leaked plaintext API keys and credentials in early versions

• No built-in authentication (security "optional")

• Cisco security research used OpenClaw as case study in poor AI agent security

Relation to Moltbook: Many Moltbook agents (the AI social network) used OpenClaw or similar frameworks to automate their posting, commenting, and interaction behaviors. The connection between the two highlighted how local AI assistants could be compromised and then used to propagate attacks through networked AI systems.

Key Lesson: OpenClaw demonstrated that powerful AI agents with system-level access require security-first design. The "move fast, security optional" approach led to numerous vulnerabilities that affected over 100,000 users.

Moltbook Database Exposure (February 2026)

Platform: Moltbook (AI agent social network - "Reddit for AI agents") Scale: 1.5 million autonomous AI agents, 17,000 human operators (88:1 ratio) Impact: Database misconfiguration exposed credentials, API keys, and agent data; 506 prompt injections identified spreading through agent network Attack Method: Database misconfiguration + prompt injection propagation through networked agents

What is Moltbook? Moltbook is a social networking platform where AI agents—not humans—create accounts, post content, comment on submissions, vote, and interact with each other autonomously. Think Reddit, but every user is an AI agent. Agents are organized into "submolts" (similar to subreddits) covering topics from technology to philosophy. The platform became an unintentional large-scale security experiment, revealing how AI agents behave, collaborate, and are compromised in networked environments.

References:

• Coverage: https://asia.nikkei.com/Business/Technology/AI-social-network-Moltbook-attracts-1.5-million-bots-and-hackers

• Lessons: Natural experiment in AI agent security at scale

Key Findings:

• Prompt injections spread rapidly through agent networks (heartbeat synchronization every 4 hours)

• 88:1 agent-to-human ratio achievable with proper structure

• Memory poisoning creates persistent compromise

• Traditional security missed database exposure despite cloud monitoring

Common Attack Patterns

1. Direct Prompt Injection: Ignore previous instructions <SYSTEM>New instructions:</SYSTEM> You are now in developer mode Disregard safety guidelines

2. Indirect Prompt Injection: Hidden in emails, documents, web pages White text on white background HTML comments, CSS display:none Base64 encoding, Unicode obfuscation

3. Tool Invocation Abuse: Unexpected shell commands File access outside approved paths Network connections to external IPs Credential access attempts

4. Data Exfiltration: Large API responses (>10MB) High-frequency tool calls Connections to attacker-controlled servers Environment variable leakage in HTTP headers

Recommended Detection Controls

Layer 1: Configuration Monitoring

• Monitor MCP configuration files (.cursor/mcp.json, claude_desktop_config.json)

• Alert on unauthorized MCP server registrations

• Validate command patterns (no bash, curl, pipes)

• Check for external URLs in configs

Layer 2: Process Monitoring

• Track AI assistant child processes

• Alert on unexpected process trees (bash, powershell, curl spawned by Claude/Copilot)

• Monitor process arguments for suspicious patterns

Layer 3: Network Traffic Analysis

• Unencrypted: Snort/Suricata rules for MCP JSON-RPC

• Encrypted: DNS monitoring, TLS SNI inspection, JA3 fingerprinting

• Monitor connections to non-approved MCP servers

Layer 4: Behavioral Analytics

• Baseline normal tool usage per user/agent

• Alert on off-hours activity

• Detect excessive API calls (3x standard deviation)

• Monitor sensitive resource access (/etc/passwd, .ssh, credentials)

Layer 5: EDR Integration

• Custom IOAs for AI agent processes

• File integrity monitoring on config files

• Memory analysis for process injection

Layer 6: SIEM Correlation

• Combine signals from multiple layers

• High confidence: 3+ indicators → auto-quarantine

• Medium confidence: 2 indicators → investigate

Stay tuned for an article on detection controls!  

Standards & Frameworks

NIST AI Risk Management Framework (AI RMF 1.0)

Link: https://www.nist.gov/itl/ai-risk-management-framework

OWASP Top 10 for LLM Applications

Link: https://genai.owasp.org/ Updates: Annually (2025 version current)

Today’s SOCs don’t have a detection or an AI readiness problem. They have a data architecture problem. Enterprise today are generating terabytes of security telemetry daily, but most of it never meaningfully contributes to detection, investigation, or response. It is ingested late and with gaps, parsed poorly, queried manually and infrequently, and forgotten quickly. Meanwhile, detection coverage remains stubbornly low and response times remain painfully long – leaving enterprises vulnerable.

This becomes more pressing when you account for attackers using AI to find and leverage vulnerabilities. 41% of incidents now involve stolen credentials (Sophos, 2025), and once access is obtained, lateral movement can begin in as little as two minutes. Today’s security teams are ill-equipped and ill-prepared to respond to this challenge.

The industry’s response? Add AI. But most AI SOC initiatives are cosmetic. A conversational layer over the same ingestion-heavy and unreliable pipeline. Data is not structured or optimized for AI deployments. What SOCs need today is an architectural shift that restructures telemetry, reasoning, and action around enabling security teams to treat AI as the operating system and ensure that their output is designed to enable the human SOC teams to improve their security posture.

The Myth Most Teams Are Buying

Most “AI SOC” initiatives follow a similar pattern. New intelligence is introduced at the surface of the system, while the underlying architecture remains intact. Sometimes this takes the form of conversational interfaces. Other times it shows up as automated triage, enrichment engines, or agent-based workflows layered onto existing SIEM infrastructure.

This ‘bolted-on’ AI interface only incrementally impacts the use, not the outcomes. What has not changed is the execution model. Detection is still constrained by the same indexes, the same static correlation logic, and the same alert-first workflows. Context is still assembled late, per incident, and largely by humans. Reasoning still begins after an alert has fired, not continuously as data flows through the environment.

This distinction matters because modern attacks do not unfold as isolated alerts. They span identity, cloud, SaaS, and endpoint domains, unfold over time, and exploit relationships that traditional SOC architectures do not model explicitly. When execution remains alert-driven and post-hoc, AI improvements only accelerate what happens after something is already detected.

In practice, this means the SOC gets better explanations of the same alerts, not better detection. Coverage gaps persist. Blind spots remain. The system is still optimized for investigation, not for identifying attack paths as they emerge.

That gap between perception and reality looks like this:

Each gap above traces back to the same root cause: intelligence added at the surface, while telemetry, correlation, and reasoning remain constrained by legacy SOC architecture.

Why Most AI SOC Initiatives Fail

Across environments, the same failure modes appear repeatedly.

1. Data chaos collapses detection before it starts
Enterprises generate terabytes of telemetry daily, but cost and normalization complexity force selective ingestion. Cloud, SaaS, and identity logs are often sampled or excluded entirely. When attackers operate primarily in these planes, detection gaps are baked in by design. Downstream AI cannot recover coverage that was never ingested.

2. Single-mode retrieval cannot surface modern attack paths
Traditional SIEMs rely on exact-match queries over indexed fields. This model cannot detect behavioral anomalies, privilege escalation chains, or multi-stage attacks spanning identity, cloud, and SaaS systems. Effective detection requires sparse search, semantic similarity, and relationship traversal. Most SOC architectures support only one.

3. Autonomous agents without governance introduce new risk
Agents capable of querying systems and triggering actions will eventually make incorrect inferences. Without evidence grounding, confidence thresholds, scoped tool access, and auditability, autonomy becomes operational risk. Governance is not optional infrastructure; it is required for safe automation.

4. Identity remains a blind spot in cloud-first environments
Despite being the primary attack surface, identity telemetry is often treated as enrichment rather than a first-class signal. OAuth abuse, service principals, MFA bypass, and cross-tenant privilege escalation rarely trigger traditional endpoint or network detections. Without identity-specific analysis, modern attacks blend in as legitimate access.

5. Detection engineering does not scale manually
Most environments already process enough telemetry to support far higher ATT&CK coverage than they achieve today. The constraint is human effort. Writing, testing, and maintaining thousands of rules across hundreds of log types does not scale in dynamic cloud environments. Coverage gaps persist because the workload exceeds human capacity.

The Six Layers That Actually Work

A functional AI-native SOC is not assembled from features. It is built as an integrated system with clear dependency ordering.

Layer 1: Unified telemetry pipeline
Telemetry from cloud, SaaS, identity, endpoint, and network sources is collected once, normalized using open schemas, enriched with context, and governed in flight. Volume reduction and entity resolution happen before storage or analysis. This layer determines what the SOC can ever see.

Layer 2: Hybrid retrieval architecture
The system supports three retrieval modes simultaneously: sparse indexes for deterministic queries, vector search for behavioral similarity, and graph traversal for relationship analysis. This enables detection of patterns that exact-match search alone cannot surface.

Layer 3: AI reasoning fabric
Reasoning applies temporal analysis, evidence grounding, and confidence scoring to retrieved data. Every conclusion is traceable to specific telemetry. This constrains hallucination and makes AI output operationally usable.

Layer 4: Multi-agent system
Domain-specialized agents operate across identity, cloud, SaaS, endpoint, detection engineering, incident response, and threat intelligence. Each agent investigates within its domain while sharing context across the system. Analysis occurs in parallel rather than through sequential handoffs.

Layer 5: Unified case memory
Context persists across investigations. Signals detected hours or days apart are automatically linked. Multi-stage attacks no longer rely on analysts remembering prior activity across tools and shifts.

Layer 6: Zero-trust governance
Policies constrain data access, reasoning scope, and permitted actions. Autonomous decisions are logged, auditable, and subject to approval based on impact. Autonomy exists, but never without control.

Miss any layer, or implement them out of order, and the system degrades quickly.

Outcomes When the Architecture Is Correct

When the six layers operate together, the impact is structural rather than cosmetic:

• Faster time to detection
  Detection shifts from alert-triggered investigation to continuous, machine-speed reasoning across telemetry streams. This is the only way to contend with adversaries operating on minute-level timelines.

• Improved analyst automation
  L1 and L2 workflows can be substantially automated, as agents handle triage, enrichment, correlation, and evidence gathering. Analysts spend more time validating conclusions and shaping detection logic, less time stitching data together.

• Broader and more consistent ATT&CK coverage
  Detection engineering moves from manual rule authoring to agent-assisted mapping of telemetry against ATT&CK techniques, highlighting gaps and proposing new detections as environments change.

• Lower false-positive burden
  Evidence grounding, confidence scoring, and cross-domain correlation reduce alert volume without suppressing signal, improving analyst trust in what reaches them.

The shift from reactive triage to proactive threat discovery becomes possible only when architectural bottlenecks like fragmented data, late context, and human-paced correlation, are removed from the system.

Stop Retrofitting AI Onto Broken Architecture

Most teams approach AI SOC transformation backward. They layer new intelligence onto existing SIEM workflows and expect better outcomes, without changing the architecture that constrains how detection, correlation, and response actually function.

The dependency chain is unforgiving. Without unified telemetry, detection operates on partial visibility. Without cross-domain correlation, attack paths remain fragmented. Without continuous reasoning, analysis begins only after alerts fire. And without governance, autonomy introduces risk rather than reducing it.

Agentic SOC architectures are expected to standardize across enterprises within the next one to two years (Omdia, 2025). The question is not whether SOCs become AI-native, but whether teams build deliberately from the foundation up — or spend the next three years patching broken architecture while attackers continue to exploit the same coverage gaps and response delays.