Is Your AI Integration Actually Safe?

You added an AI feature. Maybe it's a support chat, a "summarize this document" button, or an agent that drafts replies from your inbox. It works in the demo, and that's the catch: demos only show what happens when everyone plays nice.

The real question is what happens when someone, or something the model reads, tells it to do a thing you never planned for. The OWASP Top 10 for LLM Applications 2025 maps those risks. Here are six checks we run on AI features before launch, plus one thing to tell your users.

Prompt injection: assume the model will be fooled

OWASP ranks prompt injection first, as LLM01:2025. Direct injection is a user typing instructions into your chat box to change how the model behaves. Indirect injection is sneakier: the instructions hide in something the model reads for you, like a web page, an uploaded PDF, an email or a search result. OWASP notes the text needn't be visible to humans at all.

Picture a "summarize this contract" button. The contract contains a line of white-on-white text addressed to the AI. Your user never sees it. Your model does, and it can't reliably tell your instructions from the document's, because it reads both as one stream of text.

That isn't a bug you patch once. The UK's National Cyber Security Centre wrote in December 2025 that current models don't enforce a security boundary between instructions and data. Unlike SQL injection, it said, "there's a good chance prompt injection will never be properly mitigated in the same way." OWASP itself says it's unclear whether fool-proof prevention exists.

So keep your input defences: OWASP suggests clearly marking untrusted content, and OpenAI's safety best practices suggest limiting how much text users can send. But design so a fooled model can't do much damage. The next three sections show how.

Excessive agency: give the AI the fewest, smallest tools

An AI that can only write text can embarrass you. An AI that can call tools can act for you. OWASP calls this Excessive Agency (LLM06:2025) and traces it to three causes: too many functions, too many permissions and too much autonomy.

OWASP's own example is a classic founder trap: an assistant gets mailbox access to summarize email, and the plugin can also send. An attacker sends your user a crafted email, and the assistant is tricked into forwarding sensitive mail to them. The fixes OWASP lists are boring and effective: a read-only tool, a read-only OAuth scope, and a person who reviews every email before it goes out.

Apply the same thinking to every tool:

• Remove tools the feature doesn't need, and avoid open-ended ones like "run any shell command" or "fetch any URL".
• Run tool calls with the signed-in user's own access, not a service key that can see every customer.
• Use read-only database roles wherever reading is enough.
• Enforce permissions in your server code. OWASP's System Prompt Leakage (LLM07:2025) entry says authorization must not be handed to the model, and credentials don't belong in the system prompt.

Human approval: a click between the model and anything you can't undo

The prompt injection and excessive agency entries both recommend human approval for high-risk actions. OWASP's prompt injection cheat sheet adds a detail worth copying: decide when to ask based on the action, its target and its arguments, not on keywords in the user's prompt.

Sending email, issuing refunds, deleting records, changing roles and posting anything public should all pause for a person. The approval screen should show the real action, such as the exact recipient, amount or record, rather than the model's friendly summary of it. A fooled model writes convincing summaries.

Output handling: treat model output like user input

Easy to miss: the model's reply is untrusted input to the rest of your app. OWASP's Improper Output Handling (LLM05:2025) entry lists what goes wrong when output flows straight into other systems: cross-site scripting (XSS) when a browser renders generated HTML or Markdown, SQL injection from unparameterized queries, and remote code execution when output reaches eval or a shell. OWASP's advice is to treat the model like any other user.

If your chat renders replies as raw HTML, an injected instruction can make the model emit markup that runs in your user's browser. Even an image can leak data: the OWASP cheat sheet warns about hidden image tags whose web address sends data to an outside server, and recommends sanitizing HTML and Markdown before rendering.

• Render replies as plain text, or sanitize them against a strict allowlist.
• Don't load remote images or links from model output without checking where they point.
• Add a strict Content Security Policy, which OWASP lists as a defence against XSS from generated content.
• Never pass output to eval, a shell or a raw SQL string.

Sensitive data: watch what goes into prompts and logs

Sensitive Information Disclosure (LLM02:2025) covers personal data, financial and health records, credentials and confidential business information leaking through a model. Two habits make it likelier in apps built fast.

The first is stuffing prompts. It's tempting to send the model the whole customer record "for context". Send only the fields the task needs, and only the signed-in user's own data.

The second is logging everything. Debug logs of full prompts and replies also store whatever people typed: addresses, health details, the password someone pasted by mistake. OWASP's Logging Cheat Sheet says passwords, access tokens, session IDs and sensitive personal data usually shouldn't be logged directly. Redact before you write, and set a retention period.

Your AI provider keeps data too. OpenAI, for example, says API data isn't used to train its models by default, but abuse-monitoring logs are generally kept for up to 30 days. Read your own provider's terms, and make sure your privacy policy covers what you share with the provider and matches what your code actually sends.

Spend and rate limits: cap the bill before someone else runs it up

OWASP's Unbounded Consumption (LLM10:2025) entry describes denial of wallet: an attacker sends a high volume of requests to exploit pay-per-use pricing and run up your bill. A free tier with no limits is an open tab.

Layer your limits:

• Per user: rate limits and daily quotas, so one account or script can't eat everyone's budget.
• Per request: an input size limit, a maximum output token setting and a timeout.
• Per account: a hard cap at the provider. Anthropic's Claude Console, for example, lets you set your own spend limit below your tier's monthly cap, and requests stop when you reach it.
• Alerts: watch usage so a spike reaches you before the invoice does.

AI disclosure: tell people they're talking to a machine

It's good manners, and in some places it's the law.

In the EU, Article 50(1) of the AI Act requires providers to design AI systems that interact directly with people so those people are told they're dealing with AI, unless that's obvious. Under Article 113, that has applied since 2 August 2026.

In California, SB 243 covers companion chatbots: bots built to meet social needs and sustain a relationship across conversations. Customer service and productivity bots are among the exclusions. If a reasonable person could be misled into thinking they're talking to a human, the operator must show a clear and conspicuous notice that the bot is AI. For users it knows are minors, it must disclose that they're talking to AI and remind them at least every three hours to take a break. It also requires a self-harm response protocol. The law took effect on January 1, 2026.

Whether a specific law applies to your product is a question for an attorney. A plain "You're chatting with an AI assistant" label costs you nothing either way.

Where a pre-launch audit helps

None of this shows up in a demo; it shows up when someone tries to make your AI misbehave. With your written permission first, that's our job. When AI features are in scope, a LaunchGate audit plants harmless test instructions in the documents and pages your AI reads, lists every tool it can call and the access behind each one, checks whether its replies render as HTML, reviews what lands in your logs, and tests your rate and spend limits. You get a report of what we found, with evidence and a recommended fix for each. We report on what we tested; no test can prove prompt injection is impossible. Disclosure and privacy questions are flagged for attorney review, because LaunchGate is not a law firm and does not provide legal advice.

Want a first look? The Free Launch Check is a preliminary public-surface review — not a full audit. It only sees what's public, so it can't test your tools or logs from the inside. For that, compare the audit packages, or read our methodology. Also building with AI coding tools? See the vibe-coding security checklist.