Prompt injection and personal-data leakage need separate controls

An AI assistant can disclose personal data without any hostile instruction. A legitimate user may receive a retrieved document they are not entitled to see, or a normal diagnostic trace may copy a customer’s message.

Prompt injection creates a different failure path: instructions in an input or retrieved source try to redirect the system’s behaviour. The two risks can interact, but treating them as the same problem leaves gaps in both the controls and the tests.

Identify what is being attacked

OWASP describes direct and indirect prompt injection. A direct attempt appears in a user input. An indirect attempt can arrive through material the application processes, such as a retrieved document.

The aim may be disclosure, an unauthorised tool action or a change in the answer. An injected instruction does not need to contain a phone number or another obvious personal identifier.

Sensitive-information disclosure has a broader set of causes. OWASP’s guidance on that risk covers exposure involving model and application context. Poor access control, unnecessary prompt content and output handling can create disclosure opportunities even when every input is ordinary.

This distinction changes where the engineering work belongs. A personal-data detector cannot decide whether an instruction should be obeyed. An injection classifier cannot establish whether the user is authorised to see a particular customer’s record.

Work through a paired example

Consider a hypothetical service desk assistant with access to order information and a refund tool.

In the first test, a retrieved note includes an instruction to send the complete customer record to an external address. The application should treat the note as data and prevent unauthorised disclosure or actions. This is an injection scenario.

In the second test, an authorised employee asks an ordinary delivery question, but the retrieval layer supplies another tenant’s customer record. There is no malicious instruction. The system has an authorisation and data-selection failure.

In a third test, the assistant answers correctly but the full prompt is copied into a broadly accessible log. The answer can look safe while the data path remains inappropriate.

Each case needs a distinct expected outcome and evidence.

Enforce permissions outside the model

Tool execution should validate the actor, action, target resource and parameters at the application boundary. The model’s request is input to that decision; it is not the authorisation decision itself.

The OWASP prompt-injection prevention guidance recommends layered controls, including restricted capabilities and validation around tool use. A second model used as a guardrail can also be exposed to adversarial content, so its verdict should not replace ordinary application permissions.

For the refund tool, the service should validate which order the employee may access and what refund action is permitted. A reassuring assistant message or a well-formed tool call does not supply that permission.

The OWASP authorisation guidance supports least privilege, default denial and permission checks on each request. Those controls remain useful even when the model misunderstands the content.

Minimise data independently

Give the assistant only the information required for its task. Apply source permissions before retrieval results become model context. Limit unnecessary fields in tool responses, and control what reaches logs, caches and external services.

These measures reduce disclosure opportunities regardless of whether injection occurs. They also reduce what a successful redirection could expose.

Output checks can provide another layer, but they cannot reverse an earlier unauthorised retrieval or transfer. Evaluate the complete path, including tool calls and intermediate stores, rather than only the final answer shown to the user.

Avoid claiming that a particular prompt template eliminates injection. OWASP presents mitigations as a layered approach, not a foolproof boundary.

Keep two test tracks

An injection test track can include hostile instructions in user inputs, retrieved documents and tool results. The expected result should concern unauthorised actions and data access, not merely whether the assistant says it refused.

A disclosure test track can use entirely ordinary requests to check retrieval permissions, field minimisation, cross-tenant isolation and telemetry handling.

Before release, confirm:

• The two tracks have separate cases and reported findings.
• Tools enforce permissions without relying on model agreement.
• Retrieved content cannot expand the user’s access.
• A normal request cannot pull unnecessary personal data into context.
• Intermediate outputs and logs are included in the inspection.
• The team has a defined response when a test exposes a new path.

This separation makes the results more informative. A system can improve against injected instructions while still leaking through ordinary access paths, and the review should be able to show that clearly.