MCP architecture expands AI tool access beyond identity controls

At a glance

What this is: MCP architecture gives AI agents a structured way to discover and invoke enterprise tools, but it also exposes gaps in inventory, authorization, and audit that many identity stacks were not built to govern.

Why it matters: IAM, NHI, and AI security teams need to treat MCP as an access-governance problem because tool discovery, shared credentials, and local servers can bypass the controls they already rely on.

Context

MCP architecture is a client-host-server model for connecting AI systems to enterprise tools, but that model changes where consent and authorization are enforced. The problem is not simply that agents can call tools, it is that tool descriptions, local servers, and shared credentials can sit outside the boundaries most identity programmes were designed to see.

For IAM and NHI teams, the core gap is governance rather than connectivity. If an agent can discover a tool, inherit a credential, or act through a local server without clean identity attribution, then inventory, approval, and audit assumptions start to fail before a security team ever reviews the action.

WitnessAI's article argues that this is already a board-level issue because organisations are being asked to explain how AI-driven access is controlled. That is typical of early MCP adoption, where integration moves faster than the controls needed to govern it.

Key questions

Q: What breaks when MCP servers are not registered centrally?

A: Unregistered servers create shadow deployment. That means the organisation cannot tell which tools are connected, which identities can invoke them, or whether a connection is governed at all. The result is hidden access paths that weaken both policy enforcement and assurance reporting.

Q: Why do local MCP servers create more governance risk than routed ones?

A: Local servers can be added in developer tools without central approval and can communicate over paths that never cross a managed inspection point. That means the server may have active access and data movement even though security tools cannot see it. The governance risk is not the server type alone, but the absence of an authoritative inventory record.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Q: What should security teams do when model-driven access uses shared credentials?

A: Require the agent path to be treated as a governed identity flow, not a generic integration. That means binding tool access to named ownership, restricting high-impact actions with runtime review, and refusing to rely on a shared credential as proof of acceptable trust.

Technical breakdown

How MCP discovery moves tool descriptions into model context

MCP separates hosts, clients, and servers, and the discovery step is where most security friction begins. When a client calls tools/list, the server returns tool descriptions into the model context before a user necessarily approves execution. That means instructions can influence the model before a tool is invoked, which is why poisoned descriptions and changeable descriptions are security problems, not just UI issues. The protocol's stateless design also reduces the value of a single session-control point, because the security decision is no longer concentrated at one durable boundary.

Practical implication: govern tool discovery as an authorization event, not just a catalog lookup.

Why local stdio servers escape normal monitoring

Local stdio deployments run as subprocesses on the same machine as the launching application, so their traffic does not traverse the network in a way most DLP, proxy, or CASB tools can inspect. That makes the security posture dependent on endpoint context, application trust, and operating-system privileges rather than only on perimeter visibility. In practical terms, MCP can create a blind spot where a local server uses the host application's permissions while remaining invisible to the network stack. That is why the article treats local server activity as a governance and observability problem, not just an implementation detail.

Practical implication: extend monitoring to endpoint-launched MCP servers and the privileges they inherit.

How authorization breaks when identity does not follow the agent

MCP remote deployments may use OAuth 2.1, but authorization is still inconsistent across implementations and identity does not always propagate cleanly end to end. A server can therefore operate with a shared credential set even when multiple users or agents are interacting with it. From an identity perspective, that means the agent may borrow authority without being individually governed as a distinct identity. The issue is not only whether the protocol supports authorization mechanics; it is whether enterprise controls can maintain identity-linked accountability when the agent's access path is mediated by a host, a client, and a downstream server.

Practical implication: require identity-linked audit records for every agent action that uses shared or inherited credentials.

NHI Mgmt Group analysis

Tool discovery is now an authorization boundary, not a convenience layer: MCP turns the moment of tool advertisement into a governance event because model context can be shaped before a user approves execution. That breaks the old assumption that access decisions happen only after identity has been clearly established. Practitioners should treat discovery-time controls as part of the access model, not as a supporting detail.

Shadow MCP is the same problem as shadow IT, but with delegated authority: local MCP servers, IDE plugins, and desktop clients can create agent access paths that are invisible to standard inventory processes. The governance gap is not merely that the tools are unknown; it is that their authority can inherit from a host application and bypass the normal lifecycle controls that track human or service identities. Practitioners need to govern the server estate, not just the model.

Shared credentials are the identity failure mode that matters most here: MCP can let one server or agent operate across users with authority that is not cleanly bound to a single identity record. That is a direct challenge to auditability, recertification, and accountability, because the action trail no longer maps neatly to a person, a service account, or a well-scoped workload identity. Practitioners should assume attribution will fail unless it is designed into the control plane.

Runtime enforcement is the missing layer between protocol adoption and enterprise trust: protocol revisions can improve mechanics, but they do not close poisoned tool descriptions, prompt injection, or local-server blind spots. The named concept here is runtime governance gap: a state where the protocol enables access, but the enterprise still lacks an independent control layer that can inspect intent, execution, and attribution. Practitioners should build governance outside the protocol as if the protocol itself were untrusted.

Identity programmes must now account for model-timed actions, not just human-timed approvals: MCP accelerates the shift from user-driven requests to agent-mediated execution. That means access review, logging, and policy enforcement all have to cope with actions that are discovered, prepared, and executed inside a single conversational flow. The practitioner conclusion is simple: if the control only works after the action is already obvious, it is too late for MCP.

From our research library:

• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
• Read next: Top 10 Agentic AI Identity Issues

What this signals

Runtime governance gap: MCP adoption is exposing a gap between what the protocol can connect and what the enterprise can actually govern. The practical risk is not just hidden tools, but hidden authority paths that move faster than inventory, approval, and audit cycles can absorb. That is why runtime enforcement has to sit beside identity governance, not inside it.

MCP also makes agent inventory and server inventory inseparable. If the organisation cannot tell which hosts spawn MCP sessions, which servers they reach, and which credentials those servers inherit, then policy becomes reactive instead of preventative. The next governance phase is to treat agent connectivity as a live identity estate, not an integration backlog.

The scale of the problem is already visible in broader AI adoption data, with 19% of organisations giving AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey. That figure matters here because MCP can convert broad access into operational reality unless the runtime layer constrains what agents can actually do.

For practitioners

• Inventory every MCP server and agent path Catalogue remote servers, local stdio servers, IDE plugins, and desktop clients that can spawn MCP sessions. Map each one to the enterprise systems it can reach and the credentials it can inherit.
• Enforce deny-by-default tool access Require explicit allowlists for tools and servers, then block unknown MCP endpoints until ownership, purpose, and authorization are documented. Treat tool-description changes after approval as a review trigger.
• Add runtime controls before execution Inspect prompts and tool calls before they execute, then require human review for consequential actions such as record deletion, external communications, or contract-bearing outputs.
• Tie every agent action to identity Record prompts, responses, tool calls, and the initiating human identity in an immutable audit trail so reviewers can trace each action back to accountable ownership.
• Separate local server trust from network trust Extend monitoring to endpoints that launch local MCP servers, because network controls alone will not reveal subprocess activity or the privileges those servers inherit.

Key takeaways

• MCP creates an identity governance problem because model-driven tool access can bypass the inventory, approval, and attribution assumptions that traditional controls rely on.
• Local servers, shared credentials, and poisoned tool descriptions are the practical weaknesses that turn protocol adoption into hidden authority.
• The right response is an independent enforcement layer that combines inventory, deny-by-default policy, runtime inspection, and identity-linked audit records.

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.
• Shadow MCP: Shadow MCP is an unauthorized or ungoverned use of the Model Context Protocol inside an organization. It appears when AI agents, scripts, or tools connect to data or actions through MCP servers without security review, inventory, policy control, or monitoring. This creates hidden access paths, data exposure, and weak accountability.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Identity-Bound Audit Trail: An identity-bound audit trail links a sensitive action to a verified user, recipient, timestamp, and outcome. For secret sharing, this gives security teams the evidence needed to review handoffs, investigate misuse, and distinguish governed transfers from informal credential exchange.

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 or AI governance programme, it is worth exploring.