MCP management needs governance, access control, and ownership

At a glance

What this is: This is a practitioner guide to managing MCP servers, and its key finding is that the protocol is easy to deploy but hard to govern at scale.

Why it matters: It matters because MCP introduces a new layer of non-human access that has to fit existing IAM, PAM, and security operations without creating shadow infrastructure or unmanaged tool access.

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 full guide to managing MCP servers at scale

Context

MCP is a standard way for AI clients to talk to tools and data sources, which makes it useful but also turns it into an identity and access problem as soon as more than a few servers exist. The primary issue is not building the server, but governing who can use it, what it can call, and who owns it when something breaks.

For identity teams, MCP behaves like a new class of non-human access surface that sits between the user, the AI client, and downstream systems. Without central discovery, OAuth governance, and tool-level access control, organisations end up with shadow MCP deployments that are difficult to inventory, review, and revoke.

This is already a familiar pattern from API and microservice sprawl, but MCP compresses the adoption cycle. The governance model has to catch up before informal deployment becomes normalised infrastructure.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

Q: Why do MCP tools create a governance problem for IAM teams?

A: MCP turns each tool into a potential permission boundary, which means IAM teams must govern many small access decisions instead of one broad application login. If those boundaries are not scoped carefully, autonomous agents can accumulate effective privilege faster than traditional reviews can catch.

Q: What breaks when MCP tool permissions are scoped too broadly?

A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role. In practice, that makes audits less reliable and magnifies the blast radius of any compromise or misconfiguration. The fix is narrower claim-based policy, not looser trust in the calling identity.

Q: How do organisations know whether MCP is becoming shadow infrastructure?

A: Look for servers that are used regularly but not visible in a central catalog, owned informally, or authenticated through per-team workarounds. If users must ask around to find tools or if revocation requires manual chasing, the platform has already moved beyond controlled deployment.

Technical breakdown

OAuth and token handling for MCP servers

MCP server deployments typically rely on delegated authorisation through OAuth, which means they inherit all the usual lifecycle problems of token refresh, callback handling, secure storage, and revocation. The protocol itself does not solve where tokens live or how often they are rotated. If every server implements OAuth separately, the result is duplicated logic and inconsistent control coverage across the environment.

Practical implication: centralise OAuth handling and token governance instead of letting each MCP server manage credentials independently.

Tool-level access control and catalogue discovery

MCP becomes difficult to manage when users cannot reliably find approved servers or understand which tools they are allowed to invoke. A catalog solves the discovery problem, while tool-level scoping constrains what an authenticated user or agent can do once connected. That combination is what turns a loose collection of servers into governable infrastructure.

Practical implication: pair a curated catalog with role-based access control so discovery and authorisation are governed together.

Audit logging, content filtering, and operational ownership

Once AI clients make tool calls on behalf of people, audit trails become essential for attribution, incident response, and compliance. Gateway-level content filtering is also needed to enforce data-handling policies and detect prompt-injection-style misuse before it reaches downstream systems. None of this is sustainable without clear operational ownership, because infrastructure without an owner tends to accumulate silent risk.

Practical implication: require end-to-end logging, gateway filtering, and named operational ownership for every MCP server in production.

NHI Mgmt Group analysis

MCP governance is becoming an NHI problem before most organisations recognise it as one. The moment an MCP server is used by an AI client, it becomes part of the non-human identity estate, complete with authentication, access scope, and revocation requirements. The governance challenge is not the protocol itself but the spread of machine-to-machine access that slips past traditional application ownership. Practitioners should treat MCP as an identity surface, not just an integration layer.

Shadow MCP adoption creates the same control debt that has long defined unmanaged secrets and service accounts. Developers can stand up a working server quickly, which means usage spreads faster than inventory, review, or offboarding processes. That pattern is structurally similar to NHI sprawl, where ease of creation outpaces governance maturity. The named concept here is governance debt at the protocol edge: a fast-growing access layer that arrives before the organisation has controls for lifecycle and oversight.

Access scoping at the tool level is the difference between useful MCP and risky MCP. If all that exists is authentication, then every connected user or agent inherits broad capability inside the server boundary. Fine-grained scoping is what prevents a marketing workflow from inheriting engineering privileges or an AI agent from calling tools it does not need. Practitioners should map MCP permissions to existing identity groups and job functions rather than treating each server as a special case.

Auditability and revocation must be designed as operational primitives, not afterthoughts. The article correctly points to the need to know who called what, when, and with what result, because that is what allows incident response and entitlement review to function. This is where MCP aligns with broader IAM and PAM discipline: if access cannot be attributed or revoked centrally, it is not governable at scale. Teams should expect MCP to be evaluated against the same lifecycle questions they already ask of service accounts and privileged integrations.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For lifecycle governance, the NHI Lifecycle Management Guide is the next step for teams mapping ownership, revocation, and offboarding controls.

What this signals

Governance debt at the protocol edge: MCP is pushing identity teams toward a model where discovery, access, and revocation have to be controlled before usage becomes widespread. The practical signal is that service-account discipline and NHI lifecycle thinking now need to extend into AI-connected tooling, not just infrastructure accounts. Teams should align this work with the NIST Cybersecurity Framework 2.0 and the access control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

If MCP adoption is accelerating in your environment, expect discovery problems to show up before outright security incidents. A curated catalog, tool-level scoping, and immediate revocation paths are the controls that turn MCP from shadow infrastructure into something the programme can actually manage. That is the point at which the architecture begins to resemble governed identity rather than informal integration sprawl.

For practitioners

• Inventory shadow MCP servers Identify every MCP server already running in development, testing, and production, then map each one to an owner, data touchpoints, and the AI clients that can reach it.
• Centralise OAuth and token revocation Remove per-server token handling where possible and move to a controlled layer that manages callback URLs, refresh, and immediate revocation from one place.
• Enforce tool-level scoping by role Tie server access to existing identity groups so users only see and invoke the tools that match their function, with no broad default access.
• Require gateway logging and filtering Capture full tool-call audit trails and filter sensitive content at the gateway before requests reach downstream systems or custom connectors.
• Assign operational ownership for every server Treat each MCP server like production infrastructure with an escalation path, support model, and revocation process when the owning team changes.

Key takeaways

• MCP is easy to deploy but difficult to govern, which makes discovery, ownership, and revocation the real management problem.
• Tool-level access control and central OAuth handling are the practical controls that separate governed MCP from shadow infrastructure.
• Identity teams should treat MCP as a non-human access surface and apply the same lifecycle discipline used for other machine identities.

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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• OAuth controller: A centralised mechanism for handling delegated authorisation flows, token refresh, and revocation across multiple connected services. In MCP environments, it reduces duplication and improves consistency by removing credential handling from individual servers.

What's in the full article

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

• A practical MCP management maturity model that shows what changes from shadow adoption to enterprise scale.
• The Obot Gateway architecture for central OAuth handling, tool-level access control, content filtering, and audit logging.
• The Obot Catalog approach to discovery and reuse across 70+ enterprise integrations.
• Deployment and hosting considerations for cloud and on-premises Kubernetes environments.

👉 Obot's full post covers the maturity model, gateway controls, and deployment choices in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or NHI governance programme, it is worth exploring.