Permissions for AI Agents: How to Limit Tools, Data, and Actions to What’s Necessary

An agent’s authority is not the system’s authority

An agent can interpret a request, choose tools, and chain operations together. That does not mean it should decide which resources it is authorized to view or modify. Effective authorization belongs to the systems that hold the data or carry out the actions: the repository, email service, API, or business platform. The model may propose an operation; the target system must check whether the requesting identity can perform it on that specific resource.

This distinction matters because an agent can make mistakes, receive deceptive instructions, or choose an unsuitable tool. Prompt instructions and rules that filter which tools are available can help guide behavior, but they should not be the only controls. If another path allows the same operation with a broadly privileged credential, the tool filter does not prevent access. Combine limits in the agent interface with identity and authorization controls enforced by connected tools and services.

The practical goal is not to make every kind of error impossible for the agent. It is to reduce what can happen if it misunderstands the task: limit the resources it can access, distinguish reading from changing data, minimize how long access lasts, and prevent a single credential from turning a mistake into a far-reaching action. The recommendations in this guide are design criteria; their specific implementation depends on each platform’s capabilities and permission model.

Inventory tasks, resources, and effects before granting access

Start by describing the tasks the agent must complete, rather than listing every connector that could be enabled. For each task, identify who requests it, what data it needs, which tool provides that data, and what result is expected. Then record the potential effect of each operation. Reading a document, editing it, sending a message, and deleting a record are different capabilities, even when they are available through the same service.

Separate a user’s own data from data shared by a team or organization. The distinction should also account for the specific resource: an agent that needs to read a project folder does not therefore need read access to the entire repository. Also identify whether the task acts on behalf of a person or as an autonomous application. On platforms that distinguish delegated permissions from application permissions, that difference affects which identity is represented and which limits apply.

Do not classify an operation only by the tool’s name. An “update” call could change a harmless field or alter a status that triggers downstream processes. Describe the observable effect and who might be affected. If the impact is unclear, do not assume the operation is low risk: narrow its scope and test its behavior in a controlled environment before enabling it in production.

Design least-privilege profiles for each task and user

With the inventory in hand, define a profile for each task. Specify which identity performs it, which tools it can invoke, which resources it can access, which actions it can take, and for how long. A profile such as “email access” is too imprecise. A useful profile might say that a task can read one person’s messages to prepare a summary, but cannot send, delete, or modify messages.

When users need to retain their own limits, delegated authorization may be more appropriate than an application credential with broad, independent access. Microsoft Graph documentation distinguishes delegated permissions, which are limited by what the user can do, from application permissions, which are granted to the application. This distinction does not remove the need to configure least-privilege permissions or, by itself, guarantee that every operation is properly scoped: verify which permissions the integration requests and what the system does with them.

In some environments, token exchange can provide credentials intended for a target resource or represent a delegation. The OAuth token exchange standard describes this mechanism, but its availability and specific constraints depend on the implementation. Do not present a temporary token as automatically safe: check its audience, subject, authorized actions, duration, and renewal conditions. If the environment does not support scoped credentials, document the limitation and compensate with target-side controls, separation of duties, and oversight.

Authorize each operation in the target system

A policy that limits available tools can reduce selection errors—for example, by showing the agent only an approved set of tools. However, that does not prove that a specific call is authorized. Amazon Bedrock AgentCore documentation describes tool allowlists and warns that this filter does not replace IAM permissions for other execution paths. In design terms, the agent’s tool filter and the resource’s policy are separate layers and should be reviewed separately.

At a minimum, the target system should check the effective identity, the requested action, and the affected resource. If authorization depends on the user, checking it once when a session is created and then blindly trusting the context is not enough. Define how identity is validated for each operation and what happens if permissions change while the task is running. Implementation depends on the platform, so do not assume every connector re-evaluates permissions in the same way.

Resource-based and identity-based policies can be combined with contextual rules. AWS documents resource-based policies for AgentCore that can express principals, actions, and conditions, and recommends granting only the permissions needed. Use this type of documentation to understand the evaluation model of the service you choose; do not copy a sample policy without checking which resource, principal, and action it affects in your deployment.

Separate preparation, approval, and execution for sensitive actions

Human approval is useful when an operation could send information to third parties, change shared data, delete content, or modify permissions. It should not be a generic “continue” button. Before deciding, the person needs to understand what operation will occur, which resource it affects, what data is involved, and what effect is expected. If the preview omits the recipient, the content to be sent, or the scope of the change, the approver cannot adequately assess the risk.

Approval should also be tied to the operation that was reviewed. If the destination, arguments, resource, or action changes after approval, request a new decision. Do not turn one-off approval into a general permission the agent can reuse for other tasks. The interface should make clear who is approving and on whose behalf the operation will run.

The OpenAI Agents SDK documentation describes a flow in which a sensitive tool call can be paused for review, with the tool and its arguments inspected before execution is resumed or rejected. This is an example of a review mechanism, not a guarantee that any operation is safe: the team still needs to decide which tools require a pause and whether the information shown to the approver is enough to judge the effect.

Limit access duration and verify that revocation works

Granting access for a specific session or task reduces the time a credential can be reused, provided the environment supports this approach. Define when authorization begins and ends, whether it can be renewed, and who can renew it. Do not confuse a short session with narrow scope: a short-lived credential that can delete all data still has potentially broad impact while it is active.

Design revocation as an operation that can be tested. Remove the permission or invalidate the credential, then make new requests using the same identity. Also check existing sessions, cached tokens, background jobs, and retries. The answer depends on the provider: some changes take effect immediately, while others may be subject to propagation delays or the lifetime of previously issued credentials. If the documentation does not clarify the behavior, record that uncertainty and test it in the relevant environment.

To reduce the risk of persistent access, assign separate credentials to agents, environments, and tasks where feasible, and avoid copying user secrets into prompts, histories, or logs. If delegation or token exchange is used, retain only the data needed to operate and audit. Revocation does not replace sound initial permission design; it is an additional safeguard for responding to staff changes, incidents, or completed tasks.

Log decisions and results without making logs another risk

A useful log makes it possible to reconstruct who requested a task, which identity was used, which tool was called, which resource was targeted, what decision the system made, and what the result was. Store request identifiers and timestamps sufficient to correlate events between the agent and the target service. Distinguish an attempted call, an authorization granted, and a completed operation: these are not the same event.

Do not store tokens, keys, passwords, or other secrets in logs or traces. Nor should you automatically store all content that was read or sent. Define what data is needed to investigate failures, how it is protected, who can access it, and how long it is retained. In some cases, logging the resource identifier and a summary of the operation type will be enough; in others, a preview with privacy controls may be necessary.

Use telemetry to detect patterns that merit review: repeated denials, attempts to access resources unrelated to the task, unexpected write calls, or use of a credential after revocation. An observed pattern does not by itself prove abuse; it is a signal to investigate in the context of the request and the policies in force.

Test the boundaries, including out-of-scope attempts

Before deployment, turn every granted permission into one positive test and several negative tests. The positive test demonstrates that the legitimate task works within the intended scope. Negative tests check that the same agent cannot switch users, access an unauthorized shared resource, use a write operation when it has only read access, delete records, or invoke a tool outside its intended purpose. Repeat the tests when connectors, roles, policies, or approval flows change.

Test both the agent interface and the target system. If the agent does not offer a prohibited tool, also verify that a direct call or alternative path cannot perform the action using the available credentials. Check that an approval does not authorize arguments different from those reviewed and that a revoked permission blocks later requests. For high-impact operations, use test data and resources that let you observe the effect without affecting real people or services.

A passing test does not prove that the system is safe in every circumstance. It shows that certain cases behaved as expected under a particular configuration. Retain the test identity, applied policy, steps, and result so you can repeat the check after an update. If a platform hides part of its permission evaluation or does not provide sufficient logs, record that as a limitation instead of assuming the control worked.

Control limits and mistakes to avoid

Permissions reduce the set of possible actions, but they do not guarantee that the agent will interpret a task correctly or produce an accurate response. Read permission can expose sensitive information if the authorized document set is too broad. A narrowly scoped write permission can still cause an incorrect change within its scope. That is why good design combines authorization, input validation, risk-proportionate review, and behavioral testing.

Avoid granting an administrative credential to simplify integration, relying on the prompt to prevent unwanted operations, or assuming that an allowlist of tools is a complete policy. Do not turn a user’s consent for one task into persistent authorization for others, either. Instructions and approvals guide the process; effective permission must remain limited in the identity and connected system.

This guide focuses on technical authority and how to constrain it. It differs from a guide to indirect prompt injection, which focuses on untrusted content that tries to direct the agent, and from a failure-recovery guide, which covers how to respond to errors and partial effects. These topics are related: a hostile instruction may try to trigger an unwanted action, while permissions and target-side controls determine which actions are actually possible.

Pre-deployment checklist and checks after changes

Review the permission model before enabling an agent, and repeat the review when a tool is added, a connector changes, the data set expands, or a policy is modified. The responsible person should be able to explain what task justifies each permission and what effect an incorrect call could have. If no legitimate use can be identified for a capability, disable it until that is clarified.

As an operational reference, check that the configuration separates reading, writing, sending, deleting, and access changes; limits access by user and resource; and does not rely exclusively on model instructions. Verify the approval process for sensitive operations, what information the approver sees, how decisions and results are logged, and how access is revoked. Run the negative cases described above using the identities and systems intended for production.

This checklist does not replace product security review or provider-specific documentation. It is a way to make assumptions visible when connecting tools. If the environment cannot enforce a necessary limit, record the gap, assess the risk, and change the task design or workflow before granting broad access.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.