Machine Speed Won

Now turn the dial where your security stack has the most white space.

Key Points

• The Machine Speed Gap is the distance between how fast attackers can act and how fast defenders can understand and respond.
• A mature stack isn't failing, but its coverage has boundaries. The white space sits in runtime, among EDR, SIEM, CNAPP, and identity controls.
• Map new capabilities to the risk register, not to vendor categories, and put an economic model with your own inputs behind the decision.
• Layer first, rationalize later. Coexistence beats demolition, and consolidation should follow evidence after deployment.
• Agentic Runtime Security fills the runtime white space across cloud, SaaS, identity, third-party services, and AI.

An autonomous AI agent executed more than 17,000 recorded actions across Hugging Face's production infrastructure over a single weekend. Their team reconstructed what happened in hours, using AI-driven investigation agents, instead of the days that kind of analysis used to require.

That incident, alongside the revelations of Anthropic's Mythos and the accelerating economics of AI-enabled vulnerability discovery, comes down to a single phrase. Machine speed. IBM's latest breach research put numbers behind what many of us have been watching operationally. AI is changing how quickly attacks can be launched and how expensive they can become once defenders fall behind.

But the most useful conversation with CISOs and SOC leaders begins somewhere else. It begins with the security stack they already own.

Virtually no large enterprise is starting from zero. They have EDR. SIEM. CNAPP. Identity security. Firewalls. Email security. Vulnerability management. SOAR. Maybe XDR and an MDR provider. Increasingly, they're looking at DSPM, SSPM, AI security tools, and another wave of capabilities arriving behind them.

Every one of those investments was made, and will be made, for a reason.

So, when the threat landscape changes, the useful question becomes, “Where has my risk moved, what white space remains between the controls I already have, and what is the highest-value capability I can layer in next?”

The stack isn't failing. The environment keeps moving.

Cybersecurity has always been defense-in-depth. A CISO doesn't wake up every January and redesign the entire security architecture. They refine it.

The endpoint estate changed, so teams made EDR essential. Cloud adoption created new exposure, so they layered in CSPM, CNAPP, and cloud-native controls. Attackers made identity a primary attack path, so CISOs moved identity security higher on the agenda.

Now cloud, SaaS, AI, non-human identities, APIs, and third-party services are changing the shape of modern infrastructure again. The existing controls don't suddenly become bad investments because that happens. Their coverage simply has boundaries.

Some people know how to cut to the heart of it. One of the better security conversations I've had recently started very directly with, "Show me where you fit into what I already own."

I was surprised that this isn’t a more common question. CISOs have plenty of reasons to ask it. Wiz's 2026 CISO Budget Benchmark found that 58% of organizations already operate more than 25 security tools, with large enterprises commonly running 50 or more. Nearly half said cloud complexity and tool sprawl are actively holding their programs back.

IDC is seeing the same response from buyers. 84% of organizations surveyed said security platformization is now a priority.

Nobody asks for another console because the threat landscape got worse. The bar is higher than that. A new capability should close meaningful risk, make existing controls work better, improve the economics of the operation, or preferably some combination of all three.

Where the Machine-Speed Gap shows up in a mature stack

I still believe the Machine-Speed Gap is one of the defining problems security operations now face.

The Machine-Speed Gap is the widening distance between how quickly an attacker can act and how quickly a defender can understand what happened and respond safely. Attackers can increasingly automate reconnaissance, vulnerability discovery, credential abuse, lateral movement, and other stages of an intrusion. The defender still has to understand what happened well enough to make a safe decision about what happens next.

We’ve seen again and again in cloud investigations recently that the attack timeline usually exists. It's just scattered across five or six systems. AWS has one piece. Microsoft 365 or Okta has another. Salesforce, GitHub, an OAuth token, an AI service, or a third-party platform fills in the rest. Someone has to assemble those fragments into one attack. And that work gets even harder as infrastructure becomes more distributed and attackers become faster.

That's also what exposes an important kind of white space in many otherwise mature security programs. EDR is exceptionally good at the endpoint. CNAPP gives teams critical posture, workload, and cloud-risk visibility. SIEM provides aggregation and analytics across enormous volumes of security data. Identity products protect another critical control plane.

The gap appears in the runtime between them. It's the work of understanding an active attack as it crosses cloud, SaaS, identity, third-party services, and AI, and doing it fast enough to interrupt the outcome.

Defense-in-depth has a new speed requirement

Greg Brockman's ten-point Defender's Window agenda starts where most of us would expect. With defense-in-depth, least privilege, secure architecture, strong monitoring, safe patching, and multiple independent controls between an attacker and a catastrophic outcome.

Those fundamentals actually become more important in an AI world. Then comes the new layer.

Like Mitiga, OpenAI uses AI to triage nearly all initial security alerts before a human gets involved, and Brockman argues that defenders need to move toward machine-speed detection and bounded automated response. He pragmatically recommends defenders to start with read-only analysis, let AI work through resolved alerts, move into live triage, practice AI-assisted forensic investigation before the incident occurs, and progressively automate narrowly defined actions as confidence grows.

Layered defenses still hold up. Machine speed changes what the next layer needs to do. Increasingly, that means recognizing, investigating, and interrupting what slips through the other controls while there is still time to change the outcome.

Start with the risk register, not the category

Look at what the organization is already carrying. Which exposures survive quarter after quarter because remediation takes too long? Which mission-critical SaaS applications are unsanctioned or have thin runtime monitoring? Where are non-human identities and AI agents operating? Where does an investigator still have to string together multiple systems manually before anyone knows what really happened?

Then map technology to those gaps.

A new control earns its place when it moves one or more risks down the register far enough to justify the operational and financial cost of owning it. Perfect security isn't the goal. Aim for measurable risk reduction per dollar and per hour of security team effort.

The economics belong in the architecture discussion

A security investment creates security value, but it also consumes analyst time, engineering capacity, infrastructure, storage, integrations, training, procurement effort, and budget. A technically impressive control that adds another stream of alerts, another data tax, and another team to administer it may improve one part of the risk profile while making the operating model worse somewhere else.

That calculation is even more important in a mature stack. I think about it in three buckets: time your analysts get back, cost you take out of the operating model, and risk that moves off the register.

Time recovered

People are the scarcest resource in most SOCs.

So how many analysts and engineering hours you get back, rather than how many alerts the platform generates, becomes the new economic question.

Helios AIDR, the AI-native operational model that powers our Agentic Runtime Security, analyzes 100% of alerts automatically and closes 95% of benign or noisy signals without any analyst involvement. That’s the equivalent of four senior analyst FTEs released back to the SOC. Detection engineers who were rebuilding SaaS coverage from scratch now cover 3× the signal volume without proportional headcount growth; three FTEs shift from building detections to actual threat hunting. For alerts that do escalate, resolution drops from an hour to ten minutes. Active incidents move from three hours to ten. Six times faster, end to end.

Helios AIDR also reduces incident response effort by 50%, with AI-led investigations and pre-populated forensic data cutting the manual work in half. Across signal expansion, autonomous closure, and faster threat resolution, the modeled annual value from time recovered is approximately $1.135 million. The 2026 IBM report backs the bucket. Security teams using AI and automation extensively shortened breach times by 65 days and cut average breach costs by $1.93 million.

Senior analysts get their week back for the work that really requires senior analysts. That’s capacity, not just speed.

Cost removed

The operating model itself has a price.

Most enterprises are paying around $350 per GB per year to ingest modern infrastructure logs (cloud/SaaS/identity/AI) into a SIEM, and still can’t fully investigate what they ingested. Mitiga replaces that ingestion cost with a purpose-built forensic data lake, including cloud, SaaS, AI, and identity logs retained for 1,000 days, normalized and investigation-ready from day one. This also solves for enterprises who may not be ingesting critical SaaS and AI logs.

In Mitiga’s economic model, SIEM tax elimination accounts for approximately $1 million in modeled annual value for the representative enterprise. When assessing your own model, ask, “How much are you paying to ingest data you can’t fully use?”

Risk retired

To the board, we have a simpler question. “How much material cyber risk moved?”

IBM’s 2026 Cost of a Data Breach Report puts the public-cloud breach average at $5.38 million, the costliest data storage location in this year’s study, and finds that AI-driven attacks now add roughly $1 million to the average malicious breach. Mitiga’s early runtime detection, contained blast radius, and faster response reduce that financial exposure by 90%. The modeled annual breach avoidance value is approximately $4.842 million.

Combined with the operational categories above, the representative-enterprise model reaches approximately $6.977 million in modeled annual economic benefit, per Mitiga’s ROI Framework M-tier organizations ($1B–$50B revenue).

I wouldn’t present $6.977 million to every CISO as some universal ROI number. It isn’t. Put in your SIEM volume. Your analyst burden. Your detection-engineerin costs. Your incident history. Now we’re having a business conversation.

A six-month payback claim without a baseline is marketing, and I’m a marketing guy. A model grounded in your own environment becomes something a CISO can take to a CFO.

Our CAB feedback reinforced that point. Security leaders wanted ROI tied to a worked baseline and explicit outcomes rather than broad claims about payback.

Layer first. Rationalize later.

There is another mistake I think vendors make when entering an established security program. They arrive with a demolition plan.

Most CISOs don't need one. They need a way to close an important gap without destabilizing controls their teams already know how to operate. I like the phrase one CISO used with us recently: "Drip and replace."

Layer the new capability into the existing environment. Prove that it closes the gap. Measure the operational improvement. Let it work with the SIEM, EDR, SOAR, ticketing, and incident-response processes already in place. Then look at the stack again. Maybe nothing comes out. Maybe a SIEM data tier can shrink. Maybe custom SaaS detection engineering disappears. Maybe two overlapping point solutions no longer justify their renewals.

Make that call on evidence after deployment. Don't hand it to a vendor insisting that everything you already own is obsolete.

Our CAB was unusually consistent on the point that coexistence helps a buyer immediately understand where a new capability fits, while consolidation can happen later where the economics and operational results support it.

Where does Agentic Runtime Security fit in the stack?

At Mitiga, we've developed a shorthand for the white space we're talking about. "EDR protects your endpoints. Mitiga protects everything else."

No security product literally protects "everything else." The point is architectural. EDR established a mature runtime-defense model for endpoints. The white space we're focused on is AI-native runtime security across the rest of the modern infrastructure, including cloud, SaaS, identity, third-party services, and AI.

The question, where does runtime security fit into your stack, is narrower than that. How well can the current stack anticipate, detect, investigate, and interrupt an attack that moves across those environments while it is happening and before it makes an impact?

If the answer is already excellent, that's useful to know.

If investigators still need to manually stitch together five systems, if SaaS activity disappears into expensive SIEM storage, if embedded AI agents and non-human identities are difficult to follow across trust boundaries, or if runtime activity outside the endpoint remains thinly monitored, there is meaningful white space.

That's where Agentic Runtime Security, powered by a contextualized and correlated Cloud Security Data Lake, fits. It adds an investigation-grade data and runtime-defense layer that strengthens the systems around it. The layer contextualizes evidence for analysts, supplies higher-quality information to SIEM and SOAR, gives AI agents data they can reason over, and interrupts active, machine-speed threats earlier.

The capability should make the rest of the stack better. If it doesn't, why add it?

The operational case for SOC leaders and detection engineers

The analyst pivoting between the AWS console, Okta, and Microsoft 365 to piece together one attack timeline isn't slow. It’s the processes that are slow. The data exists. It's expensive and fragmented and uncontextualized. Retaining enough of it to investigate a breach that started 90 days ago can cost more than the investigation itself. Detection rules built in-house for SaaS applications break every time a vendor updates their schema.

Set the ROI models aside. The operational case for a contextualized, normalized, and correlated data layer is whether your team gets to the attack narrative before the attacker moves.

The Autonomous SOC makes this discipline even more important

Machine speed still changes the operating model. I haven't backed away from that argument.

Within the next couple of years, maybe sooner, I expect autonomous investigation to become a standard part of large enterprise SOCs. Human analysts simply won't manually process every action generated by machine-speed attacks.

To get there, organizations don’t need another wave of siloed AI tools. Brockman's roadmap is instructive precisely because it's incremental, which raises the most important architecture questions. What data will those systems reason over? Which actions can they take? Where do humans remain accountable?

Those questions tell me far more than whether a vendor has an "agentic" feature.

Machine speed won. That doesn't mean panic wins.

Attack economics are changing, and investigation windows are shrinking. AI will make both attackers and defenders more productive. The SOC will become increasingly autonomous.

All of it calls for an honest inventory.

Where are you paying twice for the same capability? Where does an analyst still have to become the integration layer? Where can AI remove meaningful busy work today? Where could an attack slip through several good controls and still go unseen in runtime?

Then fill the white space deliberately. Layer in the capability. Measure the security outcome, the operating impact, and the economics. Keep what works. Rationalize what no longer earns its place.

That's how I think the next security stack gets built. Find the white space. Turn the dial where it reduces the most risk.

Machine speed already won. Our job now is to make sure the economics, architecture, and operating model catch up.

EDR protects your endpoints. See what protects everything else.

Frequently asked questions

What is the Machine-Speed Gap?

The Machine-Speed Gap is the distance between how fast attackers can act and how fast defenders can understand what happened and respond. Attackers automate reconnaissance, vulnerability discovery, credential abuse, and lateral movement; defenders still have to assemble evidence scattered across five or six systems before they can make a safe decision.

Where does Agentic Runtime Security fit alongside EDR, SIEM, and CNAPP?

It fills the runtime gap between the controls a mature program already owns. EDR defends the endpoint, SIEM aggregates and analyzes, and CNAPP manages cloud posture. Agentic Runtime Security detects, investigates, and interrupts active attacks as they cross cloud, SaaS, identity, AI, and third-party services.

How should a CISO measure the ROI of a new security control?

Measure the time your analysts get back, the cost removed from the operating model, and the risk that moves off the register. Ground the model in your own inputs, such as SIEM volume, analyst burden, detection-engineering costs, and incident history, rather than a vendor's universal payback claim.