There has been an important shift in enterprise cybersecurity, and it is not the arrival of more sophisticated malware. It is the collapse of time.
For decades, organizations managed cyber risk on the assumption that they had time to detect vulnerabilities, assess their severity, navigate approval processes, schedule patch windows, and deploy fixes. That assumption is now obsolete. Industry tracking data suggest that the average time between the disclosure of a vulnerability and its active exploitation is just a matter of hours for the most critical exposures, down from roughly three weeks as recently as 2025. Frontier AI models that can autonomously generate working exploits at scale and at negligible cost have closed the gap.1
AI models, including Anthropic’s Mythos/Fable, OpenAI’s GPT-Cyber, and Google’s Gemini, represent a genuine step change. Rather than simply speeding up attack workflows, they unlock discovery and exploitation, making them accessible to a far larger group of potential attackers. McKinsey analysis suggests that critical novel vulnerabilities without available patches now account for most active exposures.
The question for organizations is not whether a vulnerability will be exploited before it can be patched, but how many vulnerabilities will be exploited. Frontier AI is a concern for chief security officers (CSOs) and chief information officers (CIOs) because it enables more effective attacks and does so faster than enterprise decision-making (Exhibit 1). From that perspective, it presents organizations with an operating-model problem instead of a technology problem.
Organizational latency: The hidden challenge
When asked what is preventing them from responding faster to critical system vulnerabilities, most security leaders seldom say it’s the technology itself. Many organizations already have robust detection tools, patch management platforms, and incident response playbooks. Rapid responses can be achieved with highly standardized environments, zero-trust architectures, and deployment-as-code capabilities. The greater challenge lies in the decision-making processes, governance, and operational coordination needed to translate technical capabilities into action at speed. Consider what often happens when a critical vulnerability is discovered:
- IT security identifies the vulnerability and assesses its severity and the systems affected. This can take a day or more, depending on the visibility of assets across legacy systems, cloud platforms, software-as-a-service (SaaS) applications, and operational technology environments, which are rarely fully inventoried.
- The security team escalates the event to IT leadership, which must assess the butraitsiness impact before authorizing patching. IT leadership then must speak with application owners who are managing release schedules and change freezes.
- The patching of both vendor/off-the-shelf and in-house software must be tested. Organizations that still manage substantial custom or legacy code—which includes most large enterprises—frequently face weeks of validation work before a fix can be certified for production deployment.
- Scheduling the patch window and understanding the release window requires IT leaders to align with people in the business. If they do this, they facilitate business as usual. Manufacturing does not have to stop production lines for patches during peak periods, hospitals do not have to take clinical systems offline during patient care hours, and financial institutions can avoid changes in peak transaction windows.
- Deployment requires sign-off from a change management leader. In many organizations, this requires a change advisory board that meets weekly.
- After all this, vendor-managed and third-party systems may operate on entirely independent patch timelines that no internal team controls.
This is not dysfunction but rather how large organizations are designed to operate. The processes exist to protect up time, manage regulatory compliance, preserve service quality, and avoid the operational disruption that poorly tested patches can cause. However, frontier AI changes the game. Vulnerabilities that once could remain exposed for weeks must now be addressed within hours to stop attackers from causing damage. Organizational architecture has become a direct security liability.
A common challenge is that nobody owns decision speed. IT owns the patching process, the business owns downtime decisions, legal owns disclosure timelines, procurement owns vendor relationships, operations owns production continuity, and security owns risk assessment. No single function has the authority, visibility, and mandate to move the enterprise at the pace the threat requires. As a result, a critical decision that should take hours ends up taking much longer.
The operating model answer: Redesigning decisions
The organizations that navigate the cyber landscape most effectively share a characteristic unrelated to their security tool stacks. They are distinguished by their operating models, and specifically by how they have redesigned the structure of continuous risk visibility, the governance of AI-enabled defense, and the architecture of organizational decision-making under time pressure.
In most cases, these organizations have achieved what we call governed autonomy.
That is, a cyber operating model in which AI handles the high-volume, time-sensitive work of continuous monitoring and routine remediation, while human judgment governs novel threats, strategic risk decisions, and anything material to the business. Achieving governed autonomy is contingent on three design imperatives, each of which is organizational before it is technical.
Continuous risk visibility is table stakes
The first design imperative is to move the organization from periodic scanning and scheduled remediation cycles to continuous operational awareness anchored on what matters most. This requires an explicit decision about scope and sequencing.
The practical starting point is not to aim for real-time visibility across the enterprise. That ambition consistently fails because the scope is too large and the change required is too disruptive. Instead, leading organizations begin by defining a minimum viable organization, which is the irreducible core of systems, processes, and assets whose disruption would be existential. For a bank, that might be payment processing, core banking, and regulatory reporting. For a manufacturer, it could be production lines and the Operational technology (OT) systems that govern them. For a hospital, it may be clinical systems and life-critical infrastructure.
By first concentrating on near-real-time visibility and continuous scanning on the core, organizations can create a defensible perimeter around what matters most. In parallel, they can reduce the attack surface, retiring unnecessary external-facing assets, rationalizing open-source code dependencies, removing stale credentials, and tightening network segmentation. At one global financial institution, leaders found that prioritizing large language model scanning on its minimum viable bank produced a material reduction in exposure around its highest-value assets faster and at a lower cost than previous approaches.
Critically, reducing the attack surface is not just a technical exercise. It requires business decisions about which assets to retire, which external interfaces to close, and which third-party integrations to restrict. Those decisions simultaneously involve IT, operations, business owners, and legal. The speed of organizational alignment determines the speed of surface reduction.
The governance of AI-enabled defense must be foundational architecture
The second design imperative is to deploy defensive AI as the operating architecture for security operations. Three distinct layers define that architecture, each of which must be designed as an “agentified” end-to-end workflow rather than assembled from independent vendor solutions:
- Threat hunting and attack-path discovery: AI models can run continuous attack-path chaining analysis across complex, heterogeneous environments—correlating signals across IT, OT, cloud, and third-party systems to reveal exposures and prioritize remediation backlogs based on real exploitability and business-value exposure, rather than generic severity scores. This matters because common vulnerability scoring systems do not distinguish between a vulnerability in a test environment and the same vulnerability on a system that is three steps from “the crown jewels.” AI-enabled prioritization can make that distinction continuously and at scale.
- Vulnerability remediation and third-party risk management: For organizations that build and maintain significant software, meaning most large financial institutions, industrial companies, and technology-intensive manufacturers, AI-assisted threat modeling, automated pressure-testing during the software development life cycle, and AI-generated patch suggestions can dramatically compress the time between vulnerability identification and a tested fix being available. This addresses one of the most stubborn bottlenecks: the time it takes a development team to understand, reproduce, and fix a vulnerability in code they may not have touched in years.
Open-source software components can become a liability due to attackers’ ability to easily identify or integrate vulnerabilities and eventually use them for exploitation (for instance, in the case of downstream attacks). Organizations should create internal transparency into where and how these components are deployed and then engage in frontier-AI-based vulnerability scanning, including before deployment, and AI-assisted patch development where applicable. For commercial software, remediation service-level agreements for third-party suppliers need to be updated to cover chained vulnerabilities. Finally, consequence management must be strengthened.
- Incident response and security operations: AI can automate triage, accelerate containment sequencing, and coordinate cross-functional response without waiting for a human decision-maker to be available. Leading organizations are preauthorizing AI agents to execute specific, bounded response actions, including isolating systems, revoking credentials, and applying compensating controls—all within defined guardrails. For low-risk responses, human review follows the action. This is not autonomous security; it is governed by speed. Business continuity and crisis processes must be retested against that reality, with a clear, pre-agreed-upon view of the minimum viable organization that must continue to run while everything else is quarantined.
The objective in all three layers is to ensure that human judgment is reserved for decisions that genuinely require it, and that routine, time-sensitive remediation actions do not wait.
The architecture of organizational decision-making must be optimized for time pressure
The third design imperative, and the most underestimated, is redesigning the decision-making architecture itself. The reality is that most organizations still manage cybersecurity through governance structures designed for a different era. There is a common belief that the risk of an unnecessary or poorly controlled change outweighs the risk of a slow one. Change advisory boards, security steering committees, cross-functional working groups, and escalation chains that cross several C-suite functions all instinctively buy into that premise. But when a vulnerability is exposed to fast-paced, AI-enabled active exploitation, delay becomes the bigger risk.
Leading organizations are redesigning organizational decision-making processes around a cross-functional response cell, which is a small, empowered team with a single decision-maker who holds CSO-delegated authority to override standard change management processes for confirmed active threats. The cell runs a daily triage cycle and owns a real-time vulnerability backlog. It has preauthorized playbooks for responses that it can execute without escalation. And it has an executive liaison who translates technical progress into board-level visibility every 24 hours. The roles are clearly defined, with decision authority explicitly assigned rather than diffused.
Thus, the key design imperative is that decision authority is genuinely centralized. One financial institution restructured its patch management governance after an incident in which a critical vulnerability sat unpatched for 11 days because no team had the technical visibility and business authority to override a production change freeze. The restructured model gave its response cell lead explicit CSO-delegated authority to act, with postaction reporting replacing preaction approval for confirmed active threats. Remediation timelines for critical vulnerabilities fell significantly.
A pharmaceutical company took a similar approach to one of the most intractable bottlenecks: R&D environment update backlogs that routinely deprioritize security patches behind product development schedules. The fix required a change program led by the business (not the IT function), which formally established remediation-first sequencing in R&D environments and gave the security function standing authority to override development schedules during active threats. The organizational intervention helped address the root cause in a way that technology alone could not.
One corollary of the three imperatives is that governance redesign should extend to broader crisis operating models. Leading organizations are investing in cross-domain response structures that can simultaneously coordinate action across cyber, physical, and operational dimensions. A European aerospace and defense company, for example, built a security intelligence center that integrated its cyber operations center, physical security operations, and external threat intelligence into a unified, real-time view. The company wanted to enable a coordinated response to attacks that combine digital and physical vectors. A European insurer consolidated its resilience capabilities under a single head of resilience. It established a quarterly resilience council at the board level, recognizing that the organizational silos among cybersecurity, business continuity, and physical security were themselves vulnerable.
Governed autonomy in practice
Governed autonomy sits within an organization’s broader resilience architecture, which operates across six dimensions: financials, operations, technology, organization, reputation, and business model.2
A CSO who owns only the technology dimension without explicit connections to organizational and operational resilience cannot implement governed autonomy successfully. The model requires joint ownership across the C-suite. The implementation journey should follow a consistent pattern, usually with three phases, each building the organizational muscle that the next requires.
Before examining how the model works, it is worth asking where your organization currently sits. Most enterprises we work with are in one of three positions:
- Strong security tooling is in place, but there is diffuse decision authority, and no one is empowered to act at speed (the most common state of affairs).
- There is centralization of some decision-making, but with a connection to AI-enabled operations.
- The organization is beginning to deploy AI agents into an environment where the governance architecture to manage them does not yet exist.
Each position has a different highest-priority action, which may, for example, be technology deployment or organizational change. The three-phase model describes the path from the first position to the third, and the organizational decisions that determine whether an organization makes a move (Exhibit 2).
In implementing governed autonomy, three overarching phases apply:
- First, the operating model does not just enable AI deployment; it governs AI usage across the organization. Accuracy thresholds, trust calibration processes, automatic revocation of autonomous authority for systematic errors, and postaction reporting requirements can ensure that, as automation expands, human accountability expands with it. This is what autonomy in practice means: It is not a constraint on AI’s potential; the architecture makes AI safe to use. For example, a patching (orchestration) agent with far-reaching access and autonomy to deploy, so it can match the speed of threats, should also be treated as a critical asset that requires safeguards to prevent compromise or behavioral drift.
- Second, the operating model is designed to build organizational capability before extending AI authority. Phase one, or the human surge, is about centralizing human decision-making and establishing AI governance discipline. Organizations that skip phase one and attempt to deploy AI agents into an environment where decision authority remains diffuse consistently produce AI systems that generate recommendations nobody acts on.
- Third, and most important, the operating model requires CEO and board sponsorship. Our experience across implementations shows that organizations that treat governed autonomy as a security program stall at phase one. The bottlenecks are business decisions regarding production downtime, change management authority, development prioritization, and vendor obligations, which the security function cannot resolve unilaterally. Organizations that treat governed authority as an enterprise resilience program, with explicit executive sponsorship and board-level governance, are more likely to progress through all three phases.
Governed autonomy can help leaders determine who decides what, with what authority, on what timeline, governed by what rules, and accountable to whom. It is the operating architecture inside which the technology performs. Without it, the best tools in the market sit behind the same committee approval chains that were a problem to begin with.
Operating model discipline under compressed timelines
The operating model discipline described here addresses the most urgent dimension of the challenge. But a second wave of complexity is already forming. Deploying agentic AI systems at scale introduces a new class of foundational requirements, including data access boundaries, identity controls, and behavioral guardrails that must be defined and enforced before autonomous agents can be trusted to act. Getting those foundations right is a governance decision with board-level consequences.
The same principle applies to the emerging economics of AI-driven security. Put another way, the cost per query of running large models continuously across threat detection, remediation, and response is introducing a category of budget pressure that traditional security spending models were never designed to absorb.
Perhaps most consequentially, the CSO role itself is being redefined. The agentic CSO of the near future will be less of a technical authority and more of an architect of governed autonomy at scale, setting policies for AI systems that act rather than advise and being accountable for decisions made at speeds no human can directly supervise. These are the challenges that will shape the next phase of this work.
The organizations that perform best on cybersecurity over the next three to five years will be those that act early to redesign decision rights, build governance capable of operating at machine speed, invest in the discipline to govern autonomous AI remediation, and connect their cyber resilience directly to the business outcomes it protects. These include manufacturing uptime, customer trust, regulatory standing, and continuity. The security budget will matter far less than the clarity of the operating model.
The implication extends beyond cybersecurity. AI is compressing management timelines across enterprise functions. Organizations that build the capability to make high-stakes decisions faster, with better information, under time pressure, will carry that advantage across their operations. But cybersecurity is the domain where compression is happening first, at the highest stakes, with the least tolerance for delay. Thus, it is the right place to build the operating model muscle that the next decade of enterprise leadership will require.
