When exploits become daily
To understand what is coming, you do not need to imagine a distant future. You need only look at two trends that are already reshaping the present, and consider where they lead.
The first trend is the amount of code.
We are producing software at a scale we have never produced it before. AI coding tools let small teams ship what large teams used to ship. They let non specialists build applications. They speed up every feature, every integration, and every internal tool.
By the end of 2024, an estimated 29 percent of Python functions in the United States were produced with substantial AI support (Simone Daniotti, Johannes Wachs, Xiangnan Feng, and Frank Neffke, "Who is using AI to code? Global diffusion and impact of generative AI," Science, 2026).
More code means more vulnerabilities. That is the simple math teams need to face. Every new application adds dependencies, APIs, permissions, and configurations. Review, testing, and security review do not scale at the same speed as generation. So the backlog of flaws will grow, including flaws nobody knows about yet, in code nobody has time to read closely.
The second trend is on the attack side. Attacking is getting easier.
Abliterated models are a big reason why. These are open models that have been modified to remove their safety refusals. A normal model may refuse to help write exploit code, build a phishing kit, or adapt malware. An abliterated model does not refuse. It can be downloaded, run locally, and used without a provider watching or cutting it off.
That lowers the floor for attackers. A person with limited skill can now get patient, step by step help with reconnaissance, vulnerability analysis, exploit development, and evasion. A skilled attacker can move faster and test more targets in parallel.
Put the two trends together and you get the flood. More vulnerable code is shipped every day, and more people have the tools to find and exploit the flaws in it, every day.
Security teams used to rely on a window between disclosure and exploitation. That window gave them weeks to scan, prioritize, and release a fix.
That window is closing. The question for teams is direct: can you investigate and fix at the speed you will soon be attacked?
What breaks first
Three things break.
First, periodic defense breaks. A monthly scan and an annual penetration test cannot keep up with daily exploitation.
Second, slow remediation breaks. A ticket that waits for assignment, sprint planning, and a normal release is a delay attackers can use.
Third, manual investigation breaks. Analysts cannot read every log, check every system, and reconstruct every attack fast enough when several incidents run at the same time.
The tempo is already changing. Microsoft reported in April 2026 that Storm-1175 moved from access to ransomware in as little as 24 hours in some cases, and Cl0p exploited an Oracle E-Business Suite zero day nearly two months before a patch existed.
Look at SharePoint in July 2025. Exploitation started July 7. By the time Eye Security scanned more than 23,000 servers, more than 400 were already compromised in four waves over five days.
Look at Cisco in September 2025. CISA gave federal agencies one day to inventory their ASA and Firepower devices, collect forensic data, check for compromise, and start updating or disconnecting them.
Look at Citrix in September 2026. Two NetScaler flaws rated 9.5 were disclosed on September 27. CISA required federal remediation by September 30. Exploitation had started in early September, and some teams shut the appliances down to stop the exposure.
In each case, the bottleneck was the same. Teams needed to know what they owned, what was hit, and what to do next, and they needed those answers in hours.
Remediation agents and blue agent swarms
That is why teams need agents on defense, and they need two different kinds.
The first is a remediation agent. Its job is to fix.
It should find the affected code and systems, build the patch, test it, and prove the exploit no longer works. Then it should open a pull request with the evidence, so a human can see what changed and what risk is left.
Its authority should be limited by risk. A routine dependency update can move fast. A change to authentication, payments, health data, or core infrastructure should require human approval.
The second is a blue agent swarm. Its job is to investigate.
Different agents should work in parallel. One triages alerts. One searches logs. One maps which users, systems, and data were exposed. One checks threat intelligence. One tracks containment.
This matters because investigation is usually the hidden delay. Before anyone can fix a problem, someone has to understand its scope. A swarm can do that first pass in minutes, and leave the analyst with a clear summary and a real decision to make.
The goal is simple. Humans should spend their time on judgment, approval, and risk. Machines should spend their time on search, testing, and repetition.
Streamline the remediation protocol
But agents alone will not solve this. The decision process has to get faster too.
Too many incidents slow down on basic questions. Who owns this system? Who leads the response? Who can approve an emergency patch? Who can take the application offline?
Those questions should be answered before an incident, in a written protocol.
The protocol should assign an owner and a lead for every critical system. It should define severity levels. It should say, for each level, whether the team patches in place, isolates the service, disables a feature, blocks traffic, or takes the application offline.
The offline decision needs to be explicit. A shutdown costs revenue and trust in the short term. Leaving a compromised system online can cost much more. Teams should decide the threshold in advance, and name the person who can make that call.
The protocol should also define the emergency path to production. That means a fast CI and CD pipeline for critical fixes. It should update dependencies, rebuild containers and artifacts, throw away old vulnerable versions, test the patch, deploy by canary, and roll back if a defined trigger is hit.
If the flaw is in a base image or a build tool, the pipeline should find every service built from it and rebuild those services too. Otherwise the team fixes one application and leaves the same flaw in twenty others.
Add communication to the same protocol. Status page updates, customer notices, and internal updates should use prepared templates, with a named owner and a set update cadence.
Then connect the whole process into one loop. Detection starts investigation. Investigation sets the scope. The protocol assigns the decision. The remediation agent builds the fix. The pipeline ships it. Verification proves the exploit fails. If verification fails, the incident stays open.
That loop is the preparation. Not a new tool by itself. Not a larger team by itself. A system that can investigate, decide, fix, and verify at the speed attackers now operate.
Build the remediation agent. Build the blue agent swarm. Write the protocol. Test the emergency pipeline. Do it now, while you still get to choose the timeline.
Sources
Eye Security, "SharePoint Under Siege," July 2025.