No. IdP policy is the right control for deciding which MCP servers an agent may connect to, but it does not govern the actions taken once the agent is inside. Teams need a second layer for per-tool authorization, auditability, and runtime containment.
Why IdP Policy Is Only the Entry Gate for MCP
IdP policy is useful because it controls which agents or users can establish a session to an MCP server, but that is only the front door. Once the connection exists, the security question shifts to what the agent can actually invoke, what data it can reach, and how much damage a valid session can do before the IdP ever sees another decision.
An MCP deployment should be treated as two distinct control planes: connection authorization and in-session authority. The first decides whether the agent may connect at all. The second decides which tools, operations, and resources are allowed after connection, and whether those actions remain bounded enough to investigate and contain.
That separation matters because the IdP typically knows about identity, session state, and coarse application access, not the internal safety of each tool exposed by the MCP server. A policy that is correct at login can still allow broad tool execution, overbroad data access, or risky side effects if the MCP layer does not enforce its own authorization boundaries.
What the Second Control Layer Must Cover
The missing layer is not just a duplicate policy check. It is the place where per-tool authorization, request context, and execution limits are enforced. In practice, that means mapping an agent’s session to specific actions, scoping access to the minimum needed for the task, and keeping tool invocations attributable enough to support review.
MCP Security Guide is the clearest reference point here because it frames mcp security as a combination of OAuth-based authorization, token handling, gateway design, and tool-level controls. That is the right mental model for teams that want to avoid treating IdP approval as a substitute for runtime authorization.
The control layer should also account for how the MCP server is deployed. Local servers, remote servers, and brokered gateway patterns all change where trust is placed and where enforcement must happen. If the server can reach sensitive systems or privileged APIs, the MCP layer needs explicit controls for those tool paths, not just a generic “signed in” decision.
MCP authorization specification supports that split by treating the MCP server as a resource server with audience-bound tokens and no token passthrough. That design helps prevent a valid identity session from becoming a blanket credential for every downstream action the agent can attempt.
How Teams Should Think About Auditability and Containment
Auditability is the practical reason a second layer matters. If every action is only visible as an IdP login, teams lose the detail needed to explain which tool ran, on what object, under which conditions, and whether the action stayed within expected bounds. Good MCP security preserves that chain of evidence at the tool boundary, not only at authentication time.
Containment is equally important. When an agent is compromised, prompted into unsafe behavior, or simply misconfigured, the blast radius is defined by tool authorization and execution limits. A strong IdP policy does not stop a connected agent from overreaching if the MCP server allows broad, persistent, or cross-context access once the session is established.
OWASP API Security Top 10 is useful here because the same failure pattern appears in API security: authentication alone does not prevent broken authorization, excessive function access, or exposure of sensitive flows. MCP tool access has the same structural weakness when teams assume the identity provider is the only trust boundary.
Identity Provider and SSO Security Guide remains relevant because it helps teams harden the upstream identity layer, but upstream hardening is still only one part of the answer. A secure IdP reduces impersonation and session abuse risk; it does not replace MCP-side authorization, logging, or containment.
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 | MCP access depends on agent authority after login, not only identity approval. |
| Recommendation — Enforce least-privilege tool scopes and revoke any agent privilege that exceeds task need. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP tool calls can be authorized at login yet still overreach at runtime. |
| Recommendation — Apply function-level authorization to each MCP tool invocation. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question centers on limiting what a connected agent may do inside MCP. |
| AU-2 — Event Logging | MCP needs tool-level audit trails, not just IdP sign-in records. | |
| IA-9 — Service Identification and Authentication | MCP connections often rely on machine or service authentication rather than human login. | |
| Recommendation — Restrict each agent session to the minimum tool and data access required. Log each MCP tool call with actor, action, target, and outcome. Authenticate MCP workloads and services with strong, bounded credentials. | ||
Practitioner Guidance
What to prioritise: Treat the IdP as the gate for connection approval, then verify that the MCP server separately enforces per-tool permissions, scoped tokens, and action logs. If a connected agent can call a high-impact tool without a second check, the design is too permissive.
What to verify: Confirm that logs show the agent identity, the specific tool invoked, the target context, and the outcome. If you cannot reconstruct those four elements after an incident, the platform is relying too heavily on IdP policy and not enough on runtime control.
Decision rule: If the MCP server can reach sensitive data, production systems, or external side-effecting APIs, require explicit in-session authorization and containment controls before broad rollout. If the server only brokers low-risk read-only operations, the second layer can be narrower, but it should still exist.
Practitioner takeaway: IdP policy is necessary for admission, but MCP security is decided by what happens after admission. Teams that stop at identity approval usually discover the real risk only when an agent is already inside the trust boundary.
Related resources from NHI Mgmt Group
- What do teams get wrong about MCP security when they rely on basic gateways alone?
- What should identity teams review first when ICAM becomes part of security policy?
- Should buyers rely on SOC 2 alone when assessing third-party security?
- What breaks when SOC teams rely on telemetry volume instead of security context?