Give an AI agent only the tools, data, and authority it needs for its assigned task. Keep access controls in the connected system or a trusted execution layer—not in the model’s judgment—and require verified approval before high-impact or hard-to-reverse actions. Least privilege limits the harm an agent can cause if it is misled, makes a mistake, or misuses a tool; it does not prevent those failures.
Start with the task, not the tool
Write down what the agent is supposed to accomplish, then identify the specific actions and information required. Grant those capabilities—and no broader ones. An agent asked to read a repository does not need permission to edit or delete files. An agent asked to summarize a document does not automatically need permission to send email, browse unrelated accounts, or run arbitrary commands.
As an Amazon Associate I earn from qualifying purchases.
There is no universal list of permission names or OAuth scopes that fits every provider. Tools differ in how precisely they can restrict access to resources, records, and fields. Treat least privilege as a design method: map the task to the smallest enforceable set of capabilities in your own system.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Use this checklist before enabling an agent
- Define the task and boundaries. Record the intended outcome, permitted resources, and actions the agent must not take.
- Remove tools the task does not require. Prefer a narrow operation over a broad shell, generic command runner, or unrestricted URL-fetch tool when a specific function will do. Disable unused extensions and connectors.
- Separate capabilities. Where the system allows it, distinguish read, create, update, delete, send, and administrative actions. Restrict access to particular resources, records, or fields rather than granting account-wide access.
- Choose a limited identity. Use an appropriately scoped identity for each agent or user-authorized session. Avoid a shared administrator account that can reach unrelated users’ data. Where possible, make the agent act within the requesting user’s own authorized scope.
- Enforce authorization outside the model. Have the connected service or trusted execution layer check the actor’s authorization for every action. A model-generated explanation, prompt instruction, or apparent confidence is not an access-control decision.
- Classify actions by impact. Allow routine, low-risk reads within the approved scope. Require explicit human review before high-impact or difficult-to-reverse operations, such as sending externally, deleting data, moving funds, changing privileges, or deploying to production.
- Bind approval to the real action. Approval should identify the actor, tool, target resource, and exact normalized parameters. Make it short-lived and, where relevant, protect against replay. The execution component must independently verify that the approval still applies before acting.
- Minimize and protect data. Send only the information needed for the task into prompts or persistent memory. Isolate users and sessions, keep credentials out of model-visible text, and redact sensitive information from logs.
- Set operational limits and monitoring. Log tool calls and material context changes, monitor for unexpected use, and constrain calls, retries, spending, and chained actions. These controls help detect or contain misuse; they do not replace authorization.
- Test and revisit the boundary. Test allowed and denied actions, unexpected arguments, indirect prompt injection, approval bypasses, and failures of policy or approval services. Reassess permissions whenever the task, connector, tool, data source, or downstream service changes.
When should an agent have read-only access?
Read-only access is a good starting point when the task is to inspect, search, summarize, or recommend. It prevents many mutations, but it is not automatically harmless: reading broadly can expose sensitive data, and retrieved content can influence later tool use. Limit read access to the resources and fields needed, and do not let a read-only task silently inherit unrelated capabilities through another connected tool.
If the task genuinely requires changes, grant only the needed mutation—such as creating a draft rather than sending it, or updating one specified record rather than editing an entire workspace. Keep delete, administrative, and externally visible actions separately controlled where the system supports that separation.
When should an AI agent ask before acting?
Require human approval when an action has significant external, financial, administrative, destructive, or hard-to-reverse consequences. Examples include sending a message to another person, deleting records, moving money, changing access rights, or deploying a change to production. An agent may prepare the action or show a proposed change, but execution should wait for approval tied to that precise action.
Do not treat an approval button or confirmation prompt as the security boundary by itself. The system that executes the action should verify the user’s authority, the exact target and parameters, and the approval’s validity. If a required authorization, approval check, or audit control fails, block high-impact execution rather than proceeding on a best guess.
How to handle instructions found in emails, webpages, and documents
External content can contain direct or indirect prompt injection: text intended to persuade an agent to misuse its tools or exceed the user’s request. Treat retrieved messages, pages, and documents as untrusted input, even when they appear relevant to the task.
- Compare each proposed action with the user’s original request, not merely with instructions found in retrieved content.
- Validate tool arguments and enforce the same authorization checks regardless of where an instruction originated.
- Do not let untrusted content grant new tools, broaden scopes, or bypass an approval requirement.
Compare permission designs across six dimensions
| Dimension | Safer design question |
|---|---|
| Functionality | Can a narrow operation replace an open-ended tool? |
| Scope | Can access be limited by resource, record, or field? |
| Identity | Can the agent use a per-user or per-agent identity instead of a shared privileged account? |
| Write impact | Does the task need only reading, or does it require mutation or an external effect? |
| Autonomy | Can the action run automatically, or should it be approval-gated? |
| Observability and recovery | Can you audit the action, limit its rate, interrupt it, and recover or roll back where possible? |
These dimensions help expose three different forms of excess: functionality the task does not need, permissions broader than the task requires, and autonomy that is too high for the action’s impact. A narrow tool description alone is not enough if its service account still has broad downstream privileges.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to test before deployment
- Confirm that required actions succeed and unnecessary reads, writes, deletes, and administrative actions are denied.
- Try unexpected or malformed tool arguments and requests that target resources outside the approved scope.
- Include documents or messages with instructions that conflict with the user’s task, and verify that the agent does not treat them as authorization.
- Check that approval cannot be reused for a different actor, target, or set of parameters.
- Simulate unavailable authorization, approval-verification, and required audit services; high-impact actions should fail closed.
- Review logs, call limits, interruption controls, and recovery options, then repeat these checks after connector or policy changes.
Permission surfaces can change as tools and connectors evolve, including in Model Context Protocol deployments. Recheck scopes after changes rather than assuming a previously safe configuration remains appropriate.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
