Prompt injection:
what it is and how to reduce the risk in agents

Prompt injection makes the model follow orders from someone with no authority

An LLM application receives legitimate instructions from the system prompt and from the authorised user. It also receives content to process, such as documents, emails, pages and query results. Prompt injection happens when part of that content changes the model's behaviour as if it were an instruction.

The name comes from SQL injection. There, parameterised queries separate command from data. In a language model, that separation does not yet have the same guarantee.

The injection can come from the user or from the content the agent reads

• Direct injection: the user writes the request to get around the application's rules, for example to obtain data their profile should not see.
• Indirect injection: the instruction arrives hidden in something the agent reads during the task, such as an attached document, a web page, a ticket or a tool result. Whoever wrote it does not even need access to the application.

The indirect form is the bigger worry for companies. A ticket opened by an external sender may carry a passage that tries to obtain other customers' data, and a web page consulted by a research agent may hide text that does not appear on screen.

Instructions and data reach the model through the same text channel

The system prompt, the user's request, retrieved documents and tool responses become a single sequence of text. The model produces the most likely continuation for the whole sequence, and a sentence phrased as an order inside a CV weighs on that continuation like any other.

Delimiters and tags signal where the external content begins, without the guarantee of a structural boundary. That is why prompt injection is still treated as an open problem.

Agents with tools widen the damage of a prompt injection

In an assistant that only chats, injection produces a manipulated answer. In an agent, tools and credentials turn text into action:

• Data leak: the agent returns, or sends to an external destination, information the author of the injection could not see.
• Improper action: the agent changes a record, closes a ticket or sends a message on the strength of a planted order.
• Manipulated answer: the candidate ranking or a research summary comes out biased without the reader noticing.

Permissions define the reach. A screening agent that only reads CVs can do limited damage. With write access to the HR system and the ability to send emails, the blast radius grows.

Filters and warnings in the prompt reduce the risk and leave gaps

The first defences are usually textual: a warning in the system prompt to disregard orders coming from documents, and a classifier for known attack patterns. Both lower the success rate.

The warning, however, is just one more passage in the same sequence of text, and the classifier recognises variations similar to those it has already seen. A new phrasing can get through. The list of risks for LLM applications published by OWASP in 2025 puts prompt injection in first place and notes that it is unclear whether a foolproof prevention method exists.

Defence against prompt injection works in layers

The design combines controls that limit what happens after a successful injection:

1. Least privilege per task: the screening agent reads CVs with no write access to the HR system.
2. Permissions enforced outside the model: the system that receives the call decides, using the identity of whoever asked, what can be read or executed.
3. Tagging of untrusted content: what comes from outside enters labelled as data, and the agent runs with fewer tools while processing it.
4. Human confirmation: external sends, record changes and deletions go past a person before they run.
5. Output limits: a closed list defines where the agent may send data, and an address planted in the text stays off it.
6. Monitoring and adversarial testing: every query and action is logged, and the security team tests the flows with manipulated content every time the model changes.

In the Company Brain, inherited permissions limit the reach of a prompt injection

The Company Brain connects CRM, helpdesk, the HR system and documents once and organises that data into a knowledge graph, a business ontology and a semantic layer. The agent queries this context over MCP.

Permissions are inherited from the source system and applied before the data reaches the model. If a manipulated ticket leads the agent to request another customer's history, the query comes back without those records, because the person who asked has no such access at the source.

Each question receives the minimum slice the answer requires. Every query is logged with the person, the sources read and what came back, which makes it possible to reconstruct the path of a suspicious answer.

The architecture reduces the damage and keeps injection an active risk

The Company Brain limits what a successful injection can reach. It does not stop the model from being influenced by planted text, and a manipulated answer within the permitted slice is still possible. A permission misconfigured at the source reaches the agent just the same, and the action controls remain the responsibility of whoever designs the agent.

The starting point is to cross who reads external content with who acts

The first survey compares two lists: agents that read content from external sources, such as CVs, tickets, emails and web pages, and agents with permission to write or send. Those that appear on both lists concentrate the prompt injection risk.

For each of them, the review defines which tools are removed, which actions require human confirmation and where the agent may send data, and the adversarial tests come before the return to production.