Should IAM teams treat MCP as a replacement for existing authorisation controls?

No. MCP is a transport and discovery pattern with some authorization guidance, not a complete governance model. IAM teams still need object-level checks, token expiry discipline, user-context propagation, and controls that stop alternate tool paths from reconstructing restricted data.

Why MCP does not replace authorisation control

MCP changes how tools and context are exposed to an agent, but it does not replace the underlying decision about what a caller is allowed to see, fetch, or execute. That decision still belongs to your authorisation model, especially when the same data can be reached through more than one tool path or when a downstream system can reconstruct restricted information from smaller allowed fragments.

For IAM teams, the practical question is not whether MCP has authorisation features, but whether those features are sufficient for the data and actions they expose. In most environments, they are not enough on their own because object-level rules, token boundaries, and context propagation still need to be enforced at the system and policy layers.

That is why teams should treat MCP as an integration surface, not a governance boundary. If a business object is sensitive, the control must survive every route to that object, including direct API access, alternate tools, cached responses, and aggregation through prompts or intermediate services.

What IAM teams must still control

Good authorisation is about the resource, the action, and the context, not just the transport. The controls that matter most are object-level checks, short-lived tokens, explicit user context, and consistent policy decisions across all tool entry points. The Authorisation Models Guide is useful here because it frames the difference between coarse role assignment and finer policy decisions that actually protect data paths.

MCP can still fit into that model, but only if the server-side authorization logic is aligned with the same policy intent as the rest of the environment. If a tool can return a record, but another tool can derive the same record from related fields, the policy has to cover both paths. The MCP Security Guide is a direct match for this distinction because it addresses MCP authorization, token passthrough, and gateway patterns without implying that the protocol itself is the full answer.

Token expiry discipline matters as much as policy wording. A long-lived credential, a delegated token without audience binding, or a stale user context can let an otherwise valid integration continue operating after the original trust condition has changed. The NHI Authentication Guide reinforces the same operational point for machine and service authentication: the way a caller proves itself and the way that proof is bounded both shape the safety of the whole path.

How alternate tool paths defeat weak authorization

The biggest architectural mistake is assuming one approved tool path closes the issue. In practice, alternate tools, broader read scopes, and composed outputs can rebuild restricted information from pieces that each looked harmless on their own. That is especially dangerous when an agent can chain calls, because the threat is not only direct access, but indirect reconstruction.

This is why object-level authorization has to be tested against the full tool ecosystem, not only the primary mcp server. A user may be blocked from one object, yet still learn it through search, summarisation, metadata, related records, or a secondary connector. The Permission-Aware RAG Guide is relevant because it shows the same control problem in retrieval systems, where over-sharing often happens through aggregation rather than a single obvious leak.

IAM teams should also expect policy drift between human workflows and agent workflows. A control that is acceptable for a person clicking through a UI may be too broad for a delegated tool or agent that can repeat the action at machine speed. The AI Agent Authorisation Guide is a useful companion because it focuses on task-scoped access, per-action decisions, and human approval where delegation becomes material.

If the protocol lets an agent discover tools but does not bind every tool invocation to the same policy context, the result is often privilege expansion by composition. That is the real reason MCP cannot be treated as a replacement: discovery is not the same as authorization, and transport is not the same as governance.

Risk and Threat Considerations

Weak MCP governance can expose sensitive objects through alternate routes, stale tokens, or overbroad delegated access. The risk is not limited to one protocol call; once a tool chain can reconstruct restricted data, a defender may lose visibility into how the disclosure occurred and which control actually failed.

Failure mechanism: An attacker or over-permissioned agent uses an allowed tool path, combines outputs across tools, or reuses a still-valid token context to reach data or actions that were meant to stay blocked.

Impact: Confidential data exposure, unauthorized actions, and hard-to-audit privilege expansion can follow, especially when the same object is reachable through multiple connectors or when token lifetime outlasts the original user intent.

Standards & Framework Alignment

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

OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API5 — Broken Function Level Authorization	MCP tools can expose actions that need per-function access control.
	API1 — Broken Object Level Authorization	Object-level checks are explicitly identified as still required.
Recommendation — Enforce per-tool authorization checks before allowing sensitive actions. Validate object ownership and access before returning each record.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	The question is about not over-trusting MCP as a replacement for access control.
	IA-5 — Authenticator Management	Token expiry and credential discipline are central to the answer.
	AC-3 — Access Enforcement	MCP still needs consistent enforcement of object-level access decisions.
Recommendation — Restrict each tool and token to the minimum privileges needed. Set short lifetimes and rotate credentials before they become stale. Apply the same access decision at every resource path and connector.
NIST Zero Trust (SP 800-207)	0 — Zero Trust Architecture	The answer depends on continuous verification and no implicit trust in the transport.
Recommendation — Verify each request context and do not trust the protocol boundary.

Practitioner Guidance

What to verify: Test authorization at the object level, not just at the MCP endpoint. You should be able to show that each sensitive object is protected consistently across direct APIs, MCP tools, and any secondary path that can reconstruct the same information.

What to prioritise: Bind token lifetime, audience, and user context together before expanding MCP adoption. If a tool cannot reliably carry the original user’s authorization context, treat it as a separate trust boundary and narrow its permissions accordingly.

Common mistake: Assuming an approved tool registry or gateway means the data is safe. The control failure usually appears later, when one allowed tool becomes a data amplifier for another.

Practitioner takeaway: Treat MCP as a way to expose capabilities, not as a substitute for authorisation. If your existing controls do not survive alternate tool paths and composable outputs, the protocol layer has not solved the governance problem.