The security review every AI integration needs before launch

A standard pre-launch security review checks the things it's always checked: access control, encrypted transport, secrets management, dependency vulnerabilities. Those still matter for an AI integration, but they don't cover the new ways data can leak once a model is in the loop. A system can pass every item on a conventional checklist and still send customer data somewhere it was never supposed to go, or let a crafted input make the system do something it shouldn't.

The AI-specific risks a normal checklist misses

• Data sent to a model provider: what's actually in the prompt, and does it include more customer data than the task requires.
• Prompt injection: content from an untrusted source, an email, a document, a webpage, containing instructions that manipulate the agent's behavior.
• Output handling: does anything downstream trust model output as safe to execute, display, or store without validation.
• Retention and training terms: does your provider agreement say your data isn't used to train models, in writing, not just assumed.

Prompt injection is the one most teams haven't thought about

If an agent reads content it didn't generate itself, an email, a support ticket, a scraped webpage, that content is untrusted input, the same way user input in a web form is untrusted. A malicious or just oddly-worded email can contain text aimed at the agent rather than the human reader, instructing it to ignore its original task, reveal information, or take an action it shouldn't. Any agent with access to tools, and access to content it didn't author, needs this treated as a real attack surface, not a hypothetical one. The mitigation is the same principle as anywhere else in security: least privilege on what the agent can actually do, and explicit confirmation before any action with real-world consequence.

The reason this catches experienced engineering teams off guard is that it doesn't look like a familiar vulnerability class. It's not SQL injection, there's no malformed syntax to sanitize against, because natural language doesn't have a clean boundary between data and instruction the way a query string does. That's what makes it hard to fully close and why the mitigation leans on limiting blast radius, tool access, action confirmation, rather than on trying to perfectly detect every injection attempt, which nobody can currently guarantee.

Output handling is the other half of the same problem

It's easy to focus entirely on what goes into a model and forget to scrutinize what comes out. If a downstream system trusts model output the way it would trust a value from a validated form field, code that gets executed, a query that gets run, a file path that gets written to, the model becomes a new path to inject something malicious into that system, whether from a compromised prompt or simply an unpredictable output the model produced on its own. Output from a model should go through the same validation any other untrusted input would, before it's allowed to do anything consequential downstream.

Every piece of content an agent reads that it didn't generate itself is untrusted input. Treat it that way.

Vendor terms deserve the same scrutiny as your own code

Teams that would never skip a code review will sign a model provider's terms of service without reading the data handling section closely, because it feels like paperwork rather than engineering. It isn't. Whether prompts are retained, for how long, whether they're used to improve the provider's models by default or only with explicit opt-in, and what happens to that data if you terminate the account are all terms that directly determine what you're allowed to send that system in the first place. For anything touching regulated or sensitive data, this isn't a nice-to-have to check later, it's a gating question that has to be answered in writing before the first real customer record ever reaches a prompt.

The minimum bar before launch

Map exactly what data leaves your systems and where it goes, including what's inside every prompt sent to a model provider, not just the obvious database fields. Confirm the provider's data retention and training terms in writing. Scope agent tool access to the minimum needed for the task, not the maximum available. And put a human confirmation step in front of any action that's irreversible or costly if it's wrong, a refund, a send, a delete. None of this is exotic security work. It's the same discipline applied to a new kind of input and a new kind of output, and skipping it is how a well-intentioned AI feature turns into the incident report nobody wanted to write.

None of these checks require exotic tooling or a specialist hire to implement. They require treating the model as what it actually is in the architecture: a component that reads untrusted input and produces output other systems will act on, which is a role security teams have decades of practice securing under different names. The mistake is forgetting to apply that practice just because the component in question happens to be a language model instead of a web form.