Azure AI Foundry Agent receives 403 Forbidden when connecting to Toolbox MCP endpoint, but same configuration works in another Foundry project

Question

Azure AI Foundry Agent receives 403 Forbidden when connecting to Toolbox MCP endpoint, but same configuration works in another Foundry project

Mayank Pant 0

I am troubleshooting an Azure AI Foundry Toolbox integration issue and would like to understand whether I am missing a configuration or permission.

I have two separate Azure AI Foundry projects:

Project A

Project B

In both projects, I am trying to connect an Azure AI Foundry Agent to a Toolbox using the Toolbox MCP endpoint through the Foundry UI.

In Project A, the Agent can successfully connect to the Toolbox using Microsoft Entra ID with Agent Identity authentication. The Toolbox is published and the tools are discovered correctly.

However, in Project B, I receive a 403 Forbidden error when attempting the same configuration.

This suggests that connecting an Agent to a Toolbox via the MCP endpoint is supported, as the same setup is working successfully in Project A.

Configuration tested in Project B

I have:

Published the Toolbox and confirmed that it contains active tools.

Granted the relevant managed identity the Azure AI Developer role.

Allowed time for RBAC changes to propagate.

Confirmed that the MCP endpoint is reachable.

Tested both:

Agent Identity

  **Project Managed Identity**
  
  Tested the following audience values:
  
     `https://ai.azure.com`
     
        `https://ai.azure.com/.default`

The error I receive is:

Access denied when connecting to the MCP server at https://<foundry-resource>.services.ai.azure.com/api/projects/<project>/toolboxes/<toolbox>/versions/<version>/mcp while enumerating tools (HTTP 403 Forbidden). Please verify: The configured credential, connection, or selected identity has the downstream permission, RBAC role, workspace or resource access, or access policy required by this server. If the endpoint is behind private networking or IP allowlists, requests from the selected network path are permitted. The server's access control configuration allows this operation for the configured authentication mode.

Comparison with Project A

Interestingly, I initially experienced a similar issue in Project A. I made several changes to the role assignments and configuration, but the error did not appear to resolve immediately.

However, when I tested the Agent again yesterday, it was working successfully. I had not made any further changes immediately before the successful test.

This makes me wonder whether there is a specific role assignment that is required, or whether there can be a delay before the relevant permissions become effective.

I have replicated the role assignments that I could identify from Project A in Project B, but the 403 error in Project B is still occurring.

What I am trying to understand

Could anyone clarify the following?

What are the exact steps in the Foundry UI to connect an Agent to a Toolbox using the Toolbox MCP endpoint?

What RBAC roles/permissions are required for the Agent Identity or Project Managed Identity to access the Toolbox?

Does the Foundry resource, project, Toolbox, or Agent require any specific role assignment?

Are there any additional access policies, authentication settings, audience values, or networking configuration required?

Is there a known RBAC propagation delay for this integration?

Is there a difference in the permissions required when using Agent Identity vs Project Managed Identity?

I would particularly appreciate an example of the minimum required RBAC configuration, as I can compare this against the two projects.

The main reason I am asking is that the exact same type of MCP Toolbox integration is working in Project A, but returns a 403 in Project B, so I am trying to identify what configuration or permission differs between the two.I am troubleshooting an Azure AI Foundry Toolbox integration issue and would like to understand whether I am missing a configuration or permission.

I have two separate Azure AI Foundry projects:

Project A

Project B

In both projects, I am trying to connect an Azure AI Foundry Agent to a Toolbox using the Toolbox MCP endpoint through the Foundry UI.

In Project A, the Agent can successfully connect to the Toolbox using Microsoft Entra ID with Agent Identity authentication. The Toolbox is published and the tools are discovered correctly.

However, in Project B, I receive a 403 Forbidden error when attempting the same configuration.

This suggests that connecting an Agent to a Toolbox via the MCP endpoint is supported, as the same setup is working successfully in Project A.

Configuration tested in Project B

I have:

Published the Toolbox and confirmed that it contains active tools.

Granted the relevant managed identity the Azure AI Developer role.

Allowed time for RBAC changes to propagate.

Confirmed that the MCP endpoint is reachable.

Tested both:

Agent Identity

  **Project Managed Identity**
  
  Tested the following audience values:
  
     `https://ai.azure.com`
     
        `https://ai.azure.com/.default`

The error I receive is:

Access denied when connecting to the MCP server at
https://<foundry-resource>.services.ai.azure.com/api/projects/<project>/toolboxes/<toolbox>/versions/<version>/mcp
while enumerating tools (HTTP 403 Forbidden). Please verify: The configured credential, connection, or selected identity has the downstream permission, RBAC role, workspace or resource access, or access policy required by this server. If the endpoint is behind private networking or IP allowlists, requests from the selected network path are permitted. The server's access control configuration allows this operation for the configured authentication mode.

Comparison with Project A

Interestingly, I initially experienced a similar issue in Project A. I made several changes to the role assignments and configuration, but the error did not appear to resolve immediately.

However, when I tested the Agent again yesterday, it was working successfully. I had not made any further changes immediately before the successful test.

This makes me wonder whether there is a specific role assignment that is required, or whether there can be a delay before the relevant permissions become effective.

I have replicated the role assignments that I could identify from Project A in Project B, but the 403 error in Project B is still occurring.

What I am trying to understand

Could anyone clarify the following?

What are the exact steps in the Foundry UI to connect an Agent to a Toolbox using the Toolbox MCP endpoint?

What RBAC roles/permissions are required for the Agent Identity or Project Managed Identity to access the Toolbox?

Does the Foundry resource, project, Toolbox, or Agent require any specific role assignment?

Are there any additional access policies, authentication settings, audience values, or networking configuration required?

Is there a known RBAC propagation delay for this integration?

Is there a difference in the permissions required when using Agent Identity vs Project Managed Identity?

I would particularly appreciate an example of the minimum required RBAC configuration, as I can compare this against the two projects.

The main reason I am asking is that the exact same type of MCP Toolbox integration is working in Project A, but returns a 403 in Project B, so I am trying to identify what configuration or permission differs between the two.

Suhail Ahamed J 0 Microsoft External Staff Moderator

Hello @Mayank Pant ,

Greetings,

A 403 during MCP tool enumeration generally indicates that the identity being used by the connection does not have the required access to the Foundry project or Toolbox.

Here are the main things I would check.

1. Verify the authentication mode

Open the agent in the Foundry portal and check the authentication configuration for the MCP tool connection.

If the connection is configured to use Agent Identity, verify that the agent identity has the required permissions on the Foundry project that contains the Toolbox.

A common issue is assigning permissions to the project managed identity while the MCP connection is configured to use a different identity.

2. Check the RBAC assignment

Go to:

Azure portal → Foundry resource/project → Access control (IAM)

Review the role assignments and verify that the identity used by the MCP connection has the appropriate data-plane permissions required for the Toolbox.

Make sure the assignment is made at the appropriate project/resource scope.

The current Foundry RBAC roles and scopes are documented here:

Role-based access control in Microsoft Foundry

3. Check both the agent identity and project identity

If the project managed identity is being used for other Toolbox management or publishing operations, its existing permissions may still be required.

However, the important point for this MCP connection is to verify the permissions of the identity configured for the connection itself.

4. Reconnect the MCP connection

After changing RBAC permissions:

Save the permission changes. 2.Allow a short period for the changes to take effect. 3.Re-save or recreate the MCP connection. 4.Run tool enumeration again.

This helps ensure that the connection is established again using the updated permissions.

5. Verify the Toolbox endpoint

Also verify that:

The Toolbox has been published.

The endpoint points to the correct Foundry resource/project.

The version in the endpoint corresponds to the published Toolbox version.

You are not accidentally using the endpoint from another project.

The Toolbox setup documentation is available here:

Use the Toolbox tool in Microsoft Foundry

If you are configuring a remote MCP server through the Foundry portal, also verify that the authentication configuration matches the documented Microsoft Entra ID setup:

Model Context Protocol tool

6. Check networking if RBAC looks correct

If the above checks look correct, compare the networking configuration between the working and failing projects.

For example, check whether either resource has:

Public network access disabled

Private endpoint configuration

Network restrictions or IP allowlists

Differences in networking configuration can also result in access failures.

What I would compare between the working and failing projects

Item	Working project	Failing project
MCP authentication mode	Compare	Compare
MCP authentication mode	Compare	Compare
Identity used by connection	Verify	Verify
Required RBAC permissions	Present?	Present?
Toolbox published	Yes/No	Yes/No
Endpoint/project	Correct?	Correct?
Toolbox version	Correct?	Correct?
Network configuration	Compare	Compare

The first thing I would verify is which identity the MCP connection is actually configured to use and whether that identity has the required permissions on the project containing the Toolbox.

If the issue persists, sharing the authentication mode, relevant role assignments (without any secrets or sensitive identifiers), and the UTC timestamp of a failed request should help narrow it down.

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.

1 answer

Your answer

Answer 1

Since the same Toolbox/MCP configuration works from another Foundry project, I would treat the working project as the control and compare the two projects' identities and authorization rather than changing the MCP server first.

A "403 Forbidden" is especially significant here because Foundry Toolbox has two separate authorization boundaries:

Agent → Toolbox
Toolbox/tool → downstream service

So successful creation of the Toolbox connection does not necessarily prove that the runtime agent identity is authorized to invoke it.

For a Prompt Agent, first identify the managed identity actually being used by the failing agent. Microsoft documents that the agent identity requires the Foundry User role on the Foundry project in this scenario.

Compare that assignment between the working and failing projects.

In the failing project, check:

Foundry project → Access control (IAM)

and verify that the agent's managed identity has the required project access.

Also compare the identity used by the working agent against the failing agent rather than comparing only your own user account. Your interactive Azure permissions and the runtime agent's permissions are not necessarily the same thing.

Next, inspect the Toolbox's downstream authentication.

If the tool uses Microsoft Entra authentication, verify:

whether it uses Agent Identity or Project Managed Identity;
the Entra audience configured for the connection;
the RBAC assignments on the underlying service;
that the role assignment is granted to the identity from the failing project, not only the identity from the working project.

This distinction matters because Microsoft documents agent-to-Toolbox identity and downstream authentication as separate authorization boundaries. A tool returning "401" or "403" can therefore indicate that the agent reached the Toolbox but authorization failed farther downstream.

If this is an MCP connection using Entra authentication, also compare the configured Audience between the two projects. The audience must correspond to the Application ID URI expected by the MCP server.

I would troubleshoot it as an A/B comparison:

Identify the runtime agent identity in Project A (working).
Identify the runtime agent identity in Project B (403).
Compare Foundry project RBAC assignments.
Compare Toolbox/project connection authentication types.
Compare the configured Entra audience.
Compare downstream-service RBAC for both identities.
Check whether either project uses Project Managed Identity while the other uses Agent Identity.
After correcting RBAC, allow time for the role assignment to propagate before testing again.

If "tools/list" succeeds but the actual tool invocation returns 403, that is another useful boundary test. It suggests the agent can reach/discover the Toolbox but authorization is failing during tool execution or against the downstream resource.

If even Toolbox discovery fails with 403, concentrate first on the agent → Foundry project/Toolbox authorization path.

Because one Foundry project already works, I would not rebuild the MCP server until these identity differences have been ruled out. The working project gives you a very useful known-good configuration to compare against.

Microsoft Learn references:

Use a Toolbox with a hosted agent:

https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/use-toolbox-hosted-agent?wt.mc_id=studentamb_521824

Create and manage a Toolbox:

https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/toolbox?wt.mc_id=studentamb_521824

MCP authentication:

https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcp-authentication?wt.mc_id=studentamb_521824