An AI agent that summarizes customer emails and an AI agent that sends customer emails may look nearly identical in a demo. Their security implications are very different.
Consider a hypothetical sales assistant connected to a shared mailbox and customer database. Its job is to prepare a morning briefing. If it inherits a salesperson’s full access, it might also be able to send messages, export contacts or change account records. None of those capabilities is necessary to produce the briefing.
The governing principle is straightforward: Give an AI agent the access its task requires—not the access its human operator happens to have. The challenge is translating that principle into enforceable controls before convenience becomes an operational dependency.
Why Agent Permissions Need Their Own Security Review
Agents connect reasoning to action. They can retrieve information, choose tools and execute operations across systems. That makes three questions essential: What functions are available? What resources can those functions reach? How much can happen without human approval?
OWASP’s guidance on excessive agency distinguishes excessive functionality, permissions and autonomy. Removing an unnecessary tool addresses functionality. Restricting that tool to specific records addresses permissions. Requiring approval before execution addresses autonomy. These controls complement one another; none replaces the others.
Written instructions are not access controls. “Never send confidential information” is guidance—not a technical barrier preventing disclosure.
Authorization belongs in the connected application, tool gateway and execution environment. The model should operate inside those boundaries, not decide whether they apply.
Use the following checklist as a deployment review, not a certification standard. Mark each item complete only when the control has been documented and tested.
Before Connecting Company Data
1. Define the job and its boundaries
Describe the authorized task in operational terms. “Help finance” is too broad. “Read invoices in the approved intake folder and draft a weekly exceptions report” is specific enough to evaluate.
- Systems: Which applications and tools are necessary?
- Resources: Which folders, mailboxes, repositories or customer records are in scope?
- Operations: Must the agent read, draft, send, update, delete or administer?
- Inputs: Will it encounter external websites, attachments or messages?
NIST’s work on tool-use agent systems provides a useful framework for distinguishing tools, data access and interactions with an environment. Make those distinctions before selecting permissions.
2. Give the agent an accountable identity
Use a distinguishable agent identity or narrowly scoped delegated session where supported. Record the responsible human owner and, when applicable, the user on whose behalf the agent acts. Avoid shared administrator credentials that obscure who initiated an action.
NIST’s concept paper on software and AI agent identity and authorization highlights identification, delegation and action-level accountability. It is a concept paper, not a finalized compliance requirement. The practical objective is to connect each action to an identifiable agent, authorized purpose and accountable owner.
3. Start narrow and read-only
Grant access to the smallest useful dataset. A document-summary agent may need one project folder, not the entire company drive. A support assistant may need assigned cases, not every customer record.
Separate retrieval from modification. Do not grant sending, deletion or administration privileges merely because the connector offers them.
Read-only does not mean risk-free. An agent that reads sensitive information may expose it through responses, logs or another connected tool. Review both what it can retrieve and where its outputs can go.
Before Enabling Actions
4. Enforce authorization on every tool request
The downstream service or trusted gateway should check the actual identity, requested resource and proposed operation on every request. An agent’s statement that an action is authorized is not evidence of authorization.
In a hypothetical customer-service deployment, an agent permitted to update assigned cases should be denied access to another team’s cases—even if it supplies a valid record identifier. Restrict tool arguments and resource scope; do not rely on the interface hiding unauthorized options.
A trusted connector can still return untrusted content. Instructions embedded in an email or document must not gain authority simply because they arrived through an approved integration.
5. Put approval at the point of consequence
Require human review for actions whose consequences justify it: sending sensitive information, changing payment details, deleting records, publishing content or modifying production systems.
The approval screen should show:
- The exact recipient, destination or resource.
- The proposed message, change or operation.
- The relevant tool arguments and affected data.
Bind approval to that specific action. If the recipient or payload changes, require another review. A blanket “Allow this agent?” prompt is not meaningful approval of future transactions.
OpenAI’s guardrails and approvals guidance places validation near consequential tools. It also cautions that agent-level input/output guardrails do not cover every tool-execution boundary. Verify your implementation rather than assuming a general safety setting protects every action.
6. Contain files, credentials and network access
Limit accessible directories, execution privileges and outbound connections. A coding agent working on one repository should not automatically reach unrelated source code, local credential stores or production infrastructure.
Where the architecture supports it, keep credentials outside the agent’s execution environment. Use a controlled broker or gateway to provide scoped, short-lived access instead of exposing reusable secrets to the model or its workspace.
Containment is an independent boundary: even when the agent follows malicious instructions, its reachable resources should remain limited.
7. Review destinations—not just allowed domains
A domain allowlist answers where traffic may go, but not necessarily whose account receives it or which operation occurs there.
Anthropic’s containment analysis describes a case where an allowed API domain still enabled uploads into an attacker-controlled account. Review destination accounts, tenants, endpoints and permitted operations—not just hostnames.
For example, allowing uploads to an approved storage provider should not mean allowing uploads to every account hosted by that provider. Wherever possible, constrain both the destination and the action.
Before Launch—and After Every Material Change
8. Test hostile content and failed controls
Use synthetic data to test whether boundaries hold under pressure. Include malicious instructions inside documents, emails and tool results. Test attempts to access out-of-scope records and perform unauthorized operations.
Also test dependency failures. What happens when the approval service is unavailable or a tool retries a request? If an action requires approval, the absence of approval must block execution. It must not silently become permission.
A useful hypothetical test is a document instructing a summarization agent to send the source material to an external address. Passing means the system prevents the unauthorized action—not merely that the agent usually refuses.
9. Log decisions and limit damage
Record the agent identity, relevant human context, requested operation, authorization decision, approval decision and execution outcome. Preserve enough detail to reconstruct events without unnecessarily copying secrets or sensitive records into logs.
Apply limits to consequential tools: transaction ceilings, recipient caps, export limits and request rates appropriate to the task. Alert on unusual destinations, repeated denials and unexpected bulk activity.
These controls do not make an unauthorized action acceptable. They reduce the damage a compromised or malfunctioning workflow can cause before someone intervenes.
10. Prove you can revoke access
Test shutdown before deployment. Revoke the agent’s session or token, then verify that subsequent tool requests are denied. Check queued work, scheduled runs and alternative credentials rather than assuming a dashboard’s stop button removes every access path.
Document what happens to operations already in progress; revocation does not undo completed actions. Repeat the review after adding connectors, expanding datasets, changing credentials or enabling new capabilities. A small integration change can materially expand authority.
Create a Permission Record Before Deployment
Keep a short record that business owners and technical reviewers can both understand:
- Owner and purpose: Who is accountable, and what task is authorized?
- Data scope: Which records, folders and accounts are accessible?
- Allowed actions: What may the agent read, draft, send, update, delete or administer?
- Approval boundary: Which exact actions require review, and by whom?
- Containment: Which files, credentials and destinations are reachable?
- Shutdown evidence: How was access termination tested and verified?
Attach the relevant configuration and test results. A written permission record is useful only when the deployed controls match it.
Expand Access Only When You Can Explain It
Start with one bounded workflow. Demonstrate useful results with narrow permissions, then add capabilities only when a documented business need justifies the additional risk.
Before connecting your next agent, have its business owner and technical owner complete this checklist together. If the owner cannot explain the agent’s scope, approval boundary and shutdown procedure, postpone broader access. That is not a rejection of automation. It is the discipline that makes dependable automation possible.