Model Context Protocol is moving rapidly from developer convenience to enterprise infrastructure.

That transition is creating a familiar problem in an unfamiliar form.

For years, security teams have dealt with shadow IT: software, cloud services and applications adopted outside normal procurement, security and governance processes.

MCP introduces a related problem, but with a materially different risk profile.

An unmanaged MCP server is not merely another application an employee has chosen to use.

It can become a machine-facing route to tools, data and actions.

That difference changes the enterprise question.

The traditional question was:

What software is being used outside our control?

The emerging MCP question is:

What machine capabilities can our AI systems reach — and what can those capabilities actually do?

That is the problem behind Shadow MCP.

From shadow applications to shadow action surfaces

WorkOS highlighted the issue on 10 August 2026, arguing that traditional shadow-IT discovery was designed around network-visible applications, while a significant portion of MCP activity can take place locally through processes running inside IDEs, terminals and desktop environments. In those cases, the connection between an AI client and an MCP server may never traverse the network boundary that older discovery tools were designed to observe.

The implication is more important than the discovery gap itself.

Shadow IT was primarily about unsanctioned applications.

Shadow MCP can become about unsanctioned machine capability.

An MCP server may give an AI system access to:

• local files;
• source repositories;
• databases;
• customer records;
• developer tooling;
• enterprise APIs;
• deployment infrastructure; or
• workflows capable of changing business systems.

The risk therefore moves beyond the presence of an unknown application.

It extends to the authority and consequences of machine action.

Discovery is necessary. It is not sufficient.

The first requirement of a mature MCP programme is straightforward:

Know what exists.

Organisations need an inventory of the MCP servers, clients and agentic systems operating across their environment.

But discovery answers only one question:

What is present?

It does not automatically answer:

What exactly is this machine-facing service?

Who operates it?

Which agents are capable of invoking it?

Under whose authority are those agents acting?

Which resources and tools can they reach?

Has the relevant machine or authority state changed?

What evidence remains after the interaction?

Those questions belong to different control layers.

Treating them all as a single “MCP security” problem makes the architecture harder to reason about.

Authentication protects the connection — not the entire trust relationship

The official MCP security model includes authorization mechanisms designed to protect access to restricted remote MCP servers. The current MCP authorization guidance is built around OAuth-based flows and explicitly treats authorization as a core security concern for sensitive resources and operations.

That is essential infrastructure.

But authentication and authorization do not eliminate the need for data governance, attribution or machine accountability.

Forcepoint made this distinction explicit in another 10 August analysis. Its recommended attribution trail spans four elements:

agent identity → triggering user → data accessed → action taken.

It also argues that a fully authenticated MCP connection can still expose data or actions that should not have been available to the agent in the first place.

This is an important architectural boundary.

Authentication answers:

May this connection proceed?

Data governance asks:

What may pass through it?

An execution gateway asks:

Which actions may be performed?

Machine identity and evidence ask:

What machine is participating, who stands behind it, under what authority, and what can a relying party establish later?

These functions complement one another.

They should not be confused with one another.

A more useful enterprise model

As MCP matures, businesses will need to separate at least seven distinct concerns.

1. Discovery

What MCP servers and agents exist?

This includes local processes, remotely hosted servers, enterprise-managed services and developer-installed integrations.

Without discovery, nothing else can be governed consistently.

2. Authentication and access

Who or what is permitted to connect?

Identity providers, OAuth infrastructure and enterprise access-management systems remain central here.

3. Governance

Which MCP servers, tools, resources and operations are allowed?

This is where organisational policy, allowlists, gateways, human approvals and tool-level controls become important.

4. Machine identity

What machine-facing service or agent is actually participating?

An endpoint name, package name or API credential may contribute to identification, but they are not necessarily the complete accountable identity of the machine relationship.

5. Operator and authority

Who stands behind the machine — and under whose authority is it acting?

The identity of an agent and the authority delegated to it are not the same thing.

A machine may be identifiable while its authority is expired, revoked, narrowed or contextually inappropriate.

6. Evidence

What information supports the claimed identity and authority?

For consequential interactions, organisations increasingly need evidence that can be inspected, retained and correlated with the action that occurred.

7. Current state

Can a relying party determine whether that evidence remains current?

Machine relationships change.

Credentials expire.

Services are replaced.

Permissions are revoked.

Operators change.

Trust therefore cannot be treated as a permanent binary attribute.

It has a lifecycle.

Shadow MCP becomes more important as MCP succeeds

Shadow MCP should not be interpreted as evidence that MCP itself is failing.

Quite the opposite.

The MCP project's own 2026 roadmap makes enterprise readiness, governance and production-scale infrastructure explicit priorities. The July 2026 specification further moved the protocol toward stateless, routable and scalable infrastructure suitable for broader production use.

The trust problem becomes more important because the protocol is becoming more useful.

A server that allows an AI assistant to retrieve public documentation presents one risk profile.

A server connected to confidential customer information presents another.

A server that lets an agent deploy software, modify infrastructure, change a database or trigger a business workflow creates a different class of consequence entirely.

The maturity path therefore looks less like:

Connect → Authenticate → Done

and more like:

Connect
→ Discover
→ Govern
→ Identify
→ Attribute
→ Evidence
→ Re-check

That is the architecture enterprises are beginning to need.

The key distinction: internal governance versus externally resolvable trust

Most enterprise MCP controls are naturally internal.

A company can maintain:

• an MCP inventory;
• a gateway;
• access-control policies;
• internal agent identities;
• audit logs;
• data-classification rules; and
• approval workflows.

Those mechanisms are essential.

But machine interactions will increasingly cross organisational boundaries.

An AI agent belonging to Organisation A may need to interact with an MCP service operated by Organisation B.

A relying party may need to establish whether a machine identity or authority relationship is still current without receiving privileged access to another company's internal IAM system, gateway or security dashboard.

That creates a different requirement:

A portable, machine-readable and independently resolvable evidence layer around the relationship.

It is this boundary — between internal control and external reliance — that becomes strategically important as agentic systems become more autonomous and interconnected.

Where ECZ-ID fits

ECZ-ID is being developed as Identity & Evidence Infrastructure for the Machine Economy.

Its role is not to replace:

• enterprise IAM;
• OAuth;
• MCP gateways;
• DLP;
• security monitoring;
• human approval;
• internal policy engines; or
• regulatory authorities.

Those systems already have legitimate control responsibilities.

The complementary ECZ-ID question is:

What independently resolvable identity, accountable operator, authority, current state and evidence can a relying party establish about a machine relationship?

For MCP and agent infrastructure, that creates a potential evidence chain around:

organisation
→ operator
→ agent
→ authority
→ MCP service
→ evidence
→ lifecycle state

The objective is not to centralise every enterprise control into one platform.

It is to make critical machine relationships legible and independently checkable.

What an enterprise should ask about Shadow MCP

A practical Shadow MCP review should go beyond a list of installed servers.

Security, platform and AI-governance teams should be able to answer:

Inventory

• Which MCP servers are currently used?
• Which are local and which are remote?
• Which are formally approved?
• Which remain unmanaged?

Operator

• Who publishes or operates each MCP surface?
• Is that operator relationship independently verifiable?

Agent

• Which agents can invoke each MCP?
• Can machine actions be distinguished from human actions?

Authority

• What authority is available to each agent?
• Is that authority scoped by tool, resource and action?
• Can it be revoked or narrowed?

Consequence

• Can the MCP read sensitive information?
• Can it write, delete, deploy, transfer or administer?

Evidence

• What is recorded when an action occurs?
• Can the machine, operator and authority relationship be reconstructed afterwards?

Lifecycle

• What happens when a server, credential, operator or agent changes?
• Can relying parties re-check current state rather than depending on a historical assertion?

That is a materially stronger control model than simply asking whether an MCP server exists.

The enterprise MCP question is changing

The first question was:

Can our AI connect to this system?

Then:

Can we secure the connection?

Shadow MCP introduces:

Do we even know which machine capabilities are operating across the organisation?

But the next question is already visible:

Can we establish what those machines are, who stands behind them, what authority they possess and what evidence another relying party can independently verify?

That question reaches beyond MCP.

It is part of the infrastructure required for a broader machine economy.

And as AI systems move from assisting humans to performing increasingly consequential work, it will become harder to treat machine identity, authority and evidence as optional metadata.

They become part of the control plane.

Assess your MCP trust surface

EcoCitizenz / ECZ-ID provides MCP and Agent Trust infrastructure designed around machine identity, accountable operator relationships, authority, evidence and independently resolvable current state.

Recommended CTA:
Run the free MCP scanner first. Where the findings warrant deeper review, progress into the £395 MCP Readiness Audit and the appropriate ongoing MCP / Agent Trust layer.

Primary internal link: MCP & Agent Trust landing page
Secondary internal link: Free MCP scanner
Commercial link: £395 MCP Readiness Audit
Trust proof link: ECZ-ID Resolver

Frequently Asked Questions

What is Shadow MCP?

Shadow MCP describes MCP servers or MCP-enabled capabilities operating without sufficient organisational visibility, approval or governance. The problem can be especially difficult where servers run locally inside developer environments rather than across network paths traditional SaaS-discovery tools were designed to observe.

Is an unmanaged MCP automatically insecure?

No.

“Unmanaged” and “insecure” are different concepts.

The problem is that an organisation cannot consistently assess, govern or evidence infrastructure it does not know exists.

Does OAuth solve Shadow MCP?

OAuth is an important component of MCP authorization, particularly for protecting restricted remote MCP services. It does not by itself provide complete MCP inventory, data governance, durable operator identity, full agent attribution or independently resolvable lifecycle evidence.

Do MCP gateways solve the problem?

Gateways can provide essential controls around access, policy, traffic, tool filtering and observability.

Machine identity, accountable operator attribution, authority evidence and external resolution are complementary concerns.

Why does agent identity matter?

As agents perform more consequential work, organisations need to distinguish machine-initiated actions from human actions and establish which agent was responsible, what authority applied and which system mediated the action.

What should organisations do first?

Begin with MCP and agent inventory, identify consequential tools and data access, enforce least privilege and appropriate approval controls, establish attribution and logging, and then determine which identity, operator, authority and lifecycle evidence must remain independently verifiable.

SOURCE NOTES FOR PUBLISHING

WorkOS — 10 August 2026
“The tools that caught shadow IT can't see MCP sprawl.”
Supports the Shadow MCP/local-process discovery thesis.

Forcepoint — 10 August 2026
“MCP Security Overlooks the Data Your AI Agents Can Reach.”
Supports the distinction between authentication, data governance and attribution.

Model Context Protocol — official documentation
Authorization and security guidance.

Model Context Protocol — 2026 Roadmap / July specification
Supports the broader enterprise-readiness and infrastructure-maturity context.