The state of AI-generated code security in 2026

AI generated code has made huge strides in the past few years. From barely being able to string together small functions to building whole apps that already work after a few prompts. There is however the lingering question in the back of every developer’s mind: “Can I actually ship it?”

Risks of AI generated code

One of the most anxienty-inducing risks of AI-generated code is the one that is the least visible: security.

• Can a user read another user’s data by changing the user-id in a request?
• Is it possible to trick the server into doing unintended things by crafting special payloads?
• Are the user’s permissions actually checked correctly before performing a task?

These are just some of the questions that need to be answered before you’re shipping your app. If you’re using AI without being aware of those issues, you might run the risk of exposing your users, or yourself, to bad actors.

What has improved: Crypto & SQL injections

Two kinds of security problems have actually seen improvements in the last year¹: Most models are now reliable when it comes to correctly implementing cryptographic features. They can also spot problems in the usage of cryptographic APIs.

Furthermore, SQL injections, which were a notorious problem for LLMs due to the huge amount of bad examples in the training data, now appear less often in generated code than before.

These improvements stem from the fact that both problems can be solved with local reasoning. It is mainly a problem of eliminating bad patterns from the training data. After that the LLM will know to always use parametrized queries.

What remains difficult: Cross-site-scripting & authorization

The one thing that makes creating safe software products using AI difficult is the one thing LLMs have always struggled with: non-local reasoning. Keeping things secure often means keeping implicit assumptions in your head when coding:

• Have we already checked that the user is actually authorized to perform the operation we’re about to do?
• Is the string we just loaded from the database created by the user or the system? If it comes from the user, have we already escaped it?
• Can we show this piece of information to the user or would that implicitly reveal something that the user isn’t supposed to have access to?

All these questions require us to reason along all paths through the system. The difficult thing for LLMs is that these paths are not limited to a single sub-system, but stretch across the whole application. At first, when your app is small, the AI can seem to be on top of such issues. The codebase is small and the LLM can keep large parts of the app in its context window. But that is deceptive. The larger your app grows, the harder it gets for the AI to maintain security, especially across application layers.

Mitigating the problem

There are a few ways to mitigate the security problems. None of them will eliminate them, but you can at least reduce the size of the attack surface by following them.

1. Mention the potential security issues. If you include the security issues that might arise in your prompt, the LLM will hopefully pull in more examples where the issue does not exist. For example, if you’re adding a database to your app, include the instruction: “Always use parametrized queries”.
2. Add annotations to your code. If you have some security related context that is relevant to a variable or function, attach it as a comment. For example, if know that a string that has been stored into the database isn’t escaped yet, annotate the database loading function with that information.
3. Get a professional audit. If you’re about to launch your AI-assisted app, you need to pay extra attention to security issues. If you don’t, you not only risk your customer’s data, but also your money & data. One way to avoid the risk is getting a professional, human-lead security audit. For a flat fee of €490, you can get the assurance from a senior software engineer that your app is truly safe to launch.