Your Chatbot Has an Attack Surface Too: Securing AI-Powered Applications
Somewhere in the last year or two, a lot of small businesses quietly became AI companies without really deciding to. A support chatbot got bolted onto the website. A "smart search" feature got added to the app. Someone wired an AI assistant into the internal helpdesk over a weekend because it was surprisingly easy to do.
None of that gets treated as a security decision. It usually gets treated as a product decision, made by whoever was closest to the code, and security only enters the conversation after something's already live. Which is a shame, because these things have a real attack surface — one that doesn't look like the attack surface anyone on a small team has necessarily dealt with before.
This isn't the same threat model as a normal web app
If you've thought about application security at all, you've thought about it in terms of inputs and outputs you can validate — a form field, an API parameter, a file upload. You check the shape of the data, you reject what doesn't fit, and mostly that works.
An LLM breaks that model, because instructions and data travel through the exact same channel: whatever text goes into the context window. There's no equivalent of a parameterized query that cleanly separates "here's an instruction" from "here's some content to process." The model reads both the same way. Which means anyone who can get text in front of the model — a user typing into your chatbot, or a webpage your AI assistant summarizes, or a document someone uploads — has a shot at getting the model to do something you didn't intend.
That's what prompt injection actually is. Not a bug you patch. A structural property of how these systems work.
What this looks like in practice
Direct injection is the obvious version — someone typing "ignore your previous instructions" straight into your chatbot, trying to get it to reveal its system prompt, act outside its intended role, or say something you'd rather it didn't say on your company's behalf.
Indirect injection is the one that catches people off guard. If your AI assistant reads a webpage, processes an uploaded document, or pulls in a customer's message and does something with it, the attacker doesn't need to talk to your chatbot at all. They just need to get malicious instructions into whatever content the model is going to read later — an email, a PDF, a support ticket, a product review. The model can't reliably tell the difference between "content to summarize" and "instructions to follow", so it sometimes just follows them.
Newer variants hide instructions inside images or audio, which is a genuine problem if your application processes anything beyond plain text — and increasingly, most do.
None of this requires the attacker to breach your network. They just need your model to read something they wrote.
Why this matters more once the chatbot can actually do things
A chatbot that only talks is a limited risk — worst case, it says something embarrassing. The risk changes shape entirely the moment it's connected to tools: booking a refund, updating a customer record, querying a database, sending an email, calling an internal API.
This is the part of the current guidance that's shifted the most recently — giving AI agents real permissions and letting them take real actions has become the fastest-growing risk category in this space, precisely because so many teams are wiring AI into actual workflows now, not just chat windows. The moment a model can act, a successful injection doesn't just produce bad text — it produces a bad action, taken with whatever permissions you gave the assistant.
Which is really a question about scope. What can this thing actually reach? If the honest answer is "the full customer database" or "our billing system, unrestricted," that's the exposure — not the chatbot's conversational ability, but the blast radius behind it.
The other risk nobody thinks about: the model just... tells people things
Sensitive information disclosure sits right alongside injection as one of the two most consistent risks across every version of the industry's guidance on this. It's a quieter failure mode. Nobody has to break in. The model is simply asked the right sequence of questions, and it answers helpfully — surfacing a customer's personal details, an internal document it was fed during setup, or a piece of proprietary content it happened to memorize.
If your chatbot has access to a knowledge base, a CRM export, or internal documentation to make it "smarter," that access is now part of what a clever prompt can potentially extract. The convenience that makes the assistant useful is the same thing that makes this risk real.
What an SME can actually do about this
You're not going to eliminate prompt injection. Nobody has, including companies with far larger security teams than yours — it's a structural issue, not a bug waiting for a patch. The realistic goal is containment: assume the model will occasionally be fooled, and make sure that when it is, the damage stays small.
A few things actually move the needle at SME scale. Give the AI assistant the minimum access it needs to do its job, not broad standing access "in case it's useful later" — a support bot that can look up an order status doesn't need write access to your customer database. Put a human in the loop for anything consequential — refunds, account changes, anything involving money or data leaving the building shouldn't happen on the model's say-so alone. Know what the assistant can actually read and touch, written down somewhere, not just living in one engineer's head. And test it occasionally the way an attacker would — a few deliberately adversarial prompts will tell you more about your actual exposure than any policy document.
None of this requires a dedicated AI security team. It requires treating the chatbot's permissions with the same seriousness you'd treat a new employee's system access — because functionally, that's closer to what it is than most people initially assume.
Where to start
The same starting point that works for most governance gaps works here: an honest inventory. What AI-powered features actually exist in your product or your internal tools right now? What can each of them read, and what can each of them do? For most SMEs, nobody's ever written that down in one place — and until it is, you don't actually know what your exposure is, you're just hoping it's fine.
Belian Advisory reviews AI-powered applications for exactly this kind of exposure — what the assistant can reach, what it can do, and where an injected prompt could actually cause harm. If you want a straight read on where your chatbot's real boundaries are, get in touch.