Black Hat USA 2026 — Part 2

Why CISOs need a central architecture before MCP becomes the next uncontrolled integration layer

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

For years, enterprise security has struggled with integration layers that became critical before anyone formally decided they were infrastructure.

APIs proliferated before API governance matured.

Cloud identities multiplied before organizations understood workload identity.

SaaS integrations accumulated OAuth grants faster than security teams could inventory them.

Service accounts became embedded across business processes and survived long after their original owners had left.

Model Context Protocol risks becoming the next iteration of the same pattern — except potentially at much greater speed.

The difference is authority.

MCP is often described as a standardized way for AI applications and agents to connect to external tools, data sources and services. Technically, that is correct.

Architecturally, it is incomplete.

Once an AI agent can discover a tool, authenticate to it, provide parameters, receive its output and use that output to decide what to do next, MCP is no longer merely transporting context.

It is participating in the delegation of authority.

That distinction should matter enormously to CISOs.

MCP does not merely transport context. It transports authority.

And Black Hat USA 2026 provided several indications that the security industry is beginning to recognize the consequences.

Black Hat’s MCP Signal

One of the more important observations from Black Hat this year was not a single spectacular MCP vulnerability.

It was how normal MCP had already become.

Black Hat’s own AI Agent Security Masterclass described modern agents as systems capable of reasoning, planning and executing actions through tools, workflows and MCP. Its threat model explicitly included prompt injection manipulating tool use, excessive agency, memory poisoning and MCP-specific supply-chain vulnerabilities. The defensive side included MCP gateways, OAuth, scanning and controls around agent autonomy. (⁠Black Hat)

That matters.

Security conferences tend to reveal technological transitions before enterprise governance catches up with them. A technology moves from research topic, to offensive target, to security product category, and eventually to enterprise infrastructure.

MCP appears to be moving through several of those stages simultaneously.

Black Hat’s Arsenal even included MCP-related security projects, including an MCP-based SIEM simulator and HoneyMCP, a deception layer specifically designed for MCP servers. (⁠Black Hat)

On the Business Hall side, the signal was equally interesting.

Black Hat’s AI Summit described an emerging “agentic fabric” consisting not merely of AI models, but interconnected agents, MCP servers, skills, plugins, hooks and connectors. (⁠Black Hat)

TrendAI researchers advertised an AI-powered vulnerability sweep covering 19,000 MCP servers. (⁠Black Hat)

And vendors were already demonstrating inventories of agents and the MCP servers they trust, verified MCP catalogs, gateway enforcement and kill switches for agents that deviate from expected behavior. (⁠Jetstream Security)

The individual products matter less than the direction of travel.

A control plane is beginning to form around MCP.

That usually happens when something has stopped being merely a developer feature.

The Architectural Mistake

The easiest mistake enterprises can make now is to classify MCP as an AI development issue.

That would put responsibility somewhere between developers, AI platform teams and application architecture.

Security would then review individual implementations.

That model will not scale.

Because MCP combines several functions that enterprises traditionally governed separately:

• service discovery
• integration middleware
• delegated identity
• machine-to-machine authorization
• execution

An MCP server can expose a database query.

Or a Git repository.

Or a ticketing system.

Or a cloud management function.

Or a security scanner.

Or an ERP transaction.

Or a file repository.

Or an internal API.

The protocol does not determine the business consequence.

The tool behind it does.

This makes MCP security fundamentally different from securing a chatbot interface.

The relevant question is no longer:

Can someone manipulate what the AI says?

It becomes:

What can the AI cause the enterprise to do?

From API Sprawl to Authority Sprawl

Most large organizations already understand API sprawl.

Thousands of APIs exist across cloud environments, SaaS platforms, internal applications and integration layers.

Many are poorly inventoried.

Some are undocumented.

Some use outdated authentication.

Some expose more functionality than anyone realizes.

MCP introduces the possibility of a similar phenomenon at the agent layer.

But there is an important difference.

An API generally waits for something to call it.

An agent can decide that calling it is the next appropriate action.

That changes the threat model.

Imagine an enterprise agent with access to:

• SharePoint
• GitHub
• ServiceNow or another ITSM platform
• Azure
• email
• an ERP system
• a vulnerability scanner

Each integration may be legitimate.

Each MCP server may be correctly configured.

Each identity may be valid.

Each API request may be syntactically correct.

And yet the resulting system may possess far more authority than anyone intended.

This is compositional privilege.

The danger does not necessarily exist inside any individual component.

It emerges from their combination.

Agent A can read information from System B.

That information influences its reasoning.

The agent invokes Tool C.

Tool C changes System D.

System D triggers automation E.

Automation E possesses another identity.

Suddenly an apparently modest MCP permission sits at the beginning of a highly privileged execution chain.

Traditional access reviews rarely model this.

They examine permissions.

Agentic systems require us to examine consequences.

MCP Changes the Meaning of Integration Security

Traditional integration security largely asks four questions:

Who connects?

To what?

Using which credentials?

With which permissions?

MCP adds another:

Who decides when the connection should be used?

That decision may no longer belong to deterministic application logic.

It may belong to an AI agent interpreting context.

This creates an uncomfortable architectural combination:

probabilistic decision-making connected to deterministic authority.

The model reasons probabilistically.

The API executes deterministically.

If the model concludes that an account should be disabled, a repository modified, a message sent or an infrastructure resource reconfigured, the downstream system does not care how uncertain the reasoning was.

It receives an authorized command.

This is why conventional AI guardrails alone cannot solve the problem.

The authorization boundary must exist outside the model.

MCP Servers Are Becoming Security Principals

Enterprises should therefore stop viewing an MCP server simply as a connector.

Operationally, it is closer to a privileged integration component.

• It needs an owner.
• It needs an identity.
• It needs a defined purpose.
• It needs an approved set of consumers.
• It needs authorization boundaries.
• It needs logging.
• It needs lifecycle management.
• It needs vulnerability management.
• And eventually, it needs revocation.

That sounds remarkably similar to the controls organizations already apply — or should apply — to APIs, service principals, enterprise applications and privileged middleware.

There is a reason.

MCP is converging with those categories.

The Shadow MCP Problem

The immediate enterprise risk may not even be sophisticated exploitation.

It may simply be uncontrolled adoption.

Developers can add MCP servers because they are useful.

AI coding environments can consume them.

Employees can experiment with them.

Business teams will eventually connect agents to SaaS services.

Security teams may discover these relationships only after they have become operational dependencies.

This is Shadow MCP.

The Black Hat ecosystem was already explicitly talking about discovering MCP servers running on employee endpoints and identifying unapproved agentic components that traditional gateways or endpoint controls might not expose clearly. (⁠backslash.security)

That should sound familiar.

We have seen the same lifecycle with:

• Shadow IT.
• Shadow SaaS.
• Shadow Cloud.
• Shadow APIs.
• Shadow AI.

MCP could combine characteristics of all five.

The difference is that an unapproved SaaS application might expose data.

An unapproved MCP integration could expose both data and action.

The CISO Response Should Be Architectural

Blocking MCP would be the wrong response for most enterprises.

So would allowing every AI project to design its own security model.

The better response is to establish a common enterprise MCP architecture while adoption is still relatively young.

The objective is not central control for its own sake.

It is to create common trust boundaries.

A mature enterprise architecture should eventually provide at least the following capabilities.

1. An Enterprise MCP Registry

The first requirement is visibility.

Organizations need to know which MCP servers exist.

Not only officially deployed servers.

All of them.

The registry should answer:

• What MCP server is this?
• Who owns it?
• Who operates it?
• Which version is deployed?
• Where did it originate?
• Which agents consume it?
• Which tools does it expose?
• Which identities does it use?
• What data can it access?
• What actions can it perform?
• What business process depends on it?

This turns MCP discovery into governance.

Registration should eventually become a prerequisite for production use.

Unregistered MCP should be treated much like an unknown enterprise application or unmanaged privileged service.

2. A Central MCP Gateway

Not every MCP interaction necessarily needs to traverse one physical gateway.

But enterprises need a logically centralized enforcement layer.

The gateway becomes the point at which enterprise policy can be separated from agent reasoning.

Its responsibilities can include:

• authentication,
• authorization,
• schema validation,
• tool filtering,
• rate limiting,
• content inspection,
• data-loss controls,
• policy enforcement,
• logging,
• risk-based restrictions,
• and emergency revocation.

This is strategically important.

The model should not be the ultimate authority over whether its requested action is permitted.

The agent proposes an action.

The control plane authorizes it.

That separation may become one of the foundational principles of agentic security.

Black Hat’s own training material already listed MCP gateways and OAuth among practical defenses for agent architectures. (⁠Black Hat)

The industry is moving toward the same conclusion.

3. Tool-Level Authorization

Authorizing access to an MCP server is too coarse.

Consider an enterprise IT MCP server exposing:

get_device_status

search_user

reset_password

disable_account

isolate_endpoint

delete_device

Giving an agent access to the server cannot mean giving it equal authority over every tool.

Authorization therefore needs to move down to the tool level.

And sometimes further.

An agent may be permitted to:

read endpoint status,

but not isolate endpoints.

It may isolate workstations,

but not domain controllers.

It may draft an account-disable action,

but require human approval before execution.

It may reset ordinary accounts,

but never privileged identities.

This is where MCP security begins to resemble privileged access management.

The unit of authorization becomes increasingly granular:

Agent × Tool × Resource × Context × Time

4. Identity Federation

Hard-coded API keys inside MCP configurations should be considered a transitional architecture.

Enterprise MCP needs identity federation.

Agents need identifiable principals.

MCP servers need identifiable workloads.

Tool calls need attributable identities.

Backend systems need to know which authority ultimately caused an action.

Otherwise enterprises risk creating chains such as:

Human
→ Agent
→ MCP
→ Service Account
→ API
→ Application

where the final application sees only:

Service Account.

The causal identity has disappeared.

That destroys accountability.

A mature architecture should preserve the chain of delegation.

Who initiated the process?

Which agent acted?

Which MCP server mediated the action?

Which tool was called?

Which backend identity executed it?

This is not merely logging.

It is delegated identity provenance.

5. Tool Provenance

Enterprises will also need to know where tools come from.

An MCP server can change.

Its tool definitions can change.

A tool description can change.

Its backend implementation can change.

Its dependencies can change.

The server itself can be replaced.

This makes provenance essential.

Production MCP components should increasingly require:

approved source,

signed artifacts where applicable,

controlled build pipelines,

version pinning,

dependency scanning,

change management,

integrity verification,

and revocation capability.

This is where MCP governance intersects with the AI supply chain — the subject of the next article in this series.

Because the important dependency may no longer simply be executable code.

The description of what a tool does can itself influence agent behavior.

6. Software Accreditation

One of the most dangerous organizational shortcuts would be treating MCP integrations as configuration rather than software.

If an MCP server can cause privileged enterprise actions, it belongs inside the secure software lifecycle.

That means risk classification.

Security review.

Ownership.

Testing.

Change control.

Vulnerability management.

Dependency management.

Production approval.

Retirement.

This is particularly important in Low-Code and AI development environments where creating integrations may become dramatically easier.

Ease of development cannot imply exemption from engineering governance.

The opposite may be true.

The easier privileged integrations become to create, the more important lightweight but mandatory accreditation becomes.

7. Runtime Logging

Traditional application logs will not be enough.

Security teams need to reconstruct agent execution chains.

For a significant action, investigators should be able to determine:

what input the agent received,

which context influenced the decision,

which agent made the decision,

which MCP server was selected,

which tool was invoked,

which parameters were supplied,

which identity authorized the action,

what the backend returned,

what subsequent action resulted,

and what information left the environment.

This creates something enterprises largely do not have today:

an audit trail of machine reasoning translated into enterprise action.

That will become essential for incident response.

It will also become essential for compliance.

8. MCP Tiering

Not every MCP server represents equal risk.

A weather-data MCP server is not equivalent to an Azure administration MCP server.

A sensible enterprise model therefore needs risk tiers.

For example:

Tier 3 — Informational

Read-only public or low-sensitivity information.

Tier 2 — Enterprise Read

Access to internal business information without modification authority.

Tier 1 — Enterprise Action

Ability to modify business systems or initiate workflows.

Tier 0 — Privileged Authority

IAM, security tooling, cloud control planes, CI/CD, PKI, ERP administration or other systems capable of materially changing enterprise trust.

The controls should increase dramatically between tiers.

Tier-0 MCP should be treated as privileged infrastructure.

Because that is what it is.

9. The Kill Switch

Every organization deploying autonomous agents eventually needs to answer a deceptively simple question:

How do we stop one?

Not shut down the AI platform.

Not disconnect every MCP server.

Not revoke every enterprise credential.

Stop that agent.

Immediately.

Black Hat sponsor demonstrations this year were already explicitly showing agent kill-switch concepts — including targeted revocation or quarantine when agent behavior deviates from its expected design. (⁠Black Hat)

The terminology may sound product-oriented.

The architectural requirement is not.

Every autonomous system with meaningful authority needs a revocation mechanism.

This should include the ability to disable:

the agent identity,

its MCP access,

individual tools,

credentials,

sessions,

or specific authority paths.

Revocation must operate faster than governance.

Because incidents operate faster than committees.

The MCP Control Plane

Put these controls together and a larger architecture begins to appear.

It looks something like this:

Agents
↓
Enterprise MCP Gateway
↓
Identity + Policy Enforcement
↓
Approved MCP Registry
↓
Authorized Tools
↓
Enterprise Systems

Surrounding the entire chain are:

• Telemetry
• Provenance
• Risk Classification
• Software Accreditation
• Runtime Monitoring
• Revocation

This is effectively an MCP control plane.

And large enterprises may eventually need one for the same reason they needed API management, identity governance and cloud control planes.

Not because every integration is dangerous.

Because thousands of individually reasonable integrations eventually become infrastructure.

READ / ACT / EGRESS

There is another principle CISOs should establish early.

MCP authorization should distinguish three fundamentally different capabilities.

READ

What information may the agent obtain?

ACT

What may the agent change?

EGRESS

Where may information leave the environment?

These permissions should not automatically inherit from one another.

An agent that can read confidential documents does not automatically need to email them.

An agent that can create a support ticket does not automatically need to read every ticket.

An agent that can query a production database does not automatically need the ability to modify it.

And an agent capable of modifying infrastructure does not automatically need unrestricted Internet access.

This separation is important because many dangerous agentic attack chains require all three.

• Read something sensitive.
• Take an action.
• Send something somewhere.

Breaking that chain structurally is more reliable than asking the model to behave.

Least Privilege Is No Longer Enough

Traditional security says:

Least Privilege.

Agentic systems require an extension:

Least Agency.

Privilege describes what a principal is technically authorized to do.

Agency describes what an autonomous system is capable of deciding to do using that privilege.

Those are not identical.

An agent might possess five individually reasonable permissions.

But together they could allow it to:

discover sensitive information,

modify infrastructure,

create credentials,

communicate externally,

and conceal the resulting activity.

The security review therefore cannot stop at entitlement analysis.

It must examine combinations.

The question becomes:

What sequences of actions become possible when these tools are composed?

That is a much harder security problem.

But it is the correct one.

The CISO Architecture Decision

There is a narrow window in which enterprises can make this relatively easy.

MCP adoption is still young enough in many organizations that architecture can precede sprawl.

That window will not remain open indefinitely.

Once hundreds of agents depend on dozens of MCP servers embedded across developer workstations, business applications, security operations and cloud automation, introducing central governance becomes politically and technically expensive.

We have seen this movie before.

• With Active Directory service accounts.
• With APIs.
• With SaaS.
• With cloud.
• With OAuth applications.
• With Kubernetes.
• With machine identities.

Security governance usually arrives after operational dependency.

MCP gives us an opportunity to reverse the order.

What I Would Ask as a CISO Now

I would not start by asking whether the organization “uses MCP.”

That question will quickly become meaningless.

I would ask:

• Where are MCP servers already running?
• Which agents consume them?
• Who owns them?
• Which enterprise systems can they reach?
• Which identities do they use?
• Which tools can modify production systems?
• Can we see every MCP tool invocation?
• Can we distinguish the human, agent and workload identities involved?
• Can security revoke one agent without disabling the platform?
• Are MCP servers subject to software accreditation?
• Do we have an approved registry?
• Do we have a gateway architecture?
• Can developers install unapproved MCP servers?

And perhaps most importantly:

Who owns MCP security architecture across the enterprise?

If the answer to the last question is unclear, that is probably the first problem to solve.

From Integration Architecture to Authority Architecture

Black Hat USA 2026 suggests that the security industry is beginning to understand something deeper about agentic AI.

The model itself is only one component.

The real enterprise system consists of:

• models,
• agents,
• identities,
• MCP servers,
• skills,
• plugins,
• tools,
• data,
• APIs,

and control planes.

The security boundary exists across all of them.

That is why MCP matters strategically.

It is becoming the connective tissue between reasoning and execution.

And connective tissue rarely remains “just an integration protocol” once the enterprise begins depending on it.

The next generation of privileged infrastructure may therefore look surprisingly mundane.

Not another domain controller.

Not another hypervisor.

Not another cloud management console.

It may be a protocol layer quietly connecting thousands of AI agents to the systems that actually run the enterprise.

The CISO’s job is to recognize that transition before attackers do.

Because the critical question is no longer simply whether an agent can access information.

It is whether that information can become a decision —

whether that decision can become a tool call —

whether that tool call carries an identity —

and whether that identity carries enough authority to turn machine reasoning into enterprise consequence.

MCP does not merely transport context.

It transports authority.

And authority requires architecture.

Black Hat USA 2026 Series

The Architecture of Trust Is Changing

Next:Part 3 — The New AI Supply Chain

The next trust problem follows directly from MCP.

Once agents discover and invoke tools, every model, skill, prompt, MCP server and runtime influencing those decisions becomes part of the supply chain.

And that changes what a dependency means.

The AI supply chain contains both executable code and executable meaning.

Publication Note & Disclaimer
This article provides security and governance analysis, not legal advice. Regulatory obligations must be assessed against the facts, jurisdictions, data types, and roles of the organizations involved.

This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.