OWASP LLM01 prompt injection: what should engineering leads do?

Prompt injection happens when inputs change an LLM's behavior in unintended ways, and OWASP says it is unclear whether fool-proof prevention exists. So engineering leads should design for limited impact: constrain the model, validate outputs, apply least privilege, require human approval for risky actions and test adversarially.

What is prompt injection?

OWASP defines it as user prompts altering an LLM's behavior or output in unintended ways, including inputs that humans cannot see as long as the model parses them. Jailbreaking is a form in which the attacker aims to make the model disregard its safety rules entirely.

There are two types. Direct injection is a user's own prompt changing behavior, deliberately or by accident. Indirect injection is external content, such as a website or file the model reads, carrying instructions that change behavior.

The indirect kind matters most for agents and assistants that browse, read mail or open documents, because the attacker never talks to your system directly.

What is the impact?

OWASP says severity depends on the business context and how much agency the model has. Potential impacts include disclosure of sensitive information, revealing system prompts or infrastructure details, biased or incorrect output, unauthorized access to functions the model can call, executing commands in connected systems, and manipulating important decisions.

The more tools a model can call, the larger the blast radius. A chat box with no tools can embarrass you. An agent with a shell and your credentials can do much worse.

What does OWASP recommend?

The page lists seven measures, and states plainly they reduce impact rather than guarantee safety.

1. Constrain model behavior.
2. Define and validate expected output formats.
3. Implement input and output filtering.
4. Enforce privilege control and least privilege access.
5. Require human approval for high risk actions.
6. Segregate and identify external content.
7. Conduct adversarial testing and attack simulations.

What does that mean for a team lead?

Treat model output as untrusted input. Whatever the model produces that flows into a database query, a shell, a browser or an API call needs the same validation as user input.

Give agents the smallest possible permissions. Scope tokens to one task. Prefer read only access by default.

Add a human step before irreversible actions. Sending money, deleting data, changing access and publishing all deserve a confirmation that shows the actual action, not the model's summary of it.

Mark outside content. Keep retrieved documents separate from instructions in your prompt structure, and label them as data.

Test on a schedule. Build a small suite of adversarial cases from your own domain and run it on every model, prompt or tool change. Keep the cases defensive: the goal is to see whether guardrails hold, not to publish recipes.

Where does tool access fit?

If your agents use tools through MCP, the permissions on each tool are your main control. Safeguard's MCP server at mcp.safeguard.sh gives unlimited tool calls on every plan, and tenant admins can switch off client types, which is a way to narrow what connects. Whatever tools you connect, decide per tool what the model may do without asking.

See the idea in the MCP guardrail demo.

What to do

1. List every tool and data source each LLM feature can reach.
2. Reduce permissions until each feature has only what it needs.
3. Validate model output before it reaches any interpreter or API.
4. Require explicit human approval for irreversible or high value actions.
5. Separate retrieved content from instructions and label it.
6. Build and run an adversarial test suite on every change.

Quick check

Sources

• OWASP GenAI, LLM01 Prompt Injection, fetched 18 October 2026.

Last reviewed: 18 October 2026.