The decision
Treat retrieved documents, emails and model output as untrusted inputs. Text can describe an instruction without being authorised to issue it. OWASP identifies prompt injection and excessive agency as application risks; a business system needs boundaries outside the model's wording.
A worked example
Imagine an assistant reading a supplier email that says to ignore previous rules and export all customers. The email is evidence to analyse, not an authority to change permissions. Even if the model requests an export, the application should verify the real user's entitlement, allowed target and approved action before any data leaves.
Alternatives worth weighing
A read-only assistant has a smaller action surface than one that updates records. For a necessary write operation, expose a narrow tool with validated parameters and a clear confirmation step. A conventional approval form can be preferable for actions whose consequences users must inspect precisely.
Where the plan breaks
Do not place credentials inside a prompt or rely on “never reveal secrets” as access control. Keep tools scoped, redact unnecessary inputs and separate tenants before retrieval. Test hostile instructions in attachments as well as direct user messages; indirect content reaches the system through ordinary work.
Make authorisation a property of the command
For a supplier-facing assistant, define a narrow list of capabilities such as reading the current user’s orders or preparing a draft response. Resolve the user and tenant from the authenticated application session, not from instructions in an email or a field suggested by the model. Validate ownership of the selected record in server code. An allowed tool name is not enough if its parameters can redirect it to another customer, destination or data scope.
For consequential actions, present an explicit preview of the proposed change. Bind approval to that particular record, operation and material parameters rather than accepting a general conversational “yes” as standing permission. If those parameters or the record state change, obtain a new decision. Read-only access can still expose sensitive information, so permissions must also apply when searching documents and returning snippets, not only when a write operation begins.
Rehearse a rejected request and a safe shutdown
Create a fictional hostile attachment that asks the assistant to disregard its role and disclose another account’s information. Test it alongside a legitimate request so the team can inspect the boundary without using real customer data. The acceptance condition is that no unauthorised read, write or outbound action occurs, even if the model produces an inappropriate tool request. Review whether error messages themselves disclose protected record existence.
Operators also need a way to disable an individual tool or source while keeping safe parts of the application available. Define what happens to work already queued when access is revoked. Record action references, authorisation decisions and safe error categories with restricted access; avoid collecting full secrets or unnecessary document contents in diagnostic logs. Repeat the review when adding a data source or capability. A successful test narrows known risks; it is not proof that prompt injection has been eliminated.
Before you commission the work
What can the assistant read, change and send? Which decision is enforced by server code? What evidence remains after a rejected request? Review these paths with the AI integration team and repeat the checks when tools or data sources change.