AI SecurityMay 24, 2026 · 9 min read

AI security: how to secure LLM applications

LLM apps add an attack surface that does not behave like anything before it. Better prompts will not save you. The controls that work live in the architecture. Here is how to secure them.
Written by
R
Raptoric AI Security
Share
LinkedInX / TwitterCopy link

Shipping an LLM feature adds a new and strange attack surface to your application. The model reads untrusted text, calls tools, touches data, and produces output that other systems trust. Each of those is an opening. AI security is the work of finding and closing them, and almost none of it happens in the prompt.

The new attack surface

An LLM application is not just a model. It is a system: prompts, retrieved documents, tools the model can call, and outputs that flow into databases, shells, or other services. Attackers do not attack the model in isolation. They attack the seams between these parts, where trust is assumed and not enforced.

The main risks

  • Prompt injection. Untrusted text that the model treats as instructions, overriding your rules.
  • Sensitive data leakage. The model surfacing data it retrieved or was trained on to a user who should not see it.
  • Tool and agent abuse. An attacker steering the model into calling tools that move money, data, or state.
  • Excessive agency. Giving the model more power than the task needs, so a single manipulation has large consequences.
  • Insecure output handling. Trusting model output as safe input to another system, which turns the model into an injection vector.

Why a better prompt does not fix it

Teams respond to prompt injection by writing longer, sterner system prompts. It never works, because a language model reads every token as input and has no privileged channel for your instructions. An instruction buried in a retrieved document carries the same weight as your rules. We explain why in prompt injection is not a prompt problem.

The controls that work

  • Scope every tool. Give the model the minimum each tool needs, and require confirmation for anything that moves money, data, or state.
  • Put a hard boundary between retrieved content and instructions. Tag untrusted text and never let it expand the model's permissions.
  • Validate outputs. Treat model output as untrusted input before it reaches a database, a shell, or another service.
  • Apply least privilege everywhere. The model should not hold credentials or access it does not strictly need.
  • Log the full chain. What was retrieved, what the model decided, what it called. You cannot investigate what you did not record.

How to test an AI system

Red-teaming an AI system does not mean grading the prompt. It means mapping the trust boundaries and attacking across them: indirect injection through retrieved documents, tool-call hijacking, and data exfiltration through the model's own outputs. The findings are architectural, because that is where the fixes live.

AI security and the EU AI Act

If you build or deploy AI in the EU, the EU AI Act brings obligations that scale with risk: risk management, logging, robustness, and security appropriate to the system. The good news is that the security testing and the regulatory evidence are the same work. Do the testing properly and the compliance follows.

Better wording buys you a day. Better structure buys you the year.

See AI security for how we red-team AI systems, or book a scoping call.

Want this tested on your own systems?
A senior engineer will scope it with you on a 30-minute call.
Book a scoping call