Secure Coding in the AI Era: New Attack Surface, Same Old Discipline

AI coding assistants are now part of nearly every development workflow. They make us faster — and they make our mistakes faster too. Studies and our own experience agree: AI-generated code ships with security bugs at roughly the same rate as human code, sometimes higher, because it's accepted with less scrutiny.

Secure coding in the AI era isn't a new discipline. It's the same discipline, applied to a new and larger attack surface. Here's what actually matters.

The new risks AI introduces

Insecure-by-default suggestions

LLMs are trained on public code — including a vast amount of insecure public code. Ask for a database query and you may get string concatenation (SQL injection). Ask for file handling and you may get a path-traversal bug. Ask for "quick auth" and you might get a hardcoded secret. The model produces what's common, not what's secure.

Hallucinated dependencies ("slopsquatting")

AI assistants sometimes invent package names that don't exist. Attackers have noticed: they register those hallucinated names on npm/PyPI with malicious payloads. A developer pastes the AI's import, runs install, and ships malware. Always verify a dependency exists and is the real, maintained package before adding it.

Leaked secrets in prompts

Pasting code with real API keys, connection strings, or customer data into a third-party AI tool can leak it — into the provider's logs, or worse, into training data. Treat the prompt box like a public channel unless you're on an enterprise plan with a contractual no-training, no-retention guarantee.

Prompt injection in AI-powered features

If your product embeds an LLM — a chatbot, a RAG assistant, an agent with tools — then user input flowing into prompts is the new injection frontier. A user (or a poisoned document the LLM reads) can smuggle instructions that make the model leak data or call tools it shouldn't. Never give an LLM the ability to perform destructive or sensitive actions without an allow-list and human confirmation.

The old discipline that still saves you

None of the fundamentals changed. They matter more now because more code is being generated, faster.

• Validate and sanitise all input. Parameterised queries, not string building. Allow-lists, not block-lists.
• Least privilege everywhere. Every service account, token, and database role should have the minimum it needs. This bounds the blast radius of any bug — AI-generated or not.
• Never trust the client. Authorisation belongs on the server. AI loves to write client-side checks that an attacker can bypass.
• Secrets in a vault, never in code. Use environment variables and secret managers; scan your repo for committed keys.
• Keep dependencies current and scanned. Automated dependency updates plus an SCA tool (Dependabot, Snyk, Socket).

How to actually work safely with AI assistants

1. Treat AI output as a junior developer's draft. Useful, fast, and in need of review. Read every line before you accept it.
2. Ask the AI to review its own security. "What are the security risks in this code?" is a genuinely useful follow-up prompt — the model often catches its own injection and validation gaps.
3. Keep a human in the loop for anything security-sensitive — auth, crypto, payments, access control, data handling.
4. Run automated security tooling in CI. Static analysis (SAST), dependency scanning (SCA), and secret scanning catch the bulk of what slips through review. This is non-negotiable when code volume goes up.
5. Use enterprise AI tiers for proprietary code — ones that contractually exclude your code from training and retention.
6. Verify every dependency the AI suggests actually exists and is the maintained, popular package — not a typo-squat or hallucination.

The uncomfortable truth

AI lowers the floor for writing code, which means more code is written by people who don't know what's dangerous about it. The bugs aren't new — SQL injection is older than most developers — but they're being generated and shipped at a scale we haven't seen before, often with less review because "the AI wrote it."

The teams that stay safe are the ones that treat security as a process, not a feature: review discipline, automated scanning in CI, least privilege by default, and a healthy skepticism toward any code — human or machine — that touches authentication, money, or customer data.

If you're shipping AI-assisted code without a security review pipeline, that's the gap to close first. We help teams set up exactly that — SAST, dependency scanning, secret detection, and a lightweight secure-review process that doesn't slow delivery down.