Local MCP usually depends on a single developer machine, but hosted MCP must support many users, many tenants, and enterprise audit expectations. That changes the control model from convenience to governance: access must be centralised, scoped, and traceable. What works in a local proof of concept is usually too loose for production adoption.
Hosted MCP permissions are a governance problem, not just a local setup detail
hosted mcp changes the permission question from “does this work on my machine?” to “who can use which tools, under what policy, and with what traceability?” In a local setup, the blast radius is often bounded by one developer’s environment. In a hosted setup, the same permission model has to stand up to shared access, tenant separation, and auditability expectations.
That difference matters because permissive defaults that are tolerable in a prototype become weak controls in production. Hosted deployments usually need central policy, explicit scopes, and a clear owner for approvals, revocation, and logging. The design goal is no longer convenience alone, but controlled delegation.
Hosted MCP also tends to sit closer to organisational identity and access controls than a local server does. Once multiple users or applications can reach the same MCP endpoint, permission decisions must be consistent across sessions and explainable after the fact. That shifts MCP from a developer convenience layer into a governed access surface.
Why local MCP can stay simple while hosted MCP cannot
local mcp is usually trusted because the developer machine is already the control boundary. Access is often implicit: the person using the machine is the person operating the tools, and the environment is short-lived or at least personally managed. That makes a simple configuration practical, even if it would be too loose for shared use.
Hosted MCP breaks that assumption. A hosted server may serve many users, many clients, and many tool paths, so the platform must distinguish between authentication, authorization, and operational oversight. Permissions that are acceptable when one person controls the environment are not sufficient when the service is shared, persistent, and potentially exposed to administrative review.
The practical difference is that hosted permissioning must support central enforcement. For example, a hosted environment usually needs scoped access to specific tools or resources, explicit session boundaries, and traceable decisions when a user is allowed to act on behalf of an organisation. Without those controls, the server becomes difficult to govern at scale.
Hosted MCP guidance is easiest to understand when you read the protocol through an authorization lens, not just a transport lens. The MCP authorization specification makes that distinction explicit for HTTP transports, and NHIMG’s MCP Security Guide expands the practical implications for token handling, gateways, and local versus remote server design.
What hosted permissions need to protect that local permissions usually do not
Hosted MCP permissions need to protect the service boundary itself, not just a user’s workstation. That usually means three things: least-privilege tool access, tenant-aware separation, and a record of who approved or exercised each capability. If any of those are missing, the hosted service can become an easy path from a legitimate login to broad tool use.
Another difference is lifecycle. Local permissions are often set once and forgotten during experimentation. Hosted permissions must survive onboarding, role change, offboarding, and incident response. When a user leaves or a client is retired, the hosted environment needs a reliable way to revoke access quickly and prove that the revocation happened.
Hosted MCP also raises the importance of delegated authority. If an MCP server can access external systems, then its permissions are not only about the human user but also about what the server is allowed to do on that user’s behalf. NHIMG’s AI Agent Authorisation Guide is useful here because the core problem is the same: constrain delegated actions to the minimum necessary scope and make the policy decision explicit.
Risk and Threat Considerations
Hosted MCP permissions create a larger attack surface because the same tool endpoint may be reachable by many users, tenants, or integrations. If authorization is too broad, a single compromised account, token, or client can expose actions far beyond the intended session or tenant boundary.
Failure mechanism: Weak scoping, token reuse, or poor tenant isolation lets a valid caller exercise permissions that were meant for a narrower context, which can lead to unauthorized tool use or cross-user access.
Impact: The result can be data exposure, unintended side effects in connected systems, and audit failure because the service cannot clearly show who did what and under which policy.
For a broader control view, NHIMG’s Authorisation Models Guide is a practical reminder that hosted MCP typically needs more than coarse roles, while the MCP authorization specification shows why audience-bound, scoped tokens matter for remote use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Hosted MCP permissions hinge on delegated tool authority and privilege scope. |
| Recommendation — Constrain agent and tool permissions to the minimum action scope and require explicit approval for elevated access. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Hosted MCP depends on robust caller authentication before authorization is applied. |
| Recommendation — Enforce strong authentication on MCP endpoints and reject any unauthenticated or ambiguous client identity. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Hosted MCP permissions should be narrowly scoped to limit shared-service blast radius. |
| AU-2 — Event Logging | Hosted MCP must produce traceable records for multi-user auditability. | |
| IA-2 — Identification and Authentication (Organizational Users) | Shared hosted MCP access requires reliable user identity before any permission decision. | |
| Recommendation — Limit each MCP user or client to only the tools and resources needed for the task. Log permission grants, tool invocations, and administrative changes with attributable context. Authenticate each user before allowing access to hosted MCP tools or administrative functions. | ||
Practitioner Guidance
What to prioritise: Decide first whether the hosted MCP service is acting as a shared platform, a tenant-specific service, or a single-purpose integration. That classification determines whether you need central policy, tenant isolation, or both.
What to verify: Confirm that each permission can be tied to a named user, workload, or approved client, and that the service can revoke that access without redeploying the whole environment. If you cannot answer that quickly, the control model is still too local in spirit.
Common mistake: Treating a hosted server like a local developer tool and inheriting broad, static permissions. In production, that usually becomes the first governance gap auditors and incident responders notice.
Practitioner takeaway: Hosted MCP should be designed so permissions are centrally governed, narrowly scoped, and auditable from day one, because once the server is shared, the permission model becomes part of the trust boundary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org