An AI assistant that summarizes a document is useful. An AI agent that can open the document, search connected drives, run a script, update a record, and send the result is something different.
When an agent can choose tools and carry out a sequence of steps; vague instructions, manipulated inputs, stolen tokens, or bad model decisions can become a real action at machine speed.
Security hinges on every agent having minimum reach and freedom required for its specified use.
AI agent permissions are more than access rights
Traditional least privilege asks what a user or application can access. That remains essential for agents, but it is only part of the control problem.
An agent may legitimately have permission to, for example, send an email or query a database. The follow-up question should be whether it will be able to use that permission on any target without a human checkpoint.
That is the distinction between least privilege and least agency. Least privilege limits reach and least agency limits autonomy. Together, they reduce the broader risk of giving an agent more freedom than its task requires.
This matters because agentic systems are nondeterministic. They interpret goals, select tools, and adapt their steps. Input filtering and model safeguards are valuable, but neither should be the final security boundary. Controls outside the model must determine which proposed actions can become real actions.
The five permission boundaries every AI agent needs
A useful agent permission model should answer five questions. If one is left undefined, the agent's effective scope may be much broader than its job description suggests.
1. Which identity does the agent use?
Give each agent an identity tied to one defined workflow. Avoid shared service accounts and never connect with an agent through a highly privileged administrator account simply because deployment is easier.
The identity should make attribution possible and carry only the rights needed for the task. A support-ticket summarizer may need read access to selected ticket fields. It does not need access to HR records, finance systems, or the ability to change identity settings.
2. Which data can it read or change?
Separate read, create, modify, and delete permissions. Scope access to specific repositories, folders, databases, tables, and record types wherever possible. Then define whether sensitive classes of data—customer information, credentials, source code, financial records, regulated data, or intellectual property—are in or out of bounds.
A useful default is a dedicated working directory or data set rather than broad access to a user's entire drive. If an agent only needs a copy of selected records, provide the copy instead of the source repository.
3. Which tools and processes can it invoke?
Access to data is not the same as permission to act on it. Agents may spawn shells, scripting engines, package managers, browsers, local servers, command-line utilities, plugins, or MCP servers. Each one expands what the agent can do.
Allow only the executables and integrations the approved workflow requires. A document agent should not be able to launch PowerShell because a connector happens to expose that option. An abandoned plugin should not remain reachable. MCP integrations should be treated as new trust relationships, because each may expose additional data and actions.
4. Where can it communicate?
Define allowed and protocols. An agent may need to reach a model provider, a source code platform, and one internal API; that does not justify unrestricted internet or lateral network access.
Egress controls matter because an attacker does not need the agent to execute malware if the agent can already collect sensitive information and send it to an unapproved destination using legitimate tools.
5. Which actions require approval?
Some permissions are necessary but too consequential for unattended use. Establish approval gates for actions that are irreversible, externally visible, high-volume, privileged, or costly.
- Sending external messages, publishing content, or contacting many recipients
- Deleting or overwriting files, records, repositories, or backups
- Changing permissions, security settings, or production configurations
- Executing code in production or installing new software
- Moving money, making purchases, or entering contractual commitments
- Exporting sensitive data or transmitting it outside approved boundaries
Approval should be meaningful and specific. Avoid generic prompts asking whether the agent may continue.
A practical way to classify agent actions
Not every action needs the same friction. Organizations can use a simple three-tier model:
The higher the potential impact, the narrower the scope and the stronger the approval requirement should be. An agent may act autonomously when the action is reversible, low impact, well observed, and tightly constrained. It should stop and ask when those conditions do not hold.
How to deploy agent permissions without blocking productivity
Security teams do not need to predict the perfect policy before an agent is tested. They do need a controlled path from observation to enforcement.
- Define the job: Write a narrow purpose statement, owner, data scope, tools, destinations, and expected actions for each agent.
- Start with no standing administrative privilege: Use dedicated identities and temporary elevation only when a justified workflow requires it.
- Test in an isolated or Monitor Only environment: Observe the files, processes, child applications, integrations, and network destinations the agent actually uses.
- Remove unused capabilities: Convert discovered behavior into explicit allow rules and eliminate tools or permissions that never support the defined job.
- Add approval gates: Require human review for high-impact actions, unusual volume, scope changes, and exceptions.
- Enforce the policy: Move from observation to secured operation once the required behavior is understood.
- Review continuously: Reassess permissions when the model, connector, workflow, data source, or business owner changes.
Enforce the boundary outside the model
Governance needs technical enforcement to avoid gaps in policy. ThreatLocker helps organizations apply Zero Trust controls wherever agents operate.
Application Allowlisting controls which AI tools, scripts, executables, and child processes are permitted to run.
Ringfencing™ limits what approved applications can access and which other applications or internet destinations they can interact with.
Privileged Access Management removes standing administrative rights and permits elevation only when required and approved.
Data Storage Access Control restricts access to sensitive files and storage locations.
Zero Trust Endpoint Firewall, Zero Trust Network Access, and Zero Trust Cloud Access limit communication to approved systems, services, and trusted devices.
Web Content Control helps govern access to public AI tools and unauthorized web resources.
These layers turn an agent's written job description into enforceable boundaries around execution, data, privileges, and communications. The model can still make a poor decision, but the environment decides whether that decision is allowed to become an action.
The goal is bounded autonomy
Agents need a clearly defined job to be useful. Provide the minimum resources required to complete it, and reliable checkpoints when the consequences exceed that job.
Even when an agent is compromised, least agency limits unnecessary autonomy. Zero Trust provides enforcement that keeps both boundaries intact.
