KINSMC
List the actions you expect the assistant to take
Suppose you want an AI assistant to answer questions about an internal equipment handbook. People ask which room has the spare charger or what steps to take before booking a projector. The assistant needs to find current handbook pages and quote the right section. It does not need a way to edit the handbook, email staff, or read everything else in the workspace.
Write down the task in terms of actions and resources. In this example, the allowed action is to read pages in one approved folder. The expected output is a message in the current conversation with links to those pages. Those two decisions give you something concrete to compare against the permissions a connector actually requests. NIST calls the broader principle least privilege: grant the minimum resources and authorizations required for a function.
Restrict both the action and the files
A read-only setting answers what an account can do. Folder and project boundaries answer what it can do that to. You need both answers. If a connector can read a whole workspace, it may be able to retrieve a financial note or a private draft even though it cannot modify it. A folder boundary limits the material it can reach. The application’s own authorization checks should enforce that boundary.
Use an approved test folder with copied or fictional documents while you set things up. Ask the workspace administrator which identity the integration uses, what that identity can read, and whether the permissions follow the person asking the question or a separate connection. On a shared system, two staff members may be entitled to see different files. Test that distinction before letting the assistant answer either person using the wider connection. If the only available grant is broader than the job requires, try a small approved copy of the handbook or ask for a connector that supports narrower access.
Keep drafting separate from sending or editing
An assistant can suggest a correction in chat, and a person can open the document and decide whether to make it. This arrangement works well for an initial rollout. People can see which evidence led to the suggestion, and the assistant’s account has no ability to change the source document.
If you later add a write step, give it its own small scope and a clear approval screen. Show the reviewer the exact file, the proposed changes, and any people who will receive a notification. The system should enforce approval before sending the write request. A sentence in a prompt asking the assistant to wait is a behavioral instruction. Authorization belongs in the service that controls the action. For the human side of review, see how to keep a human in the loop when using AI at work.
Try one allowed case and three blocked cases
Begin with a question whose answer appears in the approved folder. Confirm that the response identifies the correct source. Next, ask it to retrieve a clearly labeled fictional document outside that folder. Check that the connected account cannot retrieve it. Then ask it to edit or delete one of the permitted test documents. Check the application itself to confirm the document stayed unchanged.
For a third blocked case, put an instruction into a fictional handbook page asking the assistant to send the document elsewhere. Ask a normal question that leads the assistant to read that page. The page is material being processed. It has no authority to expand the task. Check the output and the test account’s activity history, if available. No message should have been sent. Keep the documents and destinations fictional for this exercise.
OWASP’s guidance on excessive agency describes why broad tool functions, broad permissions, and excessive autonomy can make a failure more consequential. Narrow access reduces the paths by which a bad instruction can turn into a real action. It still leaves a review job: read access can expose information in a generated answer. Check the audience and the data-handling rules with the guide to checking what an AI tool can do with your data before moving beyond the test folder.
Write down when to check the connection again
Keep a short record of the task, the approved folder, the connection owner, the permitted actions, and the results of the boundary tests. Name who can revoke the connection. Repeat the tests if the assistant gains a new tool, the folder is moved, or the connection is assigned to a different account. When someone asks to add another capability, start with the task and update the written scope before granting the permission. The record gives the next owner a clear way to compare the intended setup with the permissions they actually find.
Sources
NIST definition of least privilege · OWASP guidance on excessive agency