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.
Suhail Ahamed J 0 Reputation points Microsoft External Staff Moderator

2026-10-13T09:23:58.53+00:00
Hi @Erkki Holttinen ,

I am following up on your thread regarding access to the Azure AI Foundry Agents section within a Managed Application deployment.

To ensure you have a complete roadmap of the available pathways, I have consolidated my previous analysis with the valuable additions shared by Jubin Soni. Together, these represent the definitive guide to addressing this data-plane and tenant isolation boundary:

Consolidated Resolution & Workarounds

Verify Deny Assignment Scope (New): Review the deny assignment settings on your Managed Resource Group (MRG). Specifically, check if data actions are denied along with control-plane actions. This often explains why the backend getAgentsResolver call triggers a "workspace not found" error during UI bootstrap.

Don’t Rely on Azure Lighthouse for the Agents Blade (New): While Azure Lighthouse is excellent for delegated control-plane RBAC, it does not bypass the data-plane tenant verification executed by the Agents UI. You should sandbox this early to ensure your access workflows aren't blocked.

Multi-Tenant App Registration for Programmatic Access (New): Instead of user logins, configure a multi-tenant app registration. Once the customer consents to the service principal in their tenant, assign it a narrow, project-scoped role (e.g., Foundry Agent Consumer). When calling the SDK, ensure you explicitly pin the customer's tenant ID in your token credentials:
# Example: Explicitly pinning the customer's tenant credential = DefaultAzureCredential(authority="login.microsoftonline.com", tenant_id="<customer-tenant-id>")

Telemetry Redirection to Your Tenant (New): If you need to monitor execution (latency, errors, token usage) without granting portal access to either side, route your project’s diagnostics and Application Insights data to a Log Analytics workspace in your publisher tenant via diagnostic settings.

Thin Admin API or Agent Applications (Original): To keep your prompts, system instructions, and configurations completely hidden from the customer:

Agent Application: Publish the agent as an application and grant the customer invocation-only rights.

Mediator API: Build a lightweight, publisher-hosted API that proxies requests to the customer's Foundry workspace using the scoped service principal.

Could you let us know if this combined guidance clarifies the structural limitation and helps you finalize your alternative architecture? If this resolution is helpful, please feel free to mark the most relevant answers as accepted.

Regards,
Suhail Ahamed J

2 answers

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

kagiyama yutaka 5,575

I think the first check is the identity actually used by the Agents request. Check the Managed Application authorizations, Foundry project RBAC, and the token's tid.

Authorized publisher identities are exempt from the MRG deny assignment, but MRG access alone doesn't grant Foundry data-plane access. If customer-tenant identities and consent are off the table, the suggested service principal approach doesn't fit ur requirements.

0 comments

Answer 2

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.