AI Wrote Your Code. Have You Checked It for Vulnerabilities?

A year ago, writing a web app meant knowing how to write a web app. Today you can describe what you want to an AI assistant and watch a working application appear — routes, database queries, auth, the lot — often faster than you could have typed the boilerplate yourself. It's a genuine shift, and it's not going away.

But there's a question that almost nobody asks in the rush of watching code materialise: is any of it secure?

The trust gap

Here's the uncomfortable reality. An AI coding assistant is optimised to produce code that works — code that runs, passes the obvious test, and does what you asked. It is not, by default, optimised to produce code that's safe. Those are different goals, and the difference is completely invisible when you're steering by feel.

Your AI-generated app can look finished. It can pass every click-through. It can demo beautifully. And it can still ship with holes an attacker will find in minutes — because "works in the demo" and "safe in production" are not the same thing, and the model was aiming at the first one.

This isn't a knock on AI coding. It's a description of what these tools actually do. They pattern-match to the most common way to accomplish a task, and the most common way is very often not the secure way — because the training data is full of quick, insecure examples from tutorials, forum answers, and real codebases that themselves cut corners.

What AI-generated code gets wrong — again and again

Across AI-generated projects, the same weaknesses show up with striking regularity:

String-built database queries. Ask an assistant to "look up a user by email" and, unless you're specific, you'll frequently get a query with the input glued directly into the SQL string. It works perfectly in the demo. It's also textbook SQL injection.

Hardcoded secrets. To "just get it working," assistants happily drop API keys, tokens, and database URLs straight into the code. That code then gets committed and pushed — and anything in your repo or client bundle is effectively public.

Missing authorization. AI is good at "is the user logged in?" and much weaker at "is this user allowed to touch this specific record?" — so endpoints ship that check authentication but not authorization.

Rendering user input directly. The shortest path to displaying data is often to inject it straight into the page, which is exactly how cross-site scripting happens.

Dangerous defaults. Disabled TLS verification to "make the request work," eval to "parse this quickly," permissive CORS to "fix the error" — the assistant reaches for whatever clears the immediate obstacle, and security is the silent casualty.

None of these require a sophisticated attacker. Automated bots scan the entire internet for exactly these mistakes, constantly.

Why you can't just eyeball it

With hand-written code, you at least know what you wrote. You have a mental model of where the risky parts are. With AI-generated code, that model is gone. You didn't write it, you may not fully understand every line, and — crucially — you can't spot the thing that's missing. In security, it's almost always the missing thing that gets you: the check that isn't there, the escaping that was skipped, the key that shouldn't be in the bundle.

Worse, AI-generated code has a dangerous quality: it looks trustworthy. It's fluent, well-formatted, and confident. That fluency makes people scrutinise it less, not more. And when you can deploy a dozen times a day, each deploy is a fresh chance to ship something exposed without noticing.

So the honest position isn't "AI code is bad." It's: AI code is unverified until you verify it. You wouldn't merge a stranger's pull request without review. AI-generated code deserves the same skepticism — arguably more, because it was written to satisfy a prompt, not to pass a security review.

Trust, but verify — with a scanner that reads the code

This is exactly where safeey-cli fits. It's a free, local command-line scanner that reads your source code and flags the security issues AI assistants routinely introduce — SQL injection, command injection, XSS, hardcoded secrets, weak crypto, dangerous defaults, vulnerable dependencies — with the exact line and the fix.

Because it's deterministic and rule-based, it doesn't guess. It points at a specific line, tells you why it's dangerous, and tells you what to change. And it runs entirely on your machine, so your code never leaves it.

The workflow slots neatly into how people already build with AI:

npm install -g safeey-cli
safeey scan ./

  Safeey CLI  ·  scanned 28 file(s) in ./

  src/api/users.js
    HIGH      Possible SQL injection        :17:12   js/sql-injection
      A SQL query is assembled by string interpolation. Injected
      input can change the query's meaning.
      fix  Use parameterised queries (placeholders + a values array).

  src/lib/mailer.js
    CRITICAL  API credential exposed        :4:20    secret/generic-assignment
      A hardcoded credential appears in source (SG.x…9k).
      fix  Move it to an environment variable and rotate it.

  ────────────────────────────────────────────────
  Risk grade D (58/100)   1 critical · 1 high

In seconds, the invisible becomes visible: two real problems the AI introduced, exactly where they live, and how to fix them.

Close the loop with your AI

Here's the part that makes this genuinely powerful. safeey-cli tells you what's wrong and how to fix it in plain English — which means you can hand the finding straight back to your AI assistant:

"safeey-cli flagged a SQL injection on line 17 of users.js. Rewrite this query to use parameterised queries."

The assistant that introduced the flaw is perfectly capable of fixing it once it's told about it specifically. The scanner is the missing feedback signal in the AI coding loop: generate → scan → fix → re-scan. Run it again and watch the grade climb:

  Safeey CLI  ·  scanned 28 file(s) in ./

  ✔ No issues found.  (Grade A)

You keep all the speed of building with AI, and you add the one thing the AI workflow skips: an objective check that what you shipped is actually safe.

Make it automatic

You don't even have to remember to run it. Because safeey-cli returns a non-zero exit code on findings, it drops straight into CI:

- name: Security scan
  run: npx safeey-cli scan . --fail-on high

Now every push of AI-generated code gets scanned, and anything with a high-severity issue can't merge. The safety net is always on.

The takeaway

AI has removed the barrier to building software. It has not removed the responsibility to secure it — it's just made that responsibility much easier to forget, because the code arrives looking finished.

The fix isn't to stop using AI. It's to add a verification step that matches the speed of AI generation: a scanner that reads the code, finds what the assistant missed, and tells you how to fix it. Treat every AI-generated feature as unverified until it's scanned, and make scanning as routine as running the app.

Your AI wrote the code. safeey-cli tells you how risky it is.

npm install -g safeey-cli && safeey scan ./

Then pair it with a Safeey site scan to check your live deployment from the outside too — the code and the running app, both covered.