Read-only AI access is not a security boundary

01

Read-only is a permission, not a trust label

The comforting version of “read-only” comes from conventional access control. If software cannot modify the file, database or service, an important class of damage disappears. That remains useful. The problem begins when that control is treated as proof that material being read cannot influence the AI in an unsafe way.

Microsoft describes the underlying mechanism plainly. External text is supplied alongside a user’s request. If an attacker controls or influences that text, an instruction-tuned model may interpret part of it as instructions rather than merely material to analyze. That is indirect prompt injection.

The source does not need an exotic format. Microsoft lists webpages, emails, shared documents and data returned by tools, and says even a plain ASCII text file can carry an injection. Making a source immutable therefore does not sanitize its contents or establish how the model will interpret them.

That leaves two separate security questions. Can the application alter the source? And can source material steer the application? Read-only permissions help answer the first. They do not settle the second. That separation is the core reason the myth fails.

02

The missing boundary is between data and instructions

The familiar mental model says a document that cannot be edited is passive. For an LLM application, retrieved material may instead become part of the model’s input. Microsoft’s account shows why source permissions and model influence cannot safely be collapsed into the same concept.

Successful injection is not synonymous with successful compromise. Microsoft explicitly says many influences on an LLM’s output have no security impact. A hostile instruction still needs a consequential route: sensitive information the application can reach, an action it can perform, or some usable exfiltration channel.

That exception belongs in every risk review. A constrained application without sensitive context or useful outbound paths has a different impact profile from one with broad data access and powerful tools. “Read-only” alone says remarkably little about that difference.

The useful test is therefore not whether a file can write back. It is what the application can reach after reading it, and which effects remain possible when the model behaves unexpectedly.

03

Follow the capability after the document

Microsoft’s impact examples make the architecture more important than the offending document. One scenario has an injected instruction steer an application toward accessible user data and then an available exfiltration method. Another involves tools performing unintended actions using the user’s permissions.

This is why least privilege matters even when prompt-injection detection exists. Microsoft describes fine-grained permissions and access controls as a way to deterministically mitigate impact. It also points to data governance, sensitivity labels and data-loss-prevention controls in Microsoft 365 as ways to constrain information use.

The same principle applies to actions. Microsoft describes explicit user consent as an effective control when an impact cannot otherwise be sufficiently prevented. Its Outlook example allows AI to draft text but requires the user to approve and send it. Approval does not make hostile input trustworthy; it constrains a possible consequence.

This reframes the review around capability. The relevant inventory is not simply which repositories are writable. It includes accessible context, inherited permissions, callable tools and available outbound routes. Those determine whether manipulated model behavior has somewhere consequential to go.

04

How to do it

Practitioner discussions show why this distinction is useful, although Reddit is evidence of concern, not prevalence. In one r/cybersecurity post, a small-company user considering broader Copilot adoption asks whether documents and PDFs supplied for review create an indirect-prompt-injection risk.

Another r/cybersecurity thread asks about attacks arriving through document ingestion. Commenters discuss input handling and downstream permissions, but their claims about production experience and particular defenses are anecdotal. They should not be treated as measures of incidence or proof that a particular mitigation works.

The stronger technical basis comes from Microsoft. Its defense-in-depth approach combines model-facing protections with fine-grained permissions, data governance, deterministic blocking of known impact paths and explicit consent for some consequential actions. Several model-facing defenses are probabilistic; deterministic controls are preferred where feasible.

05

Make read-only the start of the review

A sensible review keeps read-only controls; it simply refuses to make them carry more meaning than they have. Inventory external content entering the model, then trace what context, tools and credentials become reachable when that content is present. That turns a vague AI-risk discussion into an architecture question.

Next, separate defenses that reduce the probability of injection from controls that limit its impact. Microsoft makes this distinction explicitly. Prompt hardening and detection can add layers, while fine-grained permissions and deterministic blocks can provide stronger guarantees against particular consequences.

There is no basis here for saying every retrieval system produces a damaging exploit. An attacker must be able to influence input, and consequential harm requires something worth reaching or doing. A constrained system can therefore have a substantially smaller blast radius without pretending external text is inherently trusted.

Read-only remains valuable because it can prevent unauthorized modification. What it cannot do is turn data into inert material once that data enters an instruction-following model. Security teams need both concepts on the diagram: what the AI may read, and what can happen because it read it.