The Patch-Retest Loop: How to get AI to write quality exploit patches
AI written patches are prone to leaving exploit paths open. Pensar's retest loop deploys our offensive agents to run variant analysis and attempt to re-exploit the patched vulnerability, ensuring all potential exploit paths are remediated before accepting a vulnerability as closed.
Is your coding agent leaving exploit paths open? The failure mode is easy to miss: a patch lands, the original proof-of-concept stops working, the tests pass, and the finding is marked fixed. Nothing in that sequence checked whether the same weakness is still reachable another way: through a neighboring route, a different method, or an edge case the original exploit never touched.
We saw this first hand with our customers: 2/3rds of patches were failing the first retest. Additionally, customers with custom internal workflows wanted a way to pass retest results to their own coding agents/software factories to leverage their existing scaffolding.
As a result, we added first-class support for iterative retesting of patches that can be kicked off automatically or by an agent. Anytime a patch is applied to a target environment, our customers (or their agents) can kickoff a retest - deploying our offensive agents to attempt to exploit the vulnerability again, including through variations of the original attack. If an exploit path survives, the patching agent receives the evidence and output of the retest attempt to inform its next patching attempt. This loop is run until the patch passes live retest validation and the finding/vulnerability can be confidently marked as closed.
Your team can use Pensar's patching agent which has this retest loop built-in, or they can connect their own agent harness and use our CLI, webhooks, and/or agent skills to integrate the loop into an existing remediation workflow to iteratively patch exploits with minimal human interaction.
Using offensive agents inside the patching loop
The workflow starts when Pensar reports a finding. If you have auto-patching enabled in your Pensar workspace, our remediation agent will automatically kickoff the first patch iteration, and you will receive a notification when the draft patch is ready. Otherwise, a webhook delivers the finding and all its relevant context directly to your team's coding agents, so remediation can begin without someone copying a report into a prompt.
The typical flow looks like:
- Receive the finding. Your harness subscribes to the
issue.createdwebhook event, then retrieves the finding details and proof of concept exploit. - Write the patch. Use the output of Pensar's patching agent, or have your own agent implement a fix using its internal context.
- Deploy and request a retest. Once the patch has been deployed, invoke a retest through our CLI or agent skill.
- Try to exploit it again. Pensar's offensive agent exercises the original attack vector and tests variations that could reveal an incomplete fix.
- Feed the result back. A
retest.completedwebhook delivers the outcome. If Pensar's offensive agent finds a valid exploit path is still open, it will pass this context off to your coding agent to start the next iteration of patching.
Use the patching agent with the best context
While Pensar has first class support for auto-patch generation, your own coding agent may have additional context: how authorization is supposed to work across services, why a compatibility constraint exists, which internal library should enforce a policy, who owns what part of the codebase. That context can matter enormously when choosing where to fix a vulnerability.
Luckily, we support both providing us that context or just bringing your own harness for remediation. Pensar supplies the findings and offensive verification; your harness handles the patch and deployment, then our retest flow can evaluate your agent's work to provide adversarial feedback and confirmation of remediation.
This also lets you preserve the workflow your engineers already use. If your agent opens a pull request, waits for checks, and deploys a preview environment, Pensar can slot right into that cycle.
How we test for exploit variants
The original proof of concept exploit, vulnerability analysis, and associated agent trace (the evidence-backed steps our offensive agent took to discover and exploit the vulnerability) gives our retest agent a concrete starting point. The agent can adapt that proof of concept and attack vector to investigate whether the same security failure remains reachable another way.
Depending on the finding and authorized scope, that means varying payloads, HTTP methods, headers, endpoints, or exploring edge cases/alternative bypass methods.
Consider a hypothetical cross-tenant data exposure. A user can retrieve another tenant's invoice by changing an ID in a request. The patching agent adds an ownership check to the invoice detail route, the original exploit payload now fails.
Retesting answers questions on the efficacy of this patch: can the same user obtain the invoice through an export route? Does a batch request enforce the check for every invoice? Is the authorization decision tied to the authenticated user's tenant throughout the request?
If an in-scope export route still exposes the invoice, the patching agent has a concrete counterexample to its fix. It is given all the context as to why the authorization rule was enforced in one place and bypassed in another, update the patch, deploy it, and kickoff another retest.
How can agents run retests?
After authenticating via our CLI, the agent can retrieve a finding with:
pensar issues get VULN-000123
After the patch is deployed to the configured target, it kicks off a retest with:
pensar issues retest VULN-000123
The retest command returns a queued status and session ID. The result arrives asynchronously. A successful command invocation means the retest was queued; your harness must wait for its outcome.
The retest.completed webhook carries structured fields including status, stillExists, confidence, evidence, recommendation, and error. Those fields give the coding agent a clear next action:
| Retest outcome | Next action in your harness |
|---|---|
still-vulnerable | Give the evidence and recommendation to the patching agent. Revise, deploy, and retest. |
fixed | Evaluate the evidence and confidence against your acceptance criteria, alongside application tests and required review. |
error | Investigate the testing failure. Restore the conditions needed to test and retry, or escalate for review. |
Close the defender's window¹
With Pensar's patch-retest loop, you can /goal patch all vulnerabilities with confidence that your coding agents are remediating exploits without leaving paths open - building an autonomous patching loop to secure your systems in the age of AI-enabled threats.