Black Hat USA 2026 — Part 0 of 12

A CISO’s Guide to the Twelve Security Lessons That Matter Beyond the Conference

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

Black Hat USA 2026 — The Complete Series

Overview — The Architecture of Trust Is Changing
A CISO’s Guide to the Twelve Security Lessons That Matter Beyond the Conference

Part 1 — The Agent Is Becoming the New Privileged User
Why AI security is turning into identity and access management

Part 2 — MCP Is Becoming Enterprise Infrastructure
Why CISOs need a central architecture before MCP becomes the next uncontrolled integration layer

Part 3 — The New AI Supply Chain
Models, skills, agents and inference runtimes are becoming executable dependencies

Part 4 — When Security Tools Become the Attack Surface
Why scanners, EDR and security automation deserve Tier-0 thinking

Part 5 — Prompt Injection Is Becoming an Execution Problem
Why the industry should stop treating prompt injection as an AI-content issue

Part 6 — AI Is Changing the Economics of Vulnerability Discovery
From elite security research to machine-scale exploitation

Part 7 — The Automation Paradox
AI can fix faster — but can we trust the fix?

Part 8 — Identity After Passwords
Why phishing-resistant authentication does not end identity compromise

Part 9 — The Network Is Not the Security Boundary
What NAT, HTTP/3 and provisioning attacks tell us about Zero Trust

Part 10 — Below the Operating System
The return of firmware, GPU, BMC and hardware trust

Part 11 — When Cybersecurity Becomes Physical Security
Why OT, vehicles and safety systems change the consequence model

Part 12 — The CISO Operating Model After Black Hat 2026
From asset security to authority security

Every security conference produces vulnerabilities.

New exploits. New attack techniques. New defensive tools. New acronyms.

Black Hat USA 2026 certainly delivered all of those.

But after following the research, technical disclosures, demonstrations and post-conference publications, I believe focusing on individual vulnerabilities would miss the larger message.

Something more fundamental is happening.

The architecture of trust on which enterprise cybersecurity has been built is changing.

For decades, security programs have largely been organized around things.

Networks.

Endpoints.

Applications.

Accounts.

Servers.

Databases.

Cloud workloads.

We inventory them.

We classify them.

We assign controls.

We scan them.

We patch them.

And eventually we calculate something called residual risk.

That model still matters.

But Black Hat USA 2026 exposed an increasingly important limitation.

Attackers do not necessarily attack the things we have placed in our inventories.

They attack the relationships between them.

An AI agent reads a document.

The document influences the agent.

The agent invokes an MCP tool.

The tool operates through a workload identity.

That identity receives a temporary credential.

The credential reaches a cloud control plane.

The control plane modifies automation.

The automation creates another identity.

And that identity reaches another environment.

There may be no single catastrophic vulnerability anywhere in that chain.

The attack emerges from the composition.

This leads to what I believe is the central CISO lesson from Black Hat USA 2026:

The most valuable target is increasingly not the asset itself, but whatever has been given authority over that asset.

That is the idea connecting this twelve-part series.

It is a journey from asset security to authority security.

The Twelve Parts

Part 1 — The Agent Is Becoming the New Privileged User

Why AI security is turning into identity and access management

The first major shift is straightforward.

AI systems are no longer limited to generating text.

Agents can read files, query databases, call APIs, modify code, create infrastructure, send messages and interact with enterprise applications.

The security question therefore changes.

It is no longer merely:

What can the model say?

It becomes:

What can the agent cause to happen?

That makes agent security increasingly an IAM problem.

Agents need identities.

Their authority needs boundaries.

Delegation needs attribution.

Credentials need lifecycle management.

And the effective permissions of an agent cannot be understood simply by looking at the permissions assigned directly to it.

An agent may possess little direct authority while being able to invoke tools possessing enormous authority.

The principle of least privilege therefore evolves toward something broader:

Least Agency — give an autonomous system not merely the minimum permissions, but the minimum cumulative capability required to achieve its purpose.

Part 2 — MCP Is Becoming Enterprise Infrastructure

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

Model Context Protocol initially looks like another AI integration technology.

That description increasingly understates its significance.

MCP connects agents with tools.

And tools connect agents with enterprise authority.

Databases.

Cloud platforms.

Microsoft 365.

SAP.

Git repositories.

Security systems.

Developer environments.

Internal APIs.

Once that happens, MCP starts to resemble a combination of service discovery, API gateway, integration middleware and delegated execution infrastructure.

The security implication is substantial:

MCP does not merely transport context. It transports authority.

Organizations therefore need MCP inventories, ownership, registries, tool-level authorization, workload identities, audit trails and eventually centralized policy enforcement.

Otherwise Shadow MCP may become considerably more consequential than Shadow IT.

Part 3 — The New AI Supply Chain

Models, skills, agents and inference runtimes are becoming executable dependencies

Software supply-chain security taught us to worry about packages, libraries, containers and build systems.

AI introduces another dependency ecosystem.

Models.

Checkpoints.

Adapters.

Skills.

Prompts.

MCP servers.

Agent frameworks.

Inference runtimes.

Vector stores.

Tool definitions.

The important distinction is that not everything capable of causing execution necessarily looks like executable code.

A Markdown file containing instructions may influence a coding agent.

A tool description may change which API an agent invokes.

A poisoned document may affect an autonomous workflow.

This introduces a new category:

Executable context.

The AI supply chain therefore contains both executable software and information capable of influencing systems with execution authority.

Model provenance, AI Bills of Materials, controlled registries and rapid revocation will become increasingly important enterprise controls.

Part 4 — When Security Tools Become the Attack Surface

Why scanners, EDR and security automation deserve Tier-0 thinking

Security products occupy an unusual position in enterprise architecture.

We deliberately give them enormous visibility.

They inspect source code.

Read repositories.

Monitor endpoints.

Access cloud environments.

Process suspicious files.

Receive credentials.

Connect to APIs.

And increasingly, they perform automated remediation.

That makes them attractive targets.

Black Hat 2026 reinforced an uncomfortable principle:

A security product is not outside the threat model. It may be one of the most privileged systems inside it.

Security scanners processing attacker-controlled artifacts should therefore be treated as hostile-code execution environments.

Security infrastructure increasingly deserves the same architectural scrutiny as identity infrastructure, PKI and other Tier-0 systems.

Part 5 — Prompt Injection Is Becoming an Execution Problem

Why the industry should stop treating prompt injection as an AI-content issue

The phrase prompt injection risks making the problem sound smaller than it is.

Early demonstrations often produced embarrassing chatbot responses.

Modern agentic systems change the consequence model.

An attacker-controlled document can influence an agent.

The agent can select a tool.

The tool can use an identity.

That identity can modify an enterprise system.

The resulting chain looks like:

Untrusted content
→ model interpretation
→ agent decision
→ tool invocation
→ delegated identity
→ enterprise action

Prompt injection therefore begins to resemble an initial-access technique for autonomous systems.

The fundamental security problem is no longer simply whether the model follows malicious instructions.

It is whether untrusted information can cross the boundary into trusted authority.

Part 6 — AI Is Changing the Economics of Vulnerability Discovery

From elite security research to machine-scale exploitation

AI changes more than the speed at which exploit code can be written.

It changes the economics of experimentation.

An autonomous system can generate hypotheses.

Test them.

Observe failure.

Modify the hypothesis.

Try again.

Parallelize the process.

And repeat it at machine speed.

That affects vulnerability discovery, patch analysis, exploit development and N-day weaponization.

The critical consequence for defenders is compression of time.

A vulnerability that once required substantial specialist knowledge to operationalize may increasingly become accessible to automated systems.

One particularly uncomfortable implication follows:

The patch can become the exploit specification.

Once vulnerability research becomes scalable, the traditional interval between disclosure, patch analysis and practical exploitation becomes increasingly fragile.

Part 7 — The Automation Paradox

AI can fix faster — but can we trust the fix?

The natural defensive response to machine-speed vulnerability discovery is machine-speed remediation.

That introduces another problem.

Research around AI-generated security fixes shows that agents can produce patches that appear plausible while failing to remove the underlying vulnerability, addressing only one vulnerable code path, creating regressions or even introducing new security defects.

We have already seen the more troubling possibility:

AI finds problem
→ AI generates fix
→ fix introduces vulnerability
→ another AI discovers vulnerability
→ AI iterates exploit

This leads to a fundamental engineering principle:

Generation and verification must remain independent.

AI may generate remediation.

It should not be allowed to certify its own success.

The future secure SDLC therefore needs deterministic gates, independent exploit retesting and accountable code ownership even as autonomous coding becomes more capable.

Part 8 — Identity After Passwords

Why phishing-resistant authentication does not end identity compromise

Passkeys, hardware-backed credentials and phishing-resistant authentication represent enormous security progress.

But Black Hat 2026 demonstrated why authentication cannot be the endpoint of identity security.

Attackers increasingly target the systems authorized to use credentials rather than the credentials themselves.

Sessions.

Devices.

Authentication artifacts.

Tokens.

Workload identities.

Federation.

Cloud roles.

And transitive permission chains.

The distinction is fundamental:

Phishing-resistant authentication is not the same as compromise-resistant identity.

Cloud environments make this even more important.

A low-privilege identity may be able to modify a Lambda function, inherit another execution role, reach SSM, obtain an instance identity, assume another role and eventually reach highly privileged environments.

Assigned privilege and effective privilege are not the same thing.

Identity security therefore needs to evolve from permission inventories to authority graphs.

Part 9 — The Network Is Not the Security Boundary

What NAT, HTTP/3 and provisioning attacks tell us about Zero Trust

Security architecture still contains assumptions inherited from network topology.

Internal.

External.

Segmented.

Behind NAT.

Management network.

Trusted network.

Black Hat research repeatedly challenges these shortcuts.

Shared network state does not necessarily provide security isolation.

Internal connectivity does not establish trust.

Provisioning infrastructure can become a path into everything provisioned through it.

Modern protocols introduce state and concurrency that can produce unexpected attack surfaces.

The larger lesson is simple:

Topology is not trust.

Network segmentation remains valuable.

But security isolation must be explicit, tested and tied to identity and policy rather than inferred from where something happens to sit on a network diagram.

Part 10 — Below the Operating System

The return of firmware, GPU, BMC and hardware trust

Cloud and AI sometimes make hardware appear abstract.

It is not.

AI workloads are increasing the importance of GPUs.

Servers remain dependent on firmware.

Baseboard Management Controllers can exercise extraordinary authority independently of the operating system.

Memory controllers, management processors and pre-boot environments create security boundaries below EDR visibility.

This matters particularly for resilience.

Our standard incident-response assumption often looks like:

Compromise → Reimage → Restore → Recover

But that model fails if the compromised trust layer sits below the operating system.

Reimaging the server is not recovery if the infrastructure controlling the server remains compromised.

Hardware lifecycle, firmware integrity and management-plane isolation therefore remain strategic security disciplines even in an increasingly cloud-native world.

Part 11 — When Cybersecurity Becomes Physical Security

Why OT, vehicles and safety systems change the consequence model

Cybersecurity becomes fundamentally different when software controls physical reality.

Industrial controllers.

Vehicles.

Building automation.

Robotics.

Power.

Water.

Manufacturing.

Medical and safety systems.

Here the familiar CIA triad does not disappear, but its practical ordering changes.

For many cyber-physical environments, the critical properties become:

Integrity
Availability
Safety

An attacker manipulating process logic may not care about stealing information.

The objective may be to change what the physical system does.

That means:

Process integrity becomes a safety property.

The organizational consequence is equally important.

CISO, engineering, facilities, product security, operational risk and safety management increasingly share the same risk landscape.

Cybersecurity can no longer remain confined to IT.

Part 12 — The CISO Operating Model After Black Hat 2026

From asset security to authority security

The final article asks the question that matters most:

What should CISOs actually change?

Black Hat 2026 suggests that another layer must be added to the traditional security operating model.

Asset inventory remains necessary.

Vulnerability management remains necessary.

IAM remains necessary.

Network security remains necessary.

But they increasingly need to be connected through an understanding of authority.

We need to know:

What can control what?

What can instruct what?

What can authenticate as what?

What can create another identity?

What can obtain credentials?

What can modify security controls?

What can autonomously act?

That leads to an emerging security model:

Assets
→ Identities
→ Trust relationships
→ Delegated authority
→ Execution paths
→ Consequences

And that requires several changes in the CISO operating model.

Authority graphs alongside asset inventories.

Agent identity governance.

AI supply-chain governance.

Runtime policy enforcement.

Machine-speed vulnerability management.

Trust-path monitoring.

And incident recovery that restores compromised trust relationships rather than merely rebuilding compromised machines.

From Least Privilege to Least Agency

One concept connects many of these developments.

For decades, least privilege has been one of cybersecurity’s foundational principles.

Give an identity only the permissions necessary to perform its job.

That remains correct.

But autonomous systems introduce another dimension.

Imagine an agent with ten individually read-only tools.

None looks dangerous.

Yet together those tools may allow the agent to:

discover an identity,

find a repository,

retrieve configuration,

identify an API,

locate credentials,

construct an attack path,

and cause another system to act.

Every individual permission may satisfy least privilege.

The composition may not.

That is why I believe we need to start talking about:

Least Agency

Least privilege asks:

What is this identity allowed to access?

Least agency asks:

What outcomes can this autonomous actor cause through all of the capabilities available to it?

That distinction may become increasingly important as autonomous systems enter enterprise environments.

The Rise of Authority Security

The larger pattern goes well beyond AI.

Consider what modern enterprises increasingly depend upon:

IAM controls identities.

CI/CD controls software.

MCP controls agent tools.

Cloud control planes control workloads.

BMC controls servers.

Provisioning systems control network devices.

Security platforms control endpoints.

PLCs control physical processes.

These systems are valuable not primarily because of the information they contain.

They are valuable because of what they are authorized to cause.

That suggests a useful emerging category:

Authority Security

Authority Security asks:

Where does the organization delegate the ability to cause consequential change?

And then:

Can an attacker influence, inherit, compose or redirect that authority?

That is a different way of looking at enterprise security.

And I believe Black Hat USA 2026 provided unusually strong evidence that we need it.

The Architecture of Trust Is Changing

None of this means that the traditional security disciplines are obsolete.

Quite the opposite.

Identity becomes more important.

Application security becomes more important.

Supply-chain security becomes more important.

Cloud security becomes more important.

Hardware security becomes more important.

The change is that they can no longer be governed as independent security domains.

An attack may begin in a document.

Move into an AI agent.

Cross an MCP interface.

Inherit a workload identity.

Reach a cloud control plane.

Modify automation.

Create another credential.

And eventually affect a physical process.

Which team owns that attack?

AI Security?

IAM?

Cloud Security?

Application Security?

SOC?

OT Security?

The attacker does not care.

And that may be the final lesson.

Security organizations are structured around technologies.

Attack paths are structured around possibilities.

Black Hat USA 2026 showed us what happens when those possibilities begin to multiply through AI, automation and delegated authority.

The challenge for CISOs is therefore not merely to deploy another generation of controls.

It is to understand the new relationships those controls must govern.

Because the fundamental question is changing.

For years we have asked:

Who has access to our critical systems?

The next question is harder:

Who — or what — can cause our critical systems to act?

And after Black Hat USA 2026, I believe that question deserves a permanent place on the CISO agenda.

Black Hat USA 2026 did not tell us that everything we know about cybersecurity is wrong.

It told us something more useful.

The controls we already have were designed for a world in which humans, applications and infrastructure had relatively understandable boundaries.

Those boundaries are becoming less distinct.

Software can reason.

Data can influence execution.

Machines can receive delegated authority.

Infrastructure can generate identities.

Security tools can become attack infrastructure.

AI can discover attack paths faster than humans can enumerate them.

And cyber systems increasingly control physical consequences.

The architecture of trust is changing.

The CISO operating model must change with it.