Limit an AI agent’s permissions before giving it tools
Separate reading from writing, restrict accounts and destinations and require a clear authorization path for consequential actions.
In brief
An agent’s real power comes from the tools and credentials it can use, not the safety wording in its prompt. Start with the smallest access needed for the task and add only justified capabilities.
A draft-only assistant can be useful without also receiving the ability to send, delete or purchase.
Define the task boundary
For a scheduling helper, reading selected calendar availability and drafting a suggestion may be sufficient. It does not automatically need access to all mail or permission to invite everyone. Describe the exact resources and maximum action, not just a broad “assistant” role.
Enforce it outside the model
Filter resources for the user before retrieval, validate tool arguments and separate credentials by purpose. Bound the run’s time, tool count and spending where relevant. A disabled button in the UI is not protection if the tool endpoint remains callable with broader access.
Test an attempted boundary crossing
Use harmless sample data containing instructions to read an unrelated resource or send a message. Confirm the application refuses it and logs an appropriate non-secret event. Do not put real private records into a test just to prove that the model can leak them.
Before you act
A retrieved document or webpage can contain hostile instructions. Access controls must hold even when the model follows the wrong text.
What to do next
- List every available tool, credential and readable or writable resource.
- Provide a limited read-only or draft path first and restrict destinations and accounts.
- Test denied actions and require deliberate authorization for allowed consequential changes.
