Prompt Injection: The Security Gap Hardly Anyone Mentions with AI Agents

AI agents read emails, search documents, answer customer enquiries and trigger actions in connected systems. For that to work, they have to process content from many sources — and this is exactly where a weakness lies that does not appear in most product demos. It is called prompt injection. This article puts the topic into perspective for decision-makers: without alarmism, but also without playing it down.

What is prompt injection?

AI language models process everything they receive as text in a single stream. Technically, they do not reliably distinguish between an instruction the user gives them and data they are really only supposed to read. To a model, both ultimately look like language.

This missing separation can be exploited. An attacker can hide a command in data the agent processes — worded like a normal instruction. If the agent encounters this text, there is a risk that it interprets it as an order and carries it out instead of just treating it as content. That is the core of prompt injection: a hidden instruction in the data hijacks the model’s behaviour.

Direct vs. indirect — the real danger

There are two variants, and the difference is decisive for risk assessment.

With direct prompt injection, the user types a trick themselves to talk the model into bypassing its rules (“Ignore your previous instructions and ...”). That is usually harmless: whoever does this only manipulates their own session — they have only the rights they are entitled to anyway.

The real risk is indirect prompt injection. Here the hidden instruction does not come from the user but from content the agent processes on the user’s behalf — and which a third party has prepared beforehand:

• a document in the knowledge base that the agent searches;
• an email the agent is to summarise or answer;
• a web page the agent calls up and reads;
• the output of a connected tool that the agent trusts.

The user has no idea about the hidden instruction. The agent processes the content in good faith — and in the worst case carries out the attacker’s instruction instead of doing the actual task. Because the content comes from outside and is processed automatically, this variant is considerably harder to control than a direct typed attempt.

RAG poisoning: when the knowledge base becomes a weapon

A particularly relevant form of indirect injection affects agents that access your own documents. This principle — the agent draws suitable content from a knowledge base to answer — is called retrieval-augmented generation, RAG for short. We explain what RAG is in detail here.

With RAG poisoning, an attacker deliberately smuggles poisoned content into this document collection. When the agent accesses it, the prepared content can hijack its behaviour. Security researchers have shown — and such figures are to be read as an order of magnitude, not a fixed constant — that as few as around five prepared documents can be enough to manipulate answers in the order of around 90 percent of cases. In demonstrations, even a single PDF with invisible text (such as white text on a white background or the smallest font size) was enough for the agent to carry out the hidden attacker instruction instead of the actual task.

For companies this is particularly delicate, because the knowledge base is often fed from sources that are not fully controlled: uploaded customer documents, incoming emails, imported web content, shared drives. Any of these sources can theoretically become an entry point.

Why AI agents and MCP enlarge the attack surface

A simple chatbot without system access can do little harm. As soon as an agent uses tools and accesses several data sources, however, the attack surface grows with every connection. More connected tools and data sources simply mean more entry points. Instructions can hide in:

• Tool descriptions — the text that explains to the agent what a tool can do;
• Tool outputs — the data a tool returns;
• Memory — stored content from earlier sessions;
• Retrieval hits — the documents the agent pulls from the knowledge base.

The Model Context Protocol (MCP) is not a special case here but makes the pattern visible: it is the standard through which agentic AI systems are connected to business systems in a structured way. Every additional connection is benefit and potential entry point at the same time. The right reading matters: MCP does not make AI less secure per se — what is decisive is how the connection is secured. How this is achieved cleanly on the technical side, we cover in detail in the article on MCP server security and GDPR.

The uncomfortable truth

As things stand today, there is no complete, guaranteed protection against prompt injection. Even leading AI models remain fundamentally vulnerable — the weakness lies in how today’s language models work, not in an individual product flaw.

Security reports from 2025/2026 describe — again to be understood as an order of magnitude — attack success rates that, depending on the setup and test scenario, range from around 50 to 84 percent. Large, established providers were also affected by such tests. These figures are not a doomsday forecast but a sober assessment: anyone looking for a single “miracle solution” is looking for something that does not exist.

Defence in depth — how companies protect themselves

These layers of protection interlock. No single one is sufficient on its own — in combination, however, they considerably reduce the likelihood and the possible damage.

1. Least privilege — minimal rights The agent gets exactly the rights it needs for its task — no more. An agent that creates reports does not need write access to customer data or delete rights. The less a hijacked agent is allowed to do, the smaller the maximum possible damage.
2. Human confirmation for consequential actions Actions with real consequences — sending an email, triggering a posting, deleting or overwriting data — are not executed automatically but only after explicit human approval. That way a manipulated agent causes no direct external damage.
3. Separating instruction and data / input filtering Incoming content is clearly marked as data and pre-filtered before the agent processes it. Suspicious patterns (hidden text, embedded instructions, unusual formatting) can be detected and neutralised instead of being passed unchecked to the model.
4. Output checking before further processing Before the agent’s output is processed further or triggers an action, it is checked for plausibility and unexpected instructions. A result that suddenly calls for an unplanned action is intercepted.
5. Tenant and role separation Data from different customers, departments or roles stays cleanly separated. Even if an agent is compromised in one area, it cannot spill over into other data sets.
6. Audit-ready logs Every action of the agent is logged traceably. That way, in an emergency, it is possible to reconstruct what happened, contain the damage — and close the gap in a targeted way.
7. EU hosting & GDPR Data processing in the EU and a sound data protection basis are not an end in themselves: they limit which data is in play at all and are a prerequisite for responsible operation in German mid-sized companies.

The technical implementation of these layers — in particular minimising rights, tenant separation and audit logs — belongs in the architecture of the system connection. We show this in detail in the article on MCP server security and GDPR.

If you want to understand the attack side in more depth, you will find well-founded, vendor-independent analyses in the security research by CyberSec42 on the OWASP MCP Top 10 and on prompt injection in MCP servers.

Checklist for your AI project

These points should be settled before an AI agent goes into production:

• check_circle
  Data flows mapped: Which external content does the agent process (emails, documents, web pages, tool outputs)? Every source is a potential entry point and should be assessed deliberately.
• check_circle
  Rights minimised: Does the agent have only the rights it really needs? Write and delete rights are reduced to the necessary minimum.
• check_circle
  Approvals defined: For which consequential actions is human confirmation mandatory — and who gives it?
• check_circle
  Inputs filtered: Is incoming content marked as data and pre-checked for hidden instructions before the agent processes it?
• check_circle
  Separation ensured: Are clients, roles and data sets cleanly isolated from one another?
• check_circle
  Logging active: Are all agent actions logged in an audit-ready way, so that an incident can be reconstructed?
• check_circle
  Data protection settled: Are EU hosting, a legal basis and a DPA with the AI provider in place? More in the article on GDPR-compliant AI.

Perspective for decision-makers

Prompt injection is no reason to do without AI agents — the benefit for structured, repeatable processes remains considerable. But it is a clear reason to put governance before production use rather than after. Anyone who thinks about minimal rights, human approvals, clean separation and logging from the start operates AI agents responsibly.

On top of that comes the regulatory framework: the EU AI Act becomes largely fully effective from August 2026, and the GDPR applies anyway. Both require traceable, controlled data processing — exactly what a clean defence-in-depth architecture delivers anyway. Security and compliance pull in the same direction here. We cover how to set up AI use in a data-protection-compliant way in the article on GDPR-compliant AI; the fundamentals of productive agents are explained in the article on AI agents for companies.

Frequently asked questions about prompt injection

What is prompt injection, simply explained?

Prompt injection is an attack in which hidden instructions are smuggled into data that an AI model is meant to process. Because AI models cannot technically distinguish reliably between a genuine instruction and content they are only supposed to read, an attacker can hide a command in a document, an email or a web page — and in the worst case the AI agent executes this command instead of doing its actual task.

Can you protect yourself completely against prompt injection?

No, as things stand today there is no complete, guaranteed protection — even leading AI models remain fundamentally vulnerable. Security reports from 2025/2026 describe, depending on the setup, attack success rates in the order of around 50 to 84 percent. The practical route is therefore not a single miracle solution but defence in depth: several interlocking layers of protection that significantly reduce risk and possible damage.

Is my company at risk with AI agents?

A certain risk exists wherever an AI agent processes external content — that is, documents, emails, web pages or tool outputs — and is at the same time allowed to carry out consequential actions, such as sending emails or changing or deleting data. No reason to panic, but a clear reason to define governance, minimal rights and human confirmation for critical steps before production use.

What is RAG poisoning?

RAG poisoning is a form of indirect prompt injection. When an AI agent accesses a knowledge base or document collection (retrieval-augmented generation, RAG for short), poisoned content can be deliberately planted there. Security researchers showed that an order of magnitude of around five prepared documents can manipulate answers in around 90 percent of cases — and a single PDF with invisible text can be enough for the agent to carry out the attacker’s instruction instead of its actual task.

Does MCP make AI agents less secure?

MCP in itself does not make AI less secure, but every additionally connected data source or tool enlarges the attack surface — for example via tool descriptions, tool outputs, memory or retrieval hits. What is decisive is the clean securing of the MCP connection: minimal rights, clear separation of instruction and data, audit logs and EU hosting. Implemented correctly, MCP even creates more control, because it defines exactly what an agent may access.