In-app custom Copilot failure: Foundry tool_server_error on hosted agent after RBAC and payload fixes

hi Mark R. Fitzloff, thx for sharing urs issue here at Q&A portal,

u already cleared the client-side blockers, so the remaining failure is probably inside the hosted agent runtime or one of its configured tools. The useful part is the error changed from 403 and 400 to tool_server_error. That usually means auth and request shape are now good enough, but the agent hits a tool/runtime dependency and that tool path fails server-side.

Since this is a hosted agent, the fastest path is to send MS the Foundry request IDs

f3bfa6e7-c629-4c39-a04a-21f6ed42812b

200b6eaf-6a23-4187-bf31-d8dd447263b9

127dc868-19ba-4d2d-8900-c74866e46ca8

Ask them to trace which tool call failed behind tool_server_error. From the client side, that error is too generic. Could be a tool resource, connection, auth between Foundry and a dependency, bad hosted tool config, or a Foundry runtime issue in PPE. Worth testing the same agent directly in Foundry playground with a simple Ping prompt. If it fails there too, ur Container App API is not the issue. If playground works but API fails, compare identity, project endpoint, agent id/version, and request payload from the API. https://learn.microsoft.com/en-us/azure/ai-foundry/agents/overview

My bet rn not the backend app. The progression shows the request now reaches Foundry and dies inside the agent/tool execution path. Need Foundry runtime logs for those request IDs to get real root cause.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

Hello @Mark R. Fitzloff ,

Welcome to Microsoft Q&A .Thank you for reaching out to us.

Thank you for providing the detailed troubleshooting history, reproduction steps and environment information

Based on the validation completed so far, the previously identified API-level issues appear to be resolved:

• The API health endpoint is returning 200 OK.
• The earlier 403 permission denied issue was resolved following the required RBAC updates.
• The earlier 400 unknown parameter context issue was resolved after correcting the request payload.

This indicates that the request is now successfully reaching Azure AI Foundry and passing the initial authorization and request validation stages.

The remaining failure occurs during a later stage of hosted-agent execution.

The current response HTTP 500 code: tool_server_error is consistent with a failure occurring during hosted-agent runtime processing, dependency access, integration execution, downstream resource communication, or other runtime operations after the request has already been accepted by AI Foundry.

Based on the current symptom pattern, the issue appears more consistent with a hosted-agent runtime dependency, integration or configuration issue

Please check if the following steps help-

1. Validating hosted-agent execution independently from the API layer Run the same request directly from AI Foundry Playground using the same hosted agent. Expected outcomes:
   • If the same failure occurs in Playground: The issue is likely isolated to the hosted agent, runtime dependencies, connected resources, or configuration.
   • If Playground succeeds: Additional investigation should focus on differences between Playground and API-based invocation.
2. Validating connected integrations and dependent resources If integrations, tools or connected resources are configured, validate:
   • Connection health and status.
   • Endpoint accessibility.
   • Authentication settings.
   • Secret, credential, or token validity.
   • Availability of dependent services and resources.
3. Performing isolation testing If feasible, perform controlled testing by simplifying the agent configuration:
   • Test using the minimum required configuration.
   • Temporarily disable non-essential integrations.
   • Compare behavior against a simplified hosted-agent implementation.
   Interpretation:
   • Successful execution with a simplified configuration may indicate a dependency or integration-specific issue.
4. Validating hosted-agent runtime identity permissions The identity used during hosted-agent execution may differ from the identity used by the API caller. The previous RBAC updates addressed API access to Foundry. The next validation should focus on whether the hosted-agent runtime identity has sufficient access to resources referenced during execution. Review access for any applicable resources, including:
   • Azure AI resources.
   • Azure OpenAI resources if applicable.
   • Azure AI Search resources if applicable.
   • Storage resources if applicable.
   • Other connected services referenced by the agent.
5. Validate networking configuration (if private networking is enabled) If private networking, private endpoints or network restrictions are configured, review:
   • Private endpoint configuration.
   • DNS resolution.
   • Firewall policies and allowlists.
   • Region alignment across dependent resources.
   • Proxy or TLS inspection policies that could impact connectivity.

Depending on the investigation outcome, potential mitigation actions may include:

1. Correcting dependency or integration configuration.
2. Updating permissions for the hosted-agent runtime identity.
3. Refreshing or recreating unhealthy or expired connections.
4. Temporarily bypassing a failing dependency to restore functionality.
5. Recreating affected hosted-agent configuration where appropriate.

The following references might be helpful , please check them out

• Hosted agents in Foundry Agent Service (preview) - Microsoft Foundry | Microsoft Learn
• Deploy a hosted agent - Microsoft Foundry | Microsoft Learn
• Manage hosted agents - Microsoft Foundry | Microsoft Learn
• Quickstart: Deploy your own code as a hosted agent - Microsoft Foundry | Microsoft Learn
• Known issues - Microsoft Foundry | Microsoft Learn

Please let us know if the response was helpful

Thank you