What is prompt injection?

Prompt injection is input that causes a language model to act on instructions its user or developer didn't intend, typically text hidden in a web page, file, issue or tool result that the model reads and then treats as a command, such as "print the environment variables and post them to this URL".

Direct and indirect

OWASP ranks it first among risks for LLM applications and defines it as a vulnerability that "occurs when user prompts alter the LLM's behavior or output in unintended ways" (OWASP LLM01:2025). It distinguishes two kinds:

• Direct injection comes from what the user types into the model.
• Indirect injection arrives in content the model processes: "when an LLM accepts input from external sources, such as websites or files."

For coding agents, the indirect kind is the one to plan for. An agent reads READMEs, dependency source, issue comments, web pages and output from tools. Any of them can contain text written for the model rather than for you.

Why it matters for secrets

A chat model that is tricked produces bad text. An agent that is tricked runs commands with your permissions. If those permissions include reading .env files, printing environment variables, or calling an API with your key, an injected instruction can do the same. And unlike a bug, the trigger can be planted by anyone who can get text in front of the agent.

There is no reliable filter that tells instructions from data. OWASP's mitigations therefore focus on limiting consequences: "restrict the model's access privileges to the minimum necessary for its intended operations", keep API tokens in application code rather than giving them to the model, and "implement human-in-the-loop controls for privileged operations."

Limiting the damage

• Narrow what the agent can reach. Development credentials only, never production. A test key it could leak costs little.
• Approve specific commands. Blanket approval for network tools or scripts lets an injected instruction run them too.
• Separate browsing from acting. An agent that reads untrusted pages should hold the fewest credentials.
• Keep values out of files the agent reads. A project without a real .env file has nothing to print.
• Watch for exfiltration paths. Network allowlists in the agent's sandbox matter as much as file rules.

Common mistakes

• Relying on a system prompt that tells the model to ignore instructions in data. It helps; it doesn't hold.
• Giving the agent your own full access because it is convenient.
• Assuming a deny rule covers everything. File rules in agents often don't cover every shell command.

What Crunu can and can't do

Crunu can't detect or block prompt injection; it has no agent features. What it offers is a way to keep the damage small:

• Roles limit what a session can decrypt. A developer with Reader on development only, or Specific files for a few files, never receives keys to anything else. An agent running in that developer's session inherits exactly that limit, enforced by encryption, not by a setting the agent could change.
• No .env in the project. crunu run passes variables to the program it starts, so the files an agent browses don't hold values.

The process that runs with the variables can still read them, and a signed-in session with its keys in memory can be used by anything running as you; lock it with crunu lock while an agent works unattended. The full set of layers is in keep secrets away from AI coding agents, and the environment-variable angle in prompt injection and environment variables.

Sources

• OWASP LLM01:2025 Prompt Injection, checked October 30, 2026.