Give an AI agent only the tools, data, and actions required for one written job. Use a separate identity, restrict it to named resources, keep consequential actions behind approval, record what it does, and test how to revoke access. Start with reading, add draft creation, then allow narrow writes only when the workflow proves it needs them.
Why do AI agent permissions need special attention?
An AI agent can choose and chain actions across several systems, so one broad connection can create more authority than the task requires. A support assistant that reads an inbox, searches shared files, updates the CRM, and sends email has the combined reach of all four integrations. Its effective permissions matter more than any single checkbox.
The inputs can also be untrusted. An email, document, web page, or customer message may contain instructions that conflict with the agent's job. A prompt that says “never send confidential data” guides behavior, but it does not stop an email tool whose credential can send any attachment to any address.
OWASP describes excessive agency as a combination of excessive functionality, permissions, or autonomy. Its guidance separates the controls: remove tools the agent does not need, narrow what each tool can do, limit the permissions used by that tool, and require approval for high-impact actions. The system that performs the action should enforce the rule instead of asking the model to decide whether it is authorized.
Treat instructions, permissions, and approvals as three different layers:
- Instructions describe the task and expected behavior.
- Permissions determine what the connected systems will technically allow.
- Approvals let an accountable person authorize a specific consequential action.
A reliable design uses all three where the consequence requires them. A polite refusal in a test chat is not proof that the underlying permission is contained.
What belongs in an AI agent permission contract?
Write a permission contract before connecting the first production account. This can be one page. Its purpose is to make the agent's real authority visible to the business owner and the person configuring the tools.
| Contract field | Question to answer | Small-business example |
|---|---|---|
| Job | What result may the agent produce? | Prepare a client onboarding record after a signed agreement |
| Trigger | Who or what may start the work? | A verified contract-status event, not any incoming email |
| Identity | Which dedicated account performs the action? | `onboarding-agent`, owned by the business |
| Systems | Which tools may it reach? | CRM, intake form, and project tool only |
| Data | Which fields or folders may it read? | Signed scope, primary contacts, service tier, and start date |
| Actions | Which verbs are allowed? | Read agreement status, create a draft project, add named tasks |
| Resource scope | Which records or destinations are in bounds? | The matched client account and one approved project template |
| Limits | Which amounts, counts, recipients, or states constrain the action? | One project per contract ID; no external invite before approval |
| Approval | Which exact actions wait for a person? | Sending the welcome email and inviting client users |
| Evidence | What must the log retain? | Trigger ID, source record, proposed actions, approver, result, and error |
| Duration | How long does access or elevation last? | Standing read access; write access only during an approved run |
| Revocation and owner | Who can stop it, and what must be disabled? | Operations owner can disable the identity, integration, queued jobs, and tokens |
The example is illustrative, not a documented client system. Its value is the separation between a broad goal such as “handle onboarding” and the limited actions actually required. If the project tool exposes only an administrator connection, the contract reveals a mismatch before the agent inherits that access.
Microsoft's least-privilege guidance for AI agents recommends a dedicated identity with a named owner, task-scoped access, reviewed aggregate permissions, explicit tool controls, useful audit fields, and a tested revocation path. It also recommends separating read and write roles where an agent both gathers evidence and updates a system.
Which permission level fits the job?
Choose the lowest level that can complete the current workflow. The agent does not need every permission it may need later. Add access when a tested task requires it, not when an integration asks for it by default.
| Permission level | Appropriate use | Boundary | Evidence before moving up |
|---|---|---|---|
| Read only | Search approved records, summarize, classify, or flag missing data | Named sources and fields; no update, export, or send capability | Retrieved records stay in scope and sensitive fields remain excluded |
| Draft | Prepare a reply, task list, CRM change, or project for review | Draft destination only; no external effect | Reviewers can see sources, changes, and unsupported assumptions |
| Narrow action | Update an allowed field or create a bounded record | Specific action, resource, state, count, recipient, and retry rule | Authorized and rejected cases behave correctly; duplicates are prevented |
| Approval-gated action | Send, publish, issue a bounded refund, or change a customer-facing state | Approval tied to the exact action, target, values, and expiration | The approved action cannot be changed or replayed without a new decision |
Broad autonomous administration is not a useful production starting point. An agent that can manage users, change permissions, export all records, delete data, or run arbitrary commands has a large blast radius even if its assigned task is narrow.
Read-only access is not risk-free. An agent may still expose sensitive information, combine data that employees usually see separately, or send a summary to the wrong destination. Limit the records and fields as well as the write actions. A CRM connection that can read every customer is broader than a workflow that needs one matched account.
Draft mode is often the most useful intermediate step for a small team. The agent can assemble the work while a person verifies the source, recipient, and proposed change. The review also produces examples for testing a later narrow action.
Where should permission limits be enforced?
Enforce permission limits at the point where the action reaches the tool or business system. The model can propose “update this CRM record,” but the CRM role, API, integration wrapper, or policy layer must verify the identity, action, record, fields, and current state before accepting the update.
A tool name is too coarse. Allowing `send_email` does not answer which sender, recipient, domain, attachment, template, or volume is permitted. Allowing `update_crm` does not answer which account, fields, pipeline stage, or number of records may change. The permission contract needs to reach those parameters when the consequence depends on them.
Use a dedicated agent identity when the platform supports one. Avoid connecting the owner's administrator account merely because it is convenient during setup. A separate identity makes the access review, logs, suspension, and offboarding clearer. If the agent acts for a specific employee, preserve both the agent identity and the authorizing user's context instead of collapsing them into one shared credential.
Check authorization again when the action runs. The record may have changed, the user may have lost access, the approval may have expired, or the agent may be operating in the wrong customer account. A decision made at login does not automatically authorize every later tool call.
Permissions should fail closed for consequential actions. If the authorization service, approval record, or resource check is unavailable, hold the action in an exception queue. Do not interpret a timeout as permission to continue.
Which AI agent actions should require human approval?
Require approval when a mistake creates a meaningful external commitment, data exposure, financial effect, loss, or access change that is difficult to reverse. The exact list depends on the business, but the consequence provides a better rule than the model's confidence.
Common approval candidates include:
- sending or publishing customer-facing content;
- paying, refunding, purchasing, or changing billing details;
- deleting records, accounts, backups, or production resources;
- creating, revealing, rotating, or revoking credentials;
- changing user roles, sharing settings, or security configuration;
- exporting sensitive data or sending it to a new recipient;
- accepting legal terms or making a regulated decision;
- running broad commands against production systems.
Approval must describe the actual action. Show the recipient, resource, fields, amount, message, and expected side effect. Bind the decision to those values and an expiration. If the agent changes the recipient or amount after approval, the old approval no longer applies.
Approval also needs a sensible interface. A stream of vague “Allow?” prompts trains people to click through. Group low-consequence work inside enforced limits, and interrupt a person only when the action crosses a meaningful boundary. My guide to placing human approval in an AI workflow covers the review step in more detail. Permissions remain necessary because an approval screen cannot contain actions the tool is already free to perform another way.
How should you test AI agent permissions?
Test the boundary with allowed, denied, expired, repeated, and manipulated requests before enabling real side effects. A successful normal case proves only that the agent can work. Permission testing must also prove that it cannot step outside the contract.
- Confirm the allowed path. Run one realistic case and verify the identity, source records, action, destination, log, and final business result.
- Try a neighboring resource. Ask for another customer, folder, project, mailbox, or tenant that should be outside scope. The tool must reject it.
- Try a broader action. Request export, delete, send, permission change, bulk update, or an unapproved field. Confirm that the capability is unavailable or blocked downstream.
- Use untrusted content. Place a conflicting instruction in a test email or document. Verify that it cannot widen the data scope, select a forbidden tool, or choose an external destination.
- Modify an approved action. Change the recipient, amount, record, attachment, or message after approval. The altered action should require a new decision.
- Repeat and interrupt the run. Retry after a timeout or partial completion. Confirm that the workflow does not duplicate an external action or bypass the permission check.
- Expire and revoke access. Disable the agent, remove the role, invalidate the token, and stop queued work. Confirm that the next action fails and that the team can continue manually.
- Review the evidence. The log should identify who triggered the work, which agent and permission acted, the resource, proposed and completed actions, approval, outcome, and error without copying unnecessary sensitive content.
Retest after adding a tool, changing a role, expanding a data source, moving to production, or changing who can trigger the agent. Review the combined reach across systems. Several narrow roles can become broad when the agent can chain them.
How should a small business expand agent access?
Expand access in stages tied to an operational need and test evidence. A useful sequence is task definition, read-only access, draft creation, one narrow action, then a decision to retain, restrict, or extend the workflow.
A staged permission path
- Define the job
- Read approved data
- Prepare drafts
- Perform one narrow action
- Review or stop
At each stage, record which manual step remains, what errors reviewers correct, which data the agent actually uses, and whether the business outcome is observable. Remove unused tools and fields instead of leaving them connected for a possible future feature.
Do not turn every successful pilot into permanent standing access. Elevated permission can be issued for a bounded task or time window and removed afterward. The owner should be able to answer which agents exist, what each one can reach, who is responsible, and when its access was last reviewed.
Connect this access review to ongoing operations. The permissions belong in the runbook alongside monitoring, incident handling, and change control. The article on maintaining workflow automation after launch explains how to assign owners, preserve a manual fallback, reconcile partial work, and test changes before resuming.
When not to connect the agent
Keep the agent in a disconnected or draft-only mode when the provider offers only an administrator credential, the business cannot restrict records or actions to the task, logs do not show the resulting tool actions, revocation cannot be tested, or the team has no safe way to stop and complete the work manually. Use a narrower integration, a purpose-built tool wrapper, or conventional automation instead.
What to remember
- Define one job before granting access, then review the agent's combined reach across every connected system.
- Separate instructions, technical permissions, and human approvals.
- Scope identity, data, action, resource, parameters, duration, and revocation, not only the tool name.
- Start with read access, use drafts to learn, and allow narrow writes only after testing both allowed and denied cases.
- Keep high-impact actions blocked or tied to a specific, expiring approval, and test the kill switch before launch.
If you are considering an agent, bring one task, the systems it would touch, and the actions you want it to take to a free 30-minute call. We can turn them into a permission contract, identify where approval belongs, and decide whether an agent, conventional automation, or a smaller integration is the reliable first step.
Frequently asked questions
It may be technically possible, but a dedicated agent identity is easier to scope, audit, suspend, and remove. If the agent must act for a user, preserve both identities and enforce the user's current authorization instead of giving the agent the employee's full standing access.
Read-only access prevents direct edits, but it can still expose or combine sensitive information. Limit the folders, records, fields, users, destinations, and retention, then test requests for data outside that scope.
No. Prompt rules guide model behavior, but the tool or downstream system must reject unauthorized actions. A conflicting email, document, model error, or alternate execution path should still meet an enforceable permission boundary.
Review them whenever the task, owner, tools, data scope, environment, or available actions change, and after an incident. Also schedule a proportionate check for unused access, expired needs, aggregate permissions, and a working revocation path.
Written by Antoine mazu. Antoine helps small service businesses understand and improve their workflows with solutions tailored to their needs, with or without AI. He combines product thinking with hands-on technical execution from Bayonne, France.
Sources accessed September 22, 2026: Microsoft, Least privilege for AI agents, OWASP, LLM06:2025 Excessive Agency, ClawBud, What permissions should an AI agent have?, Kontext, AI Agent Tool Permissions, TrueFoundry, AI Agent Access Control, Arcjet, Least privilege for AI agent tool calls, and Zenphi, Managing Agent Access & Permission Trimming.
