infrastructureL2 GuidedMCP & Tool Integration

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.

·1-3 MCP servers are configured (e.g., Git, Jira, documentation)
·MCP setup is documented but configured manually per developer
·Basic tool authorization is implemented (agents authenticate to MCP servers)

·MCP server configurations are shared via repository (not local-only)
·At least one MCP server provides internal documentation or codebase context

Evidence

·MCP server configuration files (mcp.json or equivalent)
·Setup documentation for MCP server installation per developer
·MCP server authentication configuration

What It Is

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.

Why It Matters

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

Getting Started

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

Tip

Use separate MCP server configurations for read-only and read-write tool sets. This makes it easy to verify that a specific agent session has only read access: check which configuration it's using. Mixing read and write tools in a single server makes it harder to audit access patterns.

6 steps to get from here to the next level

Common Pitfalls

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.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's team has just deployed their first write-capable MCP tool: an agent can now create Jira comments to summarize its work. One developer accidentally approved a tool call that created 15 comments on 15 different tickets because the agent misinterpreted the task scope. The comments are harmless but embarrassing, and Bob wants to prevent similar incidents.

What Bob should do: Bob should treat this incident as a calibration opportunity, not a failure. The right response is to tighten the authorization scope: configure the Jira write tool to require specifying the exact ticket ID in the approval confirmation, making it impossible to accidentally approve a bulk operation. Bob should also add a "dry run" capability where the agent describes what it would write before requesting approval to do so. These two changes - scoped approvals and dry runs - are basic authorization improvements that can be implemented in an afternoon and prevent the entire class of "agent did more than I expected" incidents.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah is trying to quantify the risk-benefit tradeoff for giving agents write access to developer tools. She knows write access dramatically expands what agents can do autonomously, but she's getting pushback from the security team who want evidence that the authorization model is sound.

What Sarah should do: Sarah should document the authorization model explicitly and present it to the security team as a controls proposal, not a technology decision. The controls are: read-only credentials as the default, human approval required for all write operations, scoped service accounts with minimum permissions, and a weekly audit log review. This is a defensible controls framework even to a skeptical security team. Sarah should also propose a 30-day pilot of write-capable tools under these controls, with a review meeting at the end to evaluate the incident rate. A clean 30-day pilot (zero unauthorized writes, all approvals reviewed) is the evidence the security team needs to trust the pattern at scale.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor wants to move to a more automated workflow where agents can push commits and create PRs without requiring his approval for every operation. He's confident in his ability to review agent output, but he knows the team's current basic authorization model requires approval for all writes.

What Victor should do: Victor should build the case for selective auto-approval by accumulating evidence. For 30 days, approve all write operations and log the quality: how often did the write operation match his intent? How often did it require modification or reversal? At the end of 30 days, operations with a 95%+ accuracy rate are candidates for auto-approval. Victor should propose this evidence-based approach to Bob as the path to agent autonomy: not "trust the agent," but "here are the specific operations where we've demonstrated the agent is reliable enough for auto-approval." This converts the authorization discussion from a philosophical debate to an engineering decision based on empirical data.

What Victor should do - role-specific action plan