Prompt injection in AI assistants: 8 layers of protection every company needs

A business AI assistant reads customer questions, documents and web pages, and may also use tools. That usefulness creates a new security problem: an ordinary-looking piece of content can hide an instruction intended to change the model's behaviour. This attack is called prompt injection.

It is not limited to the phrase “ignore previous rules”. Malicious text can live in a document uploaded to a knowledge base, a product description, an external page or content retrieved only during a conversation. OWASP therefore distinguishes direct from indirect prompt injection and warns that RAG or fine-tuning do not solve the problem by themselves.

A secure AI assistant is not a model with one perfect prompt. It is a system in which independent layers limit damage even when one layer fails.

What prompt injection can cause

In a simple information chat, an attacker may try to force an incorrect answer, suppress an important source or extract internal instructions. When the assistant can access orders, email or write-capable tools, the consequence may include data exposure or an unintended action.

NIST describes how indirect prompt injection can affect confidentiality, integrity and availability. There is no universal defence. The practical objective is therefore not a promise that an attack can never succeed, but limited impact, early detection and safe recovery.

Eight layers that back one another up

1. Define the assistant's job precisely

A customer-support assistant does not need broad permission to “do whatever is necessary”. Define the topics it covers, the sources it uses and when it hands a conversation to a person. Narrow scope reduces the number of dangerous decisions.

2. Separate trusted instructions from untrusted content

A user question, website text and document content are data, not new system rules. The application must preserve their origin and priority. An instruction found in a PDF must not carry the same authority as a rule configured by an administrator.

3. Allow only approved sources

A knowledge base should not absorb the entire internet automatically. Use an explicit set of domains and sources, validate redirects and publish synchronised content only after successful checks. When a page changes, track what actually changed.

4. Apply least privilege

The assistant should see only data required for the task. A public chat does not need internal documents, and an order-status assistant does not need permission to change the order. Organisations, assistants and sources must be isolated on the server, not merely by wording in a prompt.

5. Enforce critical rules deterministically

The model must not decide whether a user may access another account, whether a domain is allowed or whether a tool call is authorised. Authentication, input validation, limits and permitted operations belong in application code. The model can propose a step; the server must verify it independently.

6. Stop risky actions before execution

Reading a public article carries a different risk from sending an email, issuing a refund or changing an order. Operations with financial, legal or data impact should require human approval, or should not be available to the assistant at all.

7. Verify outputs and sources

An answer should use only results retrieved by the server from approved sources. Citations must point to actual evidence, and links should be checked before display. When evidence is missing, acknowledging uncertainty is safer than producing a confident estimate.

8. Test, monitor and prepare rollback

Add direct and indirect attempts to change rules, extract secrets and trigger unauthorised actions to your tests. Monitor refusals, unusual requests, source changes and handoff outcomes. New attacks keep emerging, so security is an operating cycle rather than a one-time review.

Risk grows with what the assistant can do

• Information assistant: needs a fixed source scope, citations and regression tests.
• Assistant with private data: add server-side user identity, tenant isolation and minimal data retrieval.
• Assistant with tools: every operation needs separate authorisation, validated parameters, an audit trail and an impact limit.
• Assistant with irreversible actions: require human approval or do not grant that capability.

A short security test before launch

1. Try to overwrite the assistant's rules through a user question.
2. Place a similar malicious instruction in a test document to exercise indirect injection.
3. Request a source belonging to another organisation or assistant.
4. Try an identifier for another order or document.
5. Trigger a risky operation with malformed and unexpected parameters.
6. Verify that the incident appears in the audit trail and the configuration can be rolled back safely.

Never use real secrets or personal data in these tests. Work with test accounts and safe samples.

How Informio approaches the problem

Informio isolates organisations, assistants and approved knowledge sources on the server. Public requests are checked against a specific assistant, allowed domains and limits. Results are designed to remain grounded in approved sources, while uncertain cases can be handed to a person.

Quality Lab lets you save both ordinary and adversarial scenarios and run them again after changing sources, instructions or models. No product can honestly promise absolute immunity to prompt injection. A well-designed system can nevertheless minimise permissions, verify every sensitive step and detect regressions quickly.

Try Informio Quality Lab and add the first security cases to your scenarios.

Sources

• OWASP GenAI Security Project – LLM01:2025 Prompt Injection
• NIST AI 100-2e2025 – Adversarial Machine Learning
• OpenAI – Understanding prompt injections