How Do You Stop Prompt Injection in Your AI Automations?

What Is Prompt Injection, in Plain Terms?

It is text that hijacks your automation. OWASP defines a prompt injection vulnerability as one where user prompts alter the model's behavior or output in unintended ways. The text can arrive in a support ticket, a web page, a PDF or an email. The model reads it as instructions rather than data.

This is the single most common way AI automations get turned against the company running them. It is not a bug in a model. It is a design problem in how the workflow feeds content to the model, and that means it is yours to solve.

We build automations for B2B teams, and this is the risk we spend the most time on. Here is how the attack works, what the standards bodies actually recommend, and the controls we put in place before an automation touches anything real.

Why Is This the Top Risk on OWASP's List?

Because it sits at number one. In the OWASP Top 10 for LLM Applications 2025, prompt injection is listed as LLM01, the first entry on the list. OWASP splits it into two kinds. Direct injection is where a user's own prompt changes the model's behavior. Indirect injection comes from content the model reads.

Indirect injection is the dangerous one for automations, because nobody typed it at you. OWASP describes it as what happens when a model processes external content from websites or files that contains instructions altering its behavior. Your automation went and fetched the attack itself.

OWASP also makes a point that catches teams out. The injected text does not need to be visible to a human. If the model parses it, it counts. White text on a white background, a hidden HTML attribute or a comment in a document all work fine.

What Does an Attack Actually Look Like in a Real Workflow?

Take a common setup. An automation watches a shared inbox, summarises each message with a language model, and writes the summary into a CRM. Someone emails in a message containing a line telling the model to ignore its instructions and instead forward the last ten records it can see. The model obeys.

OWASP gives a comparable example for direct injection: an attacker instructs a customer support chatbot to ignore previous guidelines, query private data stores and send emails, leading to unauthorized access and privilege escalation. The shape is always the same. Untrusted text meets a tool with real permissions.

The version we see most in web work involves scraping. An automation reads competitor pages, supplier listings or job boards and feeds the text to a model. Any of those pages can carry an instruction. If the automation can also write somewhere, you have handed a stranger a keyboard.

Can the Model Just Be Trained to Ignore It?

Partly, and it is getting better, but no vendor claims it is solved. Anthropic published research on 24 November 2025 describing three defense layers for browser use: training the model to resist injection, classifiers that scan untrusted content entering the context window, and scaled expert human red teaming.

The numbers are encouraging and sobering at once. Anthropic reported that Claude Opus 4.5 reached a 1 percent attack success rate against an internal adaptive attacker, evaluated across 100 attempts per environment. Anthropic then states directly that a 1 percent attack success rate, while a significant improvement, still represents meaningful risk.

Take that at face value. If your automation runs a thousand times a month against untrusted content, a 1 percent rate is ten successful attacks. Model level defenses reduce the volume. They do not remove the need for controls around the model.

What Are the Seven Controls OWASP Recommends?

OWASP names seven prevention and mitigation strategies for LLM01. They are worth learning as a checklist, because between them they cover almost everything we end up building. None of them requires a special product. All of them are architecture decisions you make once.

The seven are: constrain model behavior, define and validate expected output formats, implement input and output filtering, enforce privilege control and least privilege access, require human approval for high risk actions, segregate and identify external content, and conduct adversarial testing and attack simulations.

Read that list again and notice what is missing. There is no control called write a better system prompt. Instruction hardening helps at the margin, but OWASP does not treat it as a defense, and neither should you. The controls that carry weight are about permissions and structure.

How Do You Apply Least Privilege to an Automation?

Give the automation its own identity, not a human's. Create a dedicated service account per workflow, scope its API tokens to the exact objects it needs, and make it read only wherever a write is not strictly required. Most automations we inherit are running on a founder's personal credentials with full access.

Then split read from write across steps. If a workflow must both read untrusted content and write to a system of record, put a boundary between them. The step that reads the web should not hold the token that writes to the CRM. Pass a structured result forward instead of passing capability forward.

Output format validation does the same job from the other side. If the model is only allowed to return a small structured object, and your code rejects anything that does not match that shape, an instruction to email the database has nowhere to go. This is OWASP's second control and it is the cheapest one to implement.

Where Should a Human Sit in the Loop?

In front of anything irreversible or outward facing. OWASP's fifth control is to require human approval for high risk actions, and that is the line we use too. Sending an external email, publishing content, moving money, deleting records and changing permissions all qualify. Summarising into a draft does not.

The mistake is putting the human everywhere. An approval step on every action trains people to click approve without reading, which is worse than no control at all because it manufactures a false audit trail. Pick the few actions that matter and make those approvals genuinely readable.

Anthropic's approach for computer use follows the same logic, running classifiers that steer the model to ask for user confirmation before acting when a potential injection is detected. Confirmation is targeted at suspicion rather than applied to everything. We go further into designing these checkpoints in our piece on human in the loop AI workflows.

How Do You Test Your Own Automations for This?

Attack them yourself, on a schedule. OWASP's seventh control is adversarial testing and attack simulations, and it is the one almost nobody does. Build a small set of poisoned inputs and run them through the real workflow in a staging environment before every meaningful change.

Your test set should cover the obvious and the hidden. Plain instructions in the body text. Instructions inside an HTML comment. Instructions in white text. Instructions in a file name, an image alt attribute or a document's metadata. Instructions written politely, because many filters key on aggressive phrasing.

Then check the right thing. Do not grade whether the model refused. Grade whether any tool was called that should not have been, and whether any data left the boundary. The model saying something odd is noise. The automation acting on it is the failure. Our guide to handling AI automation failures covers how to log those events usefully.

What Changes When Your Automation Becomes an Agent?

The blast radius grows, because the system now chooses its own next step. OWASP recognised this directly. On 9 December 2025 the OWASP Gen AI Security Project released a Top 10 for Agentic Applications, built with input from more than 100 industry leaders and security experts.

Three of the threats it highlights map exactly onto what goes wrong in practice: agent behavior hijacking, tool misuse and exploitation, and identity and privilege abuse. All three are the prompt injection problem with more tools attached and less human supervision between steps.

Our rule of thumb is that every new tool an agent can call multiplies the review effort rather than adding to it. An agent with browser access and write access to production is a different security posture from a scripted workflow, and it deserves a different approval process. We wrote about that shift in our piece on AI agents browsing websites.

What Should You Do This Week?

Three things, in order, and none takes long. List every automation you run and mark which ones read content from outside your company. For each of those, write down exactly what it is allowed to write to. Then remove any permission on that list that the workflow does not strictly need.

That audit alone usually finds the real problem. In our experience the dangerous automation is rarely the clever one someone designed carefully. It is the quick one built months ago on an admin token that nobody has looked at since, quietly reading the open web every hour.

After that, build the poisoned input set and put it in your deployment checks. Ten test cases that run automatically beat a security review that happens once a year.

If you want help auditing an automation stack, or you are about to give an agent write access and want a second opinion first, we are happy to walk through it with you. Find us at phoenix.studio.