Hidden Security Risks of AI Coding Tools

The Shortcut That Ships Vulnerabilities

A developer needs to add a file upload feature to a web application. They ask GitHub Copilot to generate the code. Copilot obliges instantly, producing clean-looking code that handles the upload, saves the file, and returns a success response.

The code works. Tests pass. It ships to production.

Six months later, a security researcher discovers that any user can upload a PHP script disguised as an image and execute arbitrary code on the server. It’s one of the oldest web vulnerabilities in existence — and AI generated it without a warning.

This isn’t a hypothetical. It’s a pattern that security researchers studying AI code generation have documented repeatedly: AI tools produce insecure code at a meaningful rate, and the code often looks correct even when it isn’t.

Why AI-Generated Code Has Security Problems

AI coding assistants are trained on vast quantities of publicly available code — including the millions of lines of vulnerable code that exist across GitHub, Stack Overflow, and old tutorials. When the training data contains vulnerable patterns, the model learns those patterns.

This creates several specific problems:

Outdated patterns

The internet is full of code examples that were acceptable five years ago but are now known to be insecure. Old tutorials showing how to handle passwords with MD5 hashing. Database query examples vulnerable to SQL injection. File handling code that doesn’t validate inputs. AI models learn from all of it.

Missing context

A language model generates code based on what you asked for, not on what you need. You asked for “code to upload a file.” You didn’t ask for “code to upload a file securely, with file type validation, size limits, and virus scanning.” If you didn’t specify security requirements, the AI almost certainly didn’t include them.

Confident incorrectness

AI coding tools present their output with no uncertainty. There’s no disclaimer saying “this code may be vulnerable to injection attacks.” The clean, confident formatting triggers the same trust response as reading documentation — which is exactly why developers accept it without review.

Hallucinated dependencies

AI tools sometimes suggest importing libraries or calling functions that don’t exist — or that do exist but have known security vulnerabilities. A developer who trusts the suggestion and installs the recommended package may introduce a supply chain risk.

The Research Is Sobering

A 2022 Stanford study found that developers using GitHub Copilot were more likely to introduce security vulnerabilities than those coding without it — partly because of over-reliance on the generated output, and partly because the AI suggestions changed how developers thought about the problem.

A separate study by NYU researchers found that approximately 40% of code completions by AI tools contained security vulnerabilities. The types most common were injection vulnerabilities, path traversal, and insecure cryptographic practices.

The problem isn’t that AI coding tools are bad. They’re genuinely useful for boilerplate, documentation, and routine tasks. The problem is the assumption that “it generated cleanly, so it’s probably fine.”

What Types of Vulnerabilities Are Most Common?

For anyone who manages developers or is responsible for software quality, these are the vulnerability categories most commonly introduced by AI-generated code:

SQL injection. Code that incorporates user input directly into database queries, allowing an attacker to manipulate the query and access or delete data they shouldn’t see.

Path traversal. File handling code that doesn’t properly restrict which files a user can access, potentially allowing them to read system files outside the intended directory.

Hardcoded secrets. API keys, passwords, and tokens embedded directly in source code. AI tools learn this pattern because it exists extensively in training data — including code that was later fixed but remains in the dataset.

Insecure deserialization. Code that accepts serialised data from users and processes it without validation, which can allow an attacker to execute code on the server.

Missing authentication checks. AI-generated routes and endpoints that implement the functionality without checking whether the requesting user should be allowed to perform that action.

Weak cryptography. Use of outdated or broken algorithms (MD5, SHA-1, DES) for hashing or encryption, often because these appear throughout older code in the training data.

What Responsible Teams Are Doing

Using AI coding tools responsibly doesn’t mean avoiding them — it means building the right habits around them.

Treat AI output like external code

If a developer downloaded a random library from the internet, no responsible team would ship it without review. AI-generated code deserves the same treatment: read it, understand it, and question it.

Ask AI to review its own output for security

This sounds paradoxical, but it works. After generating code, paste it back to the AI with the prompt: “Review this code for security vulnerabilities.” Language models are often better at critique than at initial generation, and this can surface obvious issues quickly. It’s not a substitute for a proper review, but it catches low-hanging fruit.

Use static analysis tools

Tools like Semgrep, SonarQube, or GitHub’s built-in code scanning can automatically detect many common vulnerability classes. Running these on every pull request catches issues that both humans and AI miss.

Include security requirements in the prompt

Instead of “write me code to upload files,” try “write me code to securely upload files — validate file type by magic bytes, limit size to 10MB, reject executables, and store outside the web root.” The more specific your security requirements, the more likely the AI is to address them.

Maintain security-focused code review

The final check before any code ships should include a security lens. This doesn’t require a dedicated security engineer for every review — it requires developers who understand common vulnerability patterns and know what to look for in the classes of code they’re reviewing.

A Note on Pasting Sensitive Code Into Public AI

Separate from the security of the output, there’s the security of the input. When developers paste proprietary code into ChatGPT or Copilot Chat to ask for help, that code leaves your organisation’s control.

This is particularly relevant for:

• Code that contains credentials (even partially masked)
• Proprietary algorithms or business logic
• Code related to payment processing, authentication, or medical data

Enterprise versions of Copilot and ChatGPT handle data retention differently from free tiers, but the default assumption for any public AI tool should be: once you paste it, it’s no longer exclusively yours.

For Business Owners and CTOs

If your team is using AI coding tools — and they almost certainly are, whether or not you’ve formally authorised it — a few practical actions are worth taking:

1. Establish a clear AI usage policy for development. What tools are approved? What types of data can be pasted? What review process is required for AI-generated code?

2. Include AI-specific security patterns in developer training. Developers need to know which vulnerability types AI tools are most likely to produce.

3. Run a security assessment on recent code to establish a baseline. If AI tools have been in use for a year without a security audit, there may already be vulnerabilities in production.

If you’d like to discuss how to introduce safer AI development practices in your organisation, we’d be happy to talk.