The Most Requested AI Agent Permissions (and How to Scope Them)

Every time you install an agent skill, connect an MCP server, or grant an AI agent access to a SaaS account, you are answering a permission request. And the requests are strikingly consistent. Across coding agents, chat assistants, MCP servers, and skills, the same handful of permissions come up again and again: read and write files, run commands, reach the network, connect to email and calendars and repositories, read secrets, drive a browser. This guide is an explainer of those permission types - why agents ask for each one, the risk each one carries, and how to scope it down to least privilege. It is not a data report; it names no adoption percentages, because the useful thing is not how many agents request shell access but what to do when one does.

The reason permissions deserve their own guide is that an AI agent is not a static program with predictable behavior. It selects actions dynamically based on natural-language input, and that input can be untrusted - a document it reads, a web page it fetches, a message in a channel. So a permission granted to an agent is not just a capability the agent uses on your behalf; it is a capability an attacker may be able to steer. Whatever the agent can reach, a manipulated agent can reach. That is why scoping matters more here than it does for ordinary software, and why the framing throughout is least privilege. For the identity context behind all of this, see AI identity security explained.

The one rule under every recommendation

Before the individual permissions, the principle that governs all of them. Least privilege for an AI agent means granting each identity only the scopes a specific task needs, for the minimum time, in the tightest context, and denying by default. The stronger framing that agents force is to treat each agent session as an untrusted principal: because the session can be steered mid-task, its credentials should be scoped to the task in front of it and should not persist. Every scoping recommendation below is a specific application of that one rule. The full argument is in least privilege for AI agents and AI access control and least privilege.

Filesystem read and write

Agents request filesystem access constantly, because so much work is file work - read a codebase, edit a config, generate a document, parse a log. The distinction that matters is read versus write, and the scope that matters is which directories. Read access to a broad path is a data-exposure risk: an agent that can read the home directory can read SSH keys, cloud credentials, and browser data. Write access is worse, because it can modify code, configuration, or startup files, which is a persistence and tampering vector.

Scope it: confine filesystem access to the specific project or working directory the task needs, never the home folder or the root. Prefer read-only where writes are not required. Deny access to credential and configuration paths explicitly. A filesystem grant should read like a task boundary, not a blanket.

Shell and command execution

This is the broadest permission an agent can hold. An open shell is not one capability; it is every capability the operating system account has - install software, read any file, reach the network, modify the system. Coding agents and CLI tools legitimately need to run commands, which is exactly why this grant is so common and so dangerous. OWASP's guidance on Excessive Agency (LLM06) names open-ended functionality like an unrestricted shell as a primary thing to avoid, because it hands a manipulated agent unlimited local reach.

Scope it: prefer a constrained, explicit set of commands over an open shell. Run execution in a sandbox or isolated environment so the blast radius is bounded regardless of what the agent tries. Require human approval, enforced from outside the agent, for high-impact actions. And never let an agent run commands that could modify its own permissions or guardrails. The specifics for coding tools are in securing AI coding agents and CLIs.

Network and egress access

Agents ask for network access to fetch documentation, call APIs, download dependencies, and reach MCP servers. The risk is not inbound; it is egress - the ability to send data out. Outbound network access is the channel through which stolen data leaves and through which a manipulated agent contacts an attacker-controlled endpoint. It is also how untrusted external content enters the agent's context in the first place, opening the door to indirect prompt injection, which we cover in indirect prompt injection explained.

Scope it: allowlist destinations rather than permitting open egress. Where a task does not need to reach the internet, deny egress entirely - this single restriction can break the exfiltration chain architecturally. Treat any content the agent fetches as untrusted input, not as trusted instructions.

OAuth scopes into SaaS applications

This is where agents reach the data that actually matters: email, calendars, source repositories, cloud drives, chat, ticketing, CRM. Each connection is an OAuth grant, and the scopes on that grant define everything the agent can do in that application. This is the category where over-privilege is most common and least noticed, because it is easy to accept a broad scope during setup and never revisit it. An agent granted send-email scope when it only needs to read is a phishing tool waiting for a bad prompt; an agent with write access to a drive when it only needs to read is a data-tampering risk.

Scope it: grant the narrowest scope per application, prefer read over write, and scope to specific resources where the provider allows it. Use short-lived tokens rather than long-lived grants, and map every connected account as its own blast radius. Because these connections reach sensitive corporate data, they are exactly where the exposure gap in DLP for AI agents shows up.

Secrets access

Agents need credentials to do their jobs - an API key to call a service, a token to reach a database. The failure mode is standing, long-lived secrets sitting where the agent can read them freely: in environment variables, in config files, in the prompt itself. Any of those becomes an open-ended liability the moment the agent is compromised or steered, because a stolen static secret works indefinitely and often silently.

Scope it: issue short-lived, narrowly scoped credentials just-in-time for each operation rather than granting standing secrets. Store secrets in a managed secret store, not in plaintext the agent can browse. Redact secrets from anything the agent logs or transmits. The full pattern set is in secrets management for AI agents, and the identity plumbing behind it is in non-human identity governance.

Browser control

Browser-driving agents and MCP servers request control of a real browser to navigate, click, fill forms, and read pages. This grant is deceptively broad: a browser can reach any site the machine can, it often inherits logged-in sessions, and it pulls untrusted web content directly into the agent's decision loop. That is the combination of external reach plus untrusted input that makes browser agents a distinct risk surface, covered in securing computer use and browser agents.

Scope it: restrict which sites the browser can reach, avoid letting it inherit sensitive authenticated sessions, and treat page content as untrusted. Require confirmation for actions that submit data or move money. A browser grant should be as bounded as a network grant, because in effect it is one.

The permissions at a glance

The table below summarizes why agents request each permission and the least-privilege guidance for it. The same guidance applies whether the requester is an AI agent, an MCP server, or an agent skill, because all three run with the agent's authority.

Why the combination is the real risk

Individual permissions are manageable; the danger is in the combination. Simon Willison's lethal trifecta, described in June 2025, captures it: data exfiltration becomes near-guaranteed when an agent simultaneously has access to private data, exposure to untrusted content, and the ability to communicate externally. Map that onto permissions and it is filesystem or SaaS read (private data), network fetch or browser (untrusted content), and network egress (external communication) held at once. The practical upshot is powerful: you only have to remove one leg to break the chain. Deny egress and no amount of injection in the fetched content can send data out. That is what makes permission scoping an architectural control rather than hygiene, and it is why we treat it in depth in the lethal trifecta writeup.

One more rule sits above all the scoping: enforcement must live where the agent cannot reach it. An agent that can write and execute code can write code that bypasses guardrails implemented inside itself. So a permission is only as scoped as the layer enforcing it, and that layer has to be outside the agent's authority. Above all, an agent must never have permission to modify its own identity, role, or permission scope.

How Anomity helps with agent permissions

Every recommendation here depends on one thing you probably do not have yet: a clear picture of what each agent can already access. Anomity provides it. Its category is agentic endpoint security, built on the principle that you can't govern what you can't see.

A lightweight, unprivileged Endpoint Sensor runs on every managed endpoint (Windows, macOS, and Linux) and discovers eight AI artifact types: AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs. It maps what each one can reach and who owns it, so an over-privileged identity - the agent with broad filesystem scope it never uses, the MCP server holding a write credential where read would do - surfaces before it is exploited. The sensor sends metadata only over HTTPS to the Anomity Cloud; never source code, never prompts, and secrets are redacted on the endpoint.

Then it enforces. On agents that expose a hook, Anomity evaluates each tool call before it runs and returns allow, deny, or log, which is the point where a permission actually becomes a control - an unexpected shell command, an egress to an unknown host, a write to a system a task never needed can be denied rather than executed. Continuous policy means a new scope or a changed credential shows up as a change event, violations route to your SIEM, Slack, email, and Jira, and every change lands in a queryable 90-day audit trail. Anomity is SOC 2 Type II and complements your EDR/XDR, DLP, network and gateway controls, and GRC program rather than replacing them.

You can't govern what you can't see.The Anomity principle

The bottom line

The permissions AI agents request are predictable - filesystem, shell, network, OAuth scopes, secrets, browser - and so is the mistake teams make with them, which is granting far more than any task needs and never revisiting it. The fix is one rule applied six ways: the narrowest scope, the shortest lifetime, the tightest context, deny by default, and enforcement somewhere the agent cannot rewrite. Watch the combinations more than the individual grants, because it is data access plus untrusted input plus egress that turns a manipulated prompt into a breach. And start from visibility, because you cannot scope, time-box, or revoke a permission you have never seen. To map what your agents can access today, book a 30-minute demo.