Changing the speed of defense

Attackers are already using AI to shorten the work between finding a target and acting on it. Reconnaissance, code analysis, exploit development, social engineering, and campaign management can all move faster when a model handles the repetitive work. The defensive response cannot be another AI feature bolted onto a security program that still depends on periodic assessments and manual triage. The way the work gets done has to change.

CrowdStrike’s 2026 Global Threat Report recorded an average eCrime breakout time of 29 minutes, a fastest observed case of 27 seconds, and an 89 percent increase in attacks by AI-enabled adversaries. Verizon’s 2026 Data Breach Investigations Report found that 31 percent of breaches began with the exploitation of software vulnerabilities, making it the leading initial access vector in its dataset. The reports draw from different telemetry, but both point to a shrinking window between exposure, intrusion, and impact.

AI is increasing the rate of change inside the enterprise as well. In Veracode’s evaluation of more than 100 large language models, 45 percent of generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities. The models became better at producing functional code, while their security performance remained largely flat. Defenders are dealing with a faster attacker and a faster-moving environment at the same time.

Fighting AI with AI means using the technology where it changes the tempo of defense. AI can find exposure, test whether a weakness is exploitable, trace the path to a critical asset, retest a fix, and turn observed attack behavior into detection logic. People still set the scope, approve high-impact actions, make business decisions, and remain accountable for the outcome.

The offensive advantage is already real

AI does not need to run an attack from beginning to end to change the economics of cyber operations. A human operator can supervise several AI-assisted workflows at once. A model can inspect code, enumerate interfaces, draft exploit variations, compare responses, and continue testing after an approach fails. The operator can spend more time choosing targets and judging results while the machine absorbs the repetition.

Palo Alto Networks reported from its own testing that frontier AI systems were effective at discovering vulnerabilities, chaining lower-severity weaknesses into critical attack paths, and identifying logic flaws that conventional tools often miss. Results will vary with the model, tool access, target, and operator. The more important change is that specialized offensive work is becoming easier to repeat and run at higher volume.

The target has also grown beyond conventional applications and infrastructure. An AI application includes the model, prompts, orchestration, retrieval pipelines, vector stores, tools, APIs, identities, data, and every system those components can reach. Prompt injection may open the door, but the damage usually happens later, when an agent retrieves restricted information, invokes an overprivileged tool, or completes an action that was never properly authorized. OWASP now maintains separate risk frameworks for generative AI applications and for agentic systems that plan and act across workflows.

The defensive problem therefore has two sides. Security teams must counter AI-assisted threat activity, and they must test the AI-enabled systems that attackers will target.

Why the current model falls behind

Traditional assurance is still necessary, but it is intermittent. A penetration test can be excellent but still become stale after a release, an identity change, a new integration, or an infrastructure update. Architecture reviews face the same limitation. The environment keeps moving after the review is complete.

Scanners offer broad coverage, but a finding does not always show whether a weakness is reachable, exploitable, chainable, or connected to something the business cannot afford to lose. Severity is useful context. It is not proof of risk on its own.

Most security teams have the expertise to reason through these questions. What they lack is enough time to reconstruct the application, identity, cloud, code, and business context for every finding, then repeat the work after the environment changes. Analysts and engineers should be spending their time on difficult investigation, architecture, and business tradeoffs, not on assembling the same evidence over and over.

FedRAMP has stated that the legacy monthly vulnerability scanning process followed by many FedRAMP Rev5 cloud services is insufficient. Its updated approach puts more weight on reachability, exploitability, automation, and technical impact. That requirement comes from a federal program, but the operating principle applies more broadly. Security evidence has to remain current enough to support decisions in an environment that changes continuously.

Continuous AI-assisted validation does not replace expert penetration testing, secure design review, threat modeling, or incident response. It fills the space between deeper assessments, retests controls after meaningful changes, and gives experts better evidence when their judgment is needed.

What fighting AI with AI looks like

The response should match the attacker’s advantage without copying the attacker. Automated reconnaissance calls for continuous discovery of internet exposure, applications, APIs, identities, cloud paths, code repositories, agent workflows, and the data and tools those agents can reach. AI-assisted vulnerability research calls for ongoing analysis of code, configuration, authorization, and business logic. The ability to generate and retry exploit ideas calls for controlled validation that shows whether a weakness can become a working attack path.

High-volume probing also changes what the security operations center needs to see. Telemetry has to capture the rhythm of automated testing, repeated adaptation, unusual tool use, identity abuse, and data movement across application and AI boundaries. AI can help correlate that activity and draft detection logic while analysts retain control over containment and response.

The work is most useful when it runs as a loop rather than a set of disconnected tools. It starts with discovery, because defenders need an accurate view of what is exposed and reachable. Validation follows, using controlled and preferably non-destructive proof to separate a theoretical weakness from a path an attacker can use. Reachability does not make every other weakness irrelevant, but it changes what needs attention first.

Validated findings can then be prioritized with context that a severity score cannot provide on its own. External exposure, required privileges, attack complexity, blast radius, control coverage, data sensitivity, and business impact all matter. Because we don’t need another backlog of loosely ranked scanner output. The result should be a remediation queue that engineering teams can understand and trust.

Remediation is not complete when a ticket is closed. The affected path should be retested and the evidence attached to the result. Controlled attack telemetry should also feed detection engineering, giving the SOC concrete behavior to replay, tune, and monitor. When the same weakness keeps returning, the lesson belongs in architecture standards, secure coding guidance, identity patterns, CI/CD controls, and threat models.

This is what makes the model continuous. It does not mean an agent attacks production without pause. It means the right tests run often enough, and after the right changes, to keep the evidence current. A major release, new internet exposure, permission change, infrastructure update, new agent capability, model change, or tool integration should be able to trigger targeted validation without waiting for the next annual assessment.

Where automation stops

AI can take on asset mapping, code and API analysis, hypothesis generation, evidence correlation, controlled testing, retesting, remediation assistance, and detection drafting. Human authority should remain over testing authorization, scope, state-changing actions, production containment, risk acceptance, customer impact, regulatory disclosure, and exceptions. Those decisions carry consequences that cannot be delegated to a model simply because the model can act quickly.

The control plane around defensive AI should be explicit. Testing needs written authorization, defined targets, dedicated identities, rate limits, isolation, non-destructive proof, approval gates, automatic stop conditions, and a human kill mechanism. Synthetic data should be used where practical. Logs should record the model, version, instruction, tool, identity, evidence, action, and outcome so that every material step can be reconstructed.

The same discipline applies to enterprise agents. High-impact actions should use dedicated non-human identities, short-lived credentials, least privilege, and action-level authorization. An agent should not inherit a broad human account simply because that is the easiest way to connect it to a tool.

IBM’s 2025 Cost of a Data Breach research found that 97 percent of organizations reporting an AI-related security incident lacked proper AI access controls, while 63 percent lacked governance policies for managing AI or limiting shadow AI. The underlying lesson is familiar. Capability without identity, authorization, telemetry, and ownership creates risk faster than it creates value.

NIST’s AI Risk Management Framework and Generative AI Profile can provide the governance structure. OWASP’s generative AI and agentic application guidance can inform the technical testing. These frameworks should define the boundaries around defensive AI.

Measure the time it removes

Finding count is a poor way to judge whether this model works. The useful question is how much time and uncertainty the program removes from the path between exposure, validation, remediation, and detection.

Coverage still matters, especially for critical systems, but timing tells more of the story. Measure how long it takes to test a material change, confirm or rule out exploitability, close a validated attack path, verify the fix, and turn useful attack telemetry into a deployed detection. Track whether previously remediated weakness classes return. For agentic systems, track how many high-impact actions are protected by explicit authorization and complete logging.

These measures show whether AI is producing better evidence and faster correction, or merely producing more activity. A mature program should leave fewer unresolved assumptions behind. It should also give human experts more time for the work that actually requires human judgment.

Restoring the balance

Trying to keep AI out of the security program does not keep it out of the environment. It arrives through threat actors, vendors, developers, applications, and software dependencies. Adopting it without clear limits creates a different problem. The workable position is to give AI a defined role in defense, constrain its authority, instrument its actions, and keep people accountable.

AI has already changed the offense. Defenders should use it to reduce the time between a change, a test, a finding, a fix, and a detection. That is the practical case for fighting AI with AI — and why at AHEAD we are helping organizations put that model into practice. By bringing security, cloud, data, AI, and enterprise platforms together, AHEAD helps teams secure the full AI lifecycle: designing the right governance and architecture, protecting models, agents, identities, data, APIs, and tools at runtime, monitoring behavior and enforcing policy, and feeding real-world telemetry back into detection, response, and continuous validation.

The goal is not more AI activity. It is faster evidence, stronger runtime protection, faster correction, and more time for human experts to make the decisions that matter.