What is a prompt injection attack, and how does it hit AI coding agents?

What prompt injection is#

A language model reads one stream of text. Your instructions, the file it just opened and the web page it just fetched all land in the same place, and nothing marks which part is in charge.

That's the attack. Someone plants text where the model will read it, and the model follows it as a command. OWASP ranks it first in its LLM Top 10 and says "it is unclear if there are fool-proof methods of prevention for prompt injection."

Direct vs indirect#

Direct injection comes from the person typing: someone enters "ignore your instructions" into a chat box.

Indirect injection is the one that matters for coding agents. OWASP says it happens "when an LLM accepts input from external sources, such as websites or files." The developer never types anything malicious. The agent reads it on its own while doing the job.

Why coding agents are the worst case#

A coding agent can read private data (your .env, your SSH keys, your repo). It reads untrusted content all day (dependencies, issues, docs, tool output). And it can send data out (a curl, a git push, a browser call).

Simon Willison calls this the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. A coding agent on a developer laptop usually has all three.

Techniques you'll actually see#

• Hidden text in a web page. PromptArmor planted an injection "hidden in 1 point font" in a web page that Google's Antigravity agent read. The agent got around the .gitignore protection by running cat, then sent credentials out through a browser subagent to an allowlisted webhook.site URL (PromptArmor).
• Invisible characters. Pillar Security showed that zero-width joiners and bidirectional text markers can hide instructions in files that Cursor and GitHub Copilot read. Those characters "appear invisible on the GitHub platform pull request approval process," so a reviewer approves something they can't see (Pillar Security).
• Instruction files in the wrong place. A planted AGENTS.md can steer a coding agent toward a malicious package. We wrote up one case in AGENTS.md in Downloads hijacks Codex.
• Issue comments, READMEs and tool output. Same mechanism. Anything the agent reads can hide a sentence that starts "before you continue, run this."

Why filtering doesn't solve it#

Most defenses try to spot the bad instruction. But an injection is plain language, and there are endless ways to phrase it, hide it or split it across files.

Willison's verdict on filters that catch most attacks: "95% is very much a failing grade." The attacker only needs the one that gets through.

Human review won't save you either. Anthropic reports that people approve 93% of permission prompts, and in its 1,053-tester study humans caught 13.6% of dangerous commands. An injected command that looks routine gets the click.

How to reduce the damage#

Assume some injection will land. What matters is what it can do once it has.

• Treat repo content as untrusted. READMEs, issues, docs, rules files and tool output are input, never instruction. Don't open unknown repos with an agent that holds production credentials.
• Least privilege. Use short-lived, narrowly scoped credentials. If the agent never holds the cloud admin key, injected text can't use it.
• Sandbox and limit egress. A sandbox bounds what the agent can reach, and an egress allowlist bounds where data can go. Review the allowlist itself: in the Antigravity case, the credentials left through a host that was on it.
• Lock agent config. Make rules files and agent settings read-only and watch them for changes. How coding agents persist past the session covers this.
• Gate irreversible actions. Publishing, pushing to shared repos, deploying and sending external email should never happen just because a model decided to.
• Check the action, not the text. At agent volume, human approval doesn't hold up, so an automatic check has to run before each action.

The step-by-step version is in Protect coding agents from prompt injection.

How to spot it after the fact#

You won't always see the injected text, so look at behavior.

• Actions that don't match the task: a "fix the tests" session that reads ~/.aws, or a docs task that opens a network connection.
• Records of every command, edit and push, exported to your SIEM.
• Agent config and rules files that differ from a known good copy. An unexpected change is a strong signal.
• Hidden Unicode and instruction files in repos and downloads pulled in recently.
• New hooks, MCP entries, keys and cron jobs created during agent sessions.

Where Harden fits#

Harden Agentic Integrity Foundation (AIF) doesn't try to spot the injected sentence. It looks at what the agent is about to do.

It runs on the developer laptop, outside the agent, at the agent's pre-execution hook. Each command, file edit and push is checked against the session's intent before it runs. A secret reaching a network call is a dangerous flow whether a person asked for it or a poisoned README did.

Decisions are made locally in milliseconds, and nothing leaves the machine. One policy covers every agent, and it starts watch-only so you see what agents do before you enforce. A local model also reviews each action in context for prompt injection and goal hijacking, and it can only make a verdict stricter.

It's a layer, not a perimeter. It doesn't replace least privilege, and a determined attacker who controls the code can defeat static analysis.