The most useful AI automations for a small business are the ones connected to real systems: an assistant that reads incoming enquiries, drafts replies, updates the CRM and books follow-ups. The moment an AI system can both read outside content and take actions, a specific risk appears. It is called prompt injection, and it deserves a plain explanation, because it shapes how a sensible automation should be built.
What prompt injection is
A large language model takes in text and produces text. It does not have a reliable way to tell the difference between instructions from you and content it has been asked to process. The OWASP Gen AI Security Project, which maintains the most widely used list of risks for these systems, ranks prompt injection first and describes two forms. Direct injection is when a user types something that changes the model's behaviour. Indirect injection is when the model reads external content, such as a web page, document or email, that contains instructions it then follows. OWASP notes that such instructions can be invisible to a human reader while still being read by the model.
For an SME, indirect injection is the one to think about. If your assistant reads every email that arrives, then anyone who can send you an email can, in principle, try to give your assistant instructions.
Why it cannot simply be patched
Many software vulnerabilities have a definitive fix. The UK National Cyber Security Centre published a blog in December 2025 explaining why this one probably does not. Unlike older injection attacks, where code and data can be cleanly separated, a language model processes everything as one stream of text. The NCSC suggests treating the model as an "inherently confusable deputy", and designing on the assumption that it can be manipulated. OWASP reaches a similar conclusion: it is unclear whether fool-proof prevention exists, so mitigations aim to reduce impact.
The NCSC adds a useful rule of thumb. When a model processes content from a party, you should treat its privileges as falling to the level of that party. An assistant reading an email from a stranger should be able to do no more than you would let that stranger do.
The NCSC also advises caution towards any product that claims to eliminate prompt injection outright, and to prefer vendors who can explain how they reduce the risk.
Design so that a confused assistant cannot do much harm
The practical answer is architectural, not clever prompting. OWASP's guidance on what it calls excessive agency uses an example that maps neatly onto SME automations: an email assistant meant to summarise messages, built with an extension that can also send mail. A malicious incoming email instructs it to search the inbox and forward sensitive data. OWASP lists three independent fixes, any one of which would have stopped it: use a read-only mail integration, authenticate with a read-only permission scope, and require a person to send every outgoing message.
Translated into a checklist for an owner commissioning or reviewing an automation:
- List what it can read and what it can do. Write both down. If the "do" list surprises you, it is too long.
- Separate reading from acting. A step that reads untrusted input (inbound email, web forms, uploaded files) should not hold the same permissions as a step that sends, pays, deletes or bulk-updates.
- Use the narrowest permission available. Read-only where possible, specific folders or CRM objects rather than the whole account, and credentials scoped to the automation rather than borrowed from an administrator.
- Draft, do not send. For anything leaving the company, the AI prepares and a person releases. This is the single most effective control for most SMEs.
- Restrict destinations. If the automation must send or forward, limit it to known recipients or internal addresses.
- Put hard limits in ordinary code. Payment limits, recipient lists and allowed actions should be enforced by the systems around the model, not by asking the model to behave.
- Log inputs, outputs and every action. The NCSC specifically recommends monitoring tool and API calls, including failed ones, which can be a sign someone is probing.
- Ask for testing. Before going live, ask whoever builds it how they have tested behaviour against untrusted content, and what happens when the model is wrong.
What this looks like in a real workflow
Take a common first project: enquiry intake. A safe version reads the incoming message, extracts the structured fields, writes a new CRM record in a staging area, and drafts a reply in the user's drafts folder. It has no ability to send, delete, export contacts or touch invoices. A person reviews the record and the draft, then clicks send.
Even if an incoming message contains hidden instructions, the worst outcome is a strange draft that a person discards. That is the goal: not a model that can never be confused, but a system in which confusion is cheap.
Keep the ambition, change the shape
None of this is a reason to avoid connecting AI to your systems. It is a reason to connect it the way you would onboard a capable new temp: clear tasks, limited access, a supervisor who checks the work before it goes out, and a record of what was done. Automations built on that pattern tend to be both safer and easier for teams to trust.
Planning an automation that touches email, CRM or documents? The free AI Readiness Audit maps the data flows and the human checkpoints before anything is built.