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 requiring human approval for any tool call that can modify or delete data.

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. When an agent wants to use a tool, Claude Code can be configured to require human confirmation for specific tool types - particularly any tool that modifies external state. This "human-in-the-loop for writes" pattern is the correct starting point for basic authorization: the agent can read freely, but every write requires a human to click "approve." As trust in the agent's judgment increases for specific operations, those operations can be moved to auto-approved.

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.

• 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 - basic authorization with human approval for writes is the starting point; as the team observes agent behavior and builds confidence, specific write operations can be promoted to auto-approved incrementally
• 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. Enable human approval for write tools - in Claude Code, configure permissions.allow and permissions.deny in the project settings to require confirmation for any tool that modifies external state. The first time an agent wants to create a Jira comment or push a commit, a human approves the specific action.
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. Developers who click "approve" on agent write operations without reading the proposed action are providing security theater, not security. Train the team to actually read the tool call before approving, at least until the operation type is well understood.

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.