Daddy Issues: When APIM Workspaces Inherit the Parent Identity

This is a personal blog and all content herein is my own opinion and not that of my employer.

Introduction

Sometimes security research starts with an exploit.

Sometimes it starts with a much more boring question:

“Where is the actual security boundary?”

This one started with the latter.

I was evaluating Azure API Management (APIM) Workspaces and dedicated Workspace Gateways as part of a real architecture review.

The specific use case involved placing a highly connected workload onto an existing shared APIM platform.

I wanted to understand whether a Workspace with its own dedicated gateway could provide a sufficiently strong runtime boundary from the parent APIM service.

Microsoft’s documentation talked about runtime isolation.

That sounded promising.

But “runtime isolation” can mean a lot of things.

Separate compute? Separate networking? Separate noisy-neighbour boundary? Separate identity? Separate secrets? Separate trust boundary?

Those aren’t interchangeable.

So instead of assuming what Microsoft meant, I decided to test it.

And this is where things got interesting.

What Is An APIM Workspace?

Azure API Management Workspaces allow organisations to divide an APIM service into independently managed areas.

A Workspace can have its own APIs, products, subscriptions and policies, while still existing under a parent APIM service.

A Workspace can also be associated with a dedicated Workspace Gateway.

That dedicated gateway runs on separate infrastructure and can be configured so that Workspace APIs are served only from that gateway rather than the built-in gateway of the parent APIM service.

Conceptually:

That sounds like a useful isolation model.

But I wanted to know what “dedicated” actually meant from a security perspective.

The First Problem: An Undocumented Control Plane Property

Before I could test the runtime boundary properly, I needed to ensure the Workspace API was only being served by the dedicated Workspace Gateway.

The relevant Workspace resource property is:

{
  "properties": {
    "serveOn": "workspace"
  }
}

The problem?

At the time of testing, I could not find the value workspace documented in the Microsoft Learn documentation, REST API specifications or ARM/Bicep schemas.

I tried several fairly obvious guesses:

gateway
workspaceOnly
workspaceGateway
dedicatedWorkspaceGateway

All were rejected.

The default behaviour, when serveOn was omitted, was:

workspaceAndDefault

which means the Workspace API can run on both the built-in APIM gateway and any associated Workspace Gateway.

That obviously isn’t useful when you’re trying to test the dedicated runtime boundary.

Eventually I obtained the correct value:

"serveOn": "workspace"

Once configured, the ARM representation of the Workspace confirmed:

{
  "properties": {
    "serveOn": "workspace"
  }
}

And runtime testing confirmed:

• Requests through the dedicated Workspace Gateway succeeded.
• Requests through the parent APIM built-in gateway no longer reached the Workspace API.

So the routing boundary worked.

That gave me a clean test environment.

Routing isolation: confirmed.

Now I could test the more interesting part.

The Identity Question

The parent APIM service had a system-assigned managed identity.

The Workspace did not.

That’s an important distinction.

There was no Workspace identity configured. There was no Workspace Gateway identity configured.

So my question was simple:

Can an API executing exclusively on the dedicated Workspace Gateway obtain a token using the system-assigned managed identity of the parent APIM service?

I deployed a Workspace API with an inbound policy using:

<authentication-managed-identity
    resource="https://graph.microsoft.com"
    output-token-variable-name="msiToken" />

The API then decoded only safe claims from the returned JWT so I could determine which identity had been used. No raw access tokens were stored in the test evidence.

The Result

The policy succeeded.

That alone was interesting. The Workspace itself had no managed identity, yet:

<authentication-managed-identity>

worked.

I decoded the resulting JWT and inspected the oid claim.

It matched the principal ID of the system-assigned managed identity of the parent APIM service.

Exactly.

So the runtime path looked like this:

The API was executing exclusively on dedicated Workspace runtime infrastructure.

But the identity it could use belonged to the parent APIM service.

That is a very different isolation story.

Direct IMDS Access

At this point I wanted to understand whether the dedicated Workspace runtime simply had direct access to Azure Instance Metadata Service (IMDS).

So I tried calling:

http://169.254.169.254/metadata/identity/oauth2/token

from APIM policy using send-request.

That failed, no token was obtained.

So the behaviour was not simply:

Workspace Runtime -> IMDS -> Parent Managed Identity

Instead, the supported APIM policy path succeeded while direct access to IMDS did not.

Conceptually:

This matters because it demonstrates that the behaviour is mediated by APIM itself. The dedicated Workspace runtime doesn’t appear to be discovering the identity accidentally via IMDS. The platform is deliberately servicing the managed identity request.

But Can You Actually Do Anything With The Token?

Getting a JWT with an unexpected oid is interesting. Actually exercising the inherited authorization is better evidence.

So I created a controlled Azure Key Vault. I granted the parent APIM managed identity access to that Key Vault. I did not grant a Workspace identity access.

There was no Workspace identity to grant access to.

I then used the Workspace API to acquire the required token using:

<authentication-managed-identity>

and used that authorization against Key Vault.

It worked.

So this was no longer:

“I can retrieve a token.”

It was:

A workload executing on a dedicated Workspace Gateway can use Azure authorization granted to the managed identity of the parent APIM service.

That’s the important part.

Runtime Isolation Is Not Identity Isolation

The architecture now looked like this:

The routing boundary was real. The dedicated runtime infrastructure was real.

The identity boundary was not.

The effective privilege available to the Workspace API was not limited to permissions explicitly assigned to that Workspace.

It could use permissions granted to the parent APIM service identity.

That is a very important architectural property.

Why Does This Matter?

Imagine a large shared APIM platform.

The parent APIM managed identity may legitimately have access to:

• Azure Key Vault
• Storage Accounts
• Service Bus
• Azure SQL
• Microsoft Graph
• Internal Azure APIs
• Other sensitive resources

Now imagine multiple Workspaces owned by different application or platform teams.

A dedicated Workspace Gateway may lead architects to reasonably assume that workload execution is isolated from the parent runtime.

But if every Workspace can use the parent APIM managed identity, then every permission granted to that identity potentially forms part of the trust boundary of those Workspaces too.

For example:

That creates a classic permission-drift problem.

A permission may be granted to the APIM identity for Workload A. A completely different Workspace may later become capable of using the same permission.

No Azure or Entra compromise is required.

No Key Vault vulnerability is required.

No managed identity credential needs to be stolen.

The platform simply gives the Workspace the identity.

Secure By Default?

There is an important nuance here.

I do not think allowing a Workspace to use the parent APIM identity is automatically an invalid product feature.

There are scenarios where customers may want that.

But there is a huge security difference between:

Customer explicitly chooses:
"Allow this Workspace to use the parent APIM identity"

and:

Workspace API executes authentication-managed-identity
and automatically receives the parent APIM identity.

The first model establishes an explicit trust relationship.

The second model creates an implicit one.

A secure-by-default model would, in my opinion, look more like this:

Instead, the behaviour I observed was effectively:

No explicit identity delegation control was required.

That is the bit I find uncomfortable.

What Microsoft Documented

At the time of my testing, Microsoft’s public documentation around Workspaces and managed identity was confusing.

The documentation described Workspace runtime isolation, while managed identity support and behaviour were not clearly defined.

Most importantly, the effective identity relationship between:

• the parent APIM service,
• the Workspace,
• and the dedicated Workspace Gateway

was not obvious.

Following my report, the documentation changed.

The relevant Microsoft Learn content was updated to explicitly state:

“Workspaces support using managed identities by using the service’s identity.”

The earlier wording also contained a limitation around using managed identity for features such as Azure Key Vault, which was removed.

I find that particularly interesting because Key Vault was the resource I used in my proof of concept to demonstrate the inherited authorization.

The documentation now more accurately describes the behaviour of the product.

That is a positive change.

But documentation and isolation are not the same thing.

Documentation Is Not Isolation

This is worth saying explicitly:

Changing documentation does not change a security boundary.

There are two separate questions.

Is The Behaviour Documented?

It is now much clearer that a Workspace can use the service’s identity.

Good.

Customers need to know that.

Is The Behaviour A Strong Security Default?

That is a different question.

A dedicated Workspace Gateway provides dedicated runtime infrastructure. But the Workspace can still use the identity of the parent APIM service.

Therefore:

Dedicated runtime != dedicated identity boundary

If you require identity isolation, this matters considerably more than whether the underlying compute is dedicated.

Reporting To MSRC

I reported the issue to the Microsoft Security Response Center (MSRC) on 11 August 2026.

The report was titled:

Azure API Management Workspace can obtain parent APIM managed identity token across dedicated runtime boundary

I proposed the security impact as:

Elevation of Privilege

The report included:

• APIM service deployment with system-assigned managed identity
• Workspace creation
• Dedicated Workspace Gateway
• serveOn: "workspace"
• Verification that the API could only execute through the dedicated gateway
• authentication-managed-identity
• JWT claim extraction
• oid correlation with the parent APIM managed identity
• Azure Key Vault authorization demonstrating practical inherited privilege

Microsoft’s Researcher Portal also included an AI validation function.

I ran it before submitting.

Its summary was:

“Clear, concrete vulnerability describing an identity boundary exposure … with reproduced steps and real-world impact, beyond a documentation issue.”

I kept the screenshot.

For reasons.

Microsoft’s Response

On 26 August 2026, MSRC assessed the case as Low severity, below Microsoft’s threshold for immediate servicing.

The key part of the response was:

“Providing tokens to customers in general is by design, however we will take the necessary steps to update the documentation.”

I don’t think that sentence addresses the security issue I reported.

The issue was never:

“Azure provides tokens.”

Managed identities would be fairly useless if Azure didn’t provide tokens.

The reported issue was:

A workload executing exclusively on a dedicated Workspace runtime can obtain a token representing the parent APIM service identity, without an explicit customer configuration establishing that identity trust relationship, and can exercise the parent’s Azure authorization.

Those are not the same thing.

The case was determined to be below the threshold for bounty or CVE and MSRC stated that it would not be tracked further.

Microsoft did offer a Special Mention for the report.

A Brief Aside: The AI Was Apparently Less Confused

There is something slightly amusing about Microsoft’s own report validation agent summarising the issue as:

"…identity boundary exposure… real-world impact, beyond a documentation issue."

before the human assessment concluded:

"…providing tokens to customers in general is by design…"

The portal does, quite correctly, warn:

AI-generated analysis may not be accurate.

I’ll leave that there.

Complete - Duplicate?

There was one other slightly odd part of the MSRC process.

At one point the Researcher Portal displayed the report status as:

Complete - Duplicate

I asked Microsoft whether this was intentional and whether the exact issue had previously been reported.

At the time of writing there has been no response to any of my follow-up questions.

A duplicate status does not necessarily mean that Microsoft previously accepted the issue as a vulnerability.

It could represent an earlier report with the same eventual disposition.

But it is an interesting status given the statement that this behaviour is simply by design.

The Documentation Changed

Shortly after the MSRC assessment, I observed a change in Microsoft’s APIM Workspace documentation.

The change explicitly documented that Workspaces use the service’s identity.

Conceptually, the documentation moved toward describing the architecture that my testing had demonstrated:

An architect reading the documentation today should have a better chance of understanding the identity relationship than I did when I started testing.

But my security concern remains.

My Thoughts On The Microsoft Response

I disagree with the idea that this is adequately characterised as simply “providing tokens to customers.”

The important security principle is identity inheritance.

A Workspace with a dedicated runtime can obtain the parent APIM identity and therefore inherit whatever authorization has accumulated on that identity. That is not equivalent to a normal application requesting a token for its own identity.

The privilege available to the Workspace is determined by a security principal belonging to the parent service. To me, that means the effective trust boundary is the entire APIM service, not the dedicated Workspace Gateway.

Microsoft is perfectly entitled to design the service that way. But it needs to be understood by customers designing security boundaries.

And personally, I would much rather this capability require explicit enablement.

Why Does This Matter?

1. Permission Drift

The parent APIM identity may accumulate permissions over time. Those permissions may have been granted for completely unrelated APIs. A Workspace can potentially inherit them.

2. Shared Identity Blast Radius

Compromise or policy misuse inside one Workspace may expose authorization intended for another workload.

3. Dedicated Runtime Can Create A False Sense Of Security

Separate infrastructure sounds like a strong boundary. It is not an identity boundary.

4. Least Privilege Becomes Harder

The smallest privilege set for one Workspace becomes entangled with the privilege set of the parent APIM service.

5. Security Architecture Depends On Knowing The Real Boundary

If you are using Workspaces to separate teams or applications with materially different trust levels, you need to account for the shared identity context.

Mitigations

There is no magic customer-side setting that turns a Workspace Gateway into a separate APIM service. So mitigation is mostly architectural.

Treat The Parent APIM Managed Identity As Shared

Assume permissions granted to the APIM service identity may be available to Workspace APIs. Review role assignments accordingly.

Keep The Parent Identity Boring

Apply least privilege.

Avoid giving the parent APIM managed identity broad access merely because it is convenient.

Prefer Workload-Specific Credentials Where Possible

Do not use the parent APIM identity as a generic credential bag for unrelated APIs.

Separate High-Trust Workloads

If two workloads genuinely require separate identity and authorization boundaries, use separate APIM services rather than assuming a Workspace provides that boundary.

Validate Rather Than Assume

If an architecture claims to isolate something, test the actual property you care about.

Routing?
Test routing.

Network?
Test network access.

Identity?
Get a token and inspect it.

Authorization?
Call the resource.

Don’t tell me. Show me.

Disclosure Timeline

Conclusion

This research started with one question:

Where is the actual security boundary?

The answer is now much clearer.

An Azure API Management Workspace can execute exclusively on a dedicated Workspace Gateway while still obtaining tokens as the system-assigned managed identity of the parent APIM service.

That identity can carry real Azure authorization.

I demonstrated that using Azure Key Vault.

So although the Workspace runtime is dedicated, its identity context is not necessarily isolated from its parent APIM service.

Microsoft’s documentation now makes that relationship clearer.

But the architectural lesson remains:

Runtime isolation is not identity isolation.

If your security design depends on those being the same thing, you may have a problem.

As cloud services become more composable and increasingly abstract away the machinery underneath, we need to get much better at asking exactly what a boundary isolates.

Compute? Network? Configuration? Credentials? Identity? Authorization?

“Dedicated” is an implementation adjective, not a security guarantee.

And as ever:

Don’t trust the architecture diagram. Test the boundary.

As ever, thanks for reading and feel free to leave comments down below!