AI Agent Permissions
Controls governing what actions, tools, files, and resources AI agents can access, enforcing the principle of least privilege in agentic AI systems.
Also known as: AI Agent Access Control, AI Permissions
Category: AI
Tags: ai, ai-agents, safety, governance
Explanation
AI agent permissions define the boundaries of what an AI agent can and cannot do: which tools it can call, which files it can read or write, which commands it can execute, and what level of human approval is required before taking action.
An AI agent with unrestricted access is a security risk. It can read sensitive files, execute destructive commands, push code to production, send messages, or exfiltrate data. The combination of hallucination, tool access, and autonomy becomes catastrophic without permission boundaries. This makes permission management one of the most critical aspects of AI safety in agentic systems.
## Permission models
Several permission patterns have emerged:
- **Allow once**: approve a specific tool call for a single invocation only
- **Allow always**: auto-approve a tool pattern for the session or permanently
- **Deny**: reject the tool call entirely
- **Restricted patterns**: allow specific command subsets (e.g., only git commands via Bash)
- **Tiered access**: different permission levels for different agents or contexts
More broadly, permission systems use allowlists (explicitly enumerating what the agent can do), denylists (blocking specific dangerous operations), approval workflows requiring human confirmation for high-risk actions, and role-based access control mapping permissions to agent roles.
## The Least Privilege Principle applied to AI
Every agent should have the minimum permissions needed to do its job. A code review agent does not need write access. A search agent does not need shell access. A drafting agent does not need to publish. Applying least privilege to AI agents is essential but challenging because most tool interfaces are all-or-nothing.
## Challenges
- **Granularity**: "can use Bash" is too broad; "can use Bash but only for git commands" is closer to right
- **Context-dependent permissions**: the same agent might need different permissions for different tasks
- **Permission fatigue**: too many approval prompts train users to click "allow always" for everything
- **Transitive access**: if agent A can spawn agent B, agent B may inherit A's permissions unless explicitly restricted
- **Runtime skill loading**: a skill loaded at runtime can request tools the user did not anticipate, creating supply chain security concerns
Related Concepts
← Back to all concepts