Should agencies treat MCP security as part of IAM or as a separate control layer?

IAM defines who the actor is, MCP governs what the actor can do at runtime

mcp security should be treated as a separate runtime control layer because it sits after authentication and entitlement assignment. IAM establishes the principal, proves it, and assigns baseline permissions, while MCP governs whether an agent may invoke tools, pass tokens, reach resources, or chain actions in a specific session.

That distinction matters because the same identity can behave safely in one context and dangerously in another. A well-formed IAM policy does not, by itself, prevent prompt injection, tool misuse, or overbroad tool invocation once the session is active.

When agencies map the two layers correctly, IAM remains the control plane for issuance and governance, while MCP becomes the execution-time policy boundary that constrains how those rights are exercised.

Why the separation improves control design and auditability

Separating MCP security from IAM makes the control objective clearer: IAM answers “who may authenticate and receive access,” while MCP answers “what may be done with that access right now.” That prevents agencies from overloading identity policy with runtime tool safety decisions that belong closer to the agent and its execution path.

This separation also improves auditability because the evidence differs. IAM evidence is about enrollment, role assignment, access review, and revocation. MCP evidence is about tool allowlists, token handling, session scoping, resource indicators, and whether the agent was restricted to the least powerful path available at execution time.

For agencies running agents against sensitive systems, the control boundary is especially important when a runtime request is narrower than the identity’s standing permissions, or when a delegated action should be denied even though the underlying identity is valid.

What agencies should look for in a real MCP control layer

An MCP control layer should enforce execution-time boundaries that are not expressible as static identity membership alone. That usually includes authorization policy at the server or gateway, scoped tokens, explicit audience binding, server-side validation of tool calls, and controls that reduce token passthrough and confused-deputy behavior.

It should also account for tool-level risk. A tool that can read secrets, trigger infrastructure changes, or call downstream APIs needs different runtime guardrails than a read-only lookup tool, even if both are reachable by the same authenticated principal.

The practical test is simple: if the control is trying to decide whether a specific action is safe in the current session, it belongs in MCP security. If it is trying to decide whether the identity may exist, authenticate, or hold an entitlement at all, it belongs in IAM.

Risk and Threat Considerations

MCP becomes a security boundary because attackers, malicious prompts, or unsafe integrations can exploit the gap between standing identity rights and live execution rights. If agencies collapse MCP into IAM, they risk granting an agent broad authentication-based access while failing to restrict harmful tool use, token reuse, or over-permissive session behavior.

Failure mechanism: A valid identity is used to obtain legitimate access, then the runtime layer allows tool invocation, token forwarding, or resource access beyond the minimum intended for that session. This creates a confused-deputy path, privilege amplification, or silent abuse of a trusted control channel.

Impact: The result can be unauthorized data access, destructive actions, lateral movement through connected systems, or secret exposure even when IAM logs show a permitted login and nominally correct role assignment.

Practitioner Guidance

What to prioritise: Define IAM and MCP as different control questions in your policy model. IAM should cover identity proofing, entitlement assignment, and revocation; MCP should cover tool authorization, token handling, and session-scoped limits.

What to verify: Check whether an agent can still perform high-impact actions when the identity is valid but the runtime context is unsafe. If the answer is yes, the missing control is in MCP, not IAM.

Common mistake: Treating “authenticated” as equivalent to “safe to execute.” In agentic environments, that shortcut hides the real decision point, which is whether the current tool call should be allowed, constrained, or denied.

Practitioner takeaway: Use IAM to establish trust in the actor, then use MCP controls to continuously narrow what that actor can do while the session is live.

Related resources from NHI Mgmt Group

• What breaks when API security is bolted onto IAM instead of designed as a separate control layer?
• Should organisations treat PAM as part of IAM governance or as a separate control?
• Should insurers treat AI agent governance as part of IAM or as a separate control domain?
• Should organisations treat Copilot as part of IAM or as a separate AI control problem?