Who should own MCP access decisions: the IdP team or the platform team?

Why This Matters for Security Teams

Ownsership of MCP access decisions is not just an org-chart question. MCP exposes a control boundary where identity governance, tool permissions, and server policy intersect, and mistakes here quickly become overbroad access or brittle change management. The practical risk is that identity teams can enforce who a person or workload is, while platform teams understand what an MCP server can actually do. That split matters because access decisions for tools are operational, not just directory-based.

Current guidance suggests treating MCP as a workload security problem rather than a pure IAM problem. The most useful reference point is the OWASP Non-Human Identity Top 10, which frames secret sprawl, standing privilege, and weak scoping as identity risks that often emerge inside platforms. NHIMG research on the State of MCP Server Security 2025 shows why this is urgent: only 18% of MCP server deployments implement any form of access scoping for tool permissions, which means ownership gaps become default exposure.

In practice, many security teams encounter MCP mis-scoping only after a server has already been wired into production workflows, rather than through intentional design review.

How It Works in Practice

The cleanest operating model is shared governance with hard boundaries. The IdP team should own identity primitives such as users, service accounts, group membership, authentication policy, and lifecycle controls. The platform team should own the MCP server, tool-level roles, allowlists, server-side restrictions, and any runtime policy that determines which tools can be invoked. That separation keeps organisational identity controls from becoming the bottleneck for every tool change.

For MCP, the decision point should be evaluated as close to the server as possible. Identity can establish that a caller is authenticated and assigned to a group, but the platform layer should decide whether that caller may use a given tool, on a given server, under the current context. This is consistent with least privilege and with the practical lessons emerging from agentic systems in the OWASP Agentic Applications Top 10. For autonomous or semi-autonomous agents, a static identity group is not enough because the same agent may need different access by task, environment, or data sensitivity.

• Use IdP groups for coarse access eligibility, not for per-tool authorization logic.
• Keep MCP tool permissions and server restrictions in platform-owned policy-as-code.
• Prefer just-in-time grants and short-lived secrets when a tool must access sensitive systems.
• Log both identity assertions and tool invocation decisions so audit can reconstruct who approved what, and when.

Where this becomes most valuable is in agentic workflows. An autonomous system can chain tools, pivot across servers, and request permissions that were never obvious at provisioning time, which is why runtime authorization matters. NIST’s SP 800-53 Rev. 5 supports this direction through least privilege, access enforcement, and auditability requirements. These controls tend to break down in large federated environments where every MCP server inherits a different owner and policy model because decision rights become fragmented across teams.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, so organisations need to balance change velocity against governance depth. That tradeoff is real when platform teams must approve every new tool scope, especially in fast-moving AI or developer environments.

There is no universal standard for this yet, but current guidance suggests a few patterns. In highly regulated environments, the platform team usually owns server restrictions and the IdP team only exposes approved groups. In smaller environments, the same team may operate both layers, but the boundaries should still be explicit. For autonomous workloads, the right pattern is often context-aware authorization with ephemeral credentials, not broad standing roles.

Two failure modes show up repeatedly. First, teams use directory groups as a proxy for fine-grained tool authorization, which creates slow approvals and excessive privilege. Second, teams let MCP server owners bypass the IdP model entirely, which fragments audit and makes revocation inconsistent. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it highlights why ownership clarity, lifecycle control, and revocation discipline matter most when identities are non-human and operationally dynamic.

The practical rule is simple: the IdP team owns who may qualify, the platform team owns what is actually permitted, and both teams should agree on how exceptions are issued and revoked.

Related resources from NHI Mgmt Group

• Who should own external Kafka access decisions in a platform programme?
• Who should decide whether an agent is allowed to access a digital platform?
• Who should own the response when offensive tests repeatedly uncover the same access flaws?
• How should security teams govern MCP access after EMA is introduced?