Basic tool authorization

Basic tool authorization is the first deliberate access control layer on MCP tool usage: decisions about which agents can call which tools, under what conditions. At L1 (Zero MCP), authorization is moot - there are no tools to authorize. At L2 with 1-3 MCP servers, basic authorization means establishing read-only versus read-write boundaries, scoping tool access to the relevant data (one Jira project, not all Jira projects), and writing down - in a file that gets reviewed and committed - which tool calls that modify or delete data are denied outright and which must stop and ask.

The most important basic authorization decision is read vs. write. Read-only MCP tools carry minimal risk: an agent that can read your git history, your Jira tickets, and your documentation cannot cause damage with those tools. Write-capable tools are categorically different: a tool that can create Jira tickets, push git commits, or send Slack messages can cause real problems if called incorrectly. Basic tool authorization separates these categories explicitly, usually by starting with read-only tools and adding write tools incrementally with explicit human approval steps.

Claude Code implements basic authorization through its permission model, and in August 2026 the industry settled a question it had been arguing about all year: the control is the written rule, not the human click. Developers approve 97% of the permission prompts they are shown. In Anthropic's 1,053-person study, humans caught 13.6% of dangerous commands while a classifier caught 89%; across 40,000 runs, human approval accuracy was 66.3%, and npm run was waved through 52.5% of the time. A prompt that is always answered "yes" is not a control, it is a latency tax. Claude Code's auto mode became the default on 14 August for Pro, Max and Team accounts, with a circuit breaker at 3 consecutive or 20 total blocks.

This is not a return to letting the agent do whatever it likes, and reading it that way is the expensive mistake. Two declarative rule layers run before the classifier is consulted at all. permissions.deny blocks outright, and neither the classifier nor the agent's stated intent can override it. permissions.ask forces a prompt, and an explicit ask rule counts as your stated intent, so the classifier cannot auto-approve past it. Auto mode remains opt-in on Claude Enterprise, the Claude API, Bedrock, Google Cloud and Microsoft Foundry; org-managed defaults do not move on their own. So the mature form of basic tool authorization is a reviewed, version-controlled deny/ask ruleset that lives in the repository and goes through code review - not a human clicking approve, and not the classifier either. The human's judgment moves from the moment of the call to the moment the rule is written.

The starting shape of that ruleset is still read versus write. Read-only tools go in the allowed set. Anything that mutates external state starts in ask while you learn what the agent actually does with it, and anything genuinely destructive - deleting branches, touching production, rotating credentials - goes in deny and stays there. As evidence accumulates for a specific operation, you move that operation between layers by editing a file that someone reviews, which is a decision with a name attached to it.

Basic tool authorization also includes scoping: configuring each MCP server to expose only the data relevant to the current context. A Jira MCP server configured with a global admin token has access to every ticket in the organization. That's a much larger attack surface than a server configured with a read-only token scoped to a single project. Even at the basic level, applying the principle of least privilege to MCP tool configuration reduces risk significantly.

One protocol change is worth knowing about even at L2, because it alters where authorization decisions live. The MCP specification finalised on 28 July 2026 and adopted through August has a stateless core: the initialize/initialized handshake and the Mcp-Session-Id header are gone, so servers sit behind plain load balancers and run serverless. Practically, that means there is no session to attach a permission decision to. Every tool call arrives on its own and must carry its own authorization, which is a better model anyway but catches out anyone who assumed "we authorized at connect time" was enough. The same release hardens auth along RFC 9207 and 8707 lines and introduces a formal 12-month deprecation policy, under which Roots, Sampling and Logging are marked for removal. If your first three MCP servers lean on any of those, you have a year, and you should spend some of it now rather than all of it in month eleven.

• Prevents the most common MCP accidents - write-capable tools called incorrectly can create junk tickets, push incomplete code, or trigger unwanted notifications; basic read/write separation prevents these accidents without blocking read access
• Establishes the security posture before scaling - it's much easier to design authorization correctly for 3 servers than to retrofit it onto 30 servers; getting the pattern right at L2 pays compounding security dividends
• Creates the trust ladder for agent autonomy - starting every write in ask and every irreversible action in deny gives you a ladder with rungs; as the team observes agent behavior and builds confidence, specific operations move down a layer through a reviewed change to the ruleset rather than through habit
• Satisfies initial compliance requirements - many organizations have data governance policies that require access controls on systems that handle sensitive data; basic MCP authorization is the minimum viable compliance posture
• Makes tool behavior auditable - even basic authorization, when combined with logging, creates a record of what tools were called by which agents and when; this audit trail is the foundation for more sophisticated governance at L4

1. Classify each MCP tool as read or write - for each tool exposed by each MCP server, explicitly categorize it: does it only read data, or can it modify or create data? This classification drives every other authorization decision.
2. Configure read-only credentials by default - create service accounts or API tokens with the minimum required permissions: read access to git history, read access to the relevant Jira project, read access to docs. Use these tokens for MCP server configuration. Do not use personal tokens or admin accounts.
3. Write the deny/ask ruleset and commit it - in Claude Code, configure permissions.deny for anything that must never happen regardless of context or stated intent, and permissions.ask for write tools you have not yet built evidence about. Commit both to the repository and review changes to them the way you review any other security-relevant code. The rule is the control; the prompt is only what the rule produces.
4. Scope service accounts to the minimum necessary data - a Jira token scoped to one project cannot accidentally expose data from another project. Apply least privilege scoping to every MCP server credential from the start.
5. Log all tool calls - enable logging in your MCP server configuration so that every tool invocation (tool name, parameters, response, agent identity) is recorded. This log is both a debugging tool and the foundation for future audit capabilities.
6. Review write operations weekly - for the first month after deploying write-capable tools, review the tool call log weekly. Look for unexpected patterns: tools called more than expected, called with unexpected parameters, or called in sequences that suggest the agent is doing something other than what was intended.

Using admin credentials for MCP server connections. It's tempting to use your personal admin token because it "just works" for everything. This is a significant security risk: if the agent misbehaves or the token leaks, it has admin access to your entire system. Create dedicated, scoped service accounts for MCP connections and treat them as production credentials.

Approving write operations without reading them. Human approval for write operations is only as valuable as the quality of the review, and the 2026 evidence says the quality is poor: developers approve 97% of prompts, humans caught 13.6% of dangerous commands against a classifier's 89%, and approval accuracy across 40,000 runs was 66.3%. Training the team to read more carefully helps at the margin, but the structural fix is to stop relying on the click. Anything you genuinely cannot afford belongs in deny, where no amount of prompt fatigue can wave it through.

Treating auto mode as the end of authorization. The opposite mistake, and the more expensive one this month. Auto-approval by classifier sits underneath your declarative rules, not instead of them: deny blocks outright and cannot be argued past, and an explicit ask rule counts as your stated intent so the classifier will not auto-approve over it. A team that reads "auto mode is the default now" as "we no longer write permission rules" has removed the only layer that was doing reliable work. Note also that auto mode remains opt-in on Claude Enterprise, the API, Bedrock, Google Cloud and Microsoft Foundry, so what your laptop does and what your CI does may differ.

Not revoking tokens when a developer leaves. Manually configured MCP tokens are often tied to individual developer accounts. When a developer leaves, their tokens should be revoked - but with manual setup, there's no centralized registry of what tokens exist. This is one of the arguments for centralized credential management (L3), but at L2 you can mitigate it with a documented offboarding checklist.

Conflating "the agent asked for approval" with "it's safe to approve." An agent that requests write access because it misunderstood the task is still asking for approval. The human approval step is not a rubber stamp; it's a judgment call. If the proposed write operation doesn't match what you asked the agent to do, the correct response is denial and clarification, not approval.