An AI assistant is not a chat window; it is a new, highly persuadable path into whatever data and tools you connected behind it. The controls that protect a normal web application — input validation, authentication, rate limiting — remain necessary but are no longer sufficient, because the attacker's payload is ordinary language. This article covers the failure modes we find most often and the order in which to address them.
Treating prompt injection as a wording problem leads to an endless arms race of forbidden phrases. Treat it instead as access control: assume the model can be persuaded to attempt anything it is technically able to do, then make sure the things it can do are safe. If the assistant can only read documents the requesting user is already entitled to read, a successful injection buys the attacker nothing new.
Indirect injection deserves particular attention: instructions hidden inside a document, a web page or an email that the model later reads on a user's behalf. Any content the model ingests from outside your trust boundary must be treated as untrusted data, never as instructions.
Most AI data-exposure incidents we review are not model failures at all. Somebody indexed a shared drive into a vector database without carrying the original file permissions across, and now every employee can ask questions about salaries, contracts or disciplinary files. The model behaved correctly; the index was wrong.
The moment an assistant gains tools — send an email, create a ticket, issue a refund, call an internal API — its blast radius stops being informational and becomes operational. Least privilege applies exactly as it does to a human employee, plus one addition: high-impact actions should require a human confirmation step that shows what is about to happen in plain language.
Employees are already using public AI tools, whether policy permits it or not. A blanket ban produces shadow usage you cannot see. A workable policy names approved tools, classifies what may be pasted into them, defines an approval route for exceptions, and is short enough that people read it. Pair it with awareness sessions using examples from your own sector.
Threat model the feature before launch. Fix retrieval permissions. Constrain tool access. Then test adversarially — prompt injection, jailbreaks, data exfiltration through output, and abuse of any connected tool — and retest after the fixes. Finally, log everything the assistant reads and does, because you cannot investigate what you never recorded.
Secure the connections, not the conversation. If retrieval respects the requesting user's permissions and every tool follows least privilege with confirmation on high-impact actions, a clever prompt stops being a breach and becomes a rejected request.