DEF CON 34 — Part 13 of 13

From Vulnerability Management to Attack-Path Governance

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

For decades, cybersecurity has been organized around things.

Servers. Endpoints. Applications. Networks. Accounts. Databases. Cloud workloads. APIs.

• We inventory them.
• We classify them.
• We scan them.
• We patch them.
• We assign controls to them.
• And eventually, we calculate something called residual risk.

That model has served security organizations reasonably well because the systems we were protecting could often be decomposed into understandable components.

But there is a problem.

Attackers do not attack our asset inventory.

They attack the relationships between the assets.

An AI agent reads a document.

The document influences the agent.

The agent invokes a tool.

The tool uses a workload identity.

The identity obtains temporary credentials.

Those credentials access a cloud control plane.

The control plane modifies an automation pipeline.

The pipeline generates another credential.

That credential reaches another environment.

At no point does there necessarily have to be one catastrophic vulnerability.

The attack emerges from the composition.

That is the most important conclusion I take from DEF CON 34.

And it requires a change in the CISO operating model.

The next generation of security programs will need to govern not only assets and vulnerabilities, but authority paths and consequences.

I call this:

Attack-Path Governance.

The Lesson Behind the Individual Hacks

The easiest way to misunderstand DEF CON is to treat it as a collection of exploits.

Prompt injection.

MCP attacks.

Cloud identity abuse.

Malicious models.

Coding-agent compromise.

CI/CD persistence.

Inference theft.

Approval fatigue.

Security-tool compromise.

Firmware attacks.

PLC manipulation.

Autonomous vulnerability research.

Individually, these appear to belong to different security disciplines.

AI Security.

Cloud Security.

Application Security.

DevSecOps.

IAM.

SOC.

Hardware Security.

OT Security.

But viewed together, something else becomes visible.

The attacks repeatedly cross those boundaries.

The interesting part is often not the compromised component.

It is the transition between components.

Consider the pattern:

Input → Interpreter → Authority → Execution → Consequence

That pattern appeared again and again throughout this series.

The input might be:

• a document,
• a repository,
• a model,
• a tool response,
• a support ticket,
• telemetry,
• an API response,
• or another agent.

The interpreter might be an AI system.

The authority might belong to a developer, workload identity, cloud service or automation platform.

The execution might occur through MCP, CI/CD, an API, a cloud control plane or a security product.

And the consequence may happen somewhere entirely different.

That is why the attack surface is becoming the system.

Our Security Model Is Still Too Component-Centric

Most enterprise security programs still implicitly follow a model resembling this:

Asset Inventory
↓
Vulnerability Identification
↓
Control Assignment
↓
Risk Assessment
↓
Remediation
↓
Residual Risk

There is nothing inherently wrong with this model.

We still need it.

Unknown assets remain dangerous.

Unpatched vulnerabilities remain dangerous.

Misconfigured identities remain dangerous.

But the model becomes incomplete when authority is increasingly delegated across systems.

Imagine that every individual component in an architecture passes its security review.

The AI model is considered safe.

The MCP server is authenticated.

The workload identity uses short-lived credentials.

The API requires authorization.

The cloud platform follows least privilege.

The CI/CD system is hardened.

The human approves sensitive operations.

Every box in the architecture diagram might therefore appear acceptable.

Yet the composition could still produce:

Agent → MCP → API → Workload Identity → Cloud Control Plane → CI/CD → Production

And that path may permit something nobody intended.

This creates an uncomfortable possibility:

Every component can be compliant while the system remains exploitable.

That is a governance problem, not merely a vulnerability problem.

The Missing Inventory

Security teams maintain many inventories.

Asset inventories.

Application inventories.

Software inventories.

Data inventories.

User directories.

Service accounts.

Cloud resources.

Certificates.

Dependencies.

Increasingly, AI model inventories.

But there is another inventory that will become just as important:

The Relationship Inventory

It asks questions that traditional asset inventories do not.

What trusts what?

What can instruct what?

What can authenticate as what?

What can cause what to execute?

What can obtain new credentials?

What can modify future automation?

What information can cross from one trust domain into another?

What systems can ultimately affect physical reality?

Those questions reveal something far closer to the attacker’s mental model.

An attacker does not see:

Server A has CVSS 7.4.

The attacker sees:

If I control this input, can I influence this interpreter, which can invoke this tool, which inherits this identity, which can modify that resource?

That is an attack path.

From the Asset Graph to the Authority Graph

The enterprise security model therefore needs another dimension.

The traditional view might look like this:

ASSETS
↓
VULNERABILITIES
↓
CONTROLS
↓
RISK
The emerging model looks different:
ASSETS
↓
IDENTITIES
↓
TRUST RELATIONSHIPS
↓
DELEGATED AUTHORITY
↓
EXECUTION PATHS
↓
CONSEQUENCES

This is an Authority Graph.

And it may become one of the most important architectural artifacts a CISO owns.

Control 1: Build the Authority Graph

Identity governance traditionally asks:

Who has access to this system?

That question is no longer sufficient.

We must increasingly ask:

Who can cause access to this system?

Those are not the same thing.

Consider:

Human
↓
Developer Workstation
↓
Coding Agent
↓
MCP Server
↓
Cloud CLI
↓
Workload Identity
↓
Production Resource

The coding agent may not possess direct production credentials.

The MCP server may not possess direct production credentials.

Yet the chain as a whole may be able to cause production changes.

The effective privilege therefore belongs to the path.

This leads to a principle that deserves to become part of modern IAM architecture:

Effective privilege is the sum of the authority paths a principal can cause to execute.

That is significantly broader than RBAC.

It means PAM teams will eventually need visibility into agents.

Cloud-security teams will need visibility into tool invocation.

AI-security teams will need visibility into workload identity.

DevSecOps teams will need visibility into agent context.

And SOC teams will need enough telemetry to reconstruct the chain.

This is why agentic security cannot remain an isolated AI governance discipline.

It is becoming identity architecture.

Identity Is No Longer Just About Principals

Traditional IAM assumes that authority belongs to recognizable principals:

Human identity

or

Machine identity

Agentic systems introduce something more ambiguous.

The agent may act using somebody else’s authority.

The result is a separation between:

Principal

and

Decision Maker

A developer identity may authenticate the operation.

But an AI agent may have decided that the operation should occur.

That creates a fundamental attribution problem.

The audit log may say:

Eckhart changed production configuration.

The reality may be:

An agent running within Eckhart’s authenticated environment interpreted repository content, selected a tool and caused the authenticated operation.

Authentication alone therefore tells us increasingly little about intent.

We need provenance.

For sensitive actions, organizations will need to know:

Who authenticated?

What agent initiated the action?

What context influenced the decision?

Which tool executed it?

Which identity authorized it?

Which policy allowed it?

What exactly changed?

That is much richer than today’s access log.

Control 2: Separate READ, ACT and EGRESS

One of the simplest architectural disciplines I would introduce for autonomous systems is also one of the most powerful.

Every agent should be evaluated across three independent dimensions:

READ

What can the system know?

Documents.

Mailboxes.

Repositories.

Databases.

Logs.

Tickets.

Customer records.

Internal knowledge bases.

Internet content.

Agent memory.

ACT

What can the system change?

Files.

Repositories.

Infrastructure.

Cloud resources.

Tickets.

Payments.

Accounts.

Configurations.

Production systems.

Other agents.

EGRESS

Where can information leave?

External APIs.

Email.

Messaging platforms.

Web requests.

MCP servers.

Third-party models.

Plugins.

External storage.

These permissions should not automatically travel together.

A system that can READ sensitive data should not therefore automatically be able to EGRESS it.

A system that can READ untrusted internet content should not automatically be able to ACT on production.

A system that can ACT on production should not necessarily be able to consume arbitrary untrusted context.

This creates architectural combinations worth treating differently.

Broad READ + narrow ACT + narrow EGRESS

may be manageable.

Narrow READ + broad ACT

requires strong transaction controls.

But:

Broad READ + broad ACT + broad EGRESS

should immediately attract CISO attention.

That combination creates enormous compositional risk.

The Most Dangerous Permission May Be Indirect

This becomes particularly important with MCP and agent tooling.

DEF CON 34’s agent-focused research repeatedly reinforced the importance of tool-mediated relationships. AI Village’s poster program explicitly focused on adversarial attacks against agents and agentic systems, including research into agent-to-agent propagation through MCP-connected environments. (⁠AI Village)

The enterprise mistake would be to inventory only:

Which MCP tools does this agent have?

The better question is:

What authority can each MCP tool transitively reach?

Suppose an agent can invoke only one innocuous-looking service.

But that service can invoke another API.

That API authenticates through managed identity.

That identity can access Secrets Manager.

One secret provides CI/CD access.

CI/CD can deploy production workloads.

The agent’s real permission is not:

Invoke Tool A.

Its effective permission may be:

Modify Production.

The intervening architecture does not reduce the privilege.

It hides it.

Control 3: Move From Log Monitoring to Trust-Path Monitoring

Our monitoring architecture has the same organizational problem.

Security telemetry is typically divided by technology.

The IAM team sees identity events.

The endpoint team sees process execution.

The cloud team sees control-plane activity.

The DevSecOps team sees pipeline execution.

The AI platform sees prompts and tool calls.

The MCP infrastructure may maintain another log.

The SOC attempts to correlate them.

But the attacker traverses all of them.

Consider:

Malicious repository
↓
Coding agent
↓
Tool invocation
↓
Cloud CLI
↓
AssumeRole
↓
CI/CD modification
↓
New workload
↓
Secrets access

The repository was legitimately cloned.

The developer legitimately ran the agent.

The agent legitimately invoked an authorized tool.

The cloud identity legitimately assumed a permitted role.

The pipeline legitimately deployed code.

The workload legitimately accessed its secret.

Only the sequence is malicious.

This changes detection engineering.

We need to move from:

Event Detection

toward:

Path Detection

The SIEM question becomes less:

Is this API call suspicious?

and more:

What chain of authority caused this API call?

That means correlating:

identity + endpoint + agent + tool + MCP + cloud + CI/CD + workload

into one security narrative.

The SOC Will Need Causality

This may eventually become one of the defining challenges for security operations.

Today’s SOC is optimized around observable events.

Tomorrow’s SOC will increasingly need to reconstruct causality.

Not merely:

What happened?

But:

Why was the system allowed to make it happen?

That distinction matters enormously in autonomous environments.

A successful API request tells us the technical action.

It does not tell us whether the reason for the action was legitimate.

And that was one of the recurring lessons throughout this series.

The central security question for autonomous systems is not:

Was the action authorized?

It is:

Was an authorized action performed for an authorized reason?

Traditional IAM cannot answer that question alone.

Control 4: Introduce Runtime Policy Enforcement

That brings us to perhaps the most important architectural control.

We should stop assuming that one security mechanism can safely make both the decision and execute the decision.

For high-impact autonomous actions, there should be an independent policy layer.

Instead of:

Agent → Tool → Execution

we need:

Agent
↓
Proposed Action
↓
Independent Policy Decision
↓
Authorized Transaction
↓
Execution

The policy system should evaluate the actual transaction.

Not merely the agent’s description of it.

For example:

Agent says:

Update the customer configuration.

The policy engine sees:

Modify production tenant X, change parameter Y from A to B, using identity Z, initiated from agent Q, based on context source R.

Now policy can determine whether that specific transaction is permissible.

This is the agentic equivalent of transaction authorization.

And critically, the parameters approved must be the parameters executed.

Why Human Approval Is Not Enough

Part 8 of this series explored why Human-in-the-Loop can become the next MFA fatigue problem.

That conclusion belongs directly inside the CISO architecture.

A human clicking:

Approve

does not necessarily constitute meaningful authorization.

Especially when the human sees only the agent’s representation of what it intends to do.

For critical operations, the transaction should be reconstructed independently.

Agent proposes
↓
Policy layer reconstructs consequence
↓
Human verifies independent representation
↓
Policy binds approval to exact parameters
↓
Execution occurs

This prevents the agent from controlling both:

1. the transaction, and
2. the description presented to the approver.

The distinction is subtle but fundamental.

Approval is not verification.

Security Architecture Needs a Concept of Semantic Privilege Escalation

Traditional privilege escalation is technical.

A process obtains greater operating-system privileges.

A user becomes administrator.

A service assumes another role.

Agentic systems create another possibility.

The system does not technically escalate privileges.

Instead, malicious context convinces an already privileged system to use its legitimate authority differently.

No privilege boundary is necessarily violated.

Yet the attacker achieves a privileged outcome.

We could describe this as:

Semantic Privilege Escalation.

The attacker escalates not by acquiring the credential, but by influencing the decision process controlling the credential.

That distinction matters because many existing security controls are designed to prevent unauthorized possession of authority.

Agentic attacks may instead target the reasoning process deciding when legitimate authority should be exercised.

That is a very different attack surface.

Autonomous Attackers Change the Other Side of the Equation

DEF CON 34 also demonstrated that compositional security is not only a defensive problem.

The attacker is becoming compositional too.

AI Village’s HalCTF explicitly had participants design autonomous agents that navigated sandbox environments, exploited targets and captured flags without direct human interaction. (⁠AI Village)

PortSwigger researcher James Kettle’s HTTP Terminator work went further conceptually: autonomous experimentation was used to discover new HTTP desynchronization techniques and attack chains, with the research explicitly examining where autonomous systems could generate novel security research and where human/AI collaboration remained necessary. (⁠PortSwigger)

This matters strategically.

The economics of attack-path discovery are changing.

Historically, finding a complex multi-system attack path could require substantial human expertise and experimentation.

Increasingly, autonomous systems can explore combinations.

Try hypothesis A.

Observe failure.

Modify parameter.

Try hypothesis B.

Combine technique C with environment D.

Repeat.

Parallelize.

The defender therefore faces a difficult asymmetry.

Our environments contain millions of possible relationships.

Attackers increasingly have machines capable of exploring them.

That makes relationship visibility a prerequisite for defense.

Attack Surface Management Must Evolve

External Attack Surface Management asks:

What can attackers reach?

Attack-Path Governance adds:

What can reachable systems cause?

That distinction is becoming crucial.

Recon Village researchers at DEF CON 34 described finding thousands of exposed AI agents in the wild and emphasized that these deployments can be reachable, enumerable and over-permissive. (⁠Recon Village)

An exposed agent should therefore not be evaluated merely as another internet-facing application.

Its risk depends on what sits behind it.

An exposed informational chatbot is one thing.

An exposed agent connected to:

MCP + SaaS + cloud identity + internal data + execution tools

is something entirely different.

Exposure multiplied by delegated authority determines consequence.

Control 5: Recovery Must Restore Trust, Not Merely Systems

The final lesson may be the most operationally difficult.

Incident response traditionally ends when we believe the attacker has been removed.

Compromised endpoint?

Reimage it.

Compromised account?

Reset credentials.

Compromised server?

Rebuild it.

Compromised token?

Revoke it.

But compositional attacks make the recovery boundary uncertain.

Suppose an attacker compromised an agent.

Did the attacker modify its memory?

Did it poison a knowledge source?

Did it alter an MCP configuration?

Did it create another tool?

Did it modify CI/CD?

Did CI/CD create new credentials?

Did it alter federation?

Did it manipulate firmware?

Did it compromise a BMC?

Did it change another autonomous system that will recreate the attack later?

This changes the final incident-response question.

It should no longer simply be:

Which systems were compromised?

It should become:

Which trust relationships must now be considered compromised?

That leads to a concept I would call:

Recovery of Trust

Recovery ends only when the organization can once again justify the trust assumptions required to operate the environment.

That may require rebuilding more than machines.

It may require rebuilding:

• agent memory,
• RAG stores,
• MCP infrastructure,
• CI/CD pipelines,
• workload identities,
• federation,
• secrets infrastructure,
• automation,
• model artifacts,
• firmware,
• BMCs,
• or hardware trust anchors.

Part 10 of this series made the same point from the hardware direction.

If compromise occurs below the operating system, reinstalling the operating system does not necessarily restore trust.

The same principle applies above it.

If an attacker compromised the authority graph, rotating one credential may not restore trust either.

What This Means for the CISO

The implications go beyond another control framework.

The organizational structure of cybersecurity itself is becoming part of the problem.

We separate:

IAM.

Cloud Security.

Application Security.

AI Security.

Endpoint Security.

DevSecOps.

SOC.

OT Security.

Product Security.

Third-Party Risk.

Each discipline sees a section of the attack path.

The attacker sees the whole path.

That asymmetry becomes dangerous.

The CISO therefore increasingly needs an architectural function capable of asking across all of those domains:

What is the maximum consequence this system can cause through any reachable authority path?

That is a very different question from:

Is this system compliant?

A Practical Attack-Path Governance Model

I would begin with five controls.

1. Authority Graph

Map:

Human → Agent → Tool → Identity → Resource

Include indirect and transitive authority, not merely IAM assignments.

2. READ / ACT / EGRESS Separation

For every autonomous system determine independently:

READ — What can it know?

ACT — What can it change?

EGRESS — Where can information leave?

Avoid combining all three broadly in the same trust domain.

3. Trust-Path Monitoring

Correlate:

identity + endpoint + agent + MCP + cloud + CI/CD + workload

Detection should increasingly reconstruct authority chains rather than isolated events.

4. Runtime Policy Enforcement

Sensitive autonomous actions should pass through an independent policy decision at execution time.

Do not rely exclusively on:

model guardrails,

static IAM,

or human approval.

5. Recovery of Trust

Incident response must identify not only compromised assets but compromised relationships.

Recovery is complete only when the trust chain itself can once again be justified.

The CISO Dashboard Will Eventually Change

Today, boards commonly receive metrics such as:

Critical vulnerabilities.

Patch compliance.

Phishing rates.

Security incidents.

MFA adoption.

EDR coverage.

Third-party findings.

Those remain useful.

But imagine another generation of metrics.

Agents with production ACT capability

Autonomous systems combining broad READ + ACT + EGRESS

Unmonitored authority paths to Tier-0 systems

MCP servers capable of credential-bearing downstream calls

Developer agents inheriting privileged workstation context

Critical actions without independent runtime authorization

Authority paths lacking end-to-end telemetry

Trust relationships requiring reconstruction after incidents

These are not vulnerability metrics.

They are agency metrics.

They measure how much power the organization has delegated to systems and whether that delegation remains observable and constrained.

That is increasingly what CISOs need to understand.

From Zero Trust to Explicit Authority

Zero Trust gave cybersecurity an important architectural principle:

Never trust, always verify.

The next generation of autonomous systems requires an extension.

Because even a verified identity can perform a dangerous action.

Even an authenticated tool can be manipulated.

Even an authorized agent can act for the wrong reason.

Even a legitimate pipeline can provide persistence.

Even a trusted security product can become an attack path.

So the question becomes:

Verify what?

The answer increasingly needs to be:

Verify the authority chain.

Who initiated the action?

What influenced the decision?

Which tool translated the decision into execution?

Which identity authorized it?

Which policy evaluated it?

What consequence became possible?

That is explicit authority.

The Architecture of Trust Meets the Attack Surface

This is also where the Black Hat USA 2026 and DEF CON 34 series converge.

The Black Hat series asked:

Where are enterprises delegating authority?

DEF CON asks:

How can attackers traverse and combine those delegated relationships?

They are two sides of the same architectural transformation.

Black Hat showed us that the architecture of trust is changing.

DEF CON showed us what happens when attackers begin navigating that architecture.

The conclusion is uncomfortable.

Cybersecurity cannot remain primarily a discipline of protecting components.

Because increasingly, no component needs to fail catastrophically.

The document may behave exactly as designed.

The model may behave exactly as designed.

The agent may behave exactly as designed.

The MCP server may behave exactly as designed.

The identity platform may behave exactly as designed.

The cloud API may behave exactly as designed.

The CI/CD platform may behave exactly as designed.

And the result can still be catastrophic.

Because the vulnerability exists in the composition.

The New Unit of Cyber Risk

That leaves us with the central idea behind this entire series.

For most of cybersecurity’s history, we treated the vulnerable component as the natural unit of analysis.

The vulnerable server.

The vulnerable application.

The vulnerable account.

The vulnerable library.

The vulnerable device.

That model is no longer enough.

The emerging unit of cyber risk is:

The exploitable relationship.

And relationships form paths.

Content → Agent

Agent → Tool

Tool → Identity

Identity → Cloud

Cloud → Automation

Automation → Credential

Credential → Production

Software → Controller

Controller → Physical Process

No individual arrow necessarily looks catastrophic.

Together, they determine what the organization is capable of doing.

And therefore what an attacker may eventually be capable of causing it to do.

The CISO Question After DEF CON 34

For years, CISOs have asked:

What assets do we have?

Then:

Where are we vulnerable?

Then:

Which identities are privileged?

Those questions remain necessary.

But they are no longer sufficient.

The next question is harder:

What can cause what to happen inside my organization?

Answering it requires us to understand assets, identities, agents, tools, credentials, automation, trust relationships and physical consequences as one connected system.

That is not vulnerability management.

It is not merely Zero Trust.

It is not merely AI security.

It is not merely attack surface management.

It is:

Attack-Path Governance.

And after DEF CON 34, I believe it is becoming one of the defining responsibilities of the modern CISO.

Because the attack surface is no longer simply everything we own.

The attack surface is everything we have allowed to trust, instruct, authenticate, invoke and act upon everything else.

The attack surface is becoming the system.

To explore the complete series: Return to Part 0 — DEF CON 34: What CISOs Should Take Away From the Hacker’s View of the Future — for an overview of all 13 articles and the central idea connecting them: cybersecurity is moving from protecting individual assets toward governing relationships, authority paths and ultimately who—or what—can cause what to happen.

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.