Cisco Executive: Without AI, You Can't Defend Security — The Exploit Window Is Only Eight or Nine Minutes

Cisco's Jeetu Patel: The attack-defense speed gap has reached orders of magnitude — AI is a prerequisite for security, not an option.
Cisco security chief Jeetu Patel argues AI has become a prerequisite for security defense rather than an option. His evidence is a set of stark numbers: it typically takes only eight to nine minutes from vulnerability disclosure to actual exploitation, while the average enterprise patch cycle is about 45 days, and only about 20% of disclosed vulnerabilities ever get patched. This shows the patch management process has structurally failed and process optimization cannot bridge an order-of-magnitude gap. Therefore, security controls must become agentic, with controls and policy requiring dynamic adjustment — static rules no longer apply. Patel says OpenAI has become the core foundation for Cisco's shift, describing the related work as a step change. The practical implication for defenders: use automated continuous actions to shrink the exposure surface, design defense-in-depth assuming systems remain unpatched, and let humans set goals and adjudicate risk while machines handle minute-level identification and remediation.
Cisco's head of security Jeetu Patel offered a fairly blunt assessment in a recent conversation: AI is not optional — it's a prerequisite for security defense. His logic isn't complicated — the speed gap between attackers and defenders has widened to the point where humans can no longer close it with manual processes. Defenders must either hand control and policy over to agents, or accept the reality of being continuously breached.
The Attack-Defense Time Gap: Only Eight or Nine Minutes from Disclosure to Exploitation
The set of numbers Patel cited is the fulcrum of his entire argument. From the moment a vulnerability is publicly disclosed to the appearance of actual exploitation, the window is typically only eight to nine minutes. Meanwhile, the average time for enterprises to patch is about 45 days, and more striking still, only 20% of actually disclosed vulnerabilities ever get patched.

Put these three numbers together and the problem they reveal isn't that "patch management isn't good enough" — it's that the process itself has structurally failed. Defenders schedule manpower and change windows in units of days and weeks; attackers launch automated scanning and exploitation in units of minutes. Against a gap of this magnitude, discussing "strengthening security awareness training" or "optimizing ticket workflows" is meaningless.
Patel used a vivid phrase: OpenAI is "working the night shift," thereby shifting the advantage to the defender's side. The implication is that attackers no longer exclusively enjoy the speed and scale benefits of automation — defenders can likewise leverage machine speed for continuous monitoring, analysis, and response.
The time-to-exploit window has been steadily compressing in recent years, driven mainly by three factors: first, vulnerability announcements, patch diffs, and PoCs spread almost in real time through public channels, letting attackers directly locate the flaw by comparing pre- and post-patch code; second, automated vulnerability scanning and exploitation frameworks have drastically lowered the cost of weaponization, with N-day exploits often completed within hours; third, ransomware and initial access brokers have formed an industrialized division of labor, enabling rapid monetization once an entry point is found. In contrast, enterprise patch cycles are constrained by change management, compatibility verification, and downtime windows, making it very difficult to compress them to the scale of days. This structural mismatch is precisely why the "assume breach" philosophy has gained popularity, and why exposure surface management and segmentation/isolation are prioritized for investment.
Security Controls Must Become "Agentic"; Policy Cannot Be Static
As one of the world's largest security vendors, Cisco's product line covers virtually every security category. Patel's emphasis isn't on the breadth of categories but on the need for a fundamental change in how these controls operate: controls must move toward agentic, and both controls and policy must be dynamically adjusted — static rules are no longer sufficient.

The dilemma of static policy is that it assumes the environment won't change much after the policy is written. But the attack surface changes far faster than the policy update cycle — a hard-coded access rule is often already behind the real threat by the time it takes effect. Dynamic policy means the policy itself must be able to adjust based on context, behavioral signals, and real-time risk status. This is precisely where large model capabilities can intervene — not to replace security engineers, but to take on high-frequency, context-intensive judgment work.
Agentic security means security controls are no longer just tools that execute preset rules, but are driven by agents capable of goal understanding, autonomous planning, and tool invocation. The difference from traditional SOAR orchestration or automation scripts is that automation executes a fixed playbook and stops to wait for a human when it encounters situations outside the playbook; an agent can decide its next action based on the current context — for example, upon detecting an anomalous login, autonomously querying asset criticality, pulling historical behavior, determining whether to isolate the host, and handing the conclusion and supporting evidence to an analyst for adjudication. Such systems typically have a large model responsible for semantic understanding and reasoning, and deterministic tools responsible for executing high-risk actions, forming a layered structure of "model judges, system executes." The key engineering challenges are permission boundaries, auditability, and the rollback-ability of mistaken actions.
Partnership with OpenAI: Embedding Model Capabilities into the Security Foundation
Patel explicitly stated that OpenAI has become the core foundation for Cisco's push in this direction. He described the Daybreak and Astra-related work as a "step change" rather than incremental optimization — the value isn't just the improvement of Cisco's own security posture, but also the real protection outcomes on the customer side.

What's noteworthy about this statement is the positioning: the model isn't introduced as an add-on security analysis tool, but as underlying infrastructure supporting the dynamism of security controls and policy at the upper layers. This also explains why he emphasizes "prerequisite" — if model capabilities don't enter the control loop, dynamic policy is out of the question.
Treating the model as a security foundation rather than a bolt-on analysis tool means the model is placed in the middle layer between data flow and control flow: upward it handles policy generation and natural language intent; downward it interfaces with enforcement points such as firewalls, EDR, and identity systems. This architecture differs significantly from the approach of "adding an LLM alert summary next to the SIEM" — the latter only affects human reading efficiency, while the former directly affects the timeliness of control actions. Correspondingly, it introduces several new problems: the determinism and interpretability of model output, the risk of prompt injection and data poisoning contaminating the security control chain, and whether the latency of model calls themselves meets minute-level response requirements. Therefore, in practice, a hybrid deployment is usually adopted: small models for real-time classification and large models for deep analysis.
Practical Implications for Defenders
Patel repeatedly anchors his points on customers' security posture rather than the vendor's technology narrative.

Starting from this set of data, several practical judgments for security teams can be drawn. The compression of the patch window cannot be solved through process optimization — it requires making exposure surface reduction, isolation, and detection/response into automated continuous actions. The coverage problem is thornier than the speed problem — a 20% patch rate means most vulnerabilities are never addressed, and defenders must design defense-in-depth on the assumption that systems remain unpatched for extended periods. The boundary of human-machine division of labor is also shifting: humans handle goal-setting and risk adjudication, while machines handle identification, analysis, and remediation within minute-level windows.
Patel's argument doesn't offer a specific product roadmap, but the judgment itself is clear enough: in domains where the attack-defense speed gap has reached orders of magnitude, those who don't adopt AI aren't taking on risk — they're giving up on defense.
One-line Summary
Cisco's Jeetu Patel: The attack-defense speed gap has reached orders of magnitude — AI is a prerequisite for security defense, not an option.
Paragraph Summary
Cisco's head of security Jeetu Patel believes AI has become a prerequisite for security defense rather than an option. His evidence is a set of stark numbers: it typically takes only eight to nine minutes from vulnerability disclosure to actual exploitation, while the average enterprise patch cycle is about 45 days, and only about 20% of disclosed vulnerabilities ever get patched. This shows that the patch management process has structurally failed and that process optimization cannot bridge an order-of-magnitude gap. Therefore, security controls must become agentic, with both controls and policy requiring dynamic adjustment — static rules no longer apply. Patel stated that OpenAI has become the core foundation for Cisco's shift in this direction, with the related work described as a step change. The practical implication for defenders: use automated continuous actions to shrink the exposure surface, design defense-in-depth on the assumption that systems remain unpatched for extended periods, and let humans handle goal-setting and risk adjudication while machines handle minute-level identification and remediation.
Related articles
AWS AgentCore Gateway: Connecting AI A…
AWS AgentCore Gateway: Connecting AI Agents to Enterprise Backends with MCP
How AWS AgentCore Gateway acts as a primary MCP server to aggregate REST APIs, Lambda, and existing MCP services? Analyzing its AST real-time mapping, zero cold start, semantic search for tool overload, session isolation, and key injection security design, plus the architectural approach to decoupling enterprise AI agents from backends.

One Link Gives Figma AI a New Skill: Hands-On with MCP Connectors
Paste one MCP server link and the AI Agent in Figma gains new tool capabilities. We break down the setup flow, 20+ one-click apps, read/write permissions and execution policies, and the public HTTPS requirement.

Cognition SWE-2 in Practice: One Prompt to Handle the Whole Product Launch Process
Analyzing a YouTube creator's prompt for using Cognition SWE-2 to launch a product: a landing page, seven-email sequence, and non-buyer follow-up tool, plus how the 'test and report' constraint changes AI delivery quality.