OLIGO Security Raises $60 Million to Expand Runtime Protection Against AI-Speed Attacks

OLIGO Security raised $60 million after warning that AI can help attackers develop exploits at machine speed. The deal, now circulating through Google News, pushes runtime protection into a larger cybersecurity debate.

The company says security teams can no longer depend entirely on vulnerability scans and scheduled patches. Its alternative watches software while it runs, then blocks suspicious execution inside an application without terminating the surrounding workload.

That pitch challenges the dominant vulnerability-management model. Scanners identify possible weaknesses before an attack, while OLIGO wants runtime behavior to determine which weaknesses represent immediate danger.

The distinction matters because faster vulnerability discovery does not automatically produce faster remediation. Every newly identified flaw can expand an already crowded queue. Attackers only need one exploitable path, while defenders must assess thousands of findings across production systems.

OLIGO is betting that enterprises will pay to close that timing gap. The financing provides more resources for that bet, but it does not settle whether runtime controls can deliver consistent protection at enterprise scale.

The $60 Million Round Funds a Broader Runtime Push

OLIGO is financing an expansion from vulnerability prioritization into active protection across applications, cloud workloads, and AI systems.

The company announced the additional funding on August 4, 2026. The round brought its disclosed funding total to $140 million, according to the funding announcement.

Participating investors included Ballistic Ventures, Canon Capital, Greenfield Partners, Lightspeed Venture Partners, Red Dot Capital Partners, and TLV Partners. Mellanox co-founder Eyal Waldman also participated.

OLIGO said it will use the capital for product development and global go-to-market expansion. Those goals sound conventional, but the timing connects them to a specific technical claim.

Chief executive Nadav Czerninski argues that AI has changed the economics of exploitation. Attackers can use models to accelerate research, generate code, test hypotheses, and refine exploit chains.

That does not make every attack autonomous. Humans still choose targets, establish access, interpret results, and manage operational risk. However, AI can compress portions of the process that previously required more manual work.

OLIGO says this compression makes runtime the decisive defensive layer. Runtime means the period when software is actively executing, processing data, calling libraries, and interacting with an operating system.

The company reported 300% year-over-year revenue growth. It also said its valuation more than doubled following its January 2025 Series B, without disclosing the current figure.

Both numbers come from OLIGO rather than audited public filings. The growth claim signals commercial momentum, but outsiders cannot independently assess its underlying revenue base or customer concentration.

The company’s earlier financing offers useful context. OLIGO emerged publicly in February 2023 with $28 million across seed and Series A funding.

Its initial product used eBPF, a Linux kernel technology that supports restricted programs for observing system activity. The approach helped identify which library functions an application actually executed.

At the time, OLIGO framed runtime context mainly as a way to reduce vulnerability noise. A scanner might flag an installed library even when the affected function never runs.

The company’s founders argued that execution data could separate theoretical exposure from active risk. That positioning appeared in early company coverage, years before AI-driven attacks dominated security pitches.

OLIGO raised another $50 million in January 2025. The latest round arrives after its product moved further into detection, response, and real-time exploit blocking.

That progression is important. Prioritizing a vulnerability gives a security team information, while blocking execution gives a vendor influence over production behavior.

The second responsibility carries greater stakes. A missed detection can permit an intrusion, while an incorrect block can interrupt legitimate activity.

OLIGO says its controls avoid that forced choice. Investors are financing the company as it tries to prove the claim across more customers, applications, and operating environments.

Google News exposure gives the funding event wider reach, but the actual story is not another security startup raising capital. OLIGO is trying to establish runtime evidence as the security program’s source of truth.

That position pressures both application-security vendors and workload-protection platforms. Each group already analyzes part of the path between vulnerable code and an active breach.

OLIGO wants to occupy the point where application behavior meets operating-system activity. The funding supports its attempt to turn that point into a distinct enterprise security category.

Why AI-Speed Exploits Put Patch Queues Under Pressure

AI increases the value of fast defensive decisions because it can shorten the interval between discovering a weakness and testing an exploit.

Traditional vulnerability management begins before exploitation. Teams inventory software, match components against known flaws, assign severity, investigate exposure, and schedule remediation.

That process remains necessary. Removing vulnerable code addresses the underlying weakness instead of relying indefinitely on compensating controls.

The problem is time. A production organization may operate thousands of services with overlapping libraries, containers, cloud resources, and development teams.

Each scanner can generate findings from a different perspective. Source-code tools inspect development artifacts, software composition tools track dependencies, and cloud scanners examine deployed configurations.

Security teams then reconcile those signals with ownership and business context. A critical flaw inside an internet-facing payment service deserves different treatment from dormant code in an isolated test system.

AI does not erase that complexity. It can make the offensive side move faster while defenders still navigate change controls, regression tests, maintenance windows, and internal approvals.

Attackers can ask models to explain unfamiliar code or suggest likely input paths. They can generate variations of proof-of-concept code and automate repeated testing.

The results still require verification. Models can invent functions, misunderstand memory behavior, or produce code that fails against the target environment.

Yet unreliable assistance can remain economically useful when it makes experimentation cheaper. An attacker can discard failed outputs and retain the small percentage that advances an exploit chain.

Google News coverage of OLIGO’s financing therefore reflects a broader security concern. Machine assistance can increase the volume and pace of offensive exploration without guaranteeing sophisticated autonomous hacking.

Public vulnerability disclosure creates another timing problem. Defenders receive information needed for remediation, but attackers receive the same technical clues.

An available patch does not mean every affected organization has deployed it. Enterprises must identify vulnerable assets, evaluate compatibility, test changes, and coordinate releases.

That sequence can leave a window for exploitation. The window becomes more dangerous when tools accelerate reconnaissance and exploit adaptation.

Security teams also face a prioritization trap. Severity scores describe a vulnerability’s general characteristics, but they do not prove that a particular workload exposes the vulnerable behavior.

Runtime context offers a narrower question: did the application load and execute the affected function under relevant conditions?

A useful answer can shrink the immediate remediation queue. Teams can focus first on vulnerabilities with observable execution paths, external reachability, or suspicious surrounding behavior.

However, absence of observed execution is not proof of permanent safety. An uncommon business process, seasonal task, or attacker-controlled input could activate dormant code later.

Runtime prioritization should therefore inform patch order rather than cancel remediation. The evidence changes urgency, not the underlying existence of vulnerable software.

OLIGO’s product thesis goes further by treating runtime as an enforcement point. It seeks to identify exploit behavior at execution and block the relevant system operation.

This is often described as virtual patching. A security control interrupts an exploit path while the vulnerable software remains unchanged.

Virtual patching can buy time for testing and deployment. It can also protect software when a vendor patch is unavailable or operationally difficult to apply.

The technique does not remove the vulnerable code. Teams must maintain the control, monitor bypass attempts, and eventually complete durable remediation.

The funding announcement presents runtime protection as a response to machine-speed attacks. Enterprise buyers should translate that claim into measurable operational questions.

How quickly does the system create useful protections after a new technique appears? What telemetry does it require? How often does it block legitimate behavior?

Buyers must also ask whether protections survive application updates. Modern services change frequently, and an accurate behavioral baseline can drift as teams deploy new features.

AI-assisted attacks raise the urgency, but they do not lower the standard of proof. Runtime vendors must show that speed does not come at the expense of production stability.

Google News Is Tracking a Shift From Alerts to Execution Control

The runtime security race is moving from identifying risk toward making real-time decisions inside production applications.

OLIGO launched Runtime Exploit Blocking in April 2026. The capability correlates application-level function calls with system activity, according to detailed product coverage.

A single action can look legitimate in isolation. A sequence of function calls, data flows, and system operations can reveal an exploit attempt.

OLIGO says it can block the underlying system call while allowing the application and its container to continue running. That design targets a familiar enterprise concern.

Security teams want rapid containment, but application owners fear controls that interrupt revenue-producing services. A detection system becomes less useful when every response requires shutting down an entire workload.

Technique-based protection is another part of OLIGO’s pitch. Instead of writing one rule for every known vulnerability, the company says it can cover recurring exploitation patterns.

That model resembles a move from individual symptoms toward attack mechanics. A control can potentially address several known vulnerabilities and some unknown flaws that use the same execution pattern.

The advantage depends on precision. A broad technique rule that also matches legitimate application behavior can generate damaging false positives.

OLIGO says its visibility into call stacks and function behavior provides the necessary context. A call stack records the active chain of software functions leading to an operation.

That context can distinguish a normal network request from an unexpected request initiated through a vulnerable library path. It can also help analysts understand how execution reached a dangerous system call.

The mechanism separates OLIGO from tools focused primarily on predeployment code scanning. It also places the company near several established security categories.

Cloud workload protection platforms monitor processes, containers, files, identities, and network activity. Endpoint detection products analyze behavior on hosts and respond to threats.

Application detection and response tools move closer to application logic. Interactive testing and runtime instrumentation products also observe code during execution.

OLIGO’s competitive task is proving that its combined application and system view produces better decisions. More telemetry alone does not guarantee better security.

A platform can collect detailed execution data and still overwhelm analysts. It can also introduce performance costs, compatibility issues, or difficult deployment requirements.

OLIGO originally used runtime evidence to reduce noisy vulnerability findings. That remains one of its clearest potential benefits because the output maps to an existing operational burden.

Exploit blocking demands a higher level of confidence. The platform must decide quickly, enforce safely, and preserve enough evidence for investigation.

The company says it blocks attack techniques without killing the process or container. That claim requires validation across languages, frameworks, architectures, and application designs.

Coverage can vary when workloads use managed services, serverless components, custom runtimes, or non-Linux systems. eBPF is closely associated with Linux environments, although vendors can combine it with other sensors.

Enterprises should therefore examine where enforcement occurs and where visibility ends. A security architecture rarely depends on one execution environment.

AI systems further complicate the picture. An AI application can include model endpoints, orchestration frameworks, vector stores, plugins, data pipelines, and conventional web services.

Some risks involve normal software vulnerabilities. Others involve prompt injection, excessive permissions, unsafe tool calls, model manipulation, or poisoned data.

Runtime controls can observe code and system behavior, but they do not automatically solve every AI security problem. A harmful action might use fully authorized application functions.

For example, a compromised agent could request sensitive data through a legitimate connector. The operating-system behavior may look normal even though the business intent is unsafe.

That boundary matters when vendors describe broad AI runtime security. Buyers should separate exploit prevention from model governance, identity controls, data protection, and application authorization.

OLIGO has expanded its platform with AI security posture and detection capabilities. The company says these products monitor models and agents alongside applications and cloud infrastructure.

Its public research gives the pitch practical context. In 2024, OLIGO described ShadowRay, an attack campaign involving exposed Ray clusters and a disputed vulnerability.

The company reported that compromised environments included AI workloads, credentials, databases, and computing resources. Its ShadowRay research connected application weaknesses with valuable production assets.

That incident helps explain OLIGO’s current direction. AI infrastructure is not isolated from conventional software exploitation.

Models still run inside applications, import open-source packages, expose network interfaces, and depend on cloud services. Attackers can target those surrounding components without defeating the model itself.

OLIGO is positioning runtime visibility as the shared control across those layers. Its financing gives the company more capacity to pursue that platform strategy.

The market will decide whether customers prefer a specialized runtime platform or features bundled into broader cloud-security products. Large vendors can integrate code, cloud, identity, and endpoint signals.

Specialists can move faster around a particular technical layer. They must still justify another agent, console, data pipeline, and procurement relationship.

The $60 million round gives OLIGO time to make that case. It does not remove the integration burden facing enterprise customers.

Runtime Blocking Must Prove Precision Without Hiding Risk

OLIGO’s central promise faces a difficult test: blocking exploitation safely is harder than identifying suspicious execution after it happens.

The company says runtime controls can stop attacks without affecting production. That outcome is valuable, but it should be treated as a vendor claim until independently validated.

Production applications behave unpredictably. Legitimate functions can open files, launch subprocesses, deserialize data, access networks, or allocate unusual amounts of memory.

Attackers often exploit the same capabilities. The difference can depend on input provenance, call sequence, user identity, timing, and surrounding application state.

A runtime product must combine those signals fast enough to interrupt the dangerous operation. Delayed detection can permit data theft or follow-on access.

Aggressive blocking creates the opposite risk. A false positive during checkout, authentication, or transaction processing can become a customer-facing outage.

OLIGO says it stops the relevant system call instead of terminating the application. That narrower intervention can reduce disruption, but it cannot make every denied operation harmless.

Applications may enter an unexpected state when a system call fails. They can retry continuously, corrupt a transaction, expose an error, or trigger cascading timeouts.

Enterprise evaluation should include failure testing, not only demonstration attacks. Teams need to see what happens after a blocked action inside their own application architecture.

They should also test observability. Analysts need a clear explanation of the blocked sequence, affected service, originating input, and recommended response.

An unexplained block transfers uncertainty from the vulnerability queue to the incident queue. Security teams then spend time deciding whether the control prevented an attack or broke a valid workflow.

OLIGO’s reported revenue growth suggests customers see value in its approach. It does not disclose enough detail to establish the proportion using blocking in production.

Deployment depth matters more than logo counts. A customer monitoring several test services provides different evidence from one enforcing controls across critical production systems.

The company’s investor commentary also deserves context. Investors and advisers support the company’s strategy, but they are not disinterested evaluators.

Brad Arkin, a former Salesforce chief trust officer, argues that runtime shows what is truly exploitable. Ballistic Ventures says OLIGO protects production without forcing a choice between uptime and security.

Those views explain the investment thesis. They do not eliminate technical tradeoffs or substitute for customer benchmarks.

There is also a strategic risk in overcorrecting toward observed runtime activity. Vulnerability management exists partly to prevent an attacker from becoming the first actor to execute a dangerous path.

Teams should not ignore a severe flaw simply because the vulnerable function has not appeared in normal telemetry. Attack inputs intentionally create abnormal behavior.

Historical observation can establish a baseline, but an application’s future behavior is not limited to its past. New features and rare workflows can change which code runs.

Runtime evidence works best as one layer in a larger control system. Software inventory, patch management, secure development, identity controls, segmentation, and incident response remain necessary.

This layered view does not weaken OLIGO’s value proposition. It sets a realistic boundary around what runtime exploit blocking can accomplish.

The company can help teams focus attention and interrupt dangerous execution. It cannot guarantee that every attack produces an obvious, blockable system-level pattern.

Business-logic abuse remains a difficult example. An attacker can exploit valid workflows, stolen credentials, or excessive permissions without triggering a conventional software exploit.

AI agents expand that concern because they can take actions through authorized tools. A malicious instruction may cause harmful behavior that looks legitimate to lower-level sensors.

Runtime AI security must therefore connect technical execution with identity and policy context. Otherwise, it can observe the action without understanding whether the action was allowed.

Regulated organizations face another question around telemetry. Deep application visibility can expose sensitive code paths, customer data, or operational metadata.

Buyers need clear retention, access, encryption, and regional-processing policies. They also need to understand what data leaves the workload.

OLIGO’s expansion into federal markets raises the standard further. The company joined Palantir’s FedStart program to pursue FedRAMP High and Defense Department Impact Level 5 authorization.

Those milestones would support sales into sensitive government environments. Joining the program does not mean the company has already received the target authorizations.

The difference should remain explicit. Security buyers regularly distinguish an announced compliance path from completed assessment and authorization.

Google News can amplify financing claims faster than enterprise validation accumulates. Readers should therefore separate four different signals.

Funding confirms investor support. Revenue growth indicates reported commercial momentum. Partnerships can improve distribution and integration.

Only operational evidence demonstrates whether runtime blocking remains accurate under sustained production use. That evidence should include prevented incidents, false-positive rates, latency, coverage, and recovery behavior.

OLIGO does not publicly provide a complete set of those metrics. The missing detail is not unusual for a private security company, but it limits outside assessment.

The strongest skeptical position is therefore not that runtime protection lacks value. It is that the company’s broad promise needs more independent, workload-specific proof.

The $60 million round gives OLIGO resources to produce that proof. Enterprise buyers should make evidence a condition of adoption rather than assuming investment validates the technology.

What OLIGO and Its Rivals Must Prove Next

The next phase will be decided by production adoption, defensible performance data, and competitive responses from larger security platforms.

The first signal is evidence from active blocking deployments. OLIGO needs customer examples that show sustained enforcement across important production workloads.

Those examples should explain coverage, deployment scale, and application types. They should also disclose how teams measured false positives and operational overhead.

A case study showing reduced vulnerability noise would support OLIGO’s original thesis. It would not fully validate real-time blocking.

The more persuasive evidence would document an exploit attempt that the platform stopped without interrupting the surrounding service. Independent confirmation would strengthen the result.

Technical evaluations should include known exploits, variant techniques, and benign operations that resemble malicious behavior. Testing only clean demonstrations can hide boundary failures.

If OLIGO publishes repeatable performance and precision data, its claim gains strength. If the company relies mainly on growth figures and broad testimonials, uncertainty remains.

The second signal is the development of its federal and cloud partnerships. OLIGO said AWS selected it as an AI runtime security partner for AWS Security Hub Extended.

The company also joined Palantir’s FedStart program. Both relationships can place OLIGO in front of organizations with complex cloud workloads and formal security requirements.

Integration depth matters. A marketplace listing or partner designation offers less strategic value than shared telemetry, coordinated response, and established procurement routes.

Watch whether these partnerships produce reference customers and verified deployments. Progress toward FedRAMP High and IL5 authorization would also expand the company’s addressable market.

Completed authorization would strengthen OLIGO’s credibility with regulated buyers. Delays would not disprove the technology, but they could slow adoption in a valuable segment.

The third signal is competitive response. Runtime security overlaps with cloud workload protection, application security, endpoint detection, and observability.

CrowdStrike, Palo Alto Networks, Wiz, Sysdig, Aqua Security, and other vendors already collect production signals through broader platforms. Several can add runtime controls to existing customer relationships.

Those companies do not need to reproduce OLIGO’s architecture exactly. They can compete through consolidation, pricing leverage, integrations, and operational familiarity.

Application-security vendors can respond from the other direction. They can combine source analysis, dependency intelligence, reachability, and runtime context.

The central competitive question is ownership. Will buyers treat application-layer runtime protection as an independent category or a feature within a larger security platform?

OLIGO benefits if runtime data becomes a distinct source of truth. A specialist can then win by providing deeper visibility and safer enforcement.

The company faces pressure if customers prefer fewer agents and consoles. Platform vendors can bundle adequate runtime capabilities with cloud, identity, and endpoint controls.

Acquisition is another possible market outcome, although OLIGO has not announced such plans. Security platforms regularly buy specialized technology after a category gains customer demand.

Its valuation increase and financing give OLIGO more negotiating strength. They also raise expectations for independent growth.

The company must demonstrate that reported momentum extends beyond a temporary surge in AI security spending. Buyers increasingly challenge products that attach AI language to established security functions.

OLIGO has a stronger technical link than many vendors because its runtime approach predates the current financing narrative. Its 2023 positioning already focused on executed functions and application behavior.

That history supports continuity. The company is extending an existing architecture rather than presenting a newly relabeled scanner.

Still, the phrase “AI-driven attacks” covers many threat types. Some involve faster exploit development, while others involve social engineering, malicious agents, data poisoning, or model abuse.

OLIGO will need to state which attacks its platform can directly stop. Precise boundaries build more trust than a promise to secure every part of AI.

Security leaders should use the funding news as a prompt for architecture review. They should not treat it as a reason to replace their entire vulnerability program.

Teams can begin by measuring the interval between disclosure, prioritization, patching, and verified remediation. They can identify where runtime evidence would shorten decisions.

They can then test enforcement against representative workloads. Development teams, site-reliability engineers, application owners, and incident responders should participate.

The evaluation should ask whether the control improves both security and operations. A product that stops attacks but creates opaque production failures introduces another form of risk.

Knowledge also becomes important during evaluation. Runtime events must connect with ownership records, architecture decisions, incident history, and remediation work.

Engineering organizations already struggle to assemble that context across local documents and disconnected systems. A searchable technical knowledge base can help preserve investigation evidence and deployment decisions.

That workflow does not replace a security platform. It helps teams understand why a control fired, who owns the service, and what changed before the event.

OLIGO’s financing ultimately represents a bet on time. Investors believe vulnerability management built around periodic assessment cannot keep pace with faster exploit development.

The company’s answer is to observe execution and intervene at the moment an exploit becomes real. That mechanism is technically credible, but its reliability must be proven workload by workload.

Google News will continue carrying funding announcements, product launches, and attack reports. Enterprise security teams need a stricter filter than headline momentum.

They should watch for verified production blocks, completed compliance milestones, and measurable competitive responses. Those signals will show whether runtime becomes a category or another bundled capability.

OLIGO now has $60 million in new backing to make its argument. The next question is whether customers can enforce runtime controls broadly without trading one production risk for another.