Real threats.
Plain-language fixes.

What it is

Prompt injection is when crafted input gets your AI system to ignore its original instructions and follow new ones instead — hidden inside a support ticket, a web page your agent reads, an email it processes, or a file a user uploads. A model can't reliably tell "legitimate instructions from the people who built me" apart from "text that showed up in the data I'm processing." If that second kind of text contains something that reads like an instruction, many models will follow it.

Why AI agents make it worse

A chatbot that only answers questions is a limited target — at worst, it says something wrong. An agent that can browse the web, read email, call APIs, or take actions on a user's behalf is a much bigger target, because a successful injection doesn't just produce a bad answer. It can make the agent do something: send data somewhere it shouldn't, trigger a transaction, or hand over information it had access to. The more tools and data an agent can touch, the more valuable a single successful injection becomes to an attacker.

What enterprise buyers will ask

Expect questions like: what can your AI agent actually do on a user's behalf, and what's the blast radius if it's tricked into doing something malicious? Is there a human in the loop before anything consequential happens? What data can the model see, and is that scoped per user or global? Buyers want to know you've already thought about this — not that you're hearing the term for the first time on the call.

Three controls to start with

1. Least privilege for agents. Give the agent only the permissions and data access it needs for its specific task — not a standing credential that can touch everything.
2. Human approval for anything irreversible. Sending money, deleting data, or messaging a customer should go through a confirmation step, not run automatically on model output.
3. Treat all ingested content as untrusted input. Content from emails, web pages, tickets, and file uploads should be handled the way you'd handle unsanitized user input anywhere else in your stack — because, functionally, it is.

If your product sends customer data to an LLM provider, that provider is a subprocessor — the same way a cloud host or an email tool is. SOC 2 auditors expect you to treat it that way.

Why it counts as a subprocessor

Any third party that processes customer data on your behalf is a subprocessor, regardless of whether the processing is a database write or a model inference call.

What auditors expect to see

A subprocessor list that includes the model provider, a vendor review on file, and a data processing agreement where one is available.

What to check with your model provider

Data retention defaults, whether your data is used for training, and where the data is processed.

Where this fits in your policies

Model Vendor Management and AI Acceptable Use policies should name the provider explicitly, not just "third-party services" in general.