Black Hat USA 2026 — Part 12

Security leadership must move from protecting systems to governing delegated authority

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

For decades, the CISO mandate was relatively easy to describe.

• Protect the network.
• Protect the endpoints.
• Protect the applications.
• Protect the data.
• Protect the identities.
• Detect attacks.
• Respond to incidents.
• Reduce vulnerabilities.
• Maintain resilience.

Those responsibilities remain.

But Black Hat USA 2026 exposed something more fundamental.

The enterprise itself is changing.

Software no longer merely stores information.

It acts.

AI agents invoke tools.

MCP servers connect systems.

Security platforms execute changes.

Machine identities operate infrastructure.

Cloud control planes orchestrate environments.

Autonomous systems remediate vulnerabilities.

Vehicles interact with infrastructure.

Software controls physical processes.

And increasingly, machines make decisions that humans previously made themselves.

Black Hat’s own post-conference assessment described the defining shift clearly:

the agentic age has arrived. (⁠Black Hat)

For the CISO, that means the operating model must change.

Because the central security problem is no longer simply:

How do we protect systems?

It is increasingly:

How do we govern the authority we delegate to systems?

That is the final argument of this series.

The next CISO operating model must move from protecting assets toward governing delegated authority.

The Architecture of Trust Is Changing

That has been the thesis running through all twelve parts of this series.

Black Hat USA 2026 was full of vulnerabilities.

But the more important story was not any individual exploit.

It was the architecture underneath them.

Again and again, researchers demonstrated what happens when systems are trusted to do something consequential.

• An AI agent receives tools.
• An MCP server connects enterprise systems.
• A model interprets untrusted information.
• A security scanner receives privileged access.
• An autonomous system generates a remediation.
• An identity creates a session.
• A network establishes connectivity.
• A BMC controls a server.
• A GPU executes sensitive workloads.
• Software controls a physical process.

Each relationship involves trust.

And increasingly:

Trust creates authority.

That is the strategic lesson.

Security Has Always Been About Authority

We just did not always describe it that way.

• Why protect a password?

Because it grants authority.

• Why protect an administrator account?

Because it grants authority.

• Why segment a network?

Because connectivity creates paths toward authority.

• Why protect an API key?

Because it grants authority.

• Why secure a cloud control plane?

Because it exercises authority.

• Why protect a BMC?

Because it has authority beneath the operating system.

• Why secure an industrial controller?

Because it possesses physical authority.

The asset matters.

But what attackers ultimately seek is usually not the asset itself.

They seek what the asset allows them to do.

That distinction becomes critical in the agentic enterprise.

The Old Model Was Asset-Centric

Traditional enterprise security architecture largely organizes itself around things.

• Endpoints.
• Servers.
• Applications.
• Databases.
• Networks.
• Cloud environments.
• Accounts.
• Data repositories.

We inventory them.

Classify them.

Patch them.

Monitor them.

Segment them.

Assign owners.

Assess their risks.

This model worked reasonably well when authority was relatively static.

A user logged into an application.

An application accessed a database.

An administrator managed infrastructure.

The relationships were understandable.

The enterprise was complicated.

But it was relatively deterministic.

The New Enterprise Is Relationship-Centric

Agentic systems change that.

An AI agent may:

• discover a tool,
• select a tool,
• invoke an API,
• inherit a user’s authority,
• call another service,
• cause another agent to act,
• retrieve information,
• write information,
• modify configuration,
• send information externally,
• and create new state.

The important security object is no longer merely:

the agent.

It is:

the relationships the agent can activate.

The same applies beyond AI.

A machine identity matters because of the resources it can reach.

A security scanner matters because of the credentials its worker possesses.

A BMC matters because of the machines it can control.

A cloud identity matters because of the roles it can assume.

A network path matters because of the authority reachable through it.

The enterprise attack surface is becoming relational.

From Asset Inventory to Authority Graph

This requires a new abstraction.

The traditional CMDB asks:

What do we have?

The next security architecture must also ask:

What can cause what?

That produces an:

Authority Graph

An authority graph describes the paths through which identities, software and infrastructure can cause consequential actions.

For example:

Human

→ Agent
→ MCP Server
→ Tool
→ Workload Identity
→ API
→ Cloud Service
→ Resource

Or:

Developer

→ Repository
→ Security Scanner
→ Scanner Worker
→ Cloud Credential
→ Production Environment

Or:

Administrator

→ Management Network
→ BMC
→ Firmware
→ Server

Or:

Cloud Identity

→ Control System
→ Controller
→ Actuator
→ Physical Process

These are not simply dependencies.

They are executable authority paths.

The CISO Needs to Govern the Graph

This changes the CISO question.

The old question was:

Is System X secure?

The new question becomes:

What authority can flow through System X?

And then:

• What can it reach?
• What identities can it invoke?
• What tools can it call?
• What systems trust it?
• What can it cause those systems to do?
• Where does the chain terminate?
• What is the maximum consequence?

This is fundamentally different from conventional control compliance.

It is architecture governance.

The Effective Privilege of a System Is Relational

Part 2 introduced this problem with MCP.

Part 3 expanded it into the AI supply chain.

Part 5 showed how prompt injection can traverse the chain.

Part 8 demonstrated it again with identity.

The resulting principle is broader than AI:

The effective privilege of a system is not merely the permissions assigned to it. It is the authority reachable through the relationships it can activate.

That means:

**Effective Authority
= Direct Authority

• Delegated Authority
• Reachable Authority**

This should become a core CISO concept.

Least Privilege Is No Longer Enough

Least privilege remains essential.

But it assumes privilege can be evaluated locally.

Agentic systems challenge that assumption.

Imagine an agent that can:

• read email,
• read SharePoint,
• create a support ticket,
• invoke a workflow,
• and send external messages.

Each permission may appear reasonable.

Together they may form a dangerous execution chain.

No individual permission looks catastrophic.

The composition is.

This is why Part 2 introduced another principle:

Least Agency.

The question is not merely:

What is this identity permitted to do?

It is:

What sequence of actions can this system autonomously cause?

The CISO Must Govern Delegation

Delegation is becoming one of the defining security mechanisms of the next enterprise architecture.

• Humans delegate to agents.
• Agents delegate to tools.
• Applications delegate to APIs.
• Cloud platforms delegate to workloads.
• Workflows delegate to automation.
• Security teams delegate to autonomous remediation.
• Organizations delegate to SaaS providers.
• Enterprises delegate infrastructure control to cloud providers.
• Boards delegate cyber-risk management to management.

Delegation is everywhere.

But most organizations do not have a unified model for governing it.

That is becoming a problem.

Delegation Creates a New Governance Question

Every delegation should answer:

Who delegated?
What was delegated?
To whom?
For what purpose?
For how long?
Under what conditions?
With what limits?
Who can revoke it?
How is its use observed?
What is the maximum consequence?

This resembles IAM.

But it is broader than IAM.

It is:

Authority Governance.

Authority Governance

I would define Authority Governance as:

The discipline of identifying, constraining, observing and revoking the ability of human and non-human actors to cause consequential actions across enterprise systems.

It includes:

• Identity.
• Authorization.
• Delegation.
• Machine identities.
• AI agents.
• MCP.
• APIs.
• Automation.
• Control planes.
• Security tools.
• Cloud infrastructure.
• Hardware management.
• And eventually cyber-physical systems.

This is not a new security product category.

It is an operating model.

The CISO Becomes the Architect of Authority

That does not mean the CISO should operate every control.

Quite the opposite.

IT should operate technology.

Engineering should build systems.

Cloud teams should operate cloud platforms.

AI teams should build AI capabilities.

Business units should own business processes.

OT engineers should operate industrial environments.

Safety teams should own safety engineering.

But someone must maintain the enterprise view of:

where authority exists,

how it is delegated,

how it can compose,

and

where the consequences terminate.

That is increasingly a CISO responsibility.

The Role Is Not to Own Everything

This distinction matters enormously.

The modern CISO cannot become:

• Head of IT.
• Head of AI.
• Head of Cloud.
• Head of Engineering.
• Head of OT.
• Head of Safety.
• Head of Identity.
• Head of Infrastructure.

That would be organizationally impossible.

The CISO’s role is different.

The CISO establishes the security requirements governing how those capabilities exercise authority.

In other words:

The CISO does not need to operate every system. The CISO needs sufficient independence and authority to define how enterprise trust is established.

That distinction becomes more important as technology becomes more autonomous.

Independence Matters More in the Agentic Enterprise

If the same function:

builds the system,

operates the system,

defines the security requirements,

accepts the risk,

and evaluates whether the controls are effective,

then the organization has created a closed governance loop.

Agentic technology makes that increasingly dangerous.

Because autonomous systems can move faster than governance.

The organization therefore needs independent security challenge.

Not to slow innovation.

But to prevent operational convenience from silently becoming the enterprise’s risk appetite.

Security Policy Is an Expression of Risk Appetite

This is why security policies matter.

A security requirement is not merely technical documentation.

It translates enterprise risk appetite into constraints.

For example:

Privileged actions require strong authentication.

Critical systems require independent logging.

High-impact autonomous actions require external authorization.

Sensitive data cannot be sent to uncontrolled destinations.

Production workloads require approved identities.

Safety-critical actions require deterministic controls.

Those are not implementation preferences.

They are governance decisions.

Implementation Must Not Define Acceptable Risk

IT should determine how controls are implemented.

Engineering should determine how requirements are technically realized.

Business owners should determine business priorities.

But the function implementing the technology should not unilaterally decide:

which security requirements are still necessary.

Otherwise the governance chain becomes:

Implementer
→ Interprets Requirement
→ Changes Requirement
→ Declares Implementation Adequate

That collapses independent challenge.

The same principle appears repeatedly throughout this series.

The actor should not be the sole verifier of its own correctness.

Part 7 Already Showed the Pattern

In autonomous remediation we called this:

The agent should not grade its own exam.

The same principle applies organizationally.

The function implementing security controls should not be the only function deciding whether those controls adequately address enterprise risk.

That requires separation between:

Risk Evaluation

and

Implementation.

Between:

Security Requirement

and

Operational Execution.

Between:

Assurance

and

Operation.

This is not bureaucracy.

It is a trust architecture for management.

The Three Lines Still Matter

Technology changes rapidly.

Governance principles change more slowly.

The Three Lines model remains useful precisely because it distinguishes:

operational ownership,

risk oversight,

and independent assurance.

The exact organizational structure will vary.

But the principle should remain visible.

Someone operates the risk.

Someone independently challenges the risk.

Someone independently assures the governance system.

If those responsibilities collapse into one function, visibility may remain.

Independence does not.

AI Makes Separation of Duties More Important

Autonomous systems compress execution time.

A human administrator might make ten consequential changes during a day.

An autonomous agent could make thousands.

A security automation platform may modify:

identities,

endpoints,

cloud resources,

network controls,

policies,

or accounts

within seconds.

The faster execution becomes, the less realistic after-the-fact governance becomes.

Controls must move into the execution path.

That means separation of duties increasingly becomes:

architectural.

Governance Must Become Runtime

Traditional governance often happens before deployment.

Architecture review.

Risk assessment.

Security approval.

Policy review.

Go-live.

Then operation.

Agentic systems require another model.

Because the system may make new decisions continuously after deployment.

Therefore:

Design-Time Governance

must be complemented by:

Runtime Governance.

The architecture itself must enforce boundaries.

Runtime Governance

Runtime governance asks:

Is this identity still valid?

Is this action permitted?

Is this delegation valid?

Is the context trustworthy?

Is the destination allowed?

Does the action exceed the agent’s authority?

Has risk changed?

Does this action cross a consequence boundary?

Does it require human authorization?

Should execution be stopped?

This cannot depend solely on a model’s judgment.

It requires deterministic controls outside the reasoning system.

Policy Must Become Executable

This leads to another important transition.

Traditional security policies are written for humans.

Future security architecture increasingly needs policies that can also be enforced by machines.

For example:

Agent X may read Resource Y

but

may not modify Resource Y.

It may:

propose a financial transaction

but

may not execute it.

It may:

prepare a configuration change

but deployment requires independent authorization.

It may:

access internal data

but may not send that data externally.

These are executable security constraints.

From Policy Documents to Policy Enforcement

This does not mean replacing governance documents with code.

It means creating traceability:

Enterprise Risk Appetite
↓
Security Policy
↓
Security Standard
↓
Architecture Requirement
↓
Machine-Enforceable Policy
↓
Runtime Decision
↓
Evidence

The closer we get to autonomous execution, the more important this chain becomes.

Because humans cannot manually supervise machine-speed authority.

The New Security Control Plane

Several parts of this series point toward the same architecture.

Part 2 proposed an MCP control plane.

Part 5 required authorization outside the model.

Part 7 introduced a verification plane.

Part 8 introduced Authority Assurance.

Part 9 moved trust away from network location.

Together they suggest something larger:

Enterprise Authority Control Plane

Not necessarily one product.

Not necessarily one platform.

But a coherent architecture capable of answering:

Who is acting?

What are they acting as?

On whose behalf?

What authority do they possess?

What are they attempting to do?

What resource is affected?

What is the consequence?

Is the action permitted?

How is it verified?

Can it be revoked?

Identity Becomes the Foundation

The control plane begins with identity.

Not only human identity.

It must include:

users,

administrators,

service accounts,

applications,

workloads,

managed identities,

API clients,

devices,

AI agents,

MCP servers,

automation platforms,

security tools,

and autonomous services.

The first requirement is simple:

Anything capable of exercising authority must have an accountable identity.

Anonymous authority is incompatible with serious governance.

Ownership Must Follow Identity

Identity alone is insufficient.

Every consequential non-human identity should have an accountable owner.

Who requested it?

Who operates it?

Who reviews its permissions?

Who responds if it behaves unexpectedly?

Who decides when it should be retired?

Who accepts its residual risk?

The enterprise already struggles with orphaned service accounts.

Agentic systems could multiply that problem dramatically.

Purpose Must Become an Identity Attribute

For humans, organizational role provides context.

For agents and workloads, purpose becomes equally important.

An agent should not merely be:

Agent-48372.

It should have a declared purpose.

For example:

Invoice Reconciliation Agent

or

Security Vulnerability Triage Agent.

Purpose enables the enterprise to ask:

Does this action make sense for this identity?

That makes behavioral governance possible.

Authorization Must Move Closer to the Action

Traditional authorization often happens at login.

The user authenticates.

A session is created.

The session inherits broad authority.

Agentic systems make this dangerous.

Authorization increasingly needs to occur:

at the action boundary.

Not:

Can this agent access the ERP?

But:

Can this agent execute this specific transaction against this specific object under these specific conditions now?

This is the transition from:

Access Control

toward:

Action Control.

Consequence Becomes an Authorization Signal

The same action can have different consequences depending on context.

Reading a document is different from publishing it.

Preparing a payment is different from releasing it.

Proposing a firewall rule is different from deploying it.

Identifying malware is different from isolating 20,000 endpoints.

Changing a thermostat is different from changing an industrial safety parameter.

Therefore:

Authorization Strength ∝ Consequence

As consequence increases, architecture should require stronger evidence.

The Consequence Boundary

This concept appeared repeatedly throughout the series.

It deserves a permanent place in the CISO operating model.

Below a consequence boundary:

automation may act freely.

At the boundary:

additional controls appear.

Above the boundary:

human judgment, independent authorization or deterministic safeguards may become mandatory.

The boundary depends on:

reversibility,

blast radius,

financial impact,

data sensitivity,

operational impact,

safety impact,

and regulatory consequence.

Autonomy Is Not Binary

Organizations often ask:

Should we allow autonomous AI?

That is the wrong question.

Autonomy is a spectrum.

A useful model is:

Level 0 — Observe

The system only analyzes.

Level 1 — Recommend

The system proposes actions.

Level 2 — Prepare

The system prepares executable changes.

Level 3 — Execute Reversible Actions

The system acts within bounded, low-consequence authority.

Level 4 — Conditional Autonomy

The system acts independently within predefined consequence boundaries.

Level 5 — High-Consequence Autonomy

The system can execute consequential actions with limited human involvement.

Security governance should determine which systems belong at which level.

Autonomy Should Be Earned

The enterprise should not begin with autonomy and then remove privileges after incidents.

Autonomy should increase as evidence increases.

Evidence of:

correctness,

predictability,

observability,

reversibility,

security,

policy compliance,

and operational reliability.

The principle should be:

Autonomy is a privilege granted by governance, not a feature enabled by deployment.

The Verification Plane Becomes Essential

Part 7 introduced the Verification Plane.

It becomes even more important in the final operating model.

As systems gain autonomous authority, the enterprise needs mechanisms independent from the acting system to determine:

Did the expected action occur?

Did anything else occur?

Is the resulting state secure?

Is it compliant?

Is it operationally correct?

Did the action create a new attack path?

Did it exceed the intended blast radius?

Should it be rolled back?

The system that acts should not be the sole system that verifies.

Observe Independently

The same principle applies to telemetry.

If an autonomous platform:

acts,

logs its own actions,

evaluates those logs,

and declares itself healthy,

the evidence chain is weak.

High-consequence systems require independent observation.

That may mean:

external logs,

separate telemetry,

control-plane audit trails,

network evidence,

security monitoring,

cryptographic records,

or independent verification systems.

Trust requires evidence.

Evidence should not depend entirely on the actor being trusted.

Revocation Must Be External

Every autonomous system with consequential authority should have a revocation mechanism.

And ideally:

the system should not control that mechanism itself.

If an agent behaves unexpectedly:

Can its identity be disabled?

Can its token be revoked?

Can MCP connectivity be removed?

Can tools be disabled?

Can outbound communication be stopped?

Can automation be paused?

Can the entire agent class be suspended?

That is the equivalent of an emergency stop.

The Kill Switch Is a Governance Control

A kill switch sounds operational.

It is actually governance.

It represents the organization’s retained authority over delegated authority.

The enterprise is effectively saying:

We delegate execution to you, but we retain the ability to withdraw that delegation.

That principle should apply to:

agents,

automation,

machine identities,

security platforms,

cloud integrations,

and high-consequence autonomous systems.

The CISO Must Govern Machine Speed

One of the strongest signals from Black Hat USA 2026 was acceleration.

AI-assisted vulnerability research.

Autonomous exploitation.

Machine-speed remediation.

Agentic security operations.

Black Hat’s post-event analysis explicitly highlighted autonomous systems, AI-powered research and machine-speed operations as defining themes of the event. (⁠Black Hat)

This changes the operating model.

Human-speed governance cannot supervise every machine-speed decision.

Therefore governance itself must become:

architectural, pre-authorized and enforceable.

From Ticket-Based Security to Guardrail-Based Security

Traditional security organizations often operate through tickets.

Request.

Review.

Approve.

Implement.

Close.

That model will not disappear.

But it cannot govern millions of autonomous interactions.

The future model increasingly becomes:

Define Guardrail
↓
Encode Guardrail
↓
Allow Autonomous Operation
↓
Observe Continuously
↓
Intervene on Exception

This moves security from approving every action to defining the envelope within which actions are permitted.

Security Becomes Constraint Engineering

That may become one of the defining CISO disciplines of the agentic enterprise.

The CISO organization increasingly defines:

what systems may never do,

what systems may do only under certain conditions,

what requires stronger authorization,

what requires independent verification,

what requires human judgment,

and what authority must never be delegated.

That is:

Constraint Engineering.

Not to prevent innovation.

To make autonomy safe enough to scale.

The SOC Operating Model Changes Too

The SOC will not escape this transformation.

AI will increasingly:

triage,

correlate,

investigate,

hunt,

generate detections,

analyze malware,

recommend containment,

and execute selected responses.

Black Hat discussions around the emerging agentic SOC emphasized a model in which machines perform machine-scale work while humans retain context, judgment and control. (⁠Black Hat)

That is the right direction.

The objective is not:

remove the analyst.

It is:

move the analyst to the consequence boundary.

Humans Should Not Compete With Machines at Machine Tasks

Humans are poor at:

processing millions of events,

repetitive correlation,

continuous scanning,

bulk enrichment,

and instant execution.

Machines are excellent at those tasks.

Humans remain stronger at:

ambiguity,

context,

ethics,

novel situations,

organizational judgment,

business trade-offs,

and high-consequence decisions.

The operating model should exploit that difference.

Put Humans Where Judgment Matters

The question should therefore not be:

Human in the loop or human out of the loop?

It should be:

Where in the loop does human judgment create the most value?

For low-consequence repetitive activity:

possibly nowhere.

For ambiguous security events:

during investigation.

For major containment:

at authorization.

For safety-critical actions:

before execution.

For strategic risk:

at management level.

Human control should follow consequence.

The CISO Organization Must Change Skills

This changes the security workforce.

The CISO organization still needs:

SOC analysts,

incident responders,

penetration testers,

security architects,

IAM specialists,

cloud security engineers,

GRC professionals,

and vulnerability managers.

But it increasingly also needs people who understand:

agent architecture,

machine identity,

authorization systems,

AI security,

runtime policy,

automation,

MCP,

software supply chains,

attack-path analysis,

hardware trust,

and cyber-physical consequence.

The security architect becomes increasingly important.

Architecture Moves Toward the Center

Black Hat 2026 reinforces something that has been developing for years.

Many important security failures are not caused by the absence of a security product.

They emerge because individually reasonable systems compose into unsafe architectures.

The firewall works.

The identity system works.

The agent works.

The MCP server works.

The cloud API works.

The security scanner works.

And the resulting system is still exploitable.

That is an architecture problem.

The CISO Needs an Architecture Function

A mature CISO organization therefore needs the capability to reason across:

Identity Architecture.

Cloud Architecture.

AI Architecture.

Application Architecture.

Data Architecture.

Network Architecture.

Security Tooling.

Hardware Trust.

OT.

Third Parties.

And business processes.

Not to replace enterprise architects.

But to evaluate:

how trust and authority flow through the architecture.

Security Architecture Must Become Compositional

Traditional security reviews often evaluate components individually.

Is the application secure?

Is the API secure?

Is the agent secure?

Is the MCP server secure?

Is the cloud service secure?

But Part 1 through Part 11 repeatedly showed that the dangerous property may emerge only when those components interact.

Therefore:

The unit of security review must increasingly become the composition, not the component.

This may be the single most important architectural lesson of the series.

Attack Paths Become a Management Instrument

Attack-path management should therefore move beyond technical exposure management.

It can become a governance instrument.

Management needs to understand:

Which authority paths reach critical assets?

Which identities can traverse them?

Which agents can activate them?

Which suppliers participate?

Which security controls constrain them?

Which paths terminate in financial, operational or physical consequence?

This creates a more meaningful representation of cyber risk than a vulnerability count.

Stop Reporting Security as Counts

CISOs have spent years reporting:

number of vulnerabilities,

number of incidents,

number of phishing emails,

number of alerts,

number of devices,

patch percentages,

training completion,

and audit findings.

These metrics remain useful operationally.

But they rarely tell management:

How much consequential authority is exposed?

The board needs another view.

Report Exposure to Consequence

Future CISO reporting should increasingly include questions such as:

How many critical authority paths exist?

How many are insufficiently controlled?

Which autonomous systems can execute high-consequence actions?

Which privileged machine identities lack owners?

Which delegated authorities cannot be revoked quickly?

Which critical systems lack independent verification?

Which security control planes represent concentrated risk?

Which cyber paths can create physical consequences?

Which strategic dependencies have no credible alternative?

That is closer to enterprise risk.

The CISO Risk Model Changes

A useful conceptual model is:

Risk
= Exposure
× Reachable Authority
× Consequence
× Time

Exposure asks:

Can the attacker reach the path?

Reachable Authority asks:

What can they cause?

Consequence asks:

What happens if they succeed?

Time asks:

How long does the exposure remain exploitable?

This is not intended as a mathematical formula.

It is a governance lens.

Time Becomes a Strategic Variable

Part 6 showed why.

AI reduces the cost of vulnerability discovery.

Automation compresses exploitation.

Machine-speed systems compress response.

The security competition increasingly becomes temporal.

Time-to-Exploit

versus

Time-to-Safe.

That means governance latency becomes security latency.

A control requiring three weeks of manual approval may be perfectly governed and operationally useless during a rapidly exploited vulnerability.

The operating model must distinguish between:

high-consequence decisions requiring human judgment

and

pre-authorized defensive actions that should happen immediately.

Pre-Authorization Becomes Important

Machine-speed defense requires management to decide some things before the incident.

For example:

Under which conditions may a compromised endpoint be isolated automatically?

When may credentials be revoked?

When may external access be blocked?

When may a workload be quarantined?

When may an autonomous remediation deploy?

What blast radius is acceptable?

What requires escalation?

This is governance before execution.

The Board’s Role Changes Too

The board does not need to approve individual security controls.

But it does need to define:

risk appetite,

critical consequences,

acceptable autonomy,

strategic dependencies,

and the boundaries of delegated authority.

For example:

Can AI autonomously approve payments?

Can autonomous security systems disable production infrastructure?

Can agents access highly sensitive data?

Can cloud providers hold critical encryption authority?

Can safety-relevant processes depend on autonomous reasoning?

These are not technical questions.

They are governance questions.

Risk Acceptance Must Remain Human

This leads to a hard boundary.

AI may:

identify risk,

quantify risk,

model scenarios,

recommend controls,

and monitor exposure.

But accepting significant enterprise risk remains a management responsibility.

A model cannot legitimately decide:

The organization accepts this risk.

Risk acceptance is an exercise of organizational authority.

It belongs to accountable humans.

The CISO Must Preserve Escalation

The CISO operating model therefore requires independent escalation.

When security believes:

risk exceeds appetite,

controls are ineffective,

implementation decisions materially weaken security,

or management assumptions are incorrect,

the CISO must be able to communicate that risk to the appropriate decision level.

Without that capability, the organization may have a security function.

But it does not have independent security governance.

Certification Is Not the Objective

This is also where security leadership must avoid a familiar trap.

Compliance frameworks remain valuable.

ISO 27001 remains valuable.

NIST remains valuable.

CIS Controls remain valuable.

Regulatory requirements remain important.

But the architecture described throughout this series evolves faster than most control catalogs.

A certified ISMS can still face:

agent authority sprawl,

MCP proliferation,

machine-identity exposure,

AI supply-chain compromise,

autonomous execution risk,

GPU and firmware vulnerabilities,

and cyber-physical consequence.

Certification demonstrates that a management system exists.

It does not prove that every emerging architecture risk has been adequately controlled.

Controls Are a Baseline, Not the Threat Model

The correct sequence is:

Business Context
↓
Threat Landscape
↓
Architecture
↓
Risk Scenarios
↓
Security Requirements
↓
Controls
↓
Assurance

Not:

Control Catalog
↓
Implementation
↓
Assume Security

The control catalog supports risk treatment.

It should not replace risk thinking.

Black Hat exists largely because attackers continuously find what control catalogs did not anticipate.

The ISMS Must Become More Dynamic

This does not make the ISMS obsolete.

It makes the ISMS more important.

But the ISMS needs to absorb new risk classes rapidly.

Agentic AI.

Machine identities.

MCP.

AI supply chains.

Autonomous remediation.

Security control planes.

Hardware roots of trust.

Cyber-physical authority.

These should not remain isolated innovation topics.

Once materially relevant, they belong inside:

risk management,

architecture,

policy,

control design,

monitoring,

internal audit,

management review,

and continuous improvement.

That is what a management system is supposed to do.

Security Governance Must Follow Reality

A dangerous organizational pattern is to say:

Our framework does not explicitly require this.

That may be technically correct.

It may also be irrelevant.

Attackers do not wait for frameworks to update.

The CISO’s obligation is to understand material risk as it exists.

Not only as it has already been codified.

From Control Compliance to Control Effectiveness

This also changes assurance.

The question should not merely be:

Is the control implemented?

It should be:

Does the control actually constrain the relevant authority path?

An MFA control may exist.

But session theft may bypass its intended protection.

Network segmentation may exist.

But shared NAT infrastructure may undermine assumptions.

An AI policy may exist.

But agents may still invoke uncontrolled MCP tools.

A vulnerability scanner may exist.

But the scanner itself may create supply-chain risk.

Implementation is not effectiveness.

Continuous Assurance

Agentic environments increasingly require assurance to become continuous.

Not:

audit once a year.

But:

observe continuously,

validate continuously,

test continuously,

measure continuously,

reassess when architecture changes.

This does not mean permanent formal audit.

It means building evidence into operations.

The more autonomous the environment becomes, the less sufficient periodic snapshots become.

Evidence Must Be Machine-Readable

This creates another future requirement.

Security assurance increasingly needs data that machines can interpret.

Identity inventories.

Agent inventories.

Permission graphs.

MCP registries.

SBOMs.

AI-BOMs.

Asset graphs.

Policy states.

Attestation evidence.

Runtime telemetry.

Control results.

Attack paths.

The enterprise needs to know not merely what policy says.

It needs evidence of what the environment currently allows.

The CISO Dashboard of the Future

Imagine a CISO dashboard that does not begin with:

12,483 vulnerabilities.

Instead it shows:

7 Critical Authority Paths

3 Autonomous Systems With High-Consequence Authority

14 Orphaned Privileged Machine Identities

2 Unverified MCP Trust Paths

1 Security Control Plane With Excessive Blast Radius

4 Critical Systems Without Independent Revocation

2 Cyber-to-Physical Attack Paths Above Risk Appetite

That dashboard would produce a very different management conversation.

The CISO Organization Becomes a Trust Function

Perhaps this is the deepest organizational shift.

The security organization historically protected technology.

Increasingly it must govern:

trust.

Who may be trusted?

For what?

Under which conditions?

With what evidence?

For how long?

With what authority?

With what consequence?

And how quickly can that trust be withdrawn?

This is larger than cybersecurity operations.

It is enterprise trust governance.

Trust Must Become Explicit

Zero Trust taught the industry:

Never trust, always verify.

That phrase was useful.

But the deeper objective is:

Eliminate implicit trust.

Trust will always exist.

Systems must trust something.

The real challenge is to make that trust:

explicit,

bounded,

evidence-based,

observable,

contextual,

temporary where possible,

and revocable.

That applies equally to:

humans,

machines,

agents,

software,

hardware,

suppliers,

and control planes.

The Seven Questions of Delegated Authority

For every high-consequence system, I would want the enterprise to answer seven questions.

1. Identity — Who is acting?

Human, machine, agent, workload or service.

2. Ownership — Who is accountable?

Every authority path needs accountable ownership.

3. Purpose — Why does this authority exist?

Authority without defined purpose becomes privilege accumulation.

4. Scope — What can it cause?

Not merely what it can access.

5. Constraint — What can it never do?

Boundaries must be explicit.

6. Evidence — How do we know what it actually did?

Independent observability matters.

7. Revocation — How do we stop it?

Delegated authority must remain withdrawable.

These seven questions can govern almost every topic in this series.

The CISO Control Model After Black Hat 2026

If I had to reduce the entire series to an operating model, I would define twelve requirements.

1. Govern Authority, Not Only Assets

Understand what systems can cause, not merely what systems exist.

2. Inventory Human and Non-Human Actors

Every consequential actor needs identity and ownership.

3. Map Authority Paths

Build graphs connecting identities, agents, tools, services, infrastructure and consequences.

4. Govern Delegation Explicitly

Know who delegated what authority, to whom, for what purpose and for how long.

5. Enforce Least Agency

Limit autonomous action sequences, not only individual permissions.

6. Put Authorization Outside Probabilistic Reasoning

Models may propose. Deterministic controls should govern consequential execution.

7. Define Consequence Boundaries

Increase assurance as financial, operational, security or physical impact increases.

8. Build Independent Verification

The actor should not be the sole verifier of its own correctness.

9. Preserve Independent Observation and Revocation

Telemetry and kill mechanisms should remain outside the authority of the system being governed.

10. Govern Compositions

Review relationships and attack paths, not merely individual components.

11. Move Governance Into Runtime

Machine-speed systems require machine-enforceable guardrails.

12. Preserve Human Accountability

Risk appetite, significant risk acceptance and high-consequence governance remain human responsibilities.

Together, these form something more important than another security framework.

They define:

The Authority Governance Model

The Authority Governance Model

The model can be expressed as a chain:

Identity
↓
Ownership
↓
Purpose
↓
Delegation
↓
Authority
↓
Constraint
↓
Execution
↓
Verification
↓
Observation
↓
Revocation
↓
Consequence

Security must govern the entire chain.

Because attackers increasingly do.

The Board View

For executive management, I would simplify the model further.

The board needs confidence that:

We know who and what can act.

We know what authority they possess.

We know where that authority can reach.

We constrain high-consequence actions.

We can observe what happens.

We can stop delegated authority when necessary.

Material residual risks are explicitly decided by accountable management.

That is a board-level security outcome.

Not the number of firewall rules.

The CISO View

For the CISO, the operating model becomes:

Understand the architecture.

Identify the authority.

Map the relationships.

Define the constraints.

Verify the controls.

Observe the execution.

Escalate the risk.

Preserve revocation.

That is security leadership in an increasingly autonomous enterprise.

The Technology View

For architects and engineers:

Identity before access.

Purpose before privilege.

Authorization before execution.

Verification after execution.

Telemetry outside the actor.

Revocation outside the actor.

Human judgment at the consequence boundary.

This is how governance becomes architecture.

The AI View

For AI teams:

The model is not the security boundary.

The prompt is not the authorization mechanism.

The user’s identity is not automatically the agent’s authority.

An MCP connection is not merely an integration.

A tool call is a security-sensitive transaction.

Memory is persistent security state.

Agent autonomy is delegated privilege.

And:

The agent should never possess more authority than the organization is prepared to let manipulated reasoning exercise.

That may be the most important AI security principle in the series.

The Security Operations View

For the SOC:

Automate machine-scale analysis.

Automate low-consequence response.

Preserve independent telemetry.

Pre-authorize safe containment.

Verify autonomous remediation.

Escalate ambiguity.

Put analysts where judgment matters.

Measure:

Time-to-Safe

rather than merely:

Time-to-Close.

The GRC View

For GRC:

Stop treating emerging technology as an appendix.

Translate new architectures into risk scenarios.

Translate risk scenarios into requirements.

Translate requirements into enforceable controls.

Test effectiveness.

Track residual risk.

Escalate beyond appetite.

Ensure management review reflects the actual technology environment.

The ISMS should describe the organization that exists.

Not the organization that existed when the control catalog was written.

The Architecture View

For security architecture:

Stop drawing only boxes.

Draw relationships.

Draw authority.

Draw delegation.

Draw identity transitions.

Draw control planes.

Draw trust roots.

Draw attack paths.

Draw physical consequences.

Because:

The most dangerous property of a modern system may not exist inside any individual component. It may exist only in the relationship between them.

The Series in One Architecture

Looking back across Black Hat USA 2026, the progression becomes visible.

Part 1 — The Agent Is Becoming the New Privileged User

Question: Who is receiving authority?

Part 2 — MCP Is Becoming Enterprise Infrastructure

Question: How is that authority connected?

Part 3 — The New AI Supply Chain

Question: What can influence execution?

Part 4 — When Security Tools Become the Attack Surface

Question: Where has authority become dangerously concentrated?

Part 5 — Prompt Injection Is Becoming an Execution Problem

Question: Can untrusted information acquire a path to authority?

Part 6 — AI Is Changing the Economics of Vulnerability Discovery

Question: What happens when offensive discovery moves toward machine scale?

Part 7 — The Automation Paradox

Question: Who verifies autonomous defense?

Part 8 — Identity After Passwords

Question: How do we protect the authority that survives authentication?

Part 9 — The Network Is Not the Security Boundary

Question: Why can location no longer establish trust?

Part 10 — Below the Operating System

Question: What does our trust ultimately rest on?

Part 11 — When Cybersecurity Becomes Physical Security

Question: What happens when digital authority changes physical reality?

And finally:

Part 12 — The CISO Operating Model After Black Hat 2026

Question:

Who governs all of that authority?

That is the question security leadership now needs to answer.

From Protecting Systems to Governing Authority

This does not mean the traditional security program disappears.

Firewalls remain.

EDR remains.

Vulnerability management remains.

IAM remains.

SOC remains.

Security awareness remains.

Application security remains.

Cloud security remains.

OT security remains.

Compliance remains.

But they become components of a larger governance architecture.

The organizing principle changes.

From:

Protect the Asset

toward:

Govern the Authority

Because protecting an asset tells us what we want to keep safe.

Governing authority tells us how compromise can create consequence.

Security Is Becoming the Governance of Consequence

This may ultimately be the CISO’s strategic destination.

Cybersecurity is not really about malware.

Or vulnerabilities.

Or firewalls.

Or even data.

Those are mechanisms and objects.

The management problem is consequence.

What could happen?

Who or what could cause it?

Through which authority path?

Under which conditions?

How would we detect it?

How would we stop it?

Who accepts the remaining risk?

That is enterprise security governance.

The CISO Takeaway

Black Hat USA 2026 may eventually be remembered as another conference dominated by AI.

That would miss the larger lesson.

Yes, AI was everywhere.

Black Hat’s own post-event assessment said the agentic age had arrived, and its program emphasized AI, autonomous threats, identity, trust and control alongside systems under stress. (⁠Black Hat)

But the deeper story was not AI itself.

It was delegated authority.

AI agents receive authority.

MCP transports authority.

Supply chains influence authority.

Security tools concentrate authority.

Prompt injection manipulates authority.

AI changes the speed at which attackers acquire authority.

Autonomous remediation exercises defensive authority.

Identity establishes authority.

Networks transport access toward authority.

Hardware underpins authority.

Cyber-physical systems turn authority into physical consequence.

Seen this way, the entire conference begins to look different.

It becomes less a collection of vulnerabilities.

And more a map of where the modern enterprise is placing trust.

That map is changing rapidly.

Authority is moving away from:

• human users,
• static applications,
• fixed infrastructure,
• and predictable workflows.

It is moving toward:

• machines,
• agents,
• APIs,
• control planes,
• autonomous systems,
• software-defined infrastructure,
• and dynamic compositions.

The CISO operating model must follow it.

The central security question for the next decade will therefore not simply be:

What systems do we need to protect?

It will increasingly be:

What authority have we delegated — to whom, through which systems, under what constraints, with what evidence, and with what possible consequence?

That is a much harder question.

But it is also a much better one.

Because the enterprise of the future will not be secured by preventing every machine from acting.

It will be secured by ensuring that machines can act only within authority the organization consciously intended to delegate.

That requires:

• identity,
• ownership,
• constraint,
• authorization,
• verification,
• observation,
• revocation,
• and accountability.

In other words:

governance.

And that may be the most important lesson Black Hat USA 2026 leaves for the CISO.

Delegate the objective.
Bound the authority.
Verify the execution.
Preserve the ability to revoke.
Keep accountability human.

The CISO’s job is no longer only to protect the enterprise’s systems.

It is to ensure that the enterprise remains in control of what those systems are allowed to cause.

That is the transition:

From Security of Systems

to

Governance of Authority.

And that is where the next CISO operating model begins.

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.