AWS proposes an AI vulnerability harness built around verifiable evidence

AWS has described a vulnerability-analysis harness that uses AI models to filter findings, while placing technical evidence above the model’s stated confidence. The proposal addresses a practical problem: scanners produce more results than teams can review, and a large list of false positives eventually weakens trust in the entire security process.

The design is organized into layers that require progressively stronger evidence. The first looks for agreement between multiple scanners analyzing the same code. When independent tools report the same issue, plausibility increases; when only one tool reports it, the finding receives additional scrutiny. This stage is relatively inexpensive because it reuses existing tools and does not yet attempt to resolve every aspect of exploitability.

The second layer verifies the program’s actual structure. The system must check that referenced files and functions exist, that the described dataflow matches the code, and that a call path connects the entry point to the sensitive sink. This matters because a model can produce a convincing attack chain based on outdated names, the wrong package, or sanitization it failed to notice. In the proposed architecture, a claim that fails these checks should not become a high-priority finding.

The third dimension adds deployment context. Source code alone does not always reveal urgency. To improve prioritization, the harness incorporates infrastructure-as-code and controls such as authentication, authorization, AWS WAF rules, or network isolation. AWS emphasizes that these controls should not be treated as interchangeable: authentication limits who can attempt an attack, but it does not necessarily reduce the impact of command injection once an attacker reaches it. Blocking controls are mapped to specific vulnerability classes rather than applied as a blanket reduction.

The companion article about the steering file turns the methodology into persistent instructions. It includes a confidence formula based on observable signals such as confirmed taint flow, the absence of sanitization, public exposure, and a confirmed call path. It also separates severity from urgency: a medium-severity vulnerability under active exploitation may deserve faster action than a critical finding with difficult preconditions and no known tooling.

In a test application containing ten known vulnerabilities, AWS says the steering file identified nine, correctly downgraded two cases mitigated by infrastructure controls, and documented the confidence calculation. The unsteered model found all ten, but did not structurally verify its claims.

The proposal has clear limits. It does not replace a deterministic dataflow analyzer, verification of deployed infrastructure, current threat-intelligence feeds, proof-of-concept testing, or human review. Its value is in ordering those checks and stopping unverified claims before they consume engineering time. For teams already using SAST, DAST, or CodeQL, the architecture offers an incremental path: improve evidence first, add context next, and only then automate active testing in controlled environments.