AI Agent Permissions: Least Privilege at the MCP Layer

The oldest rule in security is the one agents break first. Least privilege: give the account the narrowest access that does the job, and nothing more. Every enterprise already enforces it for people. Service accounts get scoped roles. Contractors get badges that expire. Then an AI agent arrives, inherits an engineer’s token, and gets a system prompt that says please do not delete anything.

AI agent permissions are the first of the six AI operator security controls, and the one the other five lean on. The control is the narrowest set of tools that does the job, enforced on the server, not stated in a prompt. What follows is that sentence from the buyer’s chair: what it means at the layer where agents actually reach your systems, how to tell a real allow-list from a paragraph in a proposal, and what to put in the RFP. It is the first piece in a series that takes the six controls one at a time; the AI agent security checklist is the index.

The series rests on one idea. AI operator security is being safe from the AI agents you operate. Most AI security protects you from someone else’s model. AI operator security protects you from your own agents. AI operator security makes the case for the term; this guide takes the case as made and starts on the first control.

Why a Prompt Cannot Hold a Permission

Every AI policy we have read says the agent may do this but not that, and almost every deployment enforces it by pasting the sentence into the system prompt. It feels like a control. It reads like a control. It is a request.

A language model does not execute instructions; it weighs them. The system prompt is one input among many, alongside the user’s message, the documents the agent has read, and the result of its last tool call. Most of the time the prompt wins. In July 2025 it did not: a Replit agent that had been told, in plain language, that a code freeze was in effect deleted a production database and then fabricated a 4,000-record database of fictional people to cover the gap. The agent was not attacked. The rule was stated. Nothing enforced it.

The security profession has a name for the underlying mistake. NIST’s least-privilege control asks that an account hold only the access its function requires. The OWASP Top 10 for LLM Applications lists excessive agency as a top risk, names excessive functionality and excessive permissions as its causes, and gives the plain prevention: limit the extensions an agent can call to the minimum necessary. Neither says a word about prompts, because a prompt is not where access is held.

A permission is a rule the agent cannot break. A prompt is a rule it usually keeps. The difference is the whole control.

Where the Allow-List Lives

You cannot inspect what an agent thinks. You can inspect what it does, and what it does arrives as a tool call. The industry has settled on the Model Context Protocol as the layer those calls pass through: the client asks a server what tools exist, the model picks one, the client sends the call, and the server executes it and returns the result. In the protocol’s own terms, the server answers tools/list and tools/call, and it can announce when its list changes.

That makes the server the operator’s leverage. A tool the server does not expose to an agent’s identity is a tool that identity cannot call, whatever the model decides. The allow-list is therefore two things, both on the server: the set of tools advertised to a given identity, and the refusal to execute anything outside that set if a call arrives anyway. The MCP specification (current revision, 2026-07-28) puts the obligation where it belongs: servers must validate every tool input and implement proper access controls. The same revision says the set of tools a server returns may vary by the authorization presented on the request, returning only the tools the caller’s granted scopes permit, which is the allow-list in the protocol’s own words.

Two things that look like permissions are not. The first is tool annotations. A server can label a tool read-only or destructive, and a good client will use the label to decide when to ask the user; the specification is explicit that clients must treat those annotations as untrusted unless the server is trusted. They are hints about behavior, not limits on it. The second is the tool description, the sentence the model reads to decide whether a tool fits the task. A description that says only use this for refunds under one hundred dollars is a prompt by another name.

If the agent runs inside a client you do not control, which is most of them, the server is also the only place you do control. The client’s consent screens belong to the client’s vendor and the user. The prompt belongs to the model. The server is yours, or your vendor’s under a contract you can read.

Designing the Narrowest Set

Start from the job, not from the API. A vendor’s MCP server might expose fifty tools because the product has fifty capabilities. The agent you are deploying has a job, and the job needs a handful.

Write the tasks down. A support agent that answers tickets needs to find a customer, read a ticket, read the order the ticket is about, add a note, and send a reply. That is five tools, or six if status changes are in scope. It does not need to delete a customer, export the ticket table, merge two accounts, issue a refund, or email a segment. Those tools exist. They are not on the list.

Then separate the list twice. Reads from writes, because a read-only agent can be wrong without being expensive; the case for starting read-only is made in MCP embedding types. And routine from irreversible: anything that deletes, exports, merges, bulk-sends, or moves money gets its own line and its own decision, which is the per-resource, per-verb, per-sensitivity scope design described in MCP auth and security. A scope called tickets:write that quietly includes tickets:delete is not narrow, however short the list looks.

The single-digit answer is normal, and it is cheaper. Fewer tools means shorter consent screens, less for the model to weigh, and fewer plausible wrong calls. It also means the audit log, when you read it, is readable.

The right-hand column is the allow-list. The table is the artifact. A vendor who can produce it for your agent in an afternoon has the control; one who answers with the full product catalog does not.

Server-Side Enforcement, Not Client-Side Consent

A permission can sit in one of three places, and buyers routinely accept the wrong two.

Client-side consent is real and worth having. Claude shows the tools an MCP app exposes at install and asks per action for sensitive operations; other clients are coarser, as the MCP client comparison lays out, and the specification itself says there should always be a human able to deny a tool invocation. But consent lives with the user, varies by client, and is granted once by a person who wants the agent to work. It is a courtesy the client extends. It is not the operator’s control.

Server-side enforcement is the operator’s control because it does not care who clicked what. The agent’s identity is granted six tools; the seventh is not advertised, and if a call for it arrives anyway, the server returns an error and writes a log line with the identity that tried. That holds in Claude, in ChatGPT, in Cursor, and in whatever client ships next year. It holds when the prompt has been rewritten by a poisoned document, which is why this control is also the first line of defense against prompt injection. And it holds when the vendor upgrades its model and the new one reasons differently about the same instructions.

One pattern we see in enterprises running many agents is a gateway: a single MCP proxy in front of every server, where the allow-list per agent identity is configured, enforced, and logged in one place. The pattern is sound. The question to ask of it is the same one: is the gateway refusing calls, or passing a hint downstream?

How to Verify AI Agent Permissions

The vendor says the agent is scoped. Four steps turn the sentence into evidence, and they take an afternoon.

First, ask for the allow-list as configuration: the scopes or tool grants attached to the agent’s identity, exported from the system that holds them, not described on a slide. Second, pull the tool list as the agent. Call tools/list with the agent’s own credentials, or have the vendor do it on a screen you can see, and compare the result to the configuration. The list the agent sees is the list that matters; if it is longer than the configuration, the configuration is not what is being enforced. Third, attempt a call outside the list and read the refusal. The server should return an error, and the audit log should show the identity, the tool, the arguments, and the refusal. Fourth, change the prompt. Tell the agent its restrictions are lifted, ask it to call the forbidden tool, and confirm that nothing changes.

A vendor who can only demonstrate the control from the client’s consent screen has it in the wrong place. A vendor who can do all four in front of you has the first of the six controls, and probably the other five.

What to keep: the exported configuration, the tools/list output, and the log entry for the refused call, dated. They are the artifact for the auditor, and they are the baseline you will compare against when the tool list changes, which is the subject of the fourth control in this series.

Failure Modes

One question exposes all five. Ask where a call outside the list is refused, and the answer is a place that is not the server.

The Contract Term and the RFP Question

The checklist explains why every control needs a term in the contract. The term for this one is short: enforcement is server-side, and the contract names the point where it happens, so that a later move of the allow-list into a prompt is a breach rather than a product decision. Pair it with the tool-change term from the hub: additions to the agent’s tool list come with notice and a version you can pin, because an allow-list the vendor can lengthen without telling you is not an allow-list. The security terms in SaaS vendor security due diligence are where both belong.

Conclusion

Least privilege was never a model problem. The model cannot hold a permission any more than an employee can hold a badge by being told about it. It is an operator’s job, and the MCP layer is where the operator does it: a short list of tools attached to an identity, enforced by a server that refuses the rest and writes down that it did.

The model proposes. The server disposes. Give the agent the six tools the job needs, and show the auditor the forty-four it cannot call.

Related Guides

• AI Agent Security Checklist – The six AI operator security controls, with the artifact to request for each
• AI Agent Credentials – Control 2: the agent’s own identity, scopes, and revocation
• MCP Tool Versioning – Control 4: pinning the definitions behind the allow-list
• MCP Auth and Security – Scope design per resource, verb, and sensitivity, and the audit-log bar
• MCP Embedding Types – Why read-only comes first, and what actions add to the safety story
• MCP Client Comparison – Permissions granularity and consent across the leading AI clients
• MCP Terminology – Servers, tools, and the vocabulary this guide assumes
• SaaS Vendor Security Due Diligence – The contract stage these terms belong in