Your AI Coding Assistant Has OWASP Blind Spots. Here's What to Train For.

AI coding assistants are remarkable productivity tools. They're also, in specific and predictable ways, security liabilities — not because the models are malicious, but because they're trained to produce code that works, not code that's secure.

Understanding where they reliably fall short is the first step to training your team to compensate.

The confidence problem

The most dangerous property of AI-generated code isn't that it's wrong. It's that it looks right. An AI assistant will generate an authentication flow, a file upload handler, or an API endpoint with the same fluent confidence whether the output is secure or contains a textbook vulnerability.

Developers — especially developers under time pressure — read AI suggestions with a bias toward acceptance. The code is clean. It compiles. It passes the obvious test cases. The missing authorization check doesn't announce itself.

Where AI assistants reliably struggle

These are the OWASP categories where AI-generated code most commonly produces insecure patterns in practice:

A01 — Broken Access Control. AI tools are good at generating the mechanics of an endpoint but poor at reasoning about who should be allowed to call it. Missing role checks, insecure direct object references, and missing ownership validation are common in AI output because they require business-logic context the model doesn't have.

A02 — Cryptographic Failures. AI assistants frequently suggest deprecated algorithms, insufficient key lengths, or homegrown crypto patterns when a developer's prompt doesn't specify a standard. The code works. The crypto is weak.

A07 — Authentication and Session Management. JWT handling is a particularly common failure point. AI tools regularly generate code vulnerable to algorithm confusion attacks or missing signature verification, especially when the prompt is focused on "make this work" rather than "make this secure."

Prompt Injection (AI-native, not on the classic OWASP list). This is the new one. Any application that passes user input to an LLM — which is now a large and growing category — is exposed to prompt injection if the developer hasn't been trained to recognise and mitigate it. AI coding assistants don't model this threat because it didn't exist at scale when most of them were trained.

What this means for your training programme

The implication isn't "stop using AI coding tools." The implication is that developer security training needs to be updated for the AI-assisted workflow.

Developers need to know which output categories require heightened review. They need the pattern recognition to look at an AI-generated authorization check and ask "does this actually verify what I think it verifies?" They need to know that a clean-looking JWT library integration can be broken at the algorithm level.

And they need to be trained on the AI-native threat classes — prompt injection, MCP server security, insecure agentic tool use — that didn't exist in the curriculum two years ago.

The security landscape didn't wait for the training to catch up. The training needs to catch up now.