Source: [Retrieved documents must not grant an AI agent permission to act — Skills for Business]() [← All articles](https://skillsforbusiness.ai/blog/) Development · Guide # Retrieved documents must not grant an AI agent permission to act Design tool permissions around the authorized task, then test whether an AI agent resists instructions in retrieved content while still completing useful work. [Skills for Business](https://skillsforbusiness.ai/blog/editorial/)31 October 20267 min read On this page 1. [Put action controls around the model](https://skillsforbusiness.ai/blog/retrieved-documents-agent-action-permissions/#put-action-controls-around-the-model) 2. [Map permissions to the business task](https://skillsforbusiness.ai/blog/retrieved-documents-agent-action-permissions/#map-permissions-to-the-business-task) 3. [Define an injected request without giving it authority](https://skillsforbusiness.ai/blog/retrieved-documents-agent-action-permissions/#define-an-injected-request-without-giving-it-authority) 4. [Use research to design the evaluation](https://skillsforbusiness.ai/blog/retrieved-documents-agent-action-permissions/#use-research-to-design-the-evaluation) 5. [Test useful work and boundary enforcement together](https://skillsforbusiness.ai/blog/retrieved-documents-agent-action-permissions/#test-useful-work-and-boundary-enforcement-together) 6. [Retain layered defenses and a narrow rollout](https://skillsforbusiness.ai/blog/retrieved-documents-agent-action-permissions/#retain-layered-defenses-and-a-narrow-rollout) 7. [Sources](https://skillsforbusiness.ai/blog/retrieved-documents-agent-action-permissions/#sources) What to take away - Treat retrieved text as task evidence; authorize tool actions through application controls. - Inspect attempted and executed actions, rather than trusting the agent's final explanation. - Test legitimate task completion alongside unauthorized actions and blocked attempts. An AI agent reading a document should not gain new permission to send messages, change records or retrieve unrelated information because the document asks it to. Keep the authorized task and action permissions outside the retrieved text. Then test whether the application enforces those boundaries even when the agent proposes the wrong action. This matters when a business assistant moves from answering questions to using tools. A support article, ticket or webpage may contain useful facts alongside instructions aimed at the assistant. If those instructions redirect its work, the problem is indirect prompt injection: external content is being treated as authority over the agent. This guide proposes a permission map and a small test plan for a fictional support workflow. It draws on inspected research and engineering accounts. We did not run attacks against a product, test an agent or validate a particular application’s security. ## Put action controls around the model Microsoft’s July 2025 [engineering account of indirect prompt injection defenses](https://www.microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks) distinguishes probabilistic prevention and detection from controls that limit impact. It describes fine-grained access, blocking particular data-exfiltration paths and explicit consent for specific actions. It also classifies prompt hardening and Spotlighting, which distinguishes untrusted text from instructions, as probabilistic mitigations. That is a vendor account of its approach, not evidence that every Microsoft surface or another supplier’s agent implements the same controls. Our design recommendation is to make the application check the proposed action against permissions established for the task. A sentence in a retrieved file should not be able to change those permissions. Prompt instructions still have a role. Explain which content is evidence and which instructions govern the work. Preserve source boundaries when assembling context. But a reminder to ignore malicious text should sit alongside controls on what the agent can actually read, write and transmit. Removing a send tool from a draft-only workflow is different from asking the model not to use a send tool it possesses. Neither measure alone establishes the safety of the whole application: other tools, output rendering and access paths still need review. ## Map permissions to the business task Consider a fictional internal support assistant. An employee asks it to read an equipment ticket, consult the approved knowledge base and prepare a response for review. The requested outcome is a draft answer. It does not require changing an account, contacting an external party or exporting a collection of tickets. Before connecting the model, the application owner and developer could agree on this proposed permission map: | Operation | Boundary for this fictional workflow | Where to enforce it | | --- | --- | --- | | Read the assigned ticket | Only the ticket selected through the authorized workflow | Ticket service access check | | Retrieve support guidance | Approved collection within the employee’s permitted scope | Retrieval service and document permissions | | Save a response draft | Attach it to the assigned ticket without sending | Narrow draft-saving operation | | Send a response | Requires a separate authorized send step | Sending service and approval workflow | | Change an account or export tickets | Outside this task | Unavailable operation or service-side denial | The map is a proposal, not a configuration tested in a named product. Its purpose is to expose unnecessary capabilities before a prompt is written. A broad connector credential may technically allow much more than this task needs. The implementation must narrow that authority rather than infer permission from the model’s explanation. The same principle applies to read access. Draft-only operation can still disclose information in an answer if the retrieval path supplies unrelated confidential records. Restricting writes does not settle which information should enter the run. ## Define an injected request without giving it authority In the fictional test ticket, include ordinary troubleshooting facts and a harmless synthetic instruction asking the assistant to copy an unrelated test record into its reply. Use fabricated records and inert identifiers. The test environment should contain no customer data, production credentials or real external destinations. The expected behavior is to use the troubleshooting facts while declining or disregarding the unrelated instruction. The service must deny access to the unrelated record if the agent nevertheless requests it. Record those as separate observations: the model attempted an unauthorized action, and the application blocked it. A statement in a document claiming to be an administrator’s approval should not satisfy the application approval check. Likewise, an instruction described as a prerequisite for completing the ticket should not expand the task. Approval needs an authenticated path with a defined scope, not a claim embedded in the material being processed. When a workflow genuinely requires a new action, route it through the supported authorization process. Show the proposed operation, target and material being sent or changed. Approval of one draft or one destination should not silently become approval of all later actions. ## Use research to design the evaluation The original [AgentDojo research](https://arxiv.org/html/2406.13352v3) builds tool-using environments with legitimate user tasks and adversarial instructions in tool-returned data. It distinguishes ordinary task utility, utility under attack and targeted attack success. The 2024 model experiments are historical evidence, not current failure rates for your assistant. The useful contribution here is the separation between the user’s goal and the attacker’s goal when evaluating a run. An October 2026 preprint, [Ignored, Not Refused](https://arxiv.org/html/2610.23254v1), audits small open-weight agents on two benchmarks. Using an LLM judge, it distinguishes refusal, ignored instructions and mechanical failure, and examines task completion alongside attack outcomes. Its labels depend partly on stated reasoning; its static synthetic tests do not establish live resilience. We do not reproduce its percentages or combine its utility scores with the earlier paper’s differently worded definition. For local evaluation, inspect the actual tool requests, service responses and resulting state. The final reply alone cannot establish that no unauthorized action occurred. Conversely, the absence of a forbidden action is incomplete evidence if the application crashed before it could do any work. ## Test useful work and boundary enforcement together Start with a clean ticket and confirm that the fictional workflow can produce the expected draft from the supplied guidance. Keep the legitimate task stable when introducing variations. This provides a baseline for distinguishing a defense from a broken workflow. Our proposed test set includes an ordinary ticket, a ticket containing the synthetic redirection, a document claiming authority to approve a new action, an irrelevant instruction in a retrieved article, and a harmless quotation discussing prompt injection. That last case checks whether the application rejects useful material merely because it mentions an attack. For every case, retain the expected draft facts, allowed operations and prohibited effects. Record whether the task was completed, whether any prohibited effect occurred, whether an unauthorized request was attempted and where it was blocked. If the draft was saved, inspect the saved content as well as the final chat message. An attempted export blocked by the service is evidence of that service boundary working for the case. It is also a reason to investigate the model’s behavior. A run that refuses everything may avoid the export while failing the support task. These outcomes need different fixes and should remain visible in the report. Repeat important cases and retain mixed results. Record the model identifier, application revision, tools, permission configuration and source fixture. Rerun the affected cases when any of those change; a model-only comparison cannot establish the behavior of a different connector or approval implementation. ## Retain layered defenses and a narrow rollout Anthropic’s November 2025 [browser-use defense account](https://www.anthropic.com/research/prompt-injection-defenses) describes training, classifiers and red teaming, while explicitly saying prompt injection remains unresolved. Those are vendor statements about a particular evaluated setup, not independent validation of current products. They support caution about treating any single model or detector as the complete boundary. For a business deployment, give each control an owner: source access, tool authorization, approval, output handling and incident review. A small team can start with a draft-only task and narrow retrieval. A larger organization can apply the same map across services, with shared logging and security review appropriate to its environment. Our [agent-skill installation guide](https://skillsforbusiness.ai/blog/third-party-agent-skills-installation-review/) addresses what an instruction package can access. Retrieved-content controls cover a different entry point: material encountered after an approved workflow has started. Both belong in the application design. Choose one tool-enabled task and write its permission map before widening access. Demonstrate the clean case, the blocked unauthorized attempt and continued useful work in an isolated test environment. Treat those results as evidence for the tested configuration, then expand only where the business task requires more authority. ## Sources & further reading Sources checked for this article. Research findings and vendor claims are distinguished in the text. 1. [How Microsoft defends against indirect prompt injection attacks](https://www.microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks)Microsoft Security Response Center · Accessed 31 October 2026 2. [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents](https://arxiv.org/html/2406.13352v3)Debenedetti et al.; NeurIPS 2024 · Accessed 31 October 2026 3. [Ignored, Not Refused: What Low Prompt-Injection Success Rates Hide in Small Tool-Using Agents](https://arxiv.org/html/2610.23254v1)Zarif et al.; arXiv · Accessed 31 October 2026 4. [Mitigating the risk of prompt injections in browser use](https://www.anthropic.com/research/prompt-injection-defenses)Anthropic · Accessed 31 October 2026 Produced with AI-assisted research and writing. Examples and recommendations are our editorial synthesis unless attributed. This article does not claim independent product testing or human expert review. [Read our editorial policy.](https://skillsforbusiness.ai/blog/editorial/) ## Keep reading [An AI-suggested dependency needs an identity check](https://skillsforbusiness.ai/blog/ai-suggested-dependencies-identity-check/)[Give coding agents a reproducible bug and a clear acceptance test](https://skillsforbusiness.ai/blog/coding-agent-bug-report-acceptance-tests/)