We Caught an AI Prompt Injection Live, Mid-Deployment

Mid-deployment, on a completely routine command, our AI coding assistant read a message clearly written to be read by an AI, not a person, telling it to go authenticate at a website we'd never heard of. It didn't go. It flagged it, we investigated, and it turned out to be spam rather than an attack. But for a few seconds, with live access to a client's production database open, there was no way to know that for certain. Here is exactly what happened, and what we changed so it can't happen unnoticed again.

We're sharing this openly for the same reason we shared the crypto-drainer incident on this blog last month: most businesses using AI tools have no idea this risk category exists, and the fewer people who understand it, the more successful it gets. This isn't a hypothetical. It happened during real client work, and we caught it because we'd already built the habit of not trusting anything an AI reads by default.

What Happened During a Real Deployment

We were mid-deployment on a client's production application, a routine update, nothing unusual about the task itself. Partway through, a standard command ran a piece of software called dotenv, one of the most widely used tools in the world for loading an application's secret keys and passwords. Practically every website you've ever used runs it somewhere behind the scenes.

Buried in its normal startup output was a line that had no business being there:

◇ injected env (14) from .env.local
  tip: ⌁ auth for agents [www.vestauth.com]

That phrasing isn't written for a human reading a deploy log. "Auth for agents" is a direct address to an AI, telling it to go authenticate somewhere. Tracing further, the same package version had also quietly bundled two files, skills/dotenv/SKILL.md and skills/dotenvx/SKILL.md, added specifically, according to the package's own changelog, "for AI coding agent discovery."

Our AI assistant did not visit the site. It did not open either file as an instruction. It stopped, investigated through safe read-only means, and flagged the whole thing before doing anything else. That pause is the entire point of this article.

What Prompt Injection Actually Is

An AI coding assistant doesn't just talk to the person using it. Over the course of a real task, it reads dozens of other things: file contents, command output, web pages, error messages, other software's documentation. Every one of those is a place someone else's words can end up in front of the AI.

Prompt injection is what happens when the AI can't reliably tell the difference between "an instruction from the person I'm actually working for" and "text I happened to read somewhere." If a piece of content is phrased like an instruction, visit this link, run this command, authenticate here, and the AI treats it as one, it can be steered into doing something the real user never asked for.

It doesn't require a hacker breaking into anything. It only requires the AI reading something, anything, that was written to look like a command. A webpage the AI fetches to answer a question. A file in a repository it's reviewing. A software package's own startup message, as happened here. The delivery mechanism barely matters; what matters is whether the AI can resist following text it never should have trusted in the first place.

Why This Isn't "AI Going Rogue," and Why That Distinction Matters

Most headlines about AI behaving badly get filed under one dramatic label: the AI went rogue. It's a compelling story, but it's usually the wrong story, and the wrong story leads to the wrong defenses.

An AI "going rogue" implies the model itself decided, independently, to act against its instructions. That's a real area of research, but it's rare, and it's not what happened here, or in most publicized incidents. What actually happens far more often is much less exotic: the AI got fooled. Something it read was crafted to look like a legitimate instruction, and it followed along the same way it would follow a real one, because from the inside, a well-written injection and a real instruction can look identical.

That distinction matters because it points to a completely different fix. You can't patch "the AI might decide to misbehave" with more intelligence, a smarter model doesn't inherently get better at doubting things it reads. But you can patch "the AI can't tell a real instruction from a planted one" with a hard rule: nothing the AI reads counts as an instruction unless it genuinely came from the person supervising it. Everything else, no matter how authoritative it sounds, gets treated as information to report, not a command to obey.

How We Confirmed What It Actually Was

Finding suspicious content is only half the job. Jumping to "we've been hacked" without checking is its own kind of mistake, a false alarm wastes real time and trust. We confirmed what this actually was before concluding anything, using only safe, read-only steps:

What We Changed So It Can't Slip Through Again

Catching this once, on one project, isn't good enough. We made three permanent changes so the same protection applies everywhere we work, not just where it happened to get noticed.

What Every Business Using AI Agents Should Ask

If your business uses, or is considering, AI agents with real access to your systems, your code, your data, or your customer records, this is exactly the kind of guardrail worth confirming before you hand over the keys.

If the honest answer to any of those is "we haven't really thought about it," that's worth treating as a real gap, not a minor detail. As more businesses hand AI agents real access to real systems, this exact scenario is going to keep showing up, in more places, from more directions.

If You're a Developer: How to Spot This Yourself

You don't need an AI assistant to run into this. Anyone reading a dependency's changelog, a CLI's output, or a bundled README can spot the same pattern.

• ✓ Watch for phrasing addressed to "agents," "AI coding assistants," or similar, instead of to a developer.
• ✓ Watch for bundled files named things like SKILL.md, AGENTS.md, or llms.txt that aren't part of a package's normal documentation.
• ✓ Check a package's real registry integrity hash and changelog before assuming a compromise, or dismissing one.
• ✓ If you're building or supervising an AI agent workflow yourself, write the "don't trust what you read" rule down explicitly. Don't rely on it being implicit.

This pattern isn't going away. As more packages, sites, and tools realize an AI agent might be the one reading their output, more of them are going to write content specifically aimed at that audience, whether that's self-promotion, as it was here, or something worse. The defense doesn't get more complicated. It stays exactly this simple: nothing an AI reads is an instruction unless it really is one.