- AWS's security team says the same AI model produced fabricated or inflated findings under one set of instructions and evidence-based ones under another.
- The difference lies in a steering file that defines proof, confidence, infrastructure context and priority. AWS's test used one purpose-built app with ten flaws.
- Treat that file as policy: name an owner, require review of changes, and validate its weights against labeled true and false positives.
The model did not change. The instructions did.
A common question about AI in security is which model the team uses. AWS's security automation team argues a different question matters more: what does the model treat as proof? In a post published October 7, its authors write that the model's capability is fixed and that "what you configure is its judgment."
That is the idea worth taking from the post. The file that tells an AI assistant how to triage vulnerabilities is now a control, much like a policy or a runbook. It deserves an owner, a review process and a test.
What AWS built, and why
The post is the second in a series on an AI vulnerability harness. It releases a steering file. In plain terms, this is a standing brief for an AI coding assistant, read automatically each time a work session opens. Kiro reads it from a .kiro/steering/ folder. Claude Code uses CLAUDE.md. The repository ships both.
The authors say their early versions produced findings that sounded authoritative but fell apart under scrutiny. One reported a SQL injection in a function that did not exist. Another claimed high confidence with no structural basis. A third ignored an AWS WAF, a web application firewall, set to blocking mode in the request path.
How the file turns judgment into rules
The file has five core sections. Each replaces something the model would otherwise decide by feel.
First, verify before reporting. The model must confirm that the data flow, the function and the call path exist before it reports a finding. AWS says this produced zero fabricated paths in its testing.
Second, confidence becomes arithmetic. A formula built from yes-or-no signals replaces the model's own sense of certainty. Confirmed taint, meaning user-controlled data reaching a sensitive operation, carries the highest weight at 0.30.
Third, infrastructure changes priority. Take a firewall with SQL injection rules switched to blocking. AWS rates it a strong defense against that one attack class and scales the finding's weight by 0.25. Against deserialization attacks, the same firewall is irrelevant. Stacked controls cannot push the multiplier below a floor of 0.15, so no finding is scored as fully mitigated.
AWS also separates two kinds of control. Authentication limits who can attempt an exploit. It does not change the damage if one succeeds. The authors say a command injection behind IAM authentication is still P0.
Fourth, threat intelligence adds urgency. The file reads the CISA Known Exploited Vulnerabilities catalog, EPSS (an estimate of exploitation in the next 30 days) and public proof-of-concept code. The total boost is capped at +0.50. AWS argues urgency and severity are different things.
Fifth, the score becomes a decision through four action tiers. The most debated instruction is not to file P3 findings as security issues. The authors say low-value tickets train teams to ignore the tooling.
What the test shows, and what it does not
AWS tested the file on a purpose-built application with ten known flaws. Eight were exploitable and two were mitigated by infrastructure controls.
Without the file, the model found all ten and ranked the two mitigated ones lower. But it set severity by intuition and verified nothing structurally. With the file, it found nine of ten. It did not flag a hardcoded credential.
So the file added evidence-based scoring, and the model missed one flaw in this test. These results are AWS's own, from one small application. They are not independent validation.
The authors say the formula's weights are a starting point. They advise teams to run it against labeled true and false positives and adjust. AWS is also clear that the file alone is not enough. A mature harness needs further capabilities built around it.
Why this matters to the people who fund it
Consider the developer who receives the ticket. The authors say an engineer who meets one fabricated vulnerability is less likely to keep reading the reports. Trust in the pipeline is the asset at stake, and it is spent one false finding at a time.
Aviation offers a parallel. A checklist does not make the pilot more skilled. It makes good practice repeatable on a bad day. A steering file does the same for triage.
Once triage rules live in a file, they are policy. Questions to put to your security team:
Who owns the steering file, and who reviews changes to it? Were its weights tested against labeled true and false positives? Does it separate who can reach a flaw from what happens if it is exploited? Do low-confidence findings become tickets? Can we compare results before and after an edit?
The model sets what an AI assistant can do. The instructions set what it will claim. Fund and govern the second as carefully as the first.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AWS Security.
