Prompt injection: read this before adding AI to your site

The question every owner asks before switching an assistant on is some version of: can it be talked into doing something stupid? It is the right question, and it has a real answer — one that has less to do with the model and more to do with what you plugged into it.

What prompt injection actually is

OWASP ranks it LLM01, first in its Top 10 for AI applications: a prompt injection vulnerability "occurs when user inputs alter an LLM's behavior or output unexpectedly" (OWASP). It comes in two shapes:

Indirect is the one owners underestimate. Anything your assistant reads is a place an instruction can hide — including files written for machines. Our own /llms.txt is a courtesy to agents, and it is also untrusted input to whoever reads it. That cuts both ways: publish nothing there you would not want repeated.

Why can it not simply be filtered out? Because a model reads instructions and information through the same eye. As Simon Willison puts it, LLMs "are unable to reliably distinguish the importance of instructions based on where they came from" (the lethal trifecta). Any vendor promising a filter that ends this is overselling.

What it can actually reach

Here is the part that should calm you down: an injection can only reach the tools you handed the assistant. Willison's "lethal trifecta" is the combination that turns a nuisance into an incident — private data, exposure to untrusted content, and a way to send data outward. Break any one leg and the attack has nowhere to land.

Only the last row is dangerous, and it is a configuration you choose, not a property of AI.

The five guardrails to insist on

OWASP's own mitigations name them: "enforce privilege control and least privilege access", "require human approval for high-risk actions", "segregate and identify external content".

1. A closed tool list. The assistant holds a named set of tools; anything not on the list is refused rather than improvised.
2. Confirmation on every change. Look-ups can run freely. Anything that writes shows its full payload and waits for a yes.
3. Identity from sign-in, not from chat. Who someone is comes from a verified session. An account or workspace id typed into a prompt must never grant anything.
4. Outside content is data, not orders. Page text, reviews and documents are quoted to the model as material to summarise, never as instructions to obey.
5. A person on call. When a conversation turns strange, it should reach a human in the same thread rather than the assistant improvising.

Copy this into your next vendor conversation:

Before we sign, please answer in writing:
1. List every tool the assistant can call for our account.        [CHECK]
2. Which of those change data, and which run without confirmation? [CHECK]
3. Where does customer identity come from on a tool call?          [CHECK]
4. What happens to instructions found inside page/PDF content?     [CHECK]
5. How does a conversation reach a human, and how fast?            [CHECK]

Ask your AI assistant to audit it

You do not need a security team to do a first pass. Paste this into any AI assistant that can see your setup:

Act as a security reviewer for our AI support assistant. List every tool it can
call. For each one say: does it read or write, who must be signed in, and does it
require a confirmation before it runs. Then flag any tool that (a) reads private
customer data, (b) can send data to an outside address, and (c) runs without a
confirmation — those three together are the risk. Return a table and mark
anything you cannot verify as [CHECK].

How Busymate AI is built against it

The tool surface is a closed allowlist per role: an unknown tool is denied rather than attempted, and raw database access exists for nobody. A workspace admin is held to their own workspace, and a workspace id put in a prompt cannot cross that line — membership is re-checked when the tool actually runs (managing from chat).

When you connect your own systems, every tool gets one of three access levels and every change can be marked as needing a confirmation card that shows the full action before it runs (connecting your systems). Your server learns who the customer is only from a short-lived signed token it verifies — never from an account id passed in a tool argument. Human handoff is off until you turn it on, and then a person can take the thread (human handoff). The posture in full is on our security page.

The same discipline applies on the page itself: WebMCP tools are declared by you and confirmed by the visitor, which is exactly the shape the page tools guide sets up. If you want to see it behave before you commit anything, build one from your URL — reading your own public pages is the lowest-risk way to start, and pricing begins there too.