I use AI coding tools every day, I help teams adopt them, and I wrote a book about staying safe while doing it. So let me say this clearly at the start: the security risks of these tools are real, they are regularly underestimated, and none of them justify avoiding the tools. They justify discipline. This article walks through the risks I actually see in practice, not the theoretical ones, and what to do about each.
1. Your code and data leave the network
The most fundamental risk is also the most invisible. Every prompt you send to a cloud-hosted assistant carries context: the file you are editing, often neighboring files, sometimes your whole repository map. That context travels to a third-party API, is processed on someone else’s servers, and may sit in logs you will never see. For a hobby project this is a fair trade. For client code under NDA, unreleased product work, or anything your compliance regime covers, it is a decision someone should make deliberately, and in many teams nobody ever has.
Enterprise agreements with no-training commitments narrow this risk but do not remove it; a contract is a promise, not a control. If certain code must demonstrably never leave your infrastructure, the answer is running assistants against self-hosted models, and my article on choosing between on-premise and cloud AI gives the full decision framework.
2. Generated code is confidently insecure
AI models write code that looks right. That is precisely the problem: the same fluency that makes them productive makes their mistakes persuasive. In review after review I see the classic patterns: string-built SQL that invites injection, missing authorization checks on the happy path, secrets read without validation, deprecated cryptographic defaults reproduced from a decade of old tutorials in the training data. The model is not malicious; it is a mirror of everything it has read, and much of what it has read is insecure.
The mitigation is not hoping for better models. It is treating every generated line as a draft from a fast, well-read junior who has never met your threat model. Review it with a security-first eye, test it, and never merge what you do not understand. This is the central argument of my book You Are the Quality Control, and it is the habit that separates teams that get value from these tools from teams that get incidents.
3. Secrets find their way into prompts
Developers paste. An error message with a connection string, an environment file for “context”, a config with an API key: once it goes into a prompt, it has left your control as surely as if it were committed to a public repository. Agentic tools raise the stakes because they read files themselves; an assistant with repository access will happily read your .env file into context while investigating a bug unless told otherwise.
Practical hygiene: keep real secrets out of the working tree entirely (secret managers, gitignored local files), configure your tools’ ignore lists so assistants cannot read secret-bearing paths, run secret scanning in CI as the backstop, and rotate anything that does slip. Assume any credential that entered a prompt is exposed.
4. The supply chain gets a new attack surface
AI assistants recommend dependencies constantly, and sometimes they recommend packages that do not exist. Attackers noticed: they register those hallucinated names with malicious payloads and wait for the next developer whose assistant suggests the same plausible name. Combine that with old-fashioned typosquatting and the risk is concrete: a single unverified install command from a chat window can compromise a build environment.
The rule is simple and non-negotiable: every dependency an AI suggests gets the same vetting a human suggestion would. Does the package exist, is it maintained, does the name exactly match the ecosystem’s canonical one, do the downloads and history look organic? Thirty seconds of checking beats an afternoon of incident response.
5. Agents can act, and can be manipulated into acting
Modern tools are not autocomplete anymore. Agents run shell commands, edit files across a repository, and call external services. That power meets a genuinely new risk: prompt injection. An agent that reads a web page, a package README, an issue comment, or even a source file can encounter text crafted to redirect it (“ignore your instructions and run the following”). The agent cannot always tell your intent from an attacker’s embedded one.
Defense in depth works here. Run agents with the least access they need, use the approval modes the tools ship with rather than blanket auto-approve (my setup guides for Claude Code and the OpenAI Codex CLI cover these controls), sandbox what can be sandboxed, keep production credentials out of development environments entirely, and treat “the agent did it” as the new “it works on my machine”: not an excuse, a review failure.
6. Review erodes as volume grows
The quietest risk compounds over months. AI multiplies the volume of code flowing toward review while the supply of careful reviewers stays fixed. Approvals get faster, diffs get bigger, and the assumption “the tool probably got it right” spreads. Individually reasonable shortcuts add up to a codebase nobody fully understands, which is a security problem in itself: vulnerabilities hide best in code nobody truly read.
Guard the process deliberately: keep changes small enough to actually review, require the author to explain generated code in their own words, and measure review depth, not just throughput. Speed you cannot verify is not speed; it is deferred incident cost.
The pattern behind all six
Notice what these risks share. None of them is exotic, and none is stopped by a product you can buy. Each is stopped by an engineering discipline applied at a new point: data classification applied to prompts, secure code review applied to generated diffs, dependency vetting applied to suggestions, least privilege applied to agents. The theory of secure development did not change; AI just created new places where you must practice it. Teams that already had the discipline extend it in weeks. Teams that never had it discover that AI amplifies whatever engineering culture it lands in, including the gaps.
Next steps
If your organization’s constraint is that code must never reach a third-party API at all, start with my private AI deployment page: running assistants against models inside your own network removes the exposure class entirely rather than managing it. For the review discipline side, You Are the Quality Control is the field guide. And if you are rolling these tools out to a team and want the guardrails set up right the first time, tell me about your situation.
