DEF CON 34 — Part 3

How tool connectivity turns local compromise into transitive authority

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

For years, security architects have been trained to ask a deceptively simple question:

What can this identity access?

It is the foundation of least privilege, role-based access control, privileged access management and much of Zero Trust.

But agentic systems are making that question insufficient.

The more important question is becoming:

What can this identity cause another system to access on its behalf?

That difference looks small.

Architecturally, it is enormous.

Model Context Protocol is emerging as one of the mechanisms through which this distinction becomes operational.

MCP allows an AI system to discover tools, invoke services, retrieve information and initiate actions across systems that the model itself does not directly control.

That is precisely why MCP is useful.

It is also why MCP deserves to be understood as more than an AI integration protocol.

From an attacker’s perspective, MCP can become a routing layer for authority.

And research presented around DEF CON 34 provides an unusually clear demonstration of what that means.

The Credential Relay Problem

At DEF CON 34’s Cloud Village, Marios Gyftos and Chrysostomos Manousis presented research titled New Hope for SSRF: Exploiting Credential Relay from APIM to AI Foundry.

The researchers described a recurring weakness across six Azure services spanning AI, Kubernetes, developer tooling and traditional cloud infrastructure.

The pattern was strikingly simple:

the destination of an outbound request and the credentials attached to that request were determined independently.

An attacker could influence where the request went.

The service would decide what credential should accompany it.

Put those together and an apparently legitimate cloud feature becomes a credential delivery mechanism.

The researchers summarized findings affecting Azure AI Foundry, Azure AI Speech, Azure MCP Servers, AKS MCP and Azure API Management, with impacts they said ranged from theft of live Managed Identity tokens to Kubernetes lateral movement. One finding was assigned CVE-2026-26118, while others had been reported to Microsoft’s security team. (⁠Cloud Village)

The primitive can be reduced to:

**Attacker-controlled destination
+
Trusted service
+
Automatically attached credential

---
Credential relay**

At first glance, this sounds like another variation of Server-Side Request Forgery.

It is.

But that description understates its architectural significance.

Traditional SSRF asks:

Can I make the server send a request somewhere it should not?

Credential relay asks:

Can I make a trusted system authenticate to somewhere I control — or use its authority along a path I choose?

That is a substantially more powerful question.

Because the valuable asset is no longer merely network reachability.

It is delegated authority.

From SSRF to Authority Routing

Consider the traditional SSRF model:

Attacker → Application → Internal endpoint

The attacker abuses the application’s network position.

Cloud environments made this more dangerous because internal metadata services could return credentials:

Attacker → Application → Metadata service → Credential

Cloud providers subsequently invested heavily in mitigating that pattern.

Agentic infrastructure introduces another variation.

Imagine:

Attacker-controlled content
↓
Agent
↓
MCP tool
↓
Cloud service
↓
Managed Identity
↓
Target resource

Now the attacker may never communicate directly with the sensitive system.

They may never possess the identity used to access it.

They may never even have network connectivity to it.

They only need influence over a system that can cause the appropriate sequence of legitimate operations.

This is why MCP security cannot be reduced to securing MCP servers.

The real security object is the authority path created by the connection.

The Rise of Transitive Authority

This leads to one of the most important concepts for understanding agentic infrastructure:

Transitive Authority

Suppose an AI agent has no direct access to a production database.

The security team therefore concludes:

The agent cannot access production.

But the agent can invoke an MCP tool.

That MCP server runs using a Managed Identity.

The Managed Identity can invoke an internal API.

The API can query the production database.

The actual path therefore becomes:

Agent
→ MCP
→ Service
→ Managed Identity
→ API
→ Database

The agent does not possess database credentials.

It does not need them.

It possesses something potentially equivalent:

the ability to cause an authorized system to exercise them.

This is transitive authority.

And it fundamentally changes how privilege must be calculated.

Effective Privilege Is Larger Than Assigned Privilege

IAM systems generally answer questions such as:

Which roles are assigned to this identity?

Which resources can this service principal access?

Which permissions does this Managed Identity possess?

Those remain necessary questions.

But consider an agent with extremely limited direct permissions.

Its IAM record might look reassuring:

Analyzed individually, each assignment may appear defensible.

Analyzed compositionally, the result may be:

AI Agent → Production

The effective privilege of the agent therefore cannot be determined solely from the permissions attached to the agent.

A better approximation is:

Effective Privilege = Direct Authority + Reachable Delegated Authority

And even that is incomplete.

Because reachable authority can itself invoke additional authority.

The real calculation is recursive.

Effective privilege is the sum of every authority path a system can cause to execute.

That is the security problem MCP exposes particularly clearly.

MCP Changes the Shape of the Attack Graph

MCP is often described as something resembling a universal interface for AI tools.

That analogy is useful operationally.

Security teams should extend it.

Every new MCP connection adds edges to an enterprise attack graph.

Before MCP:

Application → API

After MCP:

Agent → MCP → Tool → API

But tools themselves may invoke other services:

Agent
→ MCP
→ Tool
→ Cloud API
→ Workload Identity
→ Kubernetes
→ Secret
→ Database

The number of components matters less than the number of trust transitions.

Each transition asks a different security question.

• Can the agent invoke the tool?
• Can untrusted content influence that invocation?
• Which identity does the MCP server use?
• Does the server preserve the user’s identity or substitute its own?
• Which downstream credentials are automatically attached?
• Can the destination be influenced?
• Can tool parameters alter the target?
• Can returned data influence another tool invocation?
• Can one tool create authority that another tool subsequently consumes?

That last question is particularly important.

Because agentic systems do not merely execute isolated API calls.

They compose actions.

Why Managed Identity Makes This More Interesting

Managed identities are one of the best improvements cloud platforms have made to credential management.

They reduce static secrets.

They eliminate many embedded passwords.

They support automatic credential rotation.

They integrate directly with cloud authorization.

None of that makes them inherently unsafe.

But agentic systems introduce a subtle problem.

A Managed Identity can be perfectly secure as a credential while the mechanism deciding when and where to use it is exploitable.

Microsoft’s current Foundry documentation illustrates how closely identity and MCP tool execution are connected. Foundry can authenticate MCP servers using agent identities, project Managed Identities, API credentials or OAuth identity passthrough. When Managed Identity authentication is used, the service obtains a token using the relevant agent or project identity and passes it to the MCP server. (⁠Microsoft Learn)

This is operationally elegant.

But it highlights the architectural question:

Who controls the destination and circumstances under which that identity is exercised?

Credential security and credential-use security are different problems.

A credential can be:

• impossible to extract,
• automatically rotated,
• stored in hardware,
• never exposed to a human,

and still be abused if an attacker can manipulate the system that invokes it.

That distinction will become increasingly important.

We Protected the Credential. Did We Protect the Decision?

Traditional credential security focuses heavily on possession.

Can the attacker steal the password?

Can they extract the token?

Can they obtain the API key?

Can they compromise the private key?

Managed identities elegantly reduce many of those risks.

But agentic infrastructure shifts attention from credential possession toward credential invocation.

The attacker may not need to steal the identity.

They may only need to control:

when it is used
where it is used
what it requests
or what operation it authorizes.

That suggests a broader security model.

Instead of asking:

Can the attacker obtain the credential?

we also need to ask:

Can the attacker cause the credential to be exercised for an attacker-selected purpose?

This is credential relay as an architectural problem.

AKS Shows Where the Blast Radius Can Go

The implications become clearer when MCP reaches orchestration infrastructure.

Microsoft’s AKS MCP project is designed specifically to allow AI assistants to interact with Azure Kubernetes Service. Its capabilities include operating Kubernetes resources and retrieving information about networks, compute and clusters. The implementation supports multiple authentication mechanisms, including service principals, workload identities, Managed Identities and existing Azure CLI sessions. (⁠GitHub)

That is powerful automation.

It also demonstrates why the old distinction between an “AI system” and “infrastructure management” is disappearing.

Consider:

Prompt
↓
Agent reasoning
↓
MCP tool selection
↓
AKS operation
↓
Kubernetes control plane
↓
Workload

At the beginning of that chain is language.

At the end is infrastructure.

The attack surface therefore spans both.

A prompt injection vulnerability can become relevant to Kubernetes security.

A malicious document can become relevant to cloud IAM.

An agent configuration mistake can become relevant to workload isolation.

An MCP authorization error can become relevant to production availability.

These are no longer separate security domains.

They are one execution path.

Read-Only Is Not Necessarily Low Risk

This also exposes another familiar security assumption.

Organizations frequently classify integrations as:

read-only

and therefore relatively safe.

That classification can be misleading in compositional systems.

Reading infrastructure metadata may expose:

• resource identifiers,
• network topology,
• cluster configuration,
• service endpoints,
• identities,
• secret locations,
• deployment architecture,
• trust relationships.

One tool’s output can become another tool’s input.

So:

READ → DISCOVER → SELECT → ACT

may transform several individually limited capabilities into a powerful attack chain.

This is one of the recurring themes of compositional security.

The privilege of an individual operation tells us surprisingly little about the privilege of a sequence.

The Confused Deputy Returns

None of this is conceptually unprecedented.

Computer security has known the confused deputy problem for decades.

A privileged program can be manipulated into exercising its authority on behalf of a less privileged actor.

Agentic systems industrialize the conditions under which confused-deputy problems can occur.

Why?

Because agents are specifically designed to interpret ambiguous intent and translate it into actions across systems.

They sit between:

human intent
untrusted information
machine interpretation
tool selection
identity
execution

That is an extraordinarily powerful position.

MCP then standardizes how tools can be attached to that reasoning layer.

The result is potentially a programmable confused deputy.

Not because MCP itself is malicious.

Not because AI agents inevitably fail.

But because we are intentionally building systems whose purpose is to convert information into delegated actions.

Attackers will naturally try to manipulate that conversion.

Prompt Injection Meets Credential Relay

This is where Part 3 connects directly to the previous articles in this series.

Part 1 introduced Semantic Execution:

Data → Interpretation → Authority → Execution

Part 2 examined the agent as an attack path.

MCP provides one mechanism through which that semantic influence can leave the reasoning environment and acquire infrastructure authority.

Imagine a malicious document containing instructions that successfully manipulate an agent.

The attack might proceed:

Malicious content
↓
Agent interpretation
↓
Tool selection
↓
MCP invocation
↓
Attacker-influenced destination
↓
Trusted cloud service
↓
Credential attachment
↓
Credential relay

The Cloud Village researchers explicitly described MCP credential-relay chains that could be delivered remotely through prompt injection without the attacker requiring network access to the target environment. (⁠Cloud Village)

That detail matters.

The attacker does not necessarily need to penetrate the network perimeter first.

Content can initiate the attack path.

That is a profound inversion of the traditional sequence.

Network Segmentation Cannot Solve an Authority Problem

Security architecture still frequently equates reachability with authority.

If System A cannot establish a network connection to System B, we tend to conclude that System A cannot meaningfully affect B.

Agentic systems weaken that assumption.

An agent might not reach a production network.

Its MCP server might.

Or an intermediary Azure service might.

Or an API gateway might.

Or a Kubernetes integration might.

The actual path may therefore look like:

Agent
✕ direct network access
↓
MCP
↓
Authorized intermediary
↓
Production

Network segmentation remains valuable.

But the attacker is no longer necessarily traversing the network directly.

They are traversing delegation relationships.

Zero Trust architecture therefore needs another dimension.

“Never trust, always verify” must apply not only to connections and identities.

It must apply to causal chains of delegated execution.

Shared Identity Versus User Identity

One architectural decision becomes especially consequential: whether MCP operations preserve individual user identity or execute using a shared service identity.

Microsoft’s Azure MCP documentation explicitly distinguishes these models. Its MCP server can use an On-Behalf-Of flow, preserving per-user authorization downstream, or execute using the hosting environment’s identity, typically a Managed Identity. The latter substitutes shared server authority for individual user authority. (⁠GitHub)

This creates dramatically different security properties.

With identity propagation:

User
→ Agent
→ MCP
→ User authority
→ Resource

With shared service authority:

User
→ Agent
→ MCP
→ Service authority
→ Resource

In the second architecture, the agent may effectively become a gateway into privileges that the initiating user does not personally possess.

Sometimes that is exactly the intended architecture.

But then the MCP layer becomes a privilege broker.

It deserves corresponding controls.

The CISO Problem: MCP Inventories Are Not Enough

Many enterprises are beginning to discuss MCP governance.

That is necessary.

Organizations will need to know:

Which MCP servers exist?

Who deployed them?

Which agents use them?

Which tools do they expose?

Which data can they access?

Those questions create an MCP inventory.

But DEF CON’s lesson suggests that inventory alone is insufficient.

A CISO needs an MCP authority graph.

For every meaningful MCP connection, map:

Caller
↓
Agent
↓
MCP server
↓
Tool
↓
Execution identity
↓
Downstream service
↓
Target resource

Then add:

Input sources

and:

Output destinations

Now the architecture begins to reveal the real attack surface.

The Five Questions Every MCP Deployment Should Answer

Before an MCP integration reaches production, security architecture should be able to answer five questions.

1. Who can cause the tool to execute?

Not merely who can authenticate to the MCP server.

Include:

users, agents, other agents, documents, RAG sources, browser content and automated workflows.

2. Which identity actually executes the downstream action?

The human?

The agent?

A project identity?

A service principal?

A Managed Identity?

A shared integration account?

This must never remain implicit.

3. Who controls the destination?

Can a user, agent, prompt, document, API response or tool output influence the host, URL, resource identifier, namespace, subscription or tenant?

Destination integrity must become a first-class control.

4. What authority becomes reachable transitively?

Do not stop at the MCP tool’s documented permission.

Follow every downstream trust relationship.

5. Can one tool’s output increase another tool’s authority?

This is where compositional attacks emerge.

Security testing must examine sequences, not only individual calls.

Destination Integrity Is Becoming a Security Primitive

The Azure findings suggest a control that deserves far more attention:

Destination Integrity

Security systems have become sophisticated about validating:

Who is making the request?

They are less consistently designed to validate:

Where is the authenticated request actually going?

In agentic infrastructure, both questions must be cryptographically and architecturally bound where possible.

The dangerous condition is:

Credential decision ≠ Destination decision

A stronger architecture binds:

Identity + Audience + Destination + Operation + Context

into a single authorization decision.

The system should not merely decide:

This agent may use this identity.

It should decide:

This agent may use this identity for this operation against this explicitly permitted destination under these conditions.

That is much closer to what runtime authorization for agents needs to become.

MCP Needs an Egress Security Model

Traditional API security concentrates heavily on ingress.

Who can call the API?

Are they authenticated?

What rate limits apply?

What payload is accepted?

MCP requires equal attention to egress.

Security teams should control:

• destinations MCP servers may contact,
• audiences for which tokens may be requested,
• redirects,
• dynamic URLs,
• DNS behavior,
• private address ranges,
• metadata endpoints,
• cross-tenant destinations,
• tool-generated URLs,
• agent-generated parameters.

This is particularly important because the MCP server may occupy a privileged network position.

A compromised agent should not automatically inherit the server’s entire network reachability.

Tool authorization without egress authorization is incomplete.

Least Privilege Must Become Least Path

Traditional least privilege says:

Give an identity only the permissions it needs.

Agentic infrastructure requires an extension:

Provide only the authority paths necessary for the intended task.

Call this:

Least Path

An agent may require:

Agent → MCP → CRM

It does not necessarily require:

Agent → MCP → arbitrary HTTP destination

An infrastructure assistant may require:

Agent → AKS MCP → namespace A

It may not require:

Agent → AKS MCP → Azure CLI → entire subscription

A research assistant may require:

Agent → document store → read

It may not require:

Agent → document store → URL extraction → authenticated outbound request

Least privilege governs nodes.

Least Path governs edges.

Both are required.

Logging Must Capture Causality

There is another uncomfortable consequence.

Traditional logs may record every component correctly and still fail to explain the attack.

The agent log says:

Tool requested.

The MCP log says:

Tool executed.

Entra says:

Managed Identity authenticated successfully.

Azure logs say:

API call authorized.

AKS says:

Command executed.

Every individual security system reports legitimate behavior.

The malicious property exists in the relationship between the events.

Detection therefore needs to reconstruct:

Input → Agent decision
→ Tool invocation
→ Identity selection
→ Credential issuance
→ Destination
→ Resource action

This is causal telemetry.

Without it, SOC analysts see isolated legitimate events instead of an attack path.

What This Means for Zero Trust

Agentic systems expose a limitation in many Zero Trust implementations.

We have become good at asking:

Who are you?

What device are you using?

What resource are you accessing?

We are less mature at asking:

Why is this action happening?

Agentic systems make that question unavoidable.

The identity may be valid.

The device may be compliant.

The MCP server may be approved.

The Managed Identity may be correctly configured.

The API call may satisfy RBAC.

And the entire transaction may still be malicious.

Because the initiating reason came from attacker-controlled context.

That means authorization increasingly needs to incorporate provenance and causality.

Not merely:

Who?

but:

Who caused whom to do what, using whose authority, because of which input?

A CISO Control Model for MCP

MCP should therefore be governed across four independent layers.

Layer 1 — Connectivity

Which MCP servers and tools may exist?

Maintain an enterprise registry and control deployment.

Layer 2 — Identity

Which identity does each tool use?

Prefer explicit per-agent or per-user identity where feasible and minimize shared authority.

Layer 3 — Destination

Where may authenticated requests go?

Bind credentials to approved audiences and destinations.

Layer 4 — Causality

What caused the action?

Preserve sufficient telemetry to reconstruct the path from input to execution.

Most current governance discussions concentrate on Layers 1 and 2.

DEF CON 34 suggests Layers 3 and 4 may ultimately determine whether MCP becomes manageable infrastructure or an attacker-controlled routing fabric.

The Board-Level Translation

The board does not need an explanation of JSON-RPC, MCP transports or Azure token audiences.

The risk can be stated much more simply:

AI systems increasingly obtain authority indirectly through connected services. Therefore, limiting the permissions assigned directly to an AI system does not necessarily limit what that system can cause the enterprise to do.

That is the governance issue.

An organization can deploy an apparently low-privilege agent while unintentionally giving it a high-privilege execution path.

This makes agent authorization a system architecture problem rather than merely an IAM configuration problem.

The Architectural Shift

MCP is not creating this problem by itself.

It is making an existing architectural phenomenon easier to compose.

Modern enterprises already contain enormous graphs of:

• APIs,
• service accounts,
• Managed Identities,
• workload identities,
• CI/CD systems,
• cloud services,
• Kubernetes,
• SaaS integrations,
• automation,
• and delegated authorization.

Agents introduce a new participant capable of navigating those graphs dynamically.

MCP gives that participant a standardized mechanism for discovering and invoking capabilities.

That combination changes the attack surface.

The attacker no longer needs to compromise every component.

They need to find a route through them.

The CISO Takeaway

The most important question for MCP security is therefore not:

Is this MCP server secure?

Nor is it:

Does this agent have excessive permissions?

The better question is:

What authority can an attacker reach if they gain influence over this agent?

Answering that requires following the entire chain.

Agent
→ MCP
→ Tool
→ Identity
→ Service
→ Resource

Then follow the next chain.

And the next.

Until there are no more authority transitions.

That resulting graph represents something traditional IAM inventories do not show:

the system’s executable authority.

DEF CON 34 demonstrated why that distinction matters.

The next generation of attackers may not spend their time stealing every credential they need.

They may instead learn to route legitimate credentials through legitimate systems toward attacker-selected outcomes.

And that gives us the central lesson of Part 3:

The effective privilege of an agent is the sum of every authority path it can cause to execute.

Security architecture has spent decades protecting credentials.

Agentic infrastructure forces us to protect something larger:

the routes through which authority travels.

Next: Part 4 — The AI Supply Chain Can Execute Before the Application Does

Models, loaders, skills and repositories increasingly sit upstream of conventional application security. The next article examines why loading an AI artifact is becoming an execution decision — and why software, model and agent supply chains are beginning to converge.

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.