Keep document-reading AI inside its authorised task

A document-reading assistant should be able to summarise a file without gaining authority from instructions written inside that file. Keep retrieved content separate from the user’s authorised task, restrict the application’s permissions and enforce consequential action checks outside the language model. A stronger prompt can help communicate the task, but it is not a dependable security boundary by itself.

The UK National Cyber Security Centre explains why prompt injection is not equivalent to SQL injection: language models do not provide the same robust separation between instructions and data. This is technical guidance, not an Indian legal requirement. OWASP recommends layered controls, including limited permissions and validation of tool actions. 1 2

Source content may contain facts to analyse, but it cannot authorise sending messages, changing records or accessing additional data. Reduce what the assistant can do. Test whether the application blocks an unauthorised action, not only whether the answer sounds cautious.

For an English-language document assistant used by an Indian operations team, specify the intended output, permitted sources and audience. A pilot might prepare an internal comparison from approved public product documents. It should not send the comparison, modify a customer record or determine a legal obligation unless those separate activities have been explicitly authorised and designed for.

Write down every connected capability. Ask whether the task needs it and whether the access can be narrower or read-only. Separate the service account’s permissions from the model’s description of its role. If a model is told not to edit a record but the application still permits arbitrary edits, the instruction is carrying too much responsibility.

Do not grant a document permission to redefine who approved a task. Check actions against trusted application context and the actual user authorisation. Give a reviewer the destination, affected records and expected consequence rather than a vague request to “continue”. OWASP’s guidance supports minimal permissions and tool-specific validation; implementation still needs specialist assessment. 2

In a controlled pilot, use fictional documents and a test environment. Include a benign instruction that asks the assistant to perform an action outside its assigned summarisation task, such as changing a test record’s status. The expected result is that no unauthorised write occurs. Use no real customer data, secrets or external delivery destination.

Retain the task version, document version, available permissions, observed output and application action log. Have the reviewer distinguish model refusal from application enforcement. If a model proposes the wrong action but the permission gate blocks it, record both facts; if the action executes, stop the affected capability and investigate.

These are suggested evaluation conditions, not a security test performed by QSE Advisory. A small successful sample cannot prove protection against all injection techniques. Integrate the results with human checks and data controls, including who can pause the workflow and how manual work continues.

A controlled test can use an invented product document containing an instruction to change a fictional record outside the assigned summarisation task. Do not include secrets, real recipients or live business records. The following is a proposed interpretation matrix, not a report of tests performed.

The last case matters because a cautious-looking answer and a confident success statement can both mislead reviewers about what actually happened. Compare the output with authorised application logs and the test record's state.

Run the exercise only within an approved environment and defined permissions. Its scope is one harmless authority test. Even a blocked action provides no assurance about every document, connector, read permission or injection technique. Production release still requires the relevant technical owner to assess the wider design and remaining uncertainty.

A services team may work with documents belonging to customers in several jurisdictions. Before expanding beyond public material, confirm the approved tool configuration, information-sharing permissions and relevant contractual or legal requirements with the responsible specialists. A customer’s location or a document’s language does not, on its own, establish permission to upload it.

Do not assume so. Filters and model-based guardrails are additional layers; they do not replace application permissions, validation and approval controls. 2

No. A citation can support an answer while a separate embedded instruction attempts to redirect an action. Evaluate both evidence quality and task authority.

From AI to SI is a QSE Advisory product and a related-brand resource. It is not independent evidence that a particular assistant is secure; assess any support against your own requirements.

AI assisted research and drafting. This article is general information; verify current requirements and obtain competent advice for consequential decisions.

1. UK NCSC: Prompt injection is not SQL injection — Security explanation of the imperfect separation of data and instructions in LLM systems; not Indian law.

2. OWASP LLM Prompt Injection Prevention Cheat Sheet — Living technical guidance; least privilege, tool validation and layered defences.

This article is general information. Verify current requirements and seek qualified advice for your specific circumstances.

Spotted an issue? Contact our editorial desk.