How should organisations classify access for agentic tools and MCP servers?

They should classify tools by the privilege they exercise, not just by the data they touch. A read-only tool, a read-write tool, and a destructive tool create very different risk profiles, so approvals, monitoring, and response rules should reflect the action scope of each one.

Why access should follow action scope, not just data scope

For agentic tools and MCP servers, the right classification question is not only “what data can they see?” but “what can they do with that access?” A read-only lookup tool, a write-capable integration, and a destructive admin tool all change the organisation’s exposure in different ways. Access policy should therefore be tied to the privilege exercised, the side effects it can trigger, and the blast radius if it is misused.

That distinction matters because many agent failures are not data-leak problems alone. A tool that can approve, modify, delete, deploy, or call downstream systems is an action endpoint, so it should be reviewed like one, with tighter approval, narrower scope, and stronger monitoring than a passive retrieval tool.

For MCP specifically, the server is part of the trust boundary. If the server can mediate or forward credentials, invoke tools, or act as a gateway into other systems, the access model should reflect that authority. MCP Security Guide explains why token passthrough, local server credentials, and gateway behaviour can materially change the risk profile.

How to classify read-only, read-write, and destructive tools

Start by classifying the tool by the highest-impact action it can perform in its normal operating path. A read-only tool can still be sensitive, but its control objective is usually confidentiality and misuse detection. A read-write tool introduces integrity and change-control concerns. A destructive tool, or one that can trigger irreversible external actions, should be treated as high-risk even if it touches only low-sensitivity data.

A practical test is whether the tool can create, alter, delete, approve, transfer, execute, or delegate anything outside the agent itself. If the answer is yes, the classification should move beyond “information access” and into “privileged action access.” That often changes who may approve it, whether it needs just-in-time access, and whether a human confirmation step is required for certain operations.

The same logic applies to MCP servers that expose multiple methods. One server may host harmless retrieval calls alongside methods that can mutate records or issue commands. In that case, the classification should follow the most powerful method the client can invoke, not the most common one. If an organisation cannot separate those methods cleanly, it should assume the stronger classification for the whole server.

For agent approvals, the useful control point is action granularity. AI Agent Authorisation Guide sets out why least privilege, task-scoped access, and per-action decisions are the right model when the tool can change state.

What policy, monitoring, and review should change

Once a tool is classified by action scope, approvals and monitoring should follow that scope. Read-only tools can often be pre-approved within a bounded context if their outputs are logged and their sources are known. Read-write tools should usually require explicit policy rules around which objects, environments, and time windows are in scope. Destructive tools should trigger the strongest review path, with tighter exception handling and clearer rollback expectations.

Monitoring should also distinguish between “tool was called” and “tool successfully exercised a privilege.” The latter is what matters for incident response. If a tool can post, delete, deploy, or provision, logs need to capture the request, the policy decision, the target object, and the resulting side effect. That allows teams to tell whether the agent merely attempted something risky or actually changed the environment.

Where MCP servers or agent tools sit between the agent and backend systems, the organisation should also verify whether the server is acting as a simple transport layer or as an authorization broker. Model Context Protocol: Authorization specification is directly relevant because MCP servers can behave as OAuth resource servers and should not be treated as neutral pipes when they enforce or relay access.

Risk and Threat Considerations

Misclassifying privileged tools as “just access to data” creates a gap between the apparent sensitivity of the content and the actual impact of the action. A compromised or over-permissioned agent can use a write-capable or destructive tool to modify records, exfiltrate data, trigger fraud, or create persistence through configuration changes, even when the underlying data itself looks ordinary.

Failure mechanism: The organisation assigns approvals and monitoring based on the information the tool reads, while the tool’s real authority lies in the actions it can take, so privilege is under-controlled and side effects are under-observed.

Impact: Attackers, mistaken prompts, or faulty automations can turn low-friction tool access into high-blast-radius changes, making containment, attribution, and recovery materially harder.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Tool access should match the privilege exercised, not just data exposure.
Recommendation — Limit each tool and MCP server to the narrowest action scope it needs.
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agent tools and MCP servers can misuse delegated authority and overbroad action rights.
Recommendation — Apply per-action authorization and restrict delegated privileges by task.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Action-scoped tool access is a direct least-privilege problem.
	AU-2 — Event Logging	Action scope requires logging of calls and resulting side effects.
Recommendation — Grant each agent tool only the minimum privileges needed for its function. Log tool invocation, policy decision, target object, and outcome.
NIST Zero Trust (SP 800-207)	ID — Identity	MCP servers and agent tools should be verified and authorized per request.
Recommendation — Verify the principal and request before allowing each tool action.
OWASP ASVS	V8 — Authorization	Tools that can mutate state need authorization decisions at the action level.
Recommendation — Authorize each state-changing tool operation before execution.

Practitioner Guidance

What to prioritise: Classify the tool by its strongest permitted action, then map the approval path to that action. If a single MCP server mixes retrieval and mutation, treat the mutation path as the deciding factor until the interface is separated.

What to verify: Confirm that logs capture both the policy decision and the side effect, not just the tool invocation. If you cannot show who allowed the action, what was changed, and whether it succeeded, the access classification is too weak for operations.

Common mistake: Treating “read-only data” as low risk when the same tool can still create downstream privilege, transaction, or workflow changes through an API call or delegated action.

Practitioner takeaway: The safest classification model is action-first, because in agentic environments the risk comes from what the tool can cause the system to do, not only from what it can see.