Someone's offering to let an AI agent find and fix the vulnerabilities in your aging system. Here's what has to be true before you say yes. The short answer: an agent's security patch is safe to ship only when the system already has tests, a verifier the agent can't touch, exploit-based acceptance, an inventory, a real deploy pipeline, a rehearsed rollback, and a named human on the merge.
The offers are real. On September 2, 2026, Google's Fairwind Program promised defenders "verified, deployment-ready patches in minutes." On September 3, 2026, OpenAI's Daybreak for Frontline Defenders committed a billion dollars in subsidized access for water utilities, state and local governments, and community banks, and it lists reviewing legacy code and developing fixes among the jobs it expects to do. We've maintained ColdFusion systems since 1998 and we run agentic delivery pipelines in production, so we aren't against the idea. We're against skipping the prerequisites.
Here's why. PatchBench, a research benchmark posted to arXiv on September 3, 2026, tested 11 patching agents on C/C++ vulnerabilities. Checking only whether the original proof-of-concept input still crashed inflated the agents' solve rate 1.83x on average. The agents often patched the crash site and left the root cause in place. About a quarter of their patches closely matched historical developer fixes.
1. Characterization tests around the code the agent will touch. Without tests, you can't tell a fix from a regression. Characterization tests record what the code does today, bugs included. Write them before an agent changes a function. Agents make those tests cheap to write. Skip them, and "verified patch" just means the crash went away.
2. A verifier the agent can't see or edit. Agents optimize for whatever check is in front of them. Keep the exploit, the tests, and the acceptance criteria outside the agent's write scope. If the agent can edit its own verifier, nothing is verified.
3. Exploit-driven acceptance. Accept a patch only when two things hold: the original exploit fails against the patched code, and your characterization tests still pass. PatchBench found that existing evaluations often check only whether the crash stopped.
4. A dependency and runtime inventory. Sooner or later, the agent will propose a library upgrade. Before it does, you need three answers: what else loads that library, which runtime it's pinned to, and whether the vendor still supports that combination. On an older ColdFusion server, the list can include a JAR in the lib folder that nobody remembers adding. Build the inventory first.
5. A deploy path that isn't FTP to production. Autonomous patching assumes a pipeline: build, test, stage, promote. Plenty of teams still deploy legacy systems by copying files to the live server. Point an agent at that setup and you get untested changes, faster. Build the pipeline first. If credentials are part of the mess, start with the audit we run before an agent gets production access.
6. A rollback you've rehearsed. A backup isn't a rollback. You need the steps, the time they take, and the name of the person who runs them, tested against the real system recently. Every patch the agent proposes should come with an answer to "how do we undo this in ten minutes?"
7. A human who owns the merge. Someone reads the full diff and signs their name to it. If the person who understood this code left years ago, that review will be slow at first. That's fine. A slow review with a name on it beats a fast merge nobody can explain. It's the same rule we apply before pointing any coding agent at a repo.
All seven predate AI. They're the change-safety basics any legacy system needs, and autonomous patching just removes the excuse for skipping them. If you've been offered agent-driven remediation and this list isn't covered yet, our AI automation work starts with these seven.