A security agent flags a flaw in a widely used library. The report sounds convincing. Then it lands in a queue beside several hundred others, with no reliable reproducer, no named engineer and no release decision. The model did its job; the organization has not.
That is the uncomfortable lesson in Microsoft's October 7 account of its FORGE vulnerability research. From May through September 2026, the team says its work helped discover Windows vulnerabilities assigned 140 CVEs. It also submitted 155 internally validated reports across 23 open-source projects. Those are Microsoft's figures, not a benchmark for what another company's security program can deliver. More importantly, Microsoft describes the bottleneck after discovery: validation, maintainer review, remediation and release.
For enterprise AI governance, the question is not just whether an agent may scan code. It is who can turn a candidate into a credible claim, who can change production software and what evidence survives the handoff.
A finding is a claim, not a work order
An AI-generated vulnerability report can be correct, duplicated, unreachable in the shipped build or dependent on a configuration the organization never uses. Treating all four as urgent tickets gives the loudest scanner control of the team's calendar.
Microsoft's FORGE researchers argue that the useful unit is a reproducible finding that gives the next person enough evidence to act. Their account describes an internal deduplication effort that reduced about 45% of duplicate findings across repeated scans of the same code. That figure belongs to their workflow, not to AI scanners generally. The governance point is broader: measure how many reports clear validation and reach an owner, rather than celebrating the number an agent produced.
A practical intake record should state the affected component and version, the vulnerable path, the relevant build configuration, a safe reproduction method, what the agent actually observed, and what remains unproven. A speculative exploit narrative is not a substitute for a test that another engineer can run. If the report cannot be reproduced, preserve the reason: missing precondition, false reachability, duplicate or inadequate evidence. That result improves the next scan instead of disappearing as a closed ticket.
Separate the agent's authority from the engineer's authority
The most dangerous shortcut is giving the discovery agent permission to close its own loop. Reading a repository is not the same privilege as opening a production pull request, changing a dependency, modifying a pipeline or pushing a release.
Set distinct roles for each stage. A scanner gets scoped, preferably read-only access to approved repositories and build artifacts. A validation harness can run an isolated test against an authorized build. A patch assistant may propose a change in a branch, but cannot merge it or alter the acceptance tests it must pass. The component owner reviews the root cause and compatibility trade-off; the release owner approves deployment. Emergency exceptions need an expiry, an approver and an audit record.
This is not a vote against automation. It is a way to let automation do repeatable work without pretending that an agent is the accountable software owner. NIST's Secure Software Development Framework provides a useful baseline for embedding security practices through the development lifecycle. The exact scanning workflow still needs to fit your software, release process and risk appetite.
Make the handoff machine-readable and human-owned
Imagine an agent reports a possible authentication bypass in a service used by both an internal test tenant and a customer-facing system. A generic severity label does not tell the on-call engineer which build is exposed or whether the attacker can reach the code path.
Attach a compact evidence packet to each candidate:
- An artifact identifier: commit, package version, build and environment.
- A reproduction record: input, expected behavior, observed behavior and test isolation.
- A reachability assessment: who can invoke the path and under which permissions.
- An ownership trail: reviewer, decision, due time and any explicit risk acceptance.
- A closure record: patch reference, regression test, deployment confirmation or reason for rejection.
Those fields matter because queues cross teams. The research group may understand the exploit; the product engineer knows the intended behavior; operations knows when the fix actually reached the exposed environment. A dashboard full of "resolved" tickets is weak evidence if resolution means only that a patch was suggested.
In its October 6 CISO perspective, Microsoft warns that a larger flow of findings will strain human review and argues for balancing speed with patch quality. The sensible response is not a blanket promise to patch every finding within a fixed number of hours. Set escalation rules around exposure, exploitability and business impact, then reserve an urgent path for the systems that warrant it. Keep compensating controls and rollback plans visible while a fix is being tested.
Test the queue, not the demo
Before expanding an AI vulnerability program, run one tabletop exercise using a realistic but synthetic candidate. Put a plausible report into intake and follow it all the way to a production decision. Can the team identify the exact artifact? Can an independent engineer reproduce the issue without trusting the agent's explanation? Who owns a dispute over severity? Can a proposed fix be rejected without losing the evidence? What proves the corrected build was deployed and the original failure cannot recur?
Track a few outcomes across that exercise: validated findings per reviewer-hour, duplicate rate, time from validation to owner assignment, and time from approved fix to verified deployment. Record false positives and missed cases where possible. A spike in discovered bugs paired with a growing unowned queue is not progress. Nor is a fast patch that breaks the customer's workflow.
The same discipline applies to AI agent execution policies outside security research. The agent's identity, allowed action, approval boundary and audit trail must travel together. If a team is already struggling to see where employees and agents use AI tools, start with an inventory of AI usage and governance controls before granting a scanning agent more access.
The central choice is simple: optimize for reports created, or for exposures responsibly removed. AI makes the first number easier to raise. A governed evidence-to-release path is how you improve the second. If you are mapping that path across teams, talk with Aona about your AI governance workflow and bring one real handoff your team cannot yet explain end to end.
