Microsoft Foundry: Unable to Access Agents in a Managed Application Deployment — Tenant Mismatch and Permissions Issues

Question

Microsoft Foundry: Unable to Access Agents in a Managed Application Deployment — Tenant Mismatch and Permissions Issues

Erkki Holttinen 0

Problem description

I am unable to access the Agents section in Microsoft Foundry for a deployment created through Azure Managed Applications. Despite some portal areas being accessible, the Agents area does not load as expected, showing errors about insufficient permissions or workspace not found.

Environment

The issue involves Microsoft Foundry deployed via Azure Managed Applications into a managed resource group with deny rules, in a scenario involving different Microsoft Entra tenants between publisher and customer.

What I've already tried

I have reviewed the browser network trace, observed the tenant mismatch error (in request query?getAgentsResolver), and confirmed that publisher-side accounts can partially access the portal but cannot load the Agents section. No additional troubleshooting steps or configuration checks are documented.

Current status

I am seeking clarification on whether Azure AI Foundry supports publisher-managed access in this deployment pattern, and guidance on how to properly set up access without exposing underlying assets, as current workarounds do not meet our security and operational requirements.

Suhail Ahamed J 0 Reputation points Microsoft External Staff Moderator

2026-09-30T11:56:25.8133333+00:00
Hello @Erkki Holttinen ,
Thanks for the detailed write-up and the network trace that helped narrow this down quickly.

What you're seeing is expected behavior, not a misconfiguration on your side. Azure AI Foundry's Agents experience is a data-plane surface, and it authenticates against the tenant that owns the Foundry resource. In an Azure Managed Application deployment, the Foundry resource lives in the customer's managed resource group (customer tenant), so a token issued from your publisher tenant will fail the tenant check. which is exactly the getAgentsResolver tenant mismatch you captured. The deny assignment on the MRG compounds this by blocking the control-plane calls the portal makes to resolve the project/workspace, which is why you get "workspace not found" alongside the permission errors.

The portal areas that do load for you are the ones backed by control-plane reads that your publisher identity still has rights to via the managed app's publisher access. The Agents blade isn't one of them.

Why this happens

Separate control-plane vs. data-plane authorization. Foundry evaluates resource/project management and agent runtime access independently, and the data-plane path requires a token from the resource's home tenant (Authentication and authorization in Microsoft Foundry).

Managed Application deny assignments. Deny assignments applied to the managed resource group block actions regardless of RBAC role assignments, including ones the Foundry portal depends on (Azure Managed Applications overview).

Cross-tenant token issuance. DefaultAzureCredential and portal SSO will default to your home tenant unless the target tenant is explicitly specified, producing the "token tenant does not match resource tenant" class of error (azure-dev #5974 ).

Recommended path forward
Given your requirement to retain publisher-side operational access without exposing underlying assets, I'd suggest the following. Please validate each step in a non-production subscription first.

1. Confirm the publisher access model on the managed app definition

Review the authorizations block in your managed application definition and confirm which publisher principal IDs and role definition IDs are granted against the MRG.

Note that this grants control-plane access only. It does not produce a token valid for Foundry's data plane in the customer tenant. Adding more control-plane roles here will not fix the Agents blade.

2. Assign Foundry RBAC roles explicitly at the Foundry resource / project scope

Foundry ships dedicated roles such as Foundry User and Foundry Agent Consumer for management vs. invocation-only scenarios (Role-based access control for Microsoft Foundry ).

Grant the least-privileged role that meets your need. Foundry Agent Consumer if you only need to invoke agents, not manage them.

Please verify the exact current role names and IDs against the doc above before templating, as Foundry's RBAC roles have been renamed during the Foundry rebrand.

3. Enable the identity to authenticate into the customer tenant For a publisher identity to obtain a valid token for the customer-tenant Foundry resource, one of the following is required:

Azure Lighthouse (recommended for your scenario). Onboard the customer subscription/MRG via delegated resource management. This is the supported mechanism for cross-tenant operational access and keeps your publisher identities in your own tenant with no standing access to customer data beyond what you scope. Lighthouse delegation and managed app deny assignments must be validated together. I'd need to confirm the exact interaction for the Foundry data plane.

A guest (B2B) identity or a service principal provisioned in the customer tenant, then az login --tenant <customer-tenant-id> before accessing the resource. This works but puts an identity in the customer's tenant, which may not meet your isolation requirements.

4. For programmatic access, pin the tenant explicitly

az login --tenant <customer-tenant-id

In SDK code, set the tenant on the credential rather than relying on defaults. e.g. pass tenant_id / TenantId to the credential, or set additionallyAllowedTenants where cross-tenant fallback is intended.

5. If you need agent invocation without exposing the Foundry resource

Consider publishing the agent as an Agent Application and assigning invocation rights directly on that resource instead of granting access to the parent Foundry project (Agent applications). This is the cleanest fit for "let the publisher/consumer call the agent without seeing the underlying assets."

If you have any follow-up questions or need clarification on any of these steps, feel free to reach out or continue the discussion in the thread.

Thanks,
Erkki Holttinen 0 Reputation points

2026-10-01T05:01:14.7033333+00:00

Thank you for the detailed explanation.

This clarifies the behavior we are seeing and confirms our understanding of the underlying cause.

Based on your explanation, Azure AI Foundry agent management is implemented as a data-plane operation that requires authentication against the tenant that owns the Foundry resource. In an Azure Managed Application deployment, the Foundry resources reside in the customer tenant, while publisher access provided through the Managed Application authorization model applies primarily to the control plane.

As a result, publisher identities can perform certain management operations against the deployed resources but cannot fully manage Azure AI Foundry agents without obtaining a token from the customer tenant.

While solutions such as guest identities, customer-tenant identities, Azure Lighthouse, or other cross-tenant access mechanisms may provide a way to obtain access, they do not address the fundamental challenge in our scenario. Our solution is intentionally designed so that customers do not have access to the underlying Foundry environment, agent definitions, prompts, instructions, or other intellectual property, and operational management must remain entirely under publisher control. Any approach that requires customer-tenant identities, customer-side configuration, or customer-managed access paths falls outside the operational boundaries of our solution.

Given the explanation provided, we therefore conclude that Azure AI Foundry agent management is currently not compatible with our Managed Application operating model when the Foundry resources are deployed inside the customer's managed resource group.

We will treat this as a product limitation and evaluate alternative deployment architectures for Azure AI Foundry.

Thank you for helping clarify the behavior.

1 answer

Your answer

Erkki Holttinen 0 Reputation points

2026-10-01T05:01:14.7033333+00:00

Thank you for the detailed explanation.

This clarifies the behavior we are seeing and confirms our understanding of the underlying cause.

Based on your explanation, Azure AI Foundry agent management is implemented as a data-plane operation that requires authentication against the tenant that owns the Foundry resource. In an Azure Managed Application deployment, the Foundry resources reside in the customer tenant, while publisher access provided through the Managed Application authorization model applies primarily to the control plane.

As a result, publisher identities can perform certain management operations against the deployed resources but cannot fully manage Azure AI Foundry agents without obtaining a token from the customer tenant.

While solutions such as guest identities, customer-tenant identities, Azure Lighthouse, or other cross-tenant access mechanisms may provide a way to obtain access, they do not address the fundamental challenge in our scenario. Our solution is intentionally designed so that customers do not have access to the underlying Foundry environment, agent definitions, prompts, instructions, or other intellectual property, and operational management must remain entirely under publisher control. Any approach that requires customer-tenant identities, customer-side configuration, or customer-managed access paths falls outside the operational boundaries of our solution.

Given the explanation provided, we therefore conclude that Azure AI Foundry agent management is currently not compatible with our Managed Application operating model when the Foundry resources are deployed inside the customer's managed resource group.

We will treat this as a product limitation and evaluate alternative deployment architectures for Azure AI Foundry.

Thank you for helping clarify the behavior.

Answer 1

Hi Erkki, thank you for your questions. A few additions to the answer above.

Send telemetry to your own tenant. Enable tracing into Application Insights and route diagnostic settings to a Log Analytics workspace you control. Cross-tenant delivery usually needs Azure Lighthouse or customer approval, but it covers most support needs like latency, errors, and token usage without any portal access.
Don't count on Lighthouse fixing the Agents blade. Lighthouse delegates control plane RBAC, but the Agents experience checks the tenant that owns the resource. Test this in a sandbox early.
Use a multi-tenant app registration for programmatic access. Have the customer consent so a service principal exists in their tenant, then assign it a narrow Foundry role at the project scope. Pin the tenant explicitly in your credential.
Consider a thin publisher-owned admin API. If neither side should see the underlying assets, a small service that calls Foundry with a scoped identity is easier to secure and audit than opening up the portal.
Review the deny assignment settings. Check whether data actions are denied along with control plane actions, since that may explain the "workspace not found" error.