How should organisations govern MCP access across humans, agents, and services?

Use one central policy layer that maps identity claims to servers and individual tools, then apply the same review discipline across people, automations, and downstream service calls. That keeps MCP governance aligned with IAM and NHI practice instead of creating a parallel AI-only access model.

How to govern MCP access without splitting humans, agents, and services into separate models

MCP governance works best when the policy decision is made once, at a central control point, and then enforced consistently across human users, AI agents, and backend services. The practical goal is not to invent a new AI-only access model, but to make MCP requests inherit the same identity, authorisation, review, and revocation discipline already expected in IAM and NHI operations.

That means the organisation should treat the MCP server as a governed resource, and individual tools as narrower privileges inside that resource. The same policy logic must be able to distinguish a person invoking a tool, an agent invoking it on behalf of a person, and a downstream service call made by automation, because each path creates a different trust and blast-radius profile.

A useful pattern is to define identity claims, approved servers, and approved tools in one place, then evaluate each request against those claims before execution. That avoids duplicate rules scattered across app teams, bot frameworks, and integration code, and it gives security teams one auditable policy surface for approval, exception handling, and review.

For MCP Security Guide, the key governance lesson is that authorisation should be bound to the server and the specific tool, not just to a generic client session. If the platform allows token passthrough, local server credentials, or broad gateway exceptions, governance quickly becomes inconsistent because the effective privilege shifts outside the central policy layer.

The review model should therefore reflect the action path, not only the requesting principal. Human approvals may be enough for a sensitive one-off action, but agent and service access often need shorter-lived entitlement, tighter scope, and clearer evidence of who or what initiated the call.

When organisations implement this well, they can answer three questions for every MCP request: who requested it, which tool or server was targeted, and what downstream authority was actually used. That is the difference between governed delegation and opaque tool execution.

What a central policy layer should actually control

A central MCP policy layer should control entry, routing, and authority. Entry determines whether the caller is allowed to use MCP at all, routing determines which servers and tools are visible, and authority determines what the call can do once it reaches the target.

That structure matters because MCP access is not a single permission. A user may be entitled to a server for read-only context, an agent may be entitled to a subset of tools, and a service may be entitled only to background calls with no interactive authority. Collapsing those cases into one shared allowlist usually creates overbroad access.

The most reliable operational pattern is least privilege with explicit delegation. The policy should express whether the caller is acting as a human, as an agent on behalf of a human, or as an autonomous service, then constrain the available tools, data scope, and session duration accordingly.

This is where AI Agent Authorisation Guide is useful as a governance lens, because it treats per-action decisions, task-scoped access, and human approval as the normal control pattern rather than exceptions. For MCP, that means you should authorise the specific tool invocation, not just the existence of a logged-in agent.

It is also why Agentic AI Identity Guide maps cleanly to MCP governance. If an agent can act on behalf of a user, then registration, delegation, and retirement become governance controls, not merely architecture details, because they determine whether the policy layer can trust the claims attached to the request.

For services, the same logic applies through service identity and short-lived credentials. A service call is not safer just because it is automated, it is safer only if the policy layer can bind that automation to a narrowly defined identity, scope, and expiry.

How to keep MCP governance auditable across people, automations, and downstream service calls

Governance fails when the organisation can see who logged in, but not who actually caused the tool invocation or what authority was consumed downstream. MCP therefore needs audit evidence that links the requesting principal, the delegated context, the server, the tool, and any downstream service call that inherited the action.

That audit trail should support exception review, incident response, and periodic recertification. If a tool can reach production data, trigger external API calls, or chain into another service, the review standard should be closer to privileged access review than to ordinary application onboarding.

AI Agent Observability, Audit and Incident Response Guide reinforces that action attribution and revocation evidence are not optional once an agent can make meaningful changes. The same principle applies to MCP servers, because audit records lose value if they cannot show which identity made the call, which tool was used, and when the access can be revoked.

Zero Trust for AI Agents also fits the MCP model well: verify the principal and the request each time, remove standing privilege where possible, and treat every tool invocation as a policy event. That makes the governance model resilient even when the caller is a human today and an automation tomorrow.

The cleanest operating model is a small set of approved identity patterns, a single policy engine, and a review process that measures real privilege, not just application membership. If those three pieces are in place, MCP can be governed as part of the normal access-control stack rather than as a parallel AI exception.

Risk and Threat Considerations

MCP governance breaks down when identity, delegation, and tool authority are treated as interchangeable. The main risks are overprivileged tool access, token or session reuse across contexts, and confused-deputy behaviour where a trusted agent or service performs an action the original requester should never have been able to trigger.

Failure mechanism: A policy layer that only checks whether a caller is “allowed to use MCP” can miss whether that caller should be allowed to reach a specific server, invoke a specific tool, or pass authority into a downstream service call. That creates privilege inflation and makes revocation or review incomplete.

Impact: Excessive access can expose sensitive data, trigger unintended actions, and widen blast radius across human, agent, and service pathways. In a compromise, the same weak control can also let an attacker move from one trusted identity context into another without clear detection.

Practitioner Guidance

What to prioritise: Start by defining the authoritative policy point for MCP, then enumerate the distinct identity types it must recognise: human, delegated agent, and service. If those are not separated in policy, the rest of the control model will blur together.

What to verify: Confirm that every MCP request can be traced to a principal, a server, a tool, and an expiry or revocation path. If any of those elements are missing from logging or review, the governance model is not yet strong enough for production use.

Common mistake: Do not let teams bolt MCP onto existing app permissions as a convenience layer. That usually preserves legacy overbreadth and turns the agent or service into a privilege amplifier instead of a constrained consumer.

Practitioner takeaway: The right MCP model is one policy surface with different trust rules for different actors, not separate governance islands for people, agents, and services.

Related resources from NHI Mgmt Group

• How should security teams govern API access across humans, services, and agents?
• What should organisations do when agents need access across APIs and cloud services?
• How should teams govern privileged access across humans, workloads, and agents?
• How should organisations govern privileged access across employees, vendors, and AI agents without creating more operational complexity?