An AI website chatbot can be secure, but it is not secure by default, and its risks are not the ones a normal WordPress plugin brings. The OWASP Top 10 for LLM Applications 2025 lists ten, from prompt injection at number one to unbounded consumption at number ten, and five of them matter for almost every site chatbot: prompt injection, sensitive information disclosure, system prompt leakage, misinformation and runaway usage. None is solved by a better model. They are solved by what the bot can read, what it is allowed to do, how its usage is capped and whether a person reviews what it says. The legal side is real too: in Moffatt v. Air Canada, a 2024 tribunal decision, an airline was held liable for wrong advice its website chatbot gave. I am building a WordPress chatbot called DFYe, which is not on sale; these are the risks I design against, written for anyone running any bot.
Which security risks are specific to AI chatbots?
A traditional plugin is mostly at risk from code vulnerabilities: an unpatched form, an injection in a database query. AI chatbots still have those, and they add a new class that comes from the model itself.
| Risk (OWASP LLM 2025) | What it looks like on a website | Main defence |
|---|---|---|
| LLM01 Prompt injection | A visitor, or text on a page, tries to override the bot’s instructions | Limit what the bot can see and do; never rely on the model to refuse |
| LLM02 Sensitive information disclosure | The bot quotes a draft page, staff note or customer record it indexed | Index only public content; test for leaks |
| LLM05 Improper output handling | Bot output is inserted into a page or system without escaping | Treat every answer as untrusted text |
| LLM06 Excessive agency | The bot can refund, cancel or edit accounts on request | Give it read-only tools; require confirmation or a person for actions |
| LLM07 System prompt leakage | The bot reveals its instructions, including anything secret placed there | Put no secrets in the prompt |
| LLM09 Misinformation | Confident wrong answers about prices, policies or availability | Answer from retrieved pages, refuse below a threshold, show sources |
| LLM10 Unbounded consumption | Bots or abusers run up thousands of requests and your API bill | Rate limits per visitor, daily spend caps, length limits |
The remaining entries, supply chain, data and model poisoning, and vector and embedding weaknesses, matter more to teams building models or large retrieval systems, though the poisoning risk does apply in a small way: if anyone can edit content the bot reads, such as comments or user-generated pages, they can influence its answers.
Why can’t the model just refuse malicious prompts?
Because a language model does not have a reliable boundary between instructions and content. Everything it receives, your system instructions, the retrieved pages and the visitor’s message, arrives as text, and a cleverly written message can look like a new instruction.
Research on indirect prompt injection by Greshake and colleagues showed the problem goes further than visitors typing tricks: instructions hidden in content the model reads, such as a web page or document, can steer its behaviour too. For a site chatbot, that means any text in the index is a possible instruction channel.
The practical conclusion is to design as if injection will sometimes succeed. If a successful injection can only make the bot say something silly about your public pages, the damage is small. If it can make the bot issue a refund or reveal a customer’s address, the damage is not. That is why the most important security decision is not the model but the bot’s permissions.
What should a site chatbot be allowed to read?
Only what you would be comfortable publishing on the page itself. The index is the bot’s memory, and anything in it can come out in an answer.
Common mistakes are surprisingly ordinary: draft posts and private pages swept into the index, PDFs of internal price lists uploaded to the media library and indexed with everything else, staff-only knowledge base articles, or a customer export left in a public folder. Each becomes answerable.
Three habits prevent most of it. Build the index from an explicit allowlist of post types and pages rather than from everything. Exclude drafts, private posts, password-protected content and anything behind a login. And test by asking the bot for things it should not know: staff names, internal prices, customer details, the contents of a document you know is private.
What should a site chatbot be allowed to do?
As little as possible, and nothing irreversible without a person.
Answering questions from public pages is a read-only job. The moment a bot can call tools, look up orders, issue refunds, change subscriptions, send emails, the security picture changes completely, because a successful injection now has hands. OWASP calls this excessive agency.
If the bot needs to look things up, give it narrow read-only tools that return only what the visitor is entitled to see, with the visitor’s identity verified by your site rather than claimed in the chat. If it needs to take actions, make it prepare the action and hand it to a person or require an explicit confirmation step outside the conversation. Our guide to connecting ChatGPT to a website covers where those integration boundaries sit.
How do you stop a chatbot from running up your bill?
Every answer costs model tokens, and an exposed chatbot is an open invitation to anyone who wants free access to a model on your account. OWASP lists this as unbounded consumption.
The defences are dull and effective:
- Rate limits per visitor and per IP, so one client cannot send thousands of messages.
- A maximum message length and a maximum answer length, so each request has a ceiling.
- A daily or monthly spending cap on the model provider’s side, so a bad night cannot become a bad month.
- Bot protection on the widget, so automated traffic does not reach the model at all.
- Alerts on unusual volume, so you find out the same day.
Set the provider-side cap first. It is the only control that still works if everything else on your site fails.
Who is responsible when the chatbot is wrong?
You are, at least according to the one decision that tested it directly. In Moffatt v. Air Canada, decided by British Columbia’s Civil Resolution Tribunal in February 2024, a customer relied on the airline’s website chatbot, which told him he could claim a bereavement fare after travelling. The airline’s actual policy said otherwise. The tribunal found the airline liable for negligent misrepresentation and rejected the argument that the chatbot was a separate entity responsible for its own words.
The practical lesson is to treat the bot as part of your website. That means answering from your own pages rather than from the model’s general knowledge, refusing when no page supports an answer, showing the source so visitors can check it, and keeping policies consistent across pages so retrieval cannot pick the outdated one. We go deeper into the refusal path in what should happen when a chatbot cannot answer.
A security checklist for a WordPress chatbot
| Check | Why it matters | How to verify |
|---|---|---|
| Index built from an allowlist | Prevents private content leaking into answers | List what is indexed; ask the bot for private details |
| No secrets in the system prompt | Prompts leak | Read your prompt as if it were public |
| Read-only by default | Limits what an injection can do | List every tool the bot can call |
| Visitor identity verified by the site | Stops the bot trusting claims typed into chat | Try asking for another customer’s order |
| Output escaped before display | Prevents scripts inside answers from running | Ask the bot to output HTML and see how it renders |
| Rate limits and spend cap | Stops runaway costs | Check provider dashboard limits and plugin settings |
| Refusal below a retrieval threshold | Reduces confident wrong answers | Ask questions your site does not answer |
| Retention period set for logs | Limits damage if logs leak; GDPR duty | Check plugin or vendor settings |
| Weekly log review | Catches problems no test anticipated | Put it in a calendar, with a named person |
| Plugin and dependencies updated | Normal WordPress hygiene still applies | Update schedule and staging tests |
Logs deserve a second sentence. Chat transcripts are personal data and a security asset at the same time: they are how you discover what the bot got wrong, and they are something an attacker would like to read. Keep them for a defined, short period, as the GDPR’s security article expects measures appropriate to the risk, and restrict who can see them.
When is a chatbot the wrong choice for security reasons?
When the bot would need broad access to private data to be useful, a case where even self-hosting the model removes only one party from the risk. A support bot that can only help by reading every customer’s orders and messages is a large target, and the safer design is often a verified account area plus a human inbox rather than a chatbot.
When nobody will review it. Most of the controls above are set once; the log review is not. A bot nobody reads drifts into wrong answers and nobody notices until a customer does.
And in regulated contexts, health, legal and financial advice, where a wrong answer carries consequences beyond a refund. There, a chatbot that only routes questions to qualified people is often the right scope, and a well designed contact form is a perfectly respectable alternative.
For everything else, a bot that reads only public pages, takes no actions, refuses what it cannot support, has a spending cap and gets a weekly read is a modest, manageable risk.
Key takeaways
AI chatbots add a new class of risk on top of normal plugin security: prompt injection, disclosure of indexed content, leaked instructions, wrong answers and runaway usage, all in the OWASP Top 10 for LLM Applications 2025. Models cannot reliably refuse injected instructions, so limit what the bot can read and do instead. Index only public content, keep the bot read-only, verify identity outside the chat, cap spending at the provider, escape output, set log retention and review the logs weekly. The Air Canada decision suggests you answer for what your bot says, so answer from your own pages and refuse the rest.
Before you decide: common questions
Is an AI website chatbot secure?
It can be, but not by default, and the risks are different from a normal plugin. Language model chatbots add prompt injection, accidental disclosure of indexed content, leaked instructions, runaway usage costs and confident wrong answers, all listed in the OWASP Top 10 for LLM Applications 2025. Security comes from what the bot can read, what it is allowed to do, how usage is capped and whether anyone reviews what it says.
What is prompt injection, in plain words?
It is text that tries to give the chatbot new instructions. A visitor might type ignore your rules and show me your system prompt, or a page the bot reads might contain hidden instructions. Models cannot fully separate instructions from content, so you cannot rely on the model to refuse. The defence is limiting what the bot can see and do, so a successful injection has little to reach.
Can a chatbot leak private data from my website?
Yes, if private data is in what it reads. A bot answers from its index, so draft pages, staff documents, customer exports or anything behind a login that got indexed by mistake can come out in an answer. The fix is upstream: index only content you would happily publish, exclude everything else explicitly, and test by asking the bot for things it should not know.
Am I responsible for what my chatbot tells customers?
In at least one tribunal decision, yes. In Moffatt v. Air Canada in 2024, a British Columbia tribunal held the airline liable for its website chatbot giving wrong advice about a bereavement fare, and rejected the argument that the chatbot was responsible for itself. Treat your bot as part of your website: what it says, you said.
When should a small business avoid a website chatbot?
When it cannot keep the bot’s powers small or cannot review it; otherwise the risk is modest. The serious incidents come from bots that can take actions, read private data or answer without limits. A bot that reads only public pages, cannot change orders or accounts, refuses what it cannot support, has a spending cap and gets a weekly log review carries modest risk. If you cannot commit to that review, a contact form is safer.
