Use this 4-step loop to verify an AI agent's auto-fix before it ships

A coding agent returns a diff for a vulnerability. The diff looks plausible. The scan passes. You still should not merge it on that evidence alone. An agent's auto-fix is a proposed patch until a vulnerability-specific rescan passes and your normal review and regression suite still approve it.

StackHawk publicly launched Wingman on Sept. 15, 2026. Wingman is available in Claude Code, Cursor, GitHub Copilot, Codex, and Antigravity. The tool starts automatically when a coding agent marks a feature complete, configures itself, boots the running application, and tests it like an attacker.

It sends findings to the same agent that wrote the code, lets that agent patch the flaw, and runs a second scan to check the repair before a pull request opens. The price is $10 per user per month, with unlimited applications and 50 scans per user per month. Since first becoming available, Wingman has remediated over 7,500 security flaws for early-access users across more than five AI coding agents, and 98% of the corrections stayed resolved without regressions.

Wingman reports whether a commit is clean to the continuous integration pipeline, and each test is linked to the commit it checked. The product details matter less than the process. When agents auto-fix vulnerabilities, the danger is a successful fix you did not ask for.

An auto-fix is a patch proposal

A pre-PR vulnerability scan is useful, but it does not approve a merge by itself. The agent may address the issue without fully resolving it. Without a target, the later checks can miss. Your job is to treat the output as a change request, not a finished repair.

Keep this checklist in the PR description. Each item is a yes/no check, and each one blocks a different failure mode.

• Identify the vulnerability. The PR names the affected endpoint, parameter, or component, and the flaw class.
• Verify an independent rescan of that vulnerability passed. A second scanner or different rule set checked the same target on the same commit.
• Verify the full regression suite passed and the diff was reviewed. The normal suite is green, and a human checked whether the patch fixes, hides, or moves the flaw.
• Verify the commit and scan result are recorded in CI before merge. The pipeline shows the rescan, regression result, and commit in one place.

The rescan must target the flaw

The first scan found a problem. The second scan has to answer a narrower question: is that problem gone? A scan can pass while the issue remains unresolved. The rescan should target the same route, parameter, or component, and it should use a different scanner, rule set, or manual probe than the one that produced the finding.

If the agent used a fix from the same product, the rescan should not assume that product's own check is enough. In AI coding security, the agent is both author and first reviewer. An independent check separates authorship from review.

The regression suite and diff review catch side effects

A security patch can be correct in a narrow sense and still break the app. It may change authentication, alter a response shape, or add a dependency that slows the build. The full regression suite is the part of the process that asks whether the fix fits the system, not just the ticket.

The diff review is where a human checks intent. Did the agent remove the vulnerable behavior, or did it add a bypass? Did it patch the endpoint, or did it disable a feature? A short review of the changed lines can find a plausible-looking fix that is actually a workaround.

The CI record makes the merge auditable

Without a record, the merge decision exists in a chat thread or a person's memory. The CI record should show the commit, the rescan result, the regression result, and the review approval. If the pipeline says the commit is clean, that statement should be tied to the exact commit that merged.

That record also makes the next incident easier to review. If a vulnerability reappears, you can see whether the original fix was verified, whether the suite flagged a regression, or whether the merge happened before the evidence existed. Merge only when the CI record shows the rescan, the regression suite, and the human review all match the same commit.