Give your AI tools less authority

An assistant that drafts a customer reply does not need the same access as the employee who approves it. Yet it is easy to connect both through one account with permission to read every contact, export records, and send messages.

Before improving the prompt, narrow what the tools can do.

Retrieved text can contain instructions

A customer email, document, or web page is data the assistant may need to read. It can also contain text that tries to redirect the assistant's behavior.

The 2023 paper Not what you've signed up for demonstrates indirect prompt injection through content encountered by LLM-integrated applications. That matters even when the person using your assistant is legitimate. The untrusted instructions can arrive through material they asked it to inspect.

The June 2025 paper Design Patterns for Securing LLM Agents against Prompt Injections analyzes architectural protections and their utility tradeoffs. The practical lesson for a business workflow is to limit the consequences of untrusted text influencing a model. Prompt wording alone should not carry that responsibility.

Break broad tools into business actions

Compare a general "update customer" tool with a narrower "save draft response" tool. The latter can accept a draft for one authorized conversation without exposing arbitrary record changes.

A useful review table might look like this:

Workflow	Access it needs	Access to keep separate
Draft a reply	Approved conversation and reference material	Sending, contact export, account deletion
Suggest an appointment	Availability for the approved service	Calendar administration
Classify incoming leads	Relevant lead fields and approved categories	Changing ownership rules or sending campaigns
Summarize a document	Documents the current user can read	Sharing the result with new recipients

The server must still validate the requested action. A small tool name is not protection if its implementation accepts arbitrary identifiers and trusts them.

Resolve workspace and user identity from the authenticated request. Restrict allowed fields and destinations in application code. Reject requests outside those boundaries even when the model supplies a persuasive explanation.

Match credentials to the task

RFC 9700, published in January 2025, recommends restricting access-token privileges to the minimum needed for the use case. In practice, check what the connected provider actually supports.

If a provider cannot issue sufficiently narrow access, your application can place a restrictive service between the assistant and that provider. Keep the broad credential in that service. Expose only the specific operations the workflow needs.

This reduces available actions; it does not make the whole system immune to attack. The intermediary still needs authorization, input validation, and careful credential handling.

Put approval next to the action

A person approving a message should see the recipient, exact content, sending account, and any relevant attachments. An approval of an earlier draft should not automatically authorize a later version with a new recipient.

Bind the approval to the specific action that will execute. If the material fields change, require a new decision. Separate the tool that prepares the action from the service that executes an approved one.

For a low-impact internal classification, a person may not need to approve each result. For an external message or destructive change, the costs differ. Decide that policy for each action rather than treating "autonomy" as one switch for the whole assistant.

Test a denied action as carefully as an allowed one

Add examples that ask the assistant to cross a workspace boundary, send to an unapproved address, or reveal a credential mentioned in a document. The expected result is a blocked operation with a useful record of why it was denied.

Also test the legitimate path. A restriction that silently prevents every useful task will be bypassed by frustrated staff.

The target is a tool set that does the assigned job with limited authority, clear approvals where needed, and a small, understandable set of possible mistakes.