Azure MCP Server SSRF and Credential Relay: Six Services That Carry a Managed Identity Token Wherever the Request Points

On Saturday August 8, 2026, Marios Gyftos and Chrysostomos Manousis presented "New Hope for SSRF: Exploiting Credential Relay from APIM to AI Foundry" at Cloud Village, DEF CON 34. They found the same root cause in six Azure services: Azure AI Foundry's code interpreter and OpenAPI tool, Azure AI Speech, Azure MCP Servers, AKS MCP, Azure API Management, and Entra ID. All findings went to MSRC before the talk.

The root cause fits in one sentence. User-controlled input reaches an outbound HTTP request that carries a managed identity token, an HMAC secret, or an OAuth credential, and nothing validates where that request goes.

That is server-side request forgery with a wallet attached. Classic SSRF gets you a request from a trusted network position. Credential relay gets you a request from a trusted network position that is already holding the keys.

The mechanism

Two decisions happen separately inside these services.

The first decision picks the credential. A service that needs to fetch a resource on your behalf attaches its managed identity token, scoped to whatever audience the service was configured for. That attachment is automatic and happens because the service is designed to act with your authority.

The second decision picks the destination. A URL arrives from somewhere in the request path: an OpenAPI spec the tool was pointed at, a schema field, a document the code interpreter was told to fetch, a webhook target in an API Management policy.

Neither decision consults the other. The credential is chosen by configuration. The destination is chosen by input. When the destination is attacker-controlled, the token walks out of the boundary attached to a request the attacker wrote.

The demonstrated impacts from the talk run from stealing live managed identity tokens for any Azure audience, through production Key Vault URIs and write-capable SAS tokens pulled from Microsoft's own backend, to root remote code execution on Kubernetes nodes reached through a tool that only offered read operations. The AKS one is the detail I keep coming back to. A read-only tool became root on a node, because the tool's read-only property described what the tool exposed rather than what the credential could reach.

What makes this an AI article

Six Azure services having an SSRF class is a cloud security story. The delivery path is what moves it.

Several of these services are MCP servers, or tools reachable through one. An MCP server advertises tools to a model. The model decides which tool to call and with what arguments, based on the conversation it is having. That conversation includes documents, retrieved context, ticket bodies, web pages, and anything else the application put in front of the model.

So the URL that ends up in the outbound request can arrive through the prompt. A support ticket containing a crafted instruction, a README in a repository the agent was asked to summarize, a PDF in a RAG corpus: any of these can reach the model, and the model can act on them by calling a tool with the attacker's URL as an argument. This is indirect prompt injection with a credentialed egress path at the end of it.

The chain is: injected content reaches the model over HTTP, the model emits a tool call, the tool call becomes an outbound HTTP request, and that request carries a managed identity token to a destination the attacker chose.

What a policy gateway does not own here

Being precise about this matters more than being persuasive.

The SSRF itself is Microsoft's to fix, and MSRC has advisories out. The internal validation of a destination URL inside Azure AI Foundry's OpenAPI tool happens in Microsoft's code, on Microsoft's side of the boundary. No proxy that sits between your users and your models patches that.

Managed identity scoping, token audience configuration, and the permissions a service principal holds are identity-platform work. If your AI Foundry deployment's managed identity has read on every Key Vault in the subscription, the blast radius is set by that grant, and a gateway will not shrink it.

Network egress filtering from the Azure service itself is an Azure networking control. Private endpoints, NSGs, and egress restrictions on the compute running the tool are the right controls for that layer, and they are not ours.

Say that plainly to any engineer who asks, or the credibility goes.

The slice that is enforceable at the request boundary

Two things sit squarely on HTTP AI traffic.

The first is the inbound path. The injected instruction has to reach the model, and it reaches it inside a request your application sends to an LLM endpoint. That request is inspectable. Content that carries instruction-shaped payloads aimed at tool invocation, URLs pointing at destinations outside your allowed set, and requests whose context was assembled from untrusted sources are all visible before the model ever sees them. Classification and policy at that point is the earliest place in the chain where anything you control can intervene.

The second is the record. When an agent calls a tool that produces an outbound credentialed request, the question an incident reviewer asks three weeks later is: which human's session originated this, what was in the context that produced the tool call, and what policy state applied at that moment. Azure's activity log records that a managed identity made a request. It records the identity, not the provenance.

Here is the shape that answers the question:

• decision_id: d-8841c2, recorded at 2026-08-14T09:22:07Z
• originating_identity: r.okonkwo@example.com, the human whose session started the chain
• acting_agent: svc-foundry-agent-prod, the principal executing at the time
• context_sources: ticket-48812 and confluence-page-7734, the documents that entered the model's context
• tool_call and tool_argument_host: openapi_fetch, pointed at collector.attacker-controlled.example
• policy: outbound-destination-allowlist-v3, outcome: blocked
• reason: tool argument host outside the allowed destination set

The context_sources field is the one that earns its place. Without it, an investigation into a credential relay event starts by reading three weeks of application logs to work out which document put the URL in the model's context. With it, the answer is one field.

Checks worth running this week

Inventory which Azure services in your environment expose MCP tools to a model, and which of those run under a managed identity. The AKS MCP and Azure MCP Server cases from the talk are the ones most likely to be present and least likely to be on an AI inventory, because they were installed as platform tooling rather than as AI features.

For each, list the audiences its managed identity token is valid for. A token minted for one audience that works against https://management.azure.com/ is the difference between a contained finding and a subscription-wide one.

Check whether any tool accepts a URL, a hostname, or an OpenAPI spec location as an argument. Those are the relay candidates.

Confirm you can answer, for any tool call made in the last 30 days, which user session and which context documents produced it. Most teams find they cannot, and that is the gap worth closing regardless of what Microsoft ships.

The broader MCP control surface is covered in Model Context Protocol security, and the identity side in AI agent identity.

DeepInspect

This is the part of the chain DeepInspect closes. DeepInspect sits as a stateless proxy on the HTTP path between your authenticated users, applications and agents and the model endpoints they call. Requests are classified before they are forwarded, policy is evaluated against the identity that originated the session rather than the service principal executing at the time, and a per-decision record is written into storage you control.

For a credential relay chain, that means the injected instruction is inspected on the way in, tool-call arguments carrying destinations outside your allowed set are evaluated against policy rather than trusted by default, and every decision leaves a record that names the originating human and the context that produced it. Enforcement is inline and fails closed.

DeepInspect does not patch Azure's internal URL validation, scope your managed identities, or filter egress from Microsoft's compute. Those stay with Microsoft and with your cloud platform team.

If you are running MCP tools under a managed identity and cannot trace a tool call back to the session that caused it, the per-decision record above is the missing piece. Book a demo today.