Prompt injection explained for businesses using chatbots and agents

What is prompt injection?

Prompt injection is an attack where text given to an AI model changes the model’s behaviour in a way its owner did not intend. OWASP’s LLM01 entry defines it as input that alters a large language model’s behaviour or output, and notes the text does not need to be readable by a person, as long as the model parses it. Anthropic describes the same problem as adversarial instructions hidden inside content the model processes.

The root cause is simple. A language model receives your instructions and the outside text it is working on as one stream of words. It has no reliable way to tell which words are the boss and which are the material. A short glossary entry covers the term. This page explains how it plays out for a business.

What is the difference between direct and indirect prompt injection?

Direct prompt injection comes from the person typing to the AI. Indirect prompt injection comes from content the AI reads on someone else’s behalf. OWASP uses this same split, and NIST’s adversarial machine learning report gives each its own section, one for direct prompting attacks and one for indirect prompt injection.

	Direct	Indirect
Who writes the text	The user in the chat box	A third party who wrote a page, email, file or review
Who sees it happen	Often visible in the chat log	Often invisible to the user and the business
Harmless example	A visitor tells a shop chatbot to ignore its rules and speak like a pirate	A hidden line on a web page tells a summarising assistant to add an unrelated sales pitch to its summary
Main business risk	The bot says things that embarrass the brand or reveals its setup notes	An agent acts on a stranger’s text using your accounts and permissions

Indirect injection is the harder problem. The business never sees the attacker, and the attacker never has to log in. Google describes it as hidden malicious instructions placed in external data such as emails, documents or calendar invites, aimed at making the AI leak data or take actions the user did not ask for.

Why does it matter more once an AI has tools?

A chatbot that only produces text can embarrass you. An agent that can send email, edit records or call other systems can cause real loss. The same injected sentence that makes a plain chatbot say something silly can, in an agent, trigger an action.

NIST’s report also has a section on the security of agents, which reflects how much attention the field now gives to models connected to tools. Three things decide how bad a successful injection gets:

1. What the AI can read: customer records, internal documents, inboxes.
2. What the AI can do: send messages, change data, spend money, run code.
3. Whose credentials it uses: a narrow service account or a full administrator login.

A support chatbot with read-only access to public help pages has a small blast radius. A sales agent with write access to your CRM and the ability to email customers has a large one.

What are the main defences?

No single control stops prompt injection, so vendors and standards bodies recommend layers. OWASP’s mitigation list for LLM01 includes these steps:

• Limit what the model is told it may do, and say so in the system prompt.
• Define the expected output format and check it with ordinary code, not with another prompt.
• Filter inputs and outputs.
• Apply least privilege: keep sensitive functions in your application code, with the application’s own tokens, rather than handing them to the model.
• Require human approval for high-risk actions.
• Mark untrusted outside content clearly and keep it separate from instructions.
• Test regularly by treating the model as an untrusted user.

The vendors layer their own protections on top. Google lists model hardening, classifiers that screen content for injected instructions, reminders that keep the model on the user’s task, link and image sanitising, and confirmation prompts before risky actions. Anthropic describes training, classifiers that scan untrusted content, and red teaming for its browser agent.

Anthropic also publishes numbers. In its internal tests of a browser agent, the attack success rate for its newer models fell to between 1.4% and 2.4% with improved safeguards, and the company says even about 1% remains a meaningful risk. Treat that as a reason to build limits around the model, not a reason to trust the model.

What should a small business do first?

Start by deciding what the AI is allowed to touch, then work outward. This order gives the most protection for the least effort:

1. List every tool, file store and account your chatbot or agent can reach.
2. Remove anything it does not need for its job.
3. Give it its own credentials with narrow permissions, and keep those keys out of prompts and code. See how to store AI API credentials safely.
4. Require a person to approve anything that sends, deletes, pays or publishes.
5. Treat all web pages, emails, uploads and reviews the AI reads as untrusted.
6. Keep logs of what the agent read and did, so you can reconstruct an incident.

The AI agent security checklist turns these steps into a pre-launch review, including how to vet MCP servers and set credential scopes.

How can you tell if an injection attempt worked?

Look for actions or answers that nobody asked for. Signs include a chatbot suddenly quoting internal notes, an agent contacting addresses that are not in the task, summaries containing links or sales text from nowhere, and tool calls that do not match the request that started them. Logs of tool calls and a short review of unusual ones are the practical way to catch these. Without logs, an indirect injection can leave no trace beyond the damage.