MCP tools need explicit scopes and accountable owners

Treat an MCP server as an integration with callable operations, not as a harmless list of AI features. Before connecting it, identify its owner, source, tools, data routes, credentials and maximum operational impact. Then grant only the permissions required for the approved use case.

Model Context Protocol tools can query external systems, call APIs and perform computations. The protocol describes tools as model-controlled, while recommending that applications keep a human able to deny invocations and clearly show exposed tools and operations. That makes tool governance a shared responsibility across the server, the host application and the organization operating them.

Inventory the server before the tools

A tool name alone is not a security boundary. Start with the server:

• Who publishes and maintains it?
• Where did the package or image come from?
• How are releases signed or otherwise verified?
• Where does the server run?
• Which network destinations can it reach?
• What credentials can it access?
• Who approves updates and investigates unexpected behavior?

Record the source repository and deployed version. A familiar server name is insufficient because similarly named packages, forks and republished images may not have the same code or maintainer.

Create one register row per tool

For each tool, capture the following fields.

Purpose and owner

Write one approved business purpose and name the team accountable for it. “AI productivity” is too broad. “Allow the service desk assistant to read the status of a user’s assigned laptop” is reviewable.

Inputs and parameter limits

MCP tools publish an input schema, but schema validity does not prove that every valid value should be allowed. Restrict high-impact parameters such as target account, repository, environment, command, path, region, recipient or record count.

Where possible, bind parameters to the user’s current context rather than letting the model supply an arbitrary target.

Data read and returned

Document the data the tool can retrieve, the scope used to retrieve it and what is returned to the model. Include sensitive metadata and indirect disclosure, not only the main response body.

Changes and side effects

Separate read, prepare and execute operations. A tool that creates a draft ticket has a different effect from one that disables an account or deploys a configuration.

Record downstream actions too. A “send request” tool may trigger an automation platform that performs a much larger change.

Authentication and authorization

For HTTP transports, the MCP authorization specification defines an OAuth-based flow and encourages minimum necessary scopes. Validate that access tokens are intended for the receiving server and that the server enforces the granted scope.

Authorization to connect to a server is not automatically authorization for every tool, target or parameter. Apply additional policy where the business action requires it.

Approval and evidence

Decide which invocations require confirmation or organizational approval. Record the user, agent, server, tool, parameters, policy decision, result and verification evidence appropriate to the sensitivity of the action.

Do not log secrets or full sensitive payloads merely to make the activity auditable. Evidence should explain the action without creating a second data leak.

Use impact tiers that change behavior

A simple register can use four tiers.

Tier 1 — bounded read

The tool reads non-sensitive information within a narrow, user-authorized scope. Invocation may be automatic, but the user should still be able to see that the tool is available and when it was called.

Tier 2 — sensitive read or draft

The tool accesses confidential data or prepares an external effect, such as a change request. Require stronger context, data-handling rules and visible invocation evidence.

Tier 3 — reversible change

The tool changes a record or configuration with a tested rollback. Apply target and parameter restrictions. Use confirmation or approval according to the organization’s policy and the affected environment.

Tier 4 — consequential or difficult-to-reverse action

Examples include disabling access, deploying to production, moving money, deleting data or sending sensitive information externally. Require explicit approval, short-lived authority, strong verification and a failure route. Some actions may remain prohibited regardless of approval.

The tier applies to the actual operation. A server may expose tools in several tiers.

Plan for server and tool changes

The set of tools can change. The MCP specification provides a notification mechanism for tool-list changes, but detecting a change is only the beginning. Decide what happens when:

• a new tool appears;
• a tool’s input schema changes;
• requested authorization scopes expand;
• the publisher or package source changes;
• the server begins reaching a new destination; or
• a previously read-only operation gains side effects.

Default to review before granting new authority. Existing approval of a server should not silently authorize future tools.

Do not overlook protocol-specific threats

The MCP security guidance documents risks such as confused-deputy behavior, token passthrough, server-side request forgery and local-server compromise. A permissions register will not solve implementation vulnerabilities, but it helps expose the architecture in which those risks matter.

For example, record whether an MCP server proxies a third-party API, which authorization server issues tokens, which audience the token names and where redirects or callbacks terminate. Security review can then test the actual trust relationships rather than treating OAuth as a generic safety label.

How Simorin applies the register

Simorin’s MCP & Tools Protection connects tool registration and source review to permission scope, change detection, approval or quarantine and tool-call inspection.

AI Access Boundaries contributes the delegated owner, permitted resources, actions, parameters and time limits for the agent using the tool. Session & Activity Observation contributes the investigation timeline around tool discovery, invocation, policy decisions and outcomes.

A real deployment review must distinguish controls enforced by Simorin from those enforced by the MCP host, server, authorization service and downstream API. Validate the specific transport, authentication flow, server version and tool behavior. Do not infer safety from protocol compliance or from a tool description supplied by an untrusted server.

The minimum decision artifact

Before enabling a server, produce a register containing:

• server source, version and operator;
• tool name and approved purpose;
• accountable business and technical owners;
• permitted identities or agents;
• data, resource and network scope;
• allowed parameters and prohibited targets;
• maximum side effect;
• Auto, confirmation, Approval or blocked status;
• authentication and token audience;
• evidence and retention requirements; and
• review date and change triggers.

If an operator cannot complete those fields, the server is not ready for broad access. The correct first action is to narrow the use case or keep the tool disconnected—not to grant a wide scope and rely on the model to be careful.