Cribl Expands Security Portfolio with Radiant AI SOC Acquisition

Cribl acquired Radiant Security’s AI SOC technology assets on August 19, its second security acquisition in just over one month. The google news headline captures the transaction, but not the larger conflict behind it. Cribl is moving beyond telemetry routing into work historically controlled by security information and event management platforms, commonly known as SIEMs.

The acquired intellectual property can autonomously triage, investigate, and help resolve security alerts, according to Cribl. The technology generates logic for each alert instead of depending entirely on predefined playbooks. Cribl plans to adapt it as an application running on the company’s existing telemetry platform.

That strategy puts Cribl closer to the territory occupied by Microsoft, Cisco’s Splunk, CrowdStrike, Palo Alto Networks, and newer AI SOC vendors. It also raises a harder question. Can a vendor turn an open data layer into an effective security operations platform without rebuilding the closed stack it says customers have outgrown?

Cribl’s answer rests on two acquisitions. Radiant adds investigation and alert triage. CardinalOps, acquired in July, adds detection engineering, which measures coverage and improves the rules used to identify threats.

Together, those capabilities give Cribl components spanning data preparation, detection design, and incident investigation. The combination is more important than either deal alone. It represents a deliberate attempt to move security intelligence closer to the telemetry itself.

Cribl Bought Technology Assets, Not the Entire Company

The precise structure matters because Cribl acquired Radiant’s AI SOC technology assets rather than announcing a conventional company takeover.

Cribl’s AI SOC acquisition includes intellectual property for autonomously triaging, investigating, and resolving alerts. The announcement did not disclose the transaction’s financial terms. It also did not explain how many Radiant employees, customers, or contractual obligations will move to Cribl.

That leaves an important distinction between acquiring a complete operating business and buying selected technology assets. A full acquisition usually transfers the company, workforce, customer relationships, and liabilities. An asset transaction can give the buyer greater control over what it takes, but it can make continuity less obvious.

Cribl says it will adapt Radiant’s technology to run as an application on its telemetry data platform. Telemetry is machine-generated information from applications, networks, identities, endpoints, and infrastructure. Security teams use that information to understand activity and investigate suspicious behavior.

Radiant’s product approached the problem from the other end. It consumed alerts and relevant context, then used AI to triage the alerts and conduct investigations. Its system was designed to assemble evidence, judge whether activity appeared malicious, and suggest a response.

The acquired technology generates custom triage logic for individual alerts, according to Cribl. That differs from automation based only on prewritten playbooks. A predefined playbook assumes that engineers can anticipate a scenario and encode the required steps before the alert arrives.

Dynamic logic promises more flexibility when an alert has unfamiliar characteristics. The system can select investigative actions based on the available evidence. However, Cribl has not published independent benchmarks showing how reliably this approach performs across customers, alert sources, or attack types.

Radiant brought existing field experience to the transaction. The company was founded in 2021 and previously marketed an AI-assisted security operations platform. It raised a $15 million Series A in 2023, led by Next47 with participation from earlier investors.

The company originally described its product as a SOC copilot. That positioning focused on supporting analysts rather than replacing an entire security operation. Its later messaging expanded toward an adaptive AI SOC capable of handling more of the triage and investigation process.

Cribl is now absorbing that technology into a broader platform. The company says the resulting application will investigate against telemetry wherever the data resides. If delivered as described, customers would not need to copy every relevant record into a separate AI SOC repository before an investigation starts.

That architectural detail triggers the article’s central tension. A federated approach can preserve customer choice and reduce unnecessary data movement. It can also make consistent investigation harder because source systems differ in availability, structure, retention, and query performance.

The original google news item therefore marks the start of an integration project, not the arrival of a finished combined product. Cribl has acquired capabilities and intellectual property. Customers still need evidence that those components can operate together under real security conditions.

Why Cribl Is Moving Into Security Operations Now

Cribl is following the value chain upward because controlling telemetry alone no longer captures the most consequential security decisions.

Cribl built its position by helping enterprises collect, transform, route, search, and store operational data. This layer sits between the systems producing telemetry and the platforms that analyze it. It gives customers more control over which data reaches expensive downstream tools.

That model addresses a persistent enterprise problem. Security and operations teams generate more logs than they can economically retain in every analytics platform. They also work across cloud services, endpoint products, identity systems, network tools, and privately managed infrastructure.

Routing and filtering can reduce duplication and spending. Yet a data pipeline does not decide whether an alert represents an attack. It does not automatically determine whether detection rules cover the threats an organization actually faces.

Cribl’s July acquisition of CardinalOps began closing that gap. The CardinalOps transaction added software for assessing detection coverage, identifying missing protections, and finding broken or noisy rules.

Detection engineering converts threat knowledge into logic that security products can execute. It connects adversary behaviors with the data sources and rules needed to identify them. CardinalOps automated parts of that work and mapped security controls against frameworks such as MITRE ATT&CK.

Radiant advances Cribl another step. CardinalOps addresses whether the right detections exist and function correctly. Radiant’s technology addresses what happens after those detections or other security tools produce alerts.

The sequence creates a coherent product direction:

• Cribl’s existing platform manages and exposes telemetry.

• CardinalOps evaluates detection coverage and rule quality.

• Radiant’s technology triages alerts and conducts investigations.

• Human analysts review conclusions and decide how much response authority to automate.

That progression explains why the transactions arrived close together. Cribl is not collecting unrelated AI features. It is assembling adjacent functions around a common data foundation.

Cribl CEO Clint Sharp framed the problem around security data silos. He said too much of a $121 billion security market remains trapped in isolated systems. That market estimate and the broader claim come from Cribl, so they should not be treated as independent validation of the strategy.

The motivation is still clear. AI applications depend on accessible, relevant, and well-structured context. A security agent cannot investigate effectively when key identity records sit in one platform, endpoint evidence in another, and network history somewhere else.

Traditional SIEM platforms address this by centralizing large volumes of data. The SIEM then applies rules, generates alerts, supports searches, and manages investigations. This approach creates a common analytical environment, but it can also increase storage expense and vendor dependence.

Cribl proposes a different center of gravity. Its platform aims to make distributed telemetry available to multiple applications without demanding that one analytics product own every copy. AI SOC functions would sit on that shared foundation.

The company’s earlier positioning makes this move especially notable. In 2024, Cribl raised $319 million at a reported $3.5 billion valuation. At that time, coverage of the round emphasized data infrastructure rather than an identity as an AI security company.

Two years later, Cribl calls itself an AI Platform for Telemetry and is buying operational security capabilities. This is not merely a branding adjustment. It changes what customers, partners, and competitors should expect the product to do.

The Google News Headline Hides a Challenge to the SIEM Stack

Cribl is betting that security operations can become a collection of applications on shared telemetry rather than a single system that owns the data and workflow.

That is the primary contest behind the acquisition. It is not simply Cribl versus one named competitor. The stronger conflict is an open, federated telemetry model versus the integrated SIEM stack.

A conventional SIEM centralizes data so its search, detection, correlation, investigation, and reporting functions can work from a controlled environment. The vendor can optimize performance across that stack. Customers gain consistency, but moving away can become difficult.

Cribl argues that data should remain portable and available across tools. Its platform can route records to different destinations, retain selected data in lower-cost locations, and search some information where it already lives. The vendor now wants to add security applications above that layer.

Radiant’s technology fits the model because an AI investigator needs broad contextual access. Cribl says the software can execute investigations directly against distributed telemetry. This could let an organization retain endpoint, cloud, and network records in different locations while still assembling evidence for an alert.

CardinalOps provides a complementary feedback loop. Its technology can identify missing data sources or fields when detection coverage is weak. It can also expose parsing and normalization failures that cause rules to stop working.

Cribl has cited CardinalOps research suggesting that organizations collect data capable of covering about 90 percent of MITRE ATT&CK techniques. Their SIEM detections cover only about 21 percent, according to that vendor research. The same analysis says approximately 13 percent of SIEM rules are broken.

Those figures are useful indicators, but they come from CardinalOps and were republished by its acquirer. They do not establish universal industry rates. Different organizations also define technique coverage and rule effectiveness in different ways.

The underlying mismatch remains plausible. Collecting the right data does not guarantee that a company has written, tested, and maintained the right detections. Generating an alert does not guarantee that an analyst has enough context to investigate it quickly.

Cribl’s proposed platform targets both gaps. CardinalOps assesses whether detections provide meaningful coverage. Radiant’s technology investigates the alerts those detections produce. Cribl supplies access to the underlying data.

A manufacturing customer described one version of this operating model before the acquisition. In a published AI SOC case study, Rehrig Pacific said it replaced an outsourced security arrangement and brought operations in-house with Radiant.

The customer reported that mean time to respond fell from 20 to 30 minutes to about five minutes. It also said analysts received 70 to 80 percent of the required context with each alert. These are customer and vendor-reported results, not a controlled comparison.

The case still illustrates the intended workflow. Alerts from email, cloud, endpoint, network, and internal systems arrived in one environment. Automated investigation assembled host details, user activity, related events, and a timeline before an analyst reviewed the case.

Cribl wants to reproduce that experience without requiring every customer to adopt another isolated data store. That is where the strategy pressures incumbent platforms. If investigation can run across shared telemetry, customers have less reason to let one SIEM control collection, storage, detection, and response.

Incumbents retain major advantages. Microsoft can connect security operations with identity, endpoints, cloud services, and workplace software. CrowdStrike owns deep endpoint visibility and has expanded its next-generation SIEM offering. Palo Alto Networks combines network, cloud, endpoint, and automation products.

Cisco’s Splunk also has a large installed base and mature search capabilities. These vendors can integrate security functions across products they already control. Their customers may value that operational consistency more than architectural openness.

Cribl therefore has to prove that flexibility produces better outcomes, not just more choices. A federated system that requires extensive connector work, schema management, and access troubleshooting could shift complexity rather than eliminate it.

The acquisition covered by google news is best understood as a direct test of that proposition. Cribl now owns more of the logic required to turn distributed data into security decisions. The company must show that its platform can do so predictably.

Dynamic AI Investigations Create a Trust Tradeoff

Generating unique investigative logic for every alert expands coverage, but it also makes validation and governance more demanding.

Predefined playbooks have clear limitations. They work well for familiar alerts with stable data sources and documented response procedures. They struggle when an investigation requires new queries, unexpected evidence, or reasoning across tools that the playbook did not anticipate.

Radiant’s technology promises to formulate triage logic as each alert arrives. An AI agent can decide which records to retrieve, identify relationships, evaluate suspicious behavior, and recommend further action. In theory, this makes the system adaptable across more alert categories.

The same flexibility creates risk. A fixed playbook can be reviewed before deployment and tested against known inputs. Dynamically generated steps vary from case to case, making comprehensive advance testing difficult.

Security investigations also involve adversarial data. Attackers may manipulate log fields, filenames, messages, or other content that an AI system reads. An investigation agent needs controls that separate untrusted telemetry from operational instructions.

Access presents another concern. An AI SOC application may need permission to query sensitive identity, endpoint, network, and cloud records. Automated response can require even broader authority, including the ability to disable accounts or isolate devices.

Organizations must know which actions the application can take, how approvals work, and whether every decision produces an auditable record. Cribl’s announcement describes autonomous triage, investigation, and resolution, but it does not provide a detailed public governance model for the combined product.

Accuracy also needs independent measurement. Reducing false positives sounds valuable, but an aggressive filter can create false negatives by dismissing malicious activity. The cost of overlooking a real intrusion differs sharply from the inconvenience of escalating a benign alert.

Useful evaluation should separate several questions. Did the system retrieve the correct evidence? Did it interpret that evidence accurately? Did it assign the right severity? Did it recommend a safe response? Did a human analyst agree with the conclusion?

A single accuracy percentage would hide these distinctions. Performance can also vary by data source, alert type, customer environment, and available historical context.

Integration creates further uncertainty because Cribl is combining technology from separate products. CardinalOps maps detection coverage and evaluates rules. Radiant’s assets investigate alerts. Cribl manages telemetry across distributed systems.

The components have a logical relationship, but product architecture does not become unified through acquisition announcements. Data models, identity controls, deployment systems, user interfaces, and audit records still require integration.

Sean Sosnowski of Software Analyst Cyber Research described the CardinalOps deal as a natural extension of Cribl’s control over the data layer. His comments in a security operations analysis also highlighted the breadth of potential competition Cribl faces as it moves upward.

That pressure now increases. Cribl must continue supporting integrations with companies whose SIEM and security analytics businesses it increasingly challenges. Partners may respond by limiting technical cooperation, improving their own data controls, or emphasizing integrated performance.

Customers should also distinguish architectural claims from operational evidence. Running investigations where telemetry resides can reduce copying, but remote queries still depend on source availability and latency. Data may follow inconsistent schemas or retention policies.

An investigation could fail if a source system is unavailable or if the required records have expired. It could reach the wrong conclusion when fields are incomplete. Cribl needs clear behavior for these situations, including confidence indicators and escalation rules.

The asset structure adds one more unknown. Cribl has not publicly detailed which Radiant personnel will support the technology after the transaction. Intellectual property matters, but specialized engineers and incident-response knowledge often determine whether security software continues improving.

None of these concerns invalidate the acquisition. They define the evidence Cribl must produce. The company has moved from enabling security tools to making security judgments, and the standard of proof rises with that change.

Three Signals Will Show Whether Cribl’s AI SOC Strategy Works

The next test is execution: Cribl must reveal a product, prove adoption, and show that its open model performs under operational pressure.

The first signal will arrive at CriblCon on September 28, 2026. Cribl says it will share more additions to the platform at the event. The most important details will concern packaging, integration, availability, and customer control.

A credible release should explain how the acquired Radiant technology appears inside Cribl’s platform. Customers need to know which telemetry sources it can query, whether it operates in cloud and self-managed environments, and how permissions are scoped.

Cribl should also clarify the relationship between Radiant’s investigation functions and CardinalOps’ detection engineering. A shared interface would matter less than a shared feedback loop. Investigation outcomes should help teams improve weak rules, missing context, and noisy data sources.

If Cribl presents an integrated product with concrete deployment details, the acquisition thesis becomes stronger. A demonstration without release timing, governance documentation, or supported workflows would leave the central questions unresolved.

The second signal will be customer adoption beyond curated case studies. Cribl says its platform is used by half of the Fortune 100. That distribution could give the AI SOC application a meaningful route into large enterprises.

Installed-base access does not guarantee operational trust. Existing customers may use Cribl for routing while keeping investigations inside Microsoft Sentinel, Splunk, CrowdStrike, Palo Alto Networks, or another platform. Security leaders will evaluate the new application separately.

Strong evidence would include named production deployments, documented alert volumes, independent customer interviews, and performance across several security environments. Results should cover both detection quality and analyst workload.

The most useful metrics will include false-positive reduction, missed-alert rates, investigation time, analyst override frequency, and the percentage of cases requiring manual reconstruction. Cribl should also disclose how often remote data access fails or returns incomplete context.

Consistent improvements across customers would support Cribl’s claim that applications perform better on shared telemetry. Narrow success in highly configured deployments would suggest the approach still depends heavily on services and customer-specific engineering.

The third signal will be the competitive response. SIEM vendors can reduce Cribl’s differentiation by opening access to data, improving federated search, or adding more transparent AI investigation controls.

They can also make integrated stacks more attractive. A vendor that controls the endpoint sensor, identity layer, analytics engine, and response workflow can optimize interactions across those products. Cribl must counter that advantage with portability, broader source support, and lower switching friction.

Partner behavior deserves attention as well. Cribl’s platform currently connects with many security vendors. Those integrations are central to its open model. Any restriction, reduced technical cooperation, or competing telemetry feature could weaken the strategy.

Conversely, continued partnerships would show that customers still demand composable security architectures. Vendors may decide that supporting Cribl remains necessary even as it enters adjacent markets.

This is why the acquisition is more consequential than a typical google news funding or merger item. Cribl is testing whether the control point in security operations can move from a centralized analytics suite to a shared telemetry platform.

The outcome affects enterprise buyers. A successful model could let teams preserve existing data infrastructure while replacing individual security functions over time. A failed model could leave them managing another layer of software without reducing dependence on incumbent systems.

Developers and security engineers should watch the interfaces between the layers. They need consistent schemas, controlled credentials, complete audit trails, and reliable failure handling. AI reasoning is only one part of an operational security system.

Knowledge workers outside the SOC also have a stake. Security investigations increasingly involve identity activity, cloud resources, collaboration systems, and business applications. Decisions made by an AI agent can affect employee access and production services.

Teams evaluating the announcement should treat the Google News headline as a starting point. Ask Cribl for an exact asset and integration roadmap. Test the product against representative alerts, incomplete data, unavailable sources, and adversarial inputs.

Most importantly, compare the system’s conclusions with experienced analysts over time. The decisive question is not whether AI can generate an investigation. It is whether Cribl can make those investigations accurate, governable, and repeatable across telemetry it does not fully control.