AI coding tools make you faster, and that speed is exactly the problem. They produce code that looks correct — well-formatted, plausibly named, confidently explained — which makes reviewers trust it more than they should. In 2026 the security risks are well understood; the failures come from teams treating AI output as safer than human output rather than equally suspect. Here is what to actually check.
The main risks
- Insecure-by-default code. Models reproduce common patterns from their training data, including outdated crypto, string-concatenated SQL, missing authorization checks, and permissive CORS. The code runs, the tests you wrote pass, and the vulnerability ships.
- Secrets in both directions. Developers paste API keys, tokens, and customer data into prompts. And models hard-code credentials or example secrets into generated code that then gets committed.
- Hallucinated dependencies (slopsquatting). AI sometimes suggests
import of a package that does not exist. Attackers monitor for these invented names, register them with malicious payloads, and wait for someone to run install.
- Prompt injection into agents. An AI coding agent with file and shell access can be hijacked by instructions hidden in a README, a dependency, a web page, or an issue it reads — turning "summarise this repo" into "exfiltrate the env file."
- Over-broad agent permissions. Agents given unrestricted shell, network, and credential access can do real damage when they go wrong, whether from injection or simple error.
Defenses, mapped to each risk
| Risk |
Defense |
| Insecure code |
Review AI code as carefully as human code; run SAST and linters in CI |
| Secrets in prompts |
Policy + tooling to block sensitive data in prompts; redact before sending |
| Secrets in output |
Secret scanning on commit (pre-commit hook + CI) |
| Hallucinated packages |
Verify every new dependency exists and is the one you meant before installing |
| Prompt injection |
Treat external content as untrusted; constrain agent tools and require approval |
| Over-broad permissions |
Scope agent credentials narrowly; sandbox shell and network access |
The mindset shift
The single most important rule: "the AI wrote it" is not a security argument. Generated code gets the same review, the same tests, the same static analysis, the same dependency vetting as anything a human wrote. If anything, raise the bar, because AI output is more uniform and more persuasive — reviewers skim it.
A practical checklist before merging AI code
- Does it validate and sanitise all external input?
- Are authentication and authorization checks present where they should be?
- Any hard-coded secrets, even "example" ones?
- Does every new dependency actually exist and is it the intended, maintained package?
- Did SAST, secret scanning, and the linter run and pass in CI?
- For agents: are tools, credentials, and network access scoped to the task?
FAQ
Is AI-generated code less secure than human code?
Not inherently, but it is produced faster and reviewed less carefully, so vulnerabilities slip through more often in practice. The fix is process, not banning the tools.
What is slopsquatting?
Attackers register package names that AI tools commonly hallucinate, so that when a developer trusts the suggestion and installs it, they get malware. Always verify a package before installing.
Can prompt injection really affect coding agents?
Yes. Any agent that reads external content and can run tools is exposed. Treat all read-in content as untrusted and constrain what the agent can do.
Should I stop pasting code into AI tools?
Stop pasting secrets and regulated data. For ordinary code, follow your company policy and prefer tools with clear data handling terms.
Where to go next
Best AI pair programmers in 2026, AI coding agents ranked in 2026, and AI agents that actually work in 2026.