What Black Hat 2026 Revealed About the Future of Security Operations
Cybersecurity has always been a race against time. Black Hat 2026 made it clear that AI is putting new pressure on the clock.
The industry’s answer to growing risk has long included more visibility, more detection and more specialized tools. Those investments generated valuable information, but they also created a coordination problem: someone still has to assemble the context, figure out what happened, determine what matters, decide what to do, get that decision to the right person or system and verify the outcome. Simply put, there is more telemetry and findings than humans can reasonably make sense of.
Closing that gap will require a new operating model that uses AI to pull that context together, speed up investigation and move routine work toward action, while relying on human expertise for judgment, business impact, and consequential decisions.
AI Is Changing the Economics of Cyber Operations
David Weston, corporate vice president of Enterprise and OS Security at Microsoft and Black Hat mainstage presenter, captured the offensive side of this shift in theCUBE’s conversation with him. Sophisticated vulnerability discovery used to depend on scarce expertise, time and money. AI reduces those costs by helping researchers work through technical problems, find vulnerabilities, and scale work that previously required extensive amounts of time and specialized expertise.
Threat research unveiled at Black Hat adds weight to that picture. Fortinet’s Derek Manky, Chief Security Strategist and Global VP of Threat Intelligence, said on theCUBE that the attack window has moved to under 20 hours. He described the new cybercrime economy: attackers already operate through an established ecosystem of people, infrastructure, malware, affiliates and financial mechanisms, and AI gives that ecosystem another source of leverage.
In a separate conversation, Joe Hladik, head of Rubrik Zero Labs, cautioned against getting too far ahead of what threat researchers are seeing. His work points to the combination of human tradecraft and AI as the more immediate concern. AI can handle procedural and logical work while a skilled researcher or attacker provides creativity, intuition and knowledge of how systems can be manipulated.
Rubrik’s own research illustrates that combination. Researcher Ori Lahav used AI while investigating a widely deployed enterprise AI assistant and uncovered a sandbox escape that could have exposed backend cloud infrastructure. The vulnerability was responsibly disclosed and patched. The broader finding is that AI can amplify skilled technical research and make parts of that work faster without replacing the expertise behind it.
For defenders, the implication is that portions of the attack process can happen faster and become accessible to more people, putting additional pressure on an enterprise response process that still contains a great deal of manual coordination.
Security Operations Have a Coordination Problem
The obvious defensive response is to use AI to move faster too, and there is value in that. Security teams spend enormous amounts of time gathering information, correlating signals and working through cases that ultimately require little human judgment. But speed at any individual step only gets you so far.
Consider how a security event moves through an enterprise. An alert may begin in one tool. Relevant identity information sits somewhere else. Vulnerability context lives in another system. Production information may belong to engineering. Business criticality may not exist in a security system at all. Bringing those pieces together is the actual work of investigation.
To frame the work that security organizations are trying to compress:
Context → Investigation → Prioritization → Decision → Action → Validation
Today, people provide the connective tissue. They collect evidence from different systems, determine whether the signals are related, decide whether the event matters and route the resulting decision to someone capable of acting. Every handoff adds time, though, and AI creates the possibility of moving more of that coordination into software.
Investigation is one of the clearest places to start, with AI able to correlate alerts and raw events, assemble evidence and present an analyst with a more complete case rather than another signal to investigate.
Prioritization presents a similar opportunity. A technically severe vulnerability may pose little immediate risk in one environment and demand urgent attention in another. Sorting one from the other requires threat intelligence, information about the organization’s controls, production context and some understanding of potential business impact. AI can help perform that reasoning faster, but its usefulness depends on whether the information required to make the decision is available.
Context Becomes Part of the Security Architecture
That underscores the architectural problem that security teams have long compensating for manually. Security data is fragmented because enterprise technology is fragmented. Endpoint systems understand one part of the environment. Identity systems understand another. Vulnerability platforms, cloud security tools, application telemetry and threat intelligence each contribute another piece, and human analysts have traditionally connected those fragments by hand.
As software takes on more investigation and prioritization, the quality of the decision will depend on whether it can assemble that context itself. A model can reason very quickly and still reach a poor conclusion when it lacks information about the environment. That problem reaches beyond security telemetry, too.
Datadog CISO Emilio Escobar discussed the value of security and engineering working from shared operational data during our theCUBE conversation. Today, understanding an event may require security context, production behavior, application dependencies and business impact to come together at the point of decision. That makes context part of the security architecture rather than an enrichment step added after an alert fires, and it changes how enterprises should evaluate AI security capabilities. It makes a critical difference if the system has comprehensive visibility across the organization’s environment, understands where that knowledge comes from, and is current enough to support the decision being made.
The Task Is the Practical Unit of Autonomy
The most difficult boundary comes when software moves from understanding a problem to doing something about it.
Gathering evidence carries relatively little operational risk. Closing an obvious false positive carries more. Disabling a privileged identity, isolating a production system or changing infrastructure can affect the business immediately. Treating autonomous security as a single capability obscures those differences: the task, not the SOC as a whole, is the practical unit of autonomy, and security leaders need to decide what software can do under which conditions and what level of confidence is required before it acts.
Evidence gathering can happen with little intervention. Routine investigations can be assembled automatically. Some high-confidence cases may be resolved without a person touching them. Actions with greater operational consequence require tighter controls and clearer escalation paths, though, because the threshold should reflect the consequence of being wrong.
Human oversight also has to be designed carefully. Requiring a person to approve every AI-generated decision simply moves the bottleneck. People add the most value when evidence is ambiguous, a situation falls outside established policy, or a decision carries meaningful business consequences. The role of security becomes establishing controls, thresholds and escalation paths, while decisions that could materially affect a critical business process require the context and accountability of the business owner. AI can reduce the amount of work people perform inside the operating loop, but accountability for the outcome stays with people and the organization.
A Faster Operating Loop Is Only Half the Answer
There is a real danger in reducing the AI security discussion to a contest over speed. If attackers can find vulnerabilities faster, defenders investigate faster and remediation happens faster, both sides remain in the same cycle.
Weston’s Black Hat argument points toward another source of leverage. Some of AI’s productivity gains can be invested upstream in software construction. Memory-safe languages can remove classes of vulnerabilities. Formal verification can provide stronger assurance about how software behaves. Infrastructure validation can catch problems before deployment. AI can help reduce the cost of applying practices that historically have been difficult to use broadly, and every vulnerability prevented before production is one less finding to investigate, prioritize, remediate and validate later.
Security teams will still have a large installed base to defend. Enterprises will continue to operate software they did not build, and attackers will continue to find new paths. The operating model has to work in both directions: compress the path from context to action for risk that reaches production, and reduce the amount of preventable risk entering that path upstream. That brings security operations closer to software engineering, architecture and infrastructure decisions, another theme I will return to later in this series.
What Changes Now?
Black Hat 2026 did not convince us that the autonomous SOC has arrived. Rather, it made a strong case that the economics and operating model surrounding security operations are changing. Attackers have new ways to reduce the time and expertise required for portions of their work, and defenders have an opportunity to remove human coordination from portions of theirs.
For security leaders, a useful starting point is to understand where time disappears inside the operating process:
Context → Investigation → Prioritization → Decision → Action → Validation
Where are people manually assembling information? Where does an investigation wait on another team or tool? Which decisions are repeatable enough to move to software? Which actions carry enough consequence to require human judgment? How does the organization know an automated action produced the intended outcome?
Then look upstream. Identify recurring security work that better software design, infrastructure or architecture could prevent altogether. AI can help on both fronts: it can compress the work between evidence and action, and it can make some safer engineering practices more practical. The shift worth watching is in the operating model itself: where security work happens, which work software can absorb, where people add the most value and how quickly the organization can turn security information into action.
This is the first piece in our post-Black Hat 2026 series. Next, we’ll examine how security and identity models need to evolve as AI agents gain the ability to access data, use tools and act on behalf of the business.
