AI Security

    Exploits Now Arrive in Hours. Your Approval Chain Still Takes Weeks.

    McKinsey research finds the gap between disclosure and active exploitation of critical vulnerabilities has shrunk from about three weeks to a matter of hours. The slowest part of most responses is no longer the technology. It is deciding who can act.

    Jeff SowellOctober 12, 20267 min read
    Exploits Now Arrive in Hours. Your Approval Chain Still Takes Weeks.

    McKinsey opened Cybersecurity Awareness Month with a collection titled "Time is of the essence: Cybersecurity in the age of AI". The argument fits in one line: in the age of frontier AI, time is the enemy of the security team. We agree, and we think the most useful part of the research is where it puts the blame. It is not the tools. It is how long it takes an organization to make a decision.

    Three weeks became a few hours

    In "The speed problem: How frontier AI exposes weakness in enterprise cybersecurity" (September 11, 2026), Benjamin Klein, Charlie Lewis, Rich Isenberg, Venky Anant and their coauthors cite industry tracking data showing that, for the most critical exposures, the time between a vulnerability being disclosed and being actively exploited is now a matter of hours. As recently as 2025 it was roughly three weeks. Their explanation is frontier AI models that can write working exploits on their own, at scale, for almost no cost.

    They add that McKinsey analysis now finds critical novel vulnerabilities without an available patch account for most active exposures. So the old question, will we patch before it is exploited, has turned into a different one: how many of these will be exploited before we act?

    The bottleneck is the approval chain

    The authors walk through what usually happens when a critical vulnerability lands. Security finds it and works out which systems are affected, which can take a day or more when the asset inventory is incomplete. IT leadership assesses business impact. Application owners check release schedules and change freezes. Patches get tested. Someone negotiates a maintenance window with the business. A change advisory board, which in many organizations meets weekly, signs off. Vendor-managed systems patch on their own timeline regardless.

    None of that is dysfunction. Those steps exist to protect uptime and avoid bad patches. But the authors are blunt about the result: "nobody owns decision speed." IT owns patching, the business owns downtime, legal owns disclosure, procurement owns vendors, and security owns the risk assessment. No one has the authority to move all of it at once.

    Their clearest example is a financial institution where a critical vulnerability sat unpatched for 11 days because no team had both the visibility and the authority to override a production change freeze. After the institution gave its response lead CSO-delegated authority to act, and replaced approval before the fix with a report after it for confirmed active threats, remediation times for critical vulnerabilities fell significantly.

    What McKinsey recommends

    The authors call the target model "governed autonomy": AI handles high-volume, time-sensitive monitoring and routine fixes, and people decide on novel threats, strategic risk and anything material to the business. They describe three design imperatives:

    • Continuous visibility, starting small. Instead of trying to watch everything in real time, define a "minimum viable organization," the core systems whose loss would be existential, and watch those first. Shrink the attack surface in parallel by retiring unused external assets, removing stale credentials and tightening segmentation.
    • AI-enabled defense, with guardrails. Use AI for attack-path analysis, faster fixes and incident response. Leading organizations preauthorize agents to take specific, bounded actions, such as isolating a system or revoking a credential, with human review after the fact for low-risk responses.
    • Decision rights built for time pressure. Stand up a small response cell with one decision-maker who holds delegated authority to override normal change management for confirmed active threats, preapproved playbooks, a daily triage cycle and a liaison who briefs leadership every 24 hours.

    They also warn against skipping steps. Organizations that put AI agents into an environment where decision authority is still spread out get "AI systems that generate recommendations nobody acts on." And programs run purely as security projects stall, because the hard calls (downtime, change authority, vendor obligations) belong to the business.

    What this means for a mid-market company

    McKinsey wrote this for large enterprises with change advisory boards and security steering committees. Most of the companies we work with have neither. That sounds like an advantage, and partly it is: there are fewer committees to get through. But a smaller company usually has the same problem in a different shape. The decision to take a system down during business hours belongs to whoever happens to be available, the IT provider is waiting for permission, and nobody wrote down who is allowed to say yes.

    The fixes scale down well:

    1. Write down your minimum viable organization. For a lender it might be the core banking platform and wire processing. For a clinic, the EHR and scheduling. Keep it to a handful of systems and know where each one is exposed to the internet.
    2. Name one person who can act. Give them written authority to take a critical system offline, or apply an emergency change, when a confirmed active threat hits it, with a report to leadership afterward instead of a meeting beforehand.
    3. Preapprove the first moves. Isolate the host, disable the account, block at the edge, rotate the credential. Agree on these with your IT provider and insurer now, so nobody has to ask during an incident.
    4. Put patch timelines in vendor contracts. McKinsey notes that third-party systems often patch on their own schedule. Ask your MSP and key SaaS vendors how fast they fix critical vulnerabilities, and get it in writing.
    5. Govern the automation you add. If you give a tool or AI agent the power to patch or isolate systems, treat it as a critical asset: limit what it can touch, log what it does, and decide who reviews it. The authors make the same point about patching agents with broad access.
    6. Rehearse it. Run one tabletop where the scenario is an internet-facing system exploited within hours of disclosure. Time how long it takes to get a decision. That number is your real exposure window.

    For related guidance, see our first 24 hours playbook for edge appliance zero-days, our vendor breach playbook and our tabletop exercise guide.

    Agents raise the stakes

    McKinsey's companion piece, "Securing the agentic enterprise: Opportunities for cybersecurity providers" (March 24, 2026), by Charlie Lewis, Jeffrey Caso, Alexander Keegan, Marc Sorel and Julian Fuchs-Souchon, shows how fast agents are arriving on the defense side. In a McKinsey survey of cybersecurity solution buyers, 35 percent expect AI agents to replace their tier-one SOC analysts, and nearly 50 percent expect AI to be embedded across the security stack within three years. More than 75 percent say they are looking for protection against AI input manipulation, and roughly 30 percent are not confident their current vendors can handle these risks.

    Read those numbers together with the speed problem. Organizations will hand agents real authority to fix things quickly, and those agents become part of the attack surface. Deciding what an agent may do alone, what needs a human, and who answers for the result is the same decision-rights work described above. It is also the work most companies have not done yet. Our guide to securing AI agents covers the controls.

    The board question

    The authors end on sponsorship. In their experience, organizations that treat this as a security program stall in the first phase, and those that treat it as an enterprise resilience program, with CEO and board backing, get further. Their conclusion is that "the security budget will matter far less than the clarity of the operating model."

    So the question for a board or owner this month is not whether the company has the right tools. It is simpler: if a critical system were being exploited at 2 p.m. on a Tuesday, who decides to take it offline, and how long would that take? If the answer is unclear, start there. Our questions every board should ask is a good companion.

    Sources

    Vulnerability managementFrontier AIIncident responseGovernanceAI agentsMcKinsey

    Related from the BlueRadius Library

    Sourced posts on adjacent topics, ranked by tag overlap.

    AI Security

    The AI Agents You Didn't Approve Are Already Logged In

    Bring your own agent is here: personal AI agents and AI built into SaaS are reaching company systems unreviewed. A 30-day plan to find and govern them.

    Read

    AI Security

    Securing AI Agents: An Agentic AI Security Guide for 2026

    An agentic AI security guide for mid-market: the agent attack surface, prompt injection, excessive agency, non-human identities, and a checklist.

    Read

    Leadership

    Anthropic's Security Chief Says Hold On for 18 Months. Here Is What to Ask Your Board For.

    Anthropic's deputy CISO says defenders must hold on for about 18 months and fund the basics, not AI. Five board asks, each with a test you can report on.

    Read

    Threat Intelligence

    When the Patch Hasn't Landed Yet: A Defender's Playbook for Edge Appliance Compromises

    FortiGate and Ivanti intrusions show the same pattern: logs rotate, credentials persist, the patch is not the end. A defender's playbook for the first 24 hours after an appliance z

    Read

    Threat Intelligence

    Assume the Vendor Is Compromised: The Hour-Zero Playbook

    A vendor breach compromises everyone downstream at once, and you often hear it from a headline first. The playbook to build before the outage, and the four moves that matter in the

    Read

    Incident Response

    IT Recovery Is Not Business Recovery: What the Restore Button Does Not Fix

    Systems restored is not the same as business recovered. The three hard questions of cyberattack recovery, and the system-removal exercise that answers them, from BlueRadius founder

    Read

    Related on Radius360

    Have a security story worth telling? We publish practitioner guest articles.

    Write for us

    Take the Next Step

    Ready to Strengthen Your Security Posture?

    BlueRadius delivers Fortune 500-grade protection for mid-market companies: virtual CISO leadership, 24/7 managed security, and compliance programs that actually close deals. Let's talk.