Before starting Databahn, we spent years working alongside large enterprise security teams. Across industries and environments, we kept encountering the same pattern: the increased sophistication of platform and analytics in modernized stacks, matched by the fragility of the security data layer.  

Data is siloed across tools, movement is inefficient, lineage is a mystery that requires investigation. Governance is inconsistent, and management is a manual exercise leaning heavily on engineering bandwidth not being spent on delivering clarity, but in keeping systems going despite obvious gaps. Every new initiative depended on data that was harder to manage than it should have been. It became clear to us that this was not an operational inconvenience but a structural problem.

We started Databahn with a simple conviction: that to improve detection logic, ensure scalable AI implementation, and accelerate and optimize security operations, security data itself has to be made to work. That conviction has driven every decision we have made.

This week, we shared that Databahn has grown by more than 400% year-on-year, with more than half of our customers from the Fortune 500. We are deeply grateful to the enterprises, partners, and team members who have trusted us to solve this challenge alongside them. But the growth and traction are not the headline. It is that the security ecosystem is recognizing what we saw years ago – security data is the foundation of modern security operations.

Our strategy – staying focused

As the market evolves, companies face choices about where to direct their energy. There is always pressure to broaden and extend into adjacencies, or to join up and be absorbed by larger players in the security ecosystem.  

At Databahn, we remain singularly focused on solving the enterprise security data problem. Our customers and partners rely on us to be a best-of-breed solution for security data management, not a competitor attempting to replace parts of their ecosystem with new capabilities that dilute our mission.

Our belief is straightforward: enterprises don’t need another platform to own their stack, a new SIEM to detect threats, or a new Security Data Lake to store telemetry. They have these tools and have built their systems around them. What they need is a solution to make their security data work – not locked in, not siloed, not locked behind formats and schemas that take teams thousands of lines of code to uncover.

It needs to move cleanly across environments to different tools. It needs to be governed and optimized. It should support existing systems without creating friction. Building the security data system that delivers the right security data to the right place at the right time with the right context is the problem we are choosing to solve for our customers.

Enterprise adoption reflects a larger shift

The enterprises choosing Databahn are not experimenting; they are standardizing.  

A Fortune 100 global airline managed a complex SIEM migration in just 6 weeks, while ensuring that complex data types – flight logs, sensors, etc. were seamlessly ingested and managed across the organization. The result was a more resilient and controlled data foundation, ready for AI deployment and optimized for scale and efficiency.  

Sunrun reduced log volume by 70% while improving visibility across its complex and geographically distributed environment. That shift translated into meaningful cost efficiency and stronger signal clarity.  

Becton Dickinson brought structure and governance to its security data, transforming operational complexity of a multi-SIEM deployment into clarity by centralizing their security data into one SIEM instance in just 8 weeks while significantly lowering costs.

Working with these exceptional global teams to turn security data noise into manageable and optimized signal validates our conviction. Our growth is a reflection of this realization taking hold inside the enterprise – security data isn’t working right now, but it can be made to work.

Security Data is now strategic architecture

As enterprises accelerate modernization and AI-driven initiatives, expectations placed on data have fundamentally changed. Security data is no longer exhaust, but it is infrastructure. It is the platform on which the future AI-powered SOC must operate. It must be portable, governed, observable, and adaptable to new systems without forcing architectural trade-offs.  

Enterprises cannot build intelligent workflows on unstable data foundations, where teams can’t trust their telemetry, and so must trust their AI output based on that telemetry even less. Before you layer more intelligence on top of your security stack, you have to fix the data foundation. That’s why AI transformation is being led by Forward Deployment Engineers who are structuring and cleansing data before adding AI solutions on top. Databahn provides that foundation as a platform, delivering flexible resiliency and governance without the manual effort and tech debt.

What comes next

We believe the next chapter of enterprise security will be defined by organizations that treat security data as a strategic asset rather than an operational byproduct. Our commitment is to continue going deeper into solving that core problem. To strengthen partnerships across the ecosystem and help enterprises modernize their security architecture without being forced into unnecessary complexity or locked into a platform that prevents ownership of their data.

The momentum we announced this week is meaningful, but it is just the beginning of a movement. What matters more is what it represents. That enterprises need to make their security data actually work.  

We are excited to continue solving that challenge alongside the leaders driving this shift. The future holds many exciting new partnerships, product development, and other ways we can reduce complexity and increase ownership and value of security data. If any of these challenges seem relatable, we would invite you to get in touch with us to see if we can help.

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)