# MCP Authorization: Scoping What Agents Are Allowed to Do

> Authentication proves who is calling. MCP authorization decides what they can do. Here is how to add per-tool, per-argument limits to AI agents.

Published: Fri May 29

Canonical: https://policylayer.com/blog/mcp-authorization

A valid token gets an agent through the door. It says nothing about which rooms the agent should enter. That second decision, what a connected agent is actually allowed to do, is MCP authorization, and the Model Context Protocol leaves it almost entirely undefined.

The default is binary. Once an agent connects to a server, it can call every tool that server exposes. A database server hands over `execute_query` and `drop_table` together. A GitHub server offers `create_issue` and `delete_repository` side by side. There is no middle setting between full access and no access. For AI agent authorization, binary is the wrong shape.

<!--truncate-->

## Authentication is not authorization

The two get conflated because MCP barely separates them. Authentication answers *who is calling*. Authorization answers *what this caller may do, on which tool, with which arguments*. A bearer token solves the first. It contributes nothing to the second.

This is the [binary permissions problem](/blog/deterministic-ai-agent-policies) in a new setting. Most MCP setups treat a connected agent as fully trusted, because the protocol gives them no vocabulary for partial trust. The agent that should only read issues is one token away from deleting the repository, and nothing in the connection distinguishes the two intents.

## Authorization a model cannot talk its way around

The tempting fix is to instruct the agent: you may read, you may not delete. That is not authorization, it is a suggestion. The model deciding whether to obey is the same model an attacker is trying to steer through [prompt injection](/blog/why-prompt-guardrails-fail-agent-safety). Real authorization has a property instructions never will: the agent cannot remove it, even with full reasoning and a hostile payload, because the decision is made outside the model, at the [transport boundary](/blog/runtime-governance-transport-layer).

That outside decision point is an [MCP gateway](/mcp-gateway). It evaluates every `tools/call` against deterministic policy and either allows it, denies it, or hides the tool, before the call reaches the server.

## What good MCP authorization looks like

Three properties separate enforcement from theatre.

**Per-tool scoping.** Expose `get_issue` and `list_issues`; hide `delete_repository` entirely so it never appears in the agent's toolset. You cannot misuse a tool you were never shown.

**Per-argument conditions.** Authorization that stops at the tool name is too coarse. The interesting rules live in the arguments: allow `create_refund` only up to an amount, allow `execute_query` only when it is a `SELECT`, allow `send_email` only to internal domains.

```json
{
  "version": "1",
  "default": "deny",
  "tools": {
    "create_refund": {
      "deny_if": [
        {
          "conditions": [
            { "path": "args.amount", "op": "gt", "value": 100 }
          ],
          "on_deny": "Refund exceeds the policy limit."
        }
      ]
    }
  }
}
```

**Permission ceilings.** A ceiling a developer cannot raise from their own client, even with admin access to the agent. The denial holds regardless of who is driving or what they prompt. This is the model security architects keep arriving at independently: limits enforced below the agent, not configured within it.

## Scoped to identity

Authorization is most useful tied to the per-person grant tokens from [MCP authentication](/blog/mcp-authentication). The same `create_refund` call can be allowed for a finance lead and denied for a contractor's agent, because the gateway resolves the policy against the identity behind the token. One enforcement layer, different answers per person, no change to the agent.

The agent stops being trusted by default and starts being permitted by rule. That is the whole shift.

## Related reading

- [MCP gateway: what it is and why agent fleets need one](/mcp-gateway)
- [MCP authentication: securing how agents and servers connect](/blog/mcp-authentication)
- [Deterministic AI agent policies](/blog/deterministic-ai-agent-policies)
- [Rate limiting MCP tool calls](/blog/rate-limiting-mcp-tool-calls)

---

**Control what your agents can do through MCP.**

[Get started now →](https://app.policylayer.com). The product is live.

[Browse the policy library →](/policies). Pre-classified tools across thousands of MCP servers.

[Read the MCP security reference →](/mcp-security). What the boundary looks like.