AI in engineering companies · Coding agents

The security of AI-written code

Catherine Ives-YimPublished 27 September 2026 · 5 min read

Coding agents write a great deal of code, quickly and fluently. Some of it is insecure. That is not because AI is uniquely careless. It is because agents learn from enormous amounts of existing code, much of which is insecure, and because they optimise for code that works rather than code that resists attack.

This article describes the security issues I see most often in AI-written code, the additional risks that come from agents themselves, and the practices that keep both under control. As with the rest of my writing on security, it explains the issues so they can be recognised and prevented, not as a guide to exploiting them.

Why AI-written code has characteristic weaknesses

It reproduces common patterns. Agents write what code usually looks like. Where common practice is insecure, as it often is in examples, tutorials and old projects, the agent reproduces it.

It optimises for working. An agent checks its work by running it. Insecure code usually runs perfectly well. Nothing in the loop tells the agent that it has left a door open.

It lacks context. Security often depends on knowledge outside the file being edited: who is allowed to call this function, what data flows through it, what the threat model is. If the agent is not given that context, it cannot apply it.

It looks trustworthy. Clean, well-commented, confident code attracts less scrutiny than messy code. That is exactly the wrong way round.

The typical issues

These are the weaknesses I find most often in code produced with coding agents. None is new. Each is easier to miss when the code arrives fluent and complete.

Missing or misplaced authorisation. The endpoint works, the data is returned, and nobody checks whether this user is allowed to see it. Or the check is present in one path and missing in another.

Trusting input. Data from users, devices, files or other systems used without validation, leading to the classic injection weaknesses and to devices that fail on malformed messages, as described in Connected products versus AI-assisted attackers.

Secrets in code. Keys, passwords and tokens written directly into source files or configuration, often because the agent was shown an example that did so, and then committed to version control.

Insecure defaults. Debug modes left on, permissive cross-origin settings, verbose error messages that reveal internals, services listening on every interface.

Weak cryptography. Outdated algorithms, predictable random numbers used for security purposes, home-made schemes where a standard library exists, or cryptographic checks that can be bypassed.

Unsafe handling of files and data. Paths built from user input, untrusted data deserialised directly into objects, uploads accepted without checks.

Out-of-date practice. Code written against an older version of a library, using functions since deprecated for security reasons.

Invented or unvetted dependencies. Packages that do not exist, or exist under a similar name published by someone else, as described in The AI supply chain.

Error handling that fails open. When something goes wrong, the code carries on rather than stopping safely, which in security-sensitive paths can mean skipping a check entirely.

Risks from the agent itself

A coding agent is not just a code generator. It is an agent with tools, usually running on an engineer's machine or in a build environment. That brings the risks described in Agents with keys.

It can run commands. An agent that can execute commands can, if misdirected, do anything the account it runs under can do.

It reads untrusted content. Repositories contain third-party code, documentation, issue text and comments written by others. Instructions hidden in that content can influence what the agent does, as described in When the data gives the orders.

It may see secrets. If credentials are in the working environment, files or command history, the agent may read them, include them in its output or send them to a provider.

It can change the build. An agent with access to build scripts or deployment configuration can alter what gets built and shipped.

Practices that work

Give the agent the security context. Tell it the threat model, the authorisation rules and the coding standards. Put them in the project's instruction files so every task starts with them.

Review security-sensitive code with particular care. Authentication, authorisation, cryptography, input handling, anything touching secrets or external interfaces. This is where an experienced reviewer earns their time, as argued in Coding agents need experienced engineers.

Use a second model as a reviewer. Having a different model review security-relevant changes is one of the most useful practices I have adopted. Different models miss different things. It is an extra layer, not a replacement for human review.

Automate the checks. Static analysis, dependency scanning and secret scanning on every change, whoever or whatever wrote it. These catch many of the typical issues cheaply.

Protect the tests and the build. Treat changes to tests, build scripts and deployment configuration as high-risk, requiring review.

Sandbox the agent. Run coding agents with the minimum permissions they need, in an environment without production credentials, with network access limited to what the task requires, and with commands that change anything significant requiring approval.

Keep secrets out of reach. Secrets belong in a secrets manager, never in the repository or the agent's working environment.

Vet every dependency. Never install a package because an agent suggested it.

Test independently. AI-assisted code should face the same independent security testing as any other. The connected vehicle platform I led with AI assistance was security tested throughout development, with thousands of automated tests with industry-standard security tools, run by different AI models from the ones that wrote the code. That is the minimum I would apply to any product that matters.

Four things worth taking seriously

For engineering leaders: AI-written code needs the same security discipline as human-written code, and more review in sensitive areas, because it looks more trustworthy than it is.

For security teams: add automated scanning to every change, and treat coding agents as privileged tools that need sandboxing.

For engineers: give the agent the security context it cannot know, and review authentication, authorisation, input handling and secrets with particular care.

For everyone: code that works is not the same as code that is secure. Agents check the first. People must check the second.

I would be interested to hear whether your organisation's code review and security scanning have kept pace with the volume of code agents now produce.