MCP Authorization: Scoping What Agents Are Allowed to Do

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.

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 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. 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.

That outside decision point is an 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.

{
  "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. 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 authentication: securing how agents and servers connect
• Deterministic AI agent policies
• Rate limiting MCP tool calls

---

Control what your agents can do through MCP.

Get started now →. The product is live.

Browse the policy library →. Pre-classified tools across thousands of MCP servers.

Read the MCP security reference →. What the boundary looks like.