You Own the Code AI Writes
An AI agent can build a working feature in the time it takes to describe it.
You ask for an endpoint that returns a user’s orders. A minute later, it runs, returns the right data, and the tests all pass.
But… it also returns orders to anyone who asks, regardless of their permissions, because nothing in your prompt said the caller should only see their own.
According to the AI, the code works. Many times, this kind of issue won’t show up in a demo or during testing. It shows up when the code is live in production, and by then it’s your commit and your incident to explain.
A couple of weeks ago, I wrote about when not to hand work to AI. The focus was on how AI is safe to use for work you can check and risky for work you can’t. Security is often where this gap shows up. Most engineers don’t see the security edges when AI builds functionality; it sits in nearly every feature an agent writes, and mistakes can live in production for months before anyone notices.
Working code is not secure code
A model writes code to do one thing: run and match what you asked for. Security is a separate property, and it stays optional unless you put it in the request.
Veracode tested this across more than 100 models and 80 coding tasks:
- 45% of the generated code carried an OWASP Top 10 vulnerability, the same flaws covered in week one of any security course.
- Newer and bigger models were no better. They kept getting more accurate at writing code that works, not code that’s safe.
Security is not required for code to run. Unless you are explicit, many models won’t prioritize writing production-secure logic.
The Four Most Common AI Security Gaps
A handful of failures keep coming up. Learn to recognize them in a diff, and you’ll catch most of what AI gets wrong.
- Injection. The agent builds a database query by pasting user input straight into a SQL string. Send it a crafted value and the database runs the attacker’s query instead of yours. The same shape enables cross-site scripting, where untrusted input is written directly to the page. Veracode found that models failed to defend against cross-site scripting in 86% of the samples where it was relevant.
- Broken access control. The code confirms you’re logged in, then trusts whatever account ID the request hands it. Change the ID, and someone else’s data comes back. This is what exposed a large swath of AI-built apps last year: the generated database rules skipped the per-user check, so a public key in the frontend let anyone read or write other people’s records. A researcher pulled real home addresses, debt balances, and live API keys without ever logging in.
- Hardcoded secrets. The agent wires up a payment call with the live API key hard-coded in the source, because most of the code it learned from did the same. GitGuardian found repositories using an AI assistant leak secrets about 40% more often than the public average. Once a key is committed, it lives in the git history, and you have to track down everywhere it has spread before you can safely rotate it.
- Hallucinated dependencies. Ask an agent for a library, and it will sometimes invent one that sounds right but doesn’t exist. A 2025 study found that roughly 20% of AI-recommended packages were fake, and the same fake names kept coming back, run after run. Attackers register those names on npm and PyPI with malware, so a single install on a confident suggestion can ship someone else’s code straight into your build.
None of these are obvious when reviewing code written by AI. They’re the security version of an off-by-one error. They slip through because you can’t catch a mistake you don’t recognize.
A Strong Security Foundation Drives AI Speed
Having a strong security foundation makes AI an accelerator, not a risk. It lets you accept good output quickly and reject bad output before it ships.
Without it, you’re stuck choosing between two losing moves:
- Trust everything the agent writes, and ship its mistakes.
- Doubt it all and re-check every line by hand.
Both options put the brakes on the AI functionality you are trying to leverage for speed.
With a foundation, you can:
- Set the constraints up front, the way you’d define an interface or a test. Tell the agent the auth rule and which data is sensitive before it writes a line.
- Read the diff and catch the missing check before committing, rather than in a postmortem.
- Ask the agent to defend its security choices, and judge whether the answer holds up.
Security knowledge and AI tooling make each other more valuable, just as skills compound when they reinforce one another. The foundation tells you what to ask for and how to grade what comes back. The tool does the typing.
That’s how you get speed, quality, and security together instead of trading one for another. It only works in that order. The foundation comes first because the tool can’t supply it for you.
When you approve agent code with the access-control hole still in it, you set the team’s bar at “it runs and the tests pass.” The next person conforms to that bar. So does the one after that.
It works the other way too. The engineer who catches these issues in review, names them, and asks for the fix raises the bar without calling a single meeting.
Your agent will eventually (or more likely, already has) written insecure code. The question that matters is whether you’ll catch it before it ships.