The uncomfortable truth about AI-generated code is that it is confidently mediocre about security. A model will produce a working endpoint, a plausible database query, and a helpful comment explaining what it did — and then quietly concatenate user input into that query because the training data was full of examples that did exactly that. The code compiles, the happy-path test passes, and the vulnerability ships. What has changed since 2021, when NYU's Asleep at the Keyboard? study found roughly 40% of AI completions in security-relevant scenarios contained a weakness, is not the error rate so much as the volume. Assistants now draft a substantial fraction of new code in many organizations, which means the same recurring flaws — injection, missing authorization checks, weak crypto, hardcoded secrets — arrive faster than manual review was ever designed to catch them.
This guide is about closing the gap between "the AI wrote it" and "the AI's output is safe to merge." The organizing principle is simple: treat AI-generated code as untrusted until verified, exactly as you would treat a pull request from a new contributor whose track record you do not yet know.
Why AI-generated code fails differently
Human developers introduce vulnerabilities through ignorance, fatigue, or deadline pressure. Models introduce them through pattern imitation. A large language model predicts the most statistically likely continuation of your prompt, and the most likely continuation is whatever appeared most often in its training corpus — which includes an enormous amount of tutorial code, Stack Overflow snippets, and abandoned repositories that were never written with security in mind. The result is failure modes worth naming explicitly:
- Insecure-by-default patterns. String-formatted SQL,
eval()on request data, disabled TLS verification, and permissive CORS all appear because they are common in the wild, not because they are correct. - Plausible-but-wrong dependencies. Models occasionally recommend packages that do not exist or that impersonate real ones, a problem serious enough to earn its own name — slopsquatting — and its own attacker playbook.
- Silent scope creep. Ask for a file reader and you may get one that also follows symlinks, accepts absolute paths, and never validates the directory. The extra behavior is helpful-looking and rarely questioned.
- Confident wrongness. Because the output reads fluently and includes reassuring comments, reviewers extend it more trust than an equivalent human diff would earn.
Practical controls that actually work
Securing AI output is not a single gate; it is a short chain of checks, each cheap on its own.
1. Make AI-authored changes visible. You cannot apply extra scrutiny to code you cannot identify. Where your tooling supports attribution of AI-assisted commits, use it, and label those pull requests so they route to mandatory scanning and a second human reviewer. If attribution is unavailable, assume every diff may be AI-assisted and set your baseline accordingly.
2. Scan every diff with static analysis. AI-generated code should pass the same SAST rules as everything else, with no "it's just a small helper" exemption. The patterns models repeat — injection, path traversal, deserialization of untrusted data — are precisely the ones static analysis is good at catching. Run it in CI as a blocking gate, not an advisory comment.
3. Verify dependencies before they land. When an assistant adds an import, confirm the package exists, is the one you intended, and has no known-vulnerable version. Automated software composition analysis (SCA) on every build reconciles new dependencies against a component inventory and a vulnerability database so a hallucinated or malicious package cannot slip in unnoticed.
4. Test behavior, not just compilation. Add security-focused test cases — malformed input, injection payloads, authorization boundary checks — to the suites that guard AI-touched modules. A generated function that "works" on clean input often collapses on adversarial input.
5. Confirm exploitability at runtime. Not every flagged pattern is reachable. Pairing static findings with dynamic application security testing (DAST) tells you whether a vulnerable path is actually exercisable in the running application, which lets reviewers spend their attention on real risk instead of theoretical lint.
A quick worked example
Consider a common request: "write an Express route that looks up a user by ID." A model may return:
app.get('/user/:id', (req, res) => {
db.query(`SELECT * FROM users WHERE id = ${req.params.id}`, (e, r) => res.json(r));
});
This is textbook SQL injection, and it reads as perfectly reasonable. The fix is trivial — parameterized queries — but the point is that the model produced the vulnerable version by default, and only a review or scanning step catches it:
app.get('/user/:id', (req, res) => {
db.query('SELECT * FROM users WHERE id = ?', [req.params.id], (e, r) => res.json(r));
});
Multiply that single decision across every route, query, and deserialization an assistant drafts in a week, and the value of an automated gate becomes obvious. Humans will not reliably catch the tenth instance as carefully as the first.
How Safeguard helps
Safeguard is built for exactly this workflow: verify AI output instead of trusting it. The Griffin AI detection engine is tuned to recognize the insecure patterns coding assistants repeat most — string-built queries, missing input validation, deprecated cryptographic calls, and hardcoded credentials — and flags them on the diff, before merge rather than after deployment. Dependency changes are checked automatically, so a hallucinated or typosquatted package is caught the moment it appears in a manifest. When Griffin identifies a fixable issue, auto-fix remediation opens a pull request with the patch already applied, turning review time into approval time. And because Safeguard exposes these capabilities through the Safeguard MCP server, the same assistant that wrote the code can be pointed at the platform and asked to scan its own output and remediate what it finds — closing the loop inside the developer's existing tools.
The goal is not to slow AI-assisted development down. It is to make the speed safe, so that shipping fast and shipping secure stop being a trade-off.
Ready to put a verification gate in front of your AI-generated code? Create a free Safeguard account and connect a repository in minutes, or read the full documentation to see how the pieces fit together.