Black Hat USA 2026 — Part 1

Why AI security is turning into identity and access management

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 treated artificial intelligence primarily as a data problem.

What information can a model access?
Can confidential data leak through a prompt?
Can an attacker manipulate the model?
Can the model generate harmful content?

Those questions remain relevant.

But they are becoming secondary to a much more consequential one:

What is the AI system allowed to do?

That question moves AI security out of the relatively familiar territory of model security and data protection and into one of the oldest — and hardest — disciplines in enterprise security:

identity and access management.

Black Hat USA 2026 made that transition difficult to ignore.

The conference’s dedicated AI Summit described AI as simultaneously accelerating defensive automation and enabling faster, more sophisticated attacks. Across the broader Briefings program, AI security appeared alongside cloud security, application security, identity, vulnerability research and infrastructure security rather than existing as an isolated discipline. (⁠Black Hat)

One Black Hat briefing captured the emerging problem particularly well:

“The CoreBreak Attack: Turning AI Agents into Credentials Exfiltration Vectors.”

It was classified simultaneously under Cloud Security and AI, ML & Data Science. That combination is revealing. The problem is not confined to the model. It emerges from the relationship between an agent, its identity, the credentials available to it, the systems it can reach and the actions it is authorized to perform. (⁠Black Hat)

This leads to one of the most important conclusions CISOs should take away from Black Hat 2026:

The vulnerability may be AI-specific. The blast radius is determined by IAM.

And that changes the security architecture considerably.

We Are Giving Software Agency

Traditional enterprise software mostly waits.

A user opens an application.
The user chooses an action.
The application executes it.

Even highly automated systems generally operate within relatively deterministic workflows.

Agents introduce something different.

They can receive an objective, gather information, interpret what they discover, select tools, make intermediate decisions and initiate actions across multiple systems.

The sequence increasingly looks like this:

Objective
→ Reasoning
→ Discovery
→ Tool Selection
→ Authorization
→ Execution
→ Consequence

The human may only appear at the beginning of that chain.

This is what makes agentic AI fundamentally different from another SaaS application.

Software is acquiring agency.

And agency requires authority.

An enterprise agent may eventually be able to:

• read email,
• search SharePoint,
• access CRM records,
• query databases,
• create tickets,
• modify repositories,
• execute cloud functions,
• initiate workflows,
• change configurations,
• invoke MCP tools,
• communicate externally,
• trigger security actions,
• or coordinate with other agents.

Black Hat’s own 2026 material increasingly reflects this transition. Discussions around agent security emphasized agents discovering resources, invoking services and initiating actions independently, while Black Hat sponsor research explicitly described “agent identity” as a new element of the identity detection plane. (⁠Black Hat)

This is not merely an AI governance issue.

It is the emergence of a new privileged identity class.

The Privileged User Is No Longer Necessarily Human

Enterprise IAM architecture was historically designed around three broad categories:

Human identities

employees, administrators, contractors, partners.

Machine identities

services, applications, workloads, APIs, certificates.

Privileged identities

administrators and highly trusted service accounts capable of changing critical systems.

Agents blur all three categories.

An agent is software.

But it may act on behalf of a person.

It may use machine credentials.

It may inherit user permissions.

It may call another service operating under a different identity.

And it may independently decide when those privileges should be exercised.

That combination is unusual.

Consider a hypothetical executive assistant.

The executive authenticates to the agent.

The agent can access:

Microsoft 365
→ SharePoint
→ Teams
→ Calendar
→ CRM
→ travel systems
→ internal knowledge bases.

Now connect the same agent through MCP to:

GitHub
→ ServiceNow-like workflows
→ cloud management
→ procurement
→ HR systems.

From the user’s perspective, this is productivity.

From the CISO’s perspective, something very different has happened.

A software system has acquired a transitive privilege graph across the enterprise.

The question is no longer simply:

What can this user access?

It becomes:

What can every agent acting for this user cause every connected system to do?

That graph can be dramatically larger than the user’s apparent permissions.

Delegated Identity Changes the Threat Model

Delegation itself is not new.

OAuth, Kerberos delegation, service accounts, workload identities and API tokens have existed for decades.

What changes with agents is the combination of delegation and autonomous decision-making.

Traditional delegation usually means:

System A is permitted to perform operation B on behalf of user C.

Agentic delegation increasingly means:

System A may determine which operations are necessary to achieve objective X on behalf of user C.

That distinction is enormous.

The first delegates an operation.

The second delegates decision authority.

IAM architectures were largely designed for the first.

Agentic systems increasingly require us to govern the second.

This is why the familiar concept of least privilege is no longer sufficient.

We need another concept alongside it:

Least Agency

Least privilege asks:

What permissions does this identity require?

Least agency asks:

How much independent authority does this system require?

These are not identical questions.

An agent might technically possess permission to delete a repository because its user can delete repositories.

That does not mean the agent should independently be allowed to decide that deleting a repository is necessary.

The identity may possess the privilege.

The agent should not automatically inherit the agency.

That distinction may become one of the foundational principles of enterprise AI security.

READ, ACT, EGRESS

One practical way to translate least agency into architecture is to stop treating agent permissions as a single authorization problem.

Instead, CISOs should separate three dimensions:

READ

What may the agent know?

This includes access to:

• documents,
• email,
• databases,
• source code,
• security telemetry,
• customer information,
• financial information,
• secrets,
• internal knowledge,
• agent memory.

READ determines the agent’s information authority.

ACT

What may the agent change?

This includes:

• creating records,
• modifying configurations,
• sending messages,
• changing code,
• approving workflows,
• provisioning resources,
• disabling accounts,
• executing commands,
• triggering remediation.

ACT determines the agent’s operational authority.

EGRESS

Where may information leave?

This includes:

• external email,
• APIs,
• SaaS platforms,
• MCP servers,
• web requests,
• external models,
• generated files,
• collaboration platforms,
• other agents.

EGRESS determines the agent’s disclosure authority.

These three permissions should not automatically inherit from one another.

An agent that can read confidential information does not necessarily need permission to send it externally.

An agent authorized to modify a ticket does not necessarily require access to every attachment in the ticketing system.

An agent allowed to analyze source code does not automatically require permission to merge code.

Yet many early agent architectures effectively combine all three.

That creates an extraordinarily powerful attack primitive:

READ + ACT + EGRESS

An attacker who can influence such an agent may no longer need conventional remote-code execution.

The agent already has the capabilities the attacker needs.

CoreBreak Illustrates the Deeper Problem

This is why research such as CoreBreak matters beyond the specific vulnerability.

Black Hat described the briefing explicitly as:

“The CoreBreak Attack: Turning AI Agents into Credentials Exfiltration Vectors.” (⁠Black Hat)

The important architectural lesson is not merely that credentials might be exposed.

It is that AI agents increasingly sit at the intersection of:

**untrusted information

• reasoning
• credentials
• enterprise connectivity
• execution authority**

That combination creates a new class of security boundary.

Traditional application security often tries to prevent:

attacker → application → code execution

Agent security increasingly must prevent:

attacker-controlled context
→ agent interpretation
→ legitimate tool invocation
→ legitimate identity
→ unauthorized consequence

Notice what has disappeared from that chain.

The attacker may never need to compromise the target system directly.

The target receives a legitimate request.

The credential may be valid.

The API call may be valid.

The network connection may be valid.

The agent may even believe the action is legitimate.

That is why conventional controls can struggle.

Authentication answers:

Who made the request?

But the security question becomes:

Why is this identity making this request?

Identity Is Necessary. Intent Becomes Important.

Zero Trust popularized the principle:

Never trust, always verify.

Agentic systems add another dimension.

Verification can no longer stop at identity, device and session.

Increasingly we need to understand:

Identity + Context + Intent + Authority + Action

Suppose a finance agent normally:

• reads invoices,
• compares purchase orders,
• identifies discrepancies,
• drafts recommendations.

At 02:14 it suddenly:

• queries thousands of historic invoices,
• retrieves supplier bank details,
• accesses an unrelated document repository,
• invokes a previously unused tool,
• and attempts an outbound API connection.

Every individual operation might technically be authorized.

Together they describe anomalous agency.

This is why agent identity governance will eventually need something resembling behavioral identity security.

We will need to know not only:

What can the agent do?

but also:

What should this agent normally be doing?

Black Hat discussions around high-privilege agent identities pointed in precisely this direction: discovery of agents, understanding ownership, mapping inherited permissions and scopes, observing actual behavior and determining where agents can reach are becoming continuous security requirements rather than one-time configuration exercises. (⁠Black Hat)

The Transitive Privilege Problem

Agents introduce another IAM problem that enterprises have historically handled poorly even among human identities:

transitive privilege.

Imagine:

User
→ Agent A
→ MCP Server
→ Tool
→ Cloud API
→ Service Account
→ Database.

Which identity determines authorization?

The user’s?

The agent’s?

The MCP server’s?

The service account’s?

The workload’s?

Potentially all of them.

The effective privilege of the agent may therefore be determined not by one IAM policy but by the composition of several trust relationships.

Formally, the dangerous assumption is:

Agent privilege = Agent permissions

In reality:

Agent effective authority ≈ delegated identity × connected tools × downstream privileges × reachable data × autonomous decision scope

That is why merely adding agents to an existing IGA platform will not solve the problem.

The security architecture must understand the entire authority chain.

Agents Need Their Own Identities

One of the worst architectural patterns would be to let agents operate invisibly under human identities.

If an employee and an agent share effectively the same identity context, several controls weaken simultaneously:

Attribution becomes ambiguous.

Did the person perform the action or the agent?

Behavioral analytics becomes distorted.

Machine-speed activity appears as human activity.

Revocation becomes difficult.

Stopping the agent may require disrupting the user.

Authorization becomes coarse.

The agent inherits privileges designed for human judgment.

Auditability deteriorates.

Logs show whose credentials were used rather than which actor made the decision.

A better architecture separates them:

Human Identity
→ Delegation
→ Agent Identity
→ Tool Authorization
→ Resource

The agent should become independently identifiable.

That identity should carry attributes such as:

Owner
Who is accountable for it?

Purpose
Why does it exist?

Delegator
On whose behalf is it operating?

Tools
Which capabilities may it invoke?

Data Scope
Which information may it access?

Action Scope
Which changes may it make?

Egress Scope
Where may it communicate?

Autonomy Level
Which decisions may it make independently?

Lifetime
How long should the authority exist?

Risk Tier
What is the potential consequence of compromise?

This is essentially PAM for autonomous software.

But conventional PAM alone will not be enough.

JIT and JEA Need to Come to AI

Two established privileged-access principles become particularly useful here:

Just-in-Time access

and

Just-Enough-Administration.

Agents should not retain powerful permissions simply because they might eventually need them.

Instead:

Agent
→ requests capability
→ policy evaluates context
→ temporary authority issued
→ action performed
→ authority expires

Consider a SOC agent.

It may continuously:

READ

Defender alerts, Sentinel events, threat intelligence and asset information.

But when it decides an endpoint should be isolated, that should require a different authority.

The agent requests:

ACT: isolate endpoint X

The authorization layer evaluates:

• agent identity,
• affected asset,
• incident severity,
• confidence,
• business criticality,
• current policy,
• potentially human approval.

Only then is the remediation capability issued.

That is fundamentally safer than permanently giving the SOC agent broad administrative credentials.

The same model applies to:

cloud agents,
coding agents,
finance agents,
HR agents,
procurement agents,
infrastructure agents.

Persistent privilege should become the exception.

Human Approval Is Not Authorization

There is another trap.

Organizations will attempt to solve agent risk by putting humans into approval workflows.

That is useful.

But it is not sufficient.

Imagine an agent asks:

Approve deployment?

The engineer clicks Approve.

What exactly was approved?

A Git commit?

A container?

An infrastructure change?

A script dynamically generated seconds later?

A sequence of MCP tool calls?

An operation whose parameters changed between review and execution?

Human approval can easily become the AI equivalent of MFA fatigue.

People approve outcomes they cannot meaningfully inspect.

Therefore:

Human approval must not replace technical authorization.

A stronger model is:

**Human Approval

• Independent Policy Enforcement**

The human decides whether the business intent is legitimate.

The authorization system independently verifies whether the requested execution is permitted.

Those are different controls.

Authorization Must Move Closer to Execution

This leads to perhaps the most important architectural implication.

AI guardrails operate primarily around the model.

But the decisive control should often sit elsewhere:

between reasoning and execution.

The architecture should increasingly resemble:

User
→ Agent
→ Reasoning
→ Authorization Boundary
→ Tool
→ Target System

The agent may propose an action.

It should not necessarily authorize that action itself.

That creates separation between:

decision generation

and

decision enforcement.

It is the same principle security architecture has applied elsewhere for decades.

Applications do not normally decide whether their own network traffic is permitted.

Users do not decide whether their own privileged elevation is compliant.

Processes do not issue themselves arbitrary IAM permissions.

Why should agents?

The runtime authorization layer should be independent from the model generating the request.

The Agent Authorization Record

CISOs can make this operational quickly.

Every production agent should have an explicit authorization record.

At minimum:

If an organization cannot answer those questions for a production agent, it does not yet control that agent.

It merely operates it.

From Least Privilege to Least Agency

The security industry spent decades learning to restrict human administrators.

We created:

RBAC.
PAM.
JIT.
JEA.
MFA.
Conditional Access.
Privileged workstations.
Segregation of duties.
Session recording.

Then we began deploying software capable of exercising many of those same privileges — sometimes using the user’s existing permissions — while allowing that software to determine which actions are necessary.

That should make CISOs uncomfortable for a very specific reason.

We are recreating the privileged-user problem at machine speed.

The solution is not to stop agentic AI.

The solution is to apply the lessons learned from privileged access management before agent ecosystems become too complex to retrofit.

That means extending least privilege into least agency.

An agent should receive:

the minimum information necessary,

the minimum tools necessary,

the minimum action authority necessary,

for the minimum period necessary,

with the minimum external communication necessary,

to accomplish a defined objective.

Anything beyond that is accumulated authority.

And accumulated authority eventually becomes attack surface.

A New Question for the CISO

For years, security architecture reviews have asked:

Who has access to this system?

That question now needs a companion:

What autonomous systems can act upon it?

And then another:

Through whose authority?

Those questions reveal risks traditional asset inventories rarely show.

A database might be perfectly hardened.

An API might require strong authentication.

A cloud environment might enforce phishing-resistant MFA.

None of that prevents an authorized agent from becoming the path through which authority is abused.

That is the deeper lesson emerging from Black Hat 2026.

AI security is not simply about protecting models from attackers.

It is about controlling what happens when models become actors.

And once software becomes an actor, security inevitably returns to identity.

But identity alone is no longer enough.

We must govern delegated authority.

The CISO Takeaway

The first generation of enterprise AI governance concentrated heavily on acceptable use, data protection and model risk.

The next generation must govern authority.

CISOs should therefore begin treating production agents as a distinct privileged identity class and require five things before significant autonomy is granted:

unique identity, explicit ownership, bounded authority, independent runtime authorization and complete auditability.

Most importantly, enterprises should stop automatically equating the permissions of a human with the permissions of an agent acting for that human.

A user may legitimately possess broad authority because we expect human judgment to constrain its use.

An autonomous system changes that assumption.

The security principle for the agentic enterprise should therefore become:

Delegate the objective. Do not automatically delegate the authority.

That distinction will matter enormously.

Because the most dangerous AI system may not be the smartest model.

It may simply be the model holding the most powerful credentials.

Black Hat USA 2026 Series

The Architecture of Trust Is Changing

Part 1 — The Agent Is Becoming the New Privileged User

Next:

MCP Is Becoming Enterprise Infrastructure

MCP is becoming enterprise infrastructure. As AI agents gain access to tools, identities and business systems, CISOs must govern not just integration — but the authority flowing through it.

CISOsCISOEckhart Mehler

The next architectural problem follows directly from this one.

Once agents have identities and authority, they need ways to discover and invoke capabilities.

MCP is rapidly becoming that integration layer.

And that means MCP does not merely transport context.

It transports authority.

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.