MCP governance now depends on enforcement, not just protocol design

At a glance

What this is: This analysis argues that MCP security now depends on enterprise enforcement layers, because the protocol itself will not enforce authentication, authorization, or audit controls.

Why it matters: IAM, PAM, and NHI teams need to treat MCP servers as governed access paths, not trusted integrations, because call-time authorization and lineage now determine whether delegated tool use remains defensible.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Obot's analysis of MCP governance and runtime enforcement

Context

MCP governance is an identity problem as much as a protocol problem. Once agents and tools are allowed to call downstream systems through MCP servers, the security question becomes who or what is acting, what authority it has at that moment, and whether the decision is checked at the point of use. A static approval record is not enough when the server’s tool set, backend access, and ownership can change after onboarding.

Obot’s analysis is useful because it separates the protocol layer from the enforcement layer. The article’s core claim is that enterprises must build the inventory, lineage, call-time authorization, and audit trail themselves if they want MCP deployments to remain governable under IAM and NHI controls. That is the right frame for a fast-moving integration model that behaves more like runtime access than like traditional application onboarding.

The governance challenge is not unique to MCP, but MCP makes the failure more visible. If a server can be trusted once and then change capability without re-approval, existing joiner-mover-leaver thinking no longer fits cleanly. The control problem shifts from granting access to proving that every invocation was authorized against current context.

Key questions

Q: What breaks when MCP servers are approved once but allowed to change later?

A: The original approval no longer describes the current access surface. If tools, backends, or ownership change after onboarding, the enterprise is operating on stale risk information. That creates blind spots in authorization, logging, and recertification, because the governing record reflects a past state rather than the server’s present capabilities.

Q: Why do MCP deployments complicate NHI governance?

A: MCP connects agents to tools in a way that can blur the line between a legitimate workload request and an uncontrolled execution path. For NHI governance, that matters because tokens, service accounts, and tool permissions are often managed separately, yet they now combine at runtime. If the request is not bound to identity and context, least privilege is only nominal.

Q: How can organisations tell whether MCP access is actually being governed?

A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token. If logs only show a shared credential or generic server activity, the organisation does not have effective identity governance for the protocol.

Q: Who is accountable when an MCP session misuses tools or data?

A: Accountability sits with the organisation that defined the policy, the control plane that granted the session, and the team that owns logging and revocation. If those responsibilities are split, investigation and containment become slow, and the governance gap becomes part of the incident itself.

Technical breakdown

Why MCP changes the enforcement model for identity and access

MCP is a protocol for connecting LLM applications and agents to tools and data sources, but it does not itself enforce policy. That means authentication, authorization, consent, and audit have to be implemented by the enterprise, usually in gateways, proxies, or surrounding policy layers. The architectural issue is that a server may be approved once, then mutate its tools or backend reach later. In identity terms, that is a runtime access problem, not a one-time onboarding event.

Practical implication: treat every MCP server as an enforced access surface and verify policy at invocation, not just at registration.

How identity lineage works across human, agent, and tool calls

Identity lineage in MCP needs to preserve the full chain from human initiator to client or agent, then to the MCP server, tool, and downstream resource. A service principal alone records which credential connected, but not who delegated the action or which agent executed it. This matters because delegated authority is narrower than standing human permissions, and accountability disappears if the chain is collapsed into one opaque technical identity. Good lineage makes post-incident reconstruction and recertification possible.

Practical implication: log the full delegation chain so reviewers can map each action to the initiating human and the acting non-human identity.

Why call-time authorization matters more than connection approval

Connection approval and call-time approval are different security decisions. In MCP, a server can remain connected while its tools, arguments, or target resources change, so authorization has to be re-evaluated for each invocation. That is where least privilege becomes operational rather than theoretical. If policy is only checked when the session starts, revocation becomes slow, and any compromise, role change, or decommissioning leaves an exposure window that is wider than the original approval assumed.

Practical implication: enforce per-call authorization using server, tool, arguments, target resource, and actor identity as the decision inputs.

NHI Mgmt Group analysis

MCP governance is now an enforcement problem, not a protocol problem. The protocol can describe how tools connect, but it deliberately does not enforce the security principles enterprises need. That leaves identity, access, and logging controls to surrounding systems that many deployments still treat as optional. The implication is that MCP teams must stop thinking in terms of approved integrations and start thinking in terms of continuously governed runtime access.

Identity lineage is the missing control plane for delegated tool use. Once a human can delegate work to an agent that then invokes an MCP server and a downstream tool, a single service principal is no longer enough to explain accountability. The article’s human-to-agent-to-tool chain shows why lineage must survive across actor types. That is the only way to make recertification, investigation, and offboarding meaningful in a delegated execution model.

Call-time authorization is the practical boundary between usable and governable MCP. Connection-time approval assumes the security state is stable after onboarding, but MCP tools can drift in scope and backend reach after trust has already been granted. That creates identity blast radius, where a previously safe server can become a broader access path without fresh review. Practitioners should treat every invocation as the real decision point.

Capability drift is the named concept security teams need to track. A server approved in one state can expose different tools, arguments, or downstream systems later, which means the original review no longer describes current risk. This is especially relevant to NHI governance because the object being governed is no longer a static account but a changing access surface. Practitioners need controls that follow the server’s present capabilities, not its original approval record.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• A second finding from the same research shows that only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• For a broader view of agentic risk mapping, see OWASP Agentic Applications Top 10 for the control gaps that emerge when tools are invoked at runtime.

What this signals

Capability drift is the operational warning sign. When server tools, backend reach, or ownership change after approval, the original review is no longer evidence of current control. That means IAM and NHI teams need a living control record, not a point-in-time onboarding checklist, because runtime access surfaces mutate faster than recertification cycles.

The governance pattern here overlaps with workload identity and secrets management, but MCP makes the boundary sharper because the access decision is now tied to an invocation. Teams that already use the Ultimate Guide to NHIs as a reference point should now apply the same discipline to dynamic tool catalogs, not just service accounts and API keys. The practical shift is to make policy and evidence travel with the call.

For teams building out agentic controls, the most useful external frame is the OWASP Top 10 for Agentic Applications 2026. Its value is not in naming more risk, but in forcing security teams to decide where identity, tool permission, and audit enforcement will actually live.

For practitioners

• Build a live MCP inventory Track approved servers, exposed tools, owners, versions, credentials, and downstream systems in a record that updates when the server changes. A spreadsheet from the last review is not enough for operational governance.
• Enforce authorization at every call Check server, tool, arguments, target resource, agent identity, and user identity at invocation time. Do not treat initial connection approval as permission for all subsequent tool use.
• Preserve end-to-end identity lineage Log the full path from human initiator to agent, MCP server, tool invocation, and downstream resource so investigators can reconstruct who authorized and what executed.
• Re-certify changed servers immediately Trigger review when a trusted server adds tools, changes backends, or changes ownership. Capability drift should invalidate the earlier approval until the new state is assessed.
• Centralise call evidence for audit Retain request context, policy decision results, and downstream resource references in a central log so compliance teams can prove what happened after the fact.

Key takeaways

• MCP does not solve security by itself, because the protocol intentionally leaves authentication, authorization, and audit enforcement to implementers.
• The biggest governance failure is stale approval, where a server’s tool set or backend reach changes after trust has already been granted.
• MCP security teams need live inventory, call-time authorization, and full identity lineage if they want runtime tool use to remain auditable.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Identity Lineage: Identity lineage is the traceable relationship between a human owner and the non-human identities that person creates, authorises, or depends on. It allows security teams to connect service accounts, API keys, tokens, and AI agents back to accountable ownership for review, audit, and retirement decisions.
• Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
• Call-time authorization: Authorization evaluated at the moment a tool or resource is actually invoked, rather than when a connection is first established. This matters for MCP because a connected server can change scope later. Call-time checks keep delegated access aligned with current context and make revocation meaningful.

What's in the full article

Obot's full analysis covers the operational detail this post intentionally leaves for the source:

• The MCP server catalog and proxy architecture used to broker OAuth without exposing raw credentials to the server.
• The specific header-based enforcement changes that allow gateways and policy systems to inspect tool and method calls.
• The vendor's implementation approach for logging every call with enough context for audit and investigation.
• How Obot maps access controls to agent-scoped tool sets and server-level permissions in practice.

👉 Obot's full post covers the MCP inventory model, proxy enforcement, and logging details in implementation context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.