[Bug] Published agents use project identity instead of distinct agent identity

[bmis]

Describe the Feedback

Published agents do not use their dedicated Entra ID agent identity for tool authentication. Instead, they continue to use the shared project agent identity, which contradicts the documented behavior.

According to the official documentation, when an agent is published, it should automatically receive a distinct agent identity in Microsoft Entra ID that is bound to the agent application resource. However, in practice, published agents continue to authenticate using the shared project's agent identity (agentIdentityId from the project level) instead of their own dedicated agent identity.

---

Repro Steps

Steps to reproduce the behavior:

1. Go to Microsoft Foundry Portal
2. Create and configure an agent with MCP tools that require authentication
3. Publish the agent
4. Navigate to Microsoft Entra admin center (https://entra.microsoft.com/#view/Microsoft_AAD_RegisteredApps/AllAgents.MenuView/~/allAgentIds) and verify the distinct agent identity was created for the published agent
5. In Foundry Portal, create an MCP connection with:
   • Authentication: Microsoft Entra
6. In Foundry Portal, create an MCP connection with:
   • Authentication: Microsoft Entra
   • Type: Agent Identity
7. Configure API Management with trace logging to capture authentication details from incoming requests
8. Invoke the agent using openai_client.responses.create() with agent_reference
9. The agent calls the MCP server (hosted on API Management) during execution
10. Monitor the incoming requests in API Management trace logs
11. Check the appid claim in the bearer token sent to the MCP server
12. Observe that the appid always matches the project's shared agent identity instead of the published agent's distinct identity

Expected Behavior:
Published agents should authenticate using their distinct agent identity

Actual Behavior:
Published agents continue to use the shared project agent identity (agentIdentityId from the Project resource), even after being published.

System Information

• Environment: Microsoft Foundry Production
• SDK: azure-ai-projects>=2.0.0b1
• Python: 3.x
• Authentication: DefaultAzureCredential

Labels

Please include relevant labels such as:

• bug
• Feature Area: Agent Identity, Authentication, Agent Publishing
• Issue: Runtime, Identity Management
• Priority: High (Security & Access Control)

Additional Context

Documentation Reference

From Agent identity concepts in Microsoft Foundry:

Tool authentication

Agents access remote resources and tools by using agent identities for authentication. The authentication mechanism differs based on the agent's publication status:

• Unpublished agents: Authenticate by using the shared project's agent identity.
• Published agents: Authenticate by using the unique agent identity that's associated with the agent application.

When you publish an agent, you must reassign RBAC permissions to the new agent identity for any resources that the agent needs to access. This reassignment ensures that the published agent maintains appropriate access while operating under its distinct identity.

Impact

This issue has several critical implications:

1. Security: Published agents may have broader permissions than intended since they inherit the shared project identity permissions
2. Audit Trail: Cannot properly track which specific agent performed actions
3. Least Privilege: Impossible to implement proper least-privilege access control per agent
4. Governance: Cannot apply Conditional Access policies to individual published agents
5. Lifecycle Management: RBAC changes intended for the published agent identity have no effect
   a custom MCP server hosted on Azure API Management. The MCP server returns mock data with authentication information for testing purposes. API Management trace logging was enabled to capture the authentication token details from incoming requests.

The API Management logs consistently show that the appid claim in the bearer token matches the project's shared agent identity ID, not the published agent's distinct agent identity ID. This confirms that the Foundry Agent Service runtime is not switching to the distinct identity after publication.

Test Setup:

• MCP server endpoint hosted on Azure API Management
• MCP tool configured with AgenticIdentityToken authentication
• Agent configured to use the MCP tool
• API Management trace logging enabled

Results from API Management trace:

• Expected appid: <distinct-agent-identity-id> (from Agent Application JSON view)
• Actual appid: <project-shared-identity-id> (from Project JSON view)

Testing Consistency:
This issue was verified using both invocation methods:

• Python SDK (openai_client.responses.create() with agent_reference)
• Foundry Portal (manual agent invocation through the UI)

Both methods produce identical results - the published agent consistently uses the project's shared agent identity instead of its distinct agent identity. This confirms the issue is in the Foundry Agent Service runtime, not specific to any client implementation.

Code Sample

# Before running the sample:
#    pip install --pre azure-ai-projects>=2.0.0b1
#    pip install azure-identity

import json
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

myEndpoint = "https://<project-endpoint>.services.ai.azure.com/api/projects/<project-name>"

project_client = AIProjectClient(
    endpoint=myEndpoint,
    credential=DefaultAzureCredential(),
)

# Get the published agent
agent = project_client.agents.get(agent_name="published-agent-name")
print(f"Retrieved agent: {agent.name}")

openai_client = project_client.get_openai_client()

# Create a conversation to maintain context
conversation = openai_client.conversations.create()
print(f"Created conversation: {conversation.id}")

# Send initial request that will trigger MCP tool
response = openai_client.responses.create(
    conversation=conversation.id,
    input="Request that triggers MCP tool",
    extra_body={"agent": {"name": agent.name, "type": "agent_reference"}},
)

# Process any MCP approval requests
input_list = []
for item in response.output:
    if item.type == "mcp_approval_request" and item.id:
        print("\nMCP approval requested:")
        print(f"  Server: {item.server_label}")
        print(f"  Tool: {getattr(item, 'name', '<unknown>')}")
        print(f"  Arguments: {json.dumps(getattr(item, 'arguments', None), indent=2, default=str)}")
        
        should_approve = input("Approve this MCP tool call? (y/N): ").strip().lower() == "y"
        
        input_list.append({
            "type": "mcp_approval_response",
            "approve": should_approve,
            "approval_request_id": item.id,
        })

# If there were approval requests, send approval response
if input_list:
    print("\nSending approval response...")
    response = openai_client.responses.create(
        input=input_list,
        previous_response_id=response.id,
        extra_body={"agent": {"name": agent.name, "type": "agent_reference"}},
    )

print(f"\nResponse output: {response.output_text}")

# At this point, check API Management trace logs
# The appid claim will show the project's shared identity, not the published agent's distinct identity

Request

Please investigate why published agents are not using their distinct agent identities for tool authentication and ensure the runtime behavior matches the documented specification.

[fosteramanda]

@bmis In the code sample above you are not invoking the published agent since you are using the project endpoint. To invoke a published agent you are invoking the application resource endpoint (see code sample below):

`# filepath: Direct OpenAI compatible approach
from openai import OpenAI
from azure.identity import DefaultAzureCredential, get_bearer_token_provider

edit base_url with your , , and

openai = OpenAI(
api_key=get_bearer_token_provider(DefaultAzureCredential(), "https://ai.azure.com/.default"),
base_url="https://.services.ai.azure.com/api/projects//applications//protocols/openai",
default_query = {"api-version": "2025-11-15-preview"}
)

response = openai.responses.create(
input="Write a haiku",
)
print(f"Response output: {response.output_text}")`

[bmis]

@fosteramanda Thank you for the response. I tested the application endpoint approach you suggested, but encountered some clarifications needed:

Testing Application Endpoint

I attempted to invoke the published agent using the application resource endpoint as shown in your example:

from openai import OpenAI
from azure.identity import DefaultAzureCredential, get_bearer_token_provider

application_endpoint = "https://<hub-name>.services.ai.azure.com/api/projects/<project-name>/applications/<agent-name>/protocols/openai"

openai_client = OpenAI(
    api_key=get_bearer_token_provider(
        DefaultAzureCredential(), 
        "https://ai.azure.com/.default"
    ),
    base_url=application_endpoint,
    default_query={"api-version": "2025-11-15-preview"}
)

response = openai_client.responses.create(
    input="Request that triggers MCP tool",
)

Result: HTTP 400 error:

openai.BadRequestError: Error code: 400 - {'error': {'message': 'Failed to fetch agentic identity access token with status code: BadRequest, response: "Failed to get agent application resources <agent-name>, exception: Service invocation failed!\\r\\nRequest: GET <region>.api.azureml.ms/agents/v2.0/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.MachineLearningServices/workspaces/<workspace-name>/applications/<agent-name>\\r\\nStatus Code: 404 NotFound\\r\\nReason Phrase: Not Found"', 'type': 'invalid_request_error', 'param': None, 'code': 'tool_user_error'}}

Key observation: The error shows the runtime is trying to fetch agentic identity access token but fails because the application resource doesn't exist (404). This suggests the runtime knows it should use distinct identity, but can't access it without the application resource.

Clarification Needed

It appears there's a distinction between:

1. Published Agent (in Foundry Portal) - has distinct agent identity in Entra ID
2. Application Resource (Microsoft.MachineLearningServices/.../applications) - separate Azure resource with its own endpoint

My understanding:
When you publish an agent in Foundry Portal, it should create an application agent resource with the /applications/<agent-name> endpoint. Bot Service then uses this endpoint to route messages to the agent. However, in my case:

My scenario:

• ✅ Agent published in Foundry Portal
• ✅ Distinct agent identity visible in Entra admin center
• ✅ Bot Service created with Messaging endpoint: .../applications/<agent-name>/protocols/activityprotocol
• ❌ Application resource returns 404 when accessed directly via /applications/<agent-name> endpoint

This suggests the application resource wasn't created during publishing, or there's an additional step required.

Questions:

1. When publishing an agent in Foundry Portal, should it automatically create the application resource with /applications/<agent-name> endpoint?
2. If not automatic, what are the steps to create the application resource for a published agent?
3. Is Bot Service creation separate from application resource creation, or are they related?

The Core Issue

Even without the application resource endpoint, the published agent has a distinct identity in Entra ID and should use it according to the documentation.

Confusion about invocation methods

The Microsoft Foundry Portal provides a code sample for published agents using AIProjectClient:

# Sample from Foundry Portal for published agent
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

project_client = AIProjectClient(
    endpoint="https://<hub-name>.services.ai.azure.com/api/projects/<project-name>",
    credential=DefaultAzureCredential(),
)

agent = project_client.agents.get(agent_name="<agent-name>")
openai_client = project_client.get_openai_client()

response = openai_client.responses.create(
    input=[{"role": "user", "content": "Tell me what you can help with."}],
    extra_body={"agent": {"name": agent.name, "type": "agent_reference"}},
)

However, your suggestion uses the openai.OpenAI client with application endpoint:

# Suggested approach using OpenAI client
from openai import OpenAI
from azure.identity import get_bearer_token_provider

openai = OpenAI(
    api_key=get_bearer_token_provider(DefaultAzureCredential(), "https://ai.azure.com/.default"),
    base_url="https://<hub-name>.services.ai.azure.com/api/projects/<project-name>/applications/<agent-name>/protocols/openai",
    default_query={"api-version": "2025-11-15-preview"}
)

Note: The same behavior occurs when invoking the agent through the Microsoft Foundry Portal UI (manual invocation) - the appid in trace logs still shows the project shared identity instead of the distinct agent identity.

According to the documentation:

"Published agents: Authenticate by using the unique agent identity that's associated with the agent application."

The published agent has a distinct identity in Entra ID, but the runtime is not using it. This appears to be a bug in the Foundry Agent Service runtime.

Thank you for clarification!

[bmis]

Update: Root Cause Identified

After further testing, I've identified a clear pattern that explains both this issue and #71:

Pattern Discovery

Testing multiple published agents revealed:

✅ Application resource EXISTS (publish works):

• Agent with no tools → /applications/<agent-name> endpoint works
• Agent with Web Search tool → /applications/<agent-name> endpoint works

❌ Application resource MISSING (404 error):

• Agent with MCP Server tools → /applications/<agent-name> returns 404
• Consistent across multiple agents with MCP tools

Testing Evidence

# Agent without tools - SUCCESS
curl -X POST "https://.../applications/clearagent/protocols/openai/responses?api-version=2025-11-15-preview" \
  -H "Authorization: Bearer $token" -d '{"input":"Say hello"}'
✅ Response: "Hello! How can I assist you today?"

# Agent with MCP tools - FAILS
curl -X POST "https://.../applications/polisyagent/protocols/openai/responses?api-version=2025-11-15-preview" \
  -H "Authorization: Bearer $token" -d '{"input":"Say hello"}'
❌ Error: 404 NotFound - "Failed to fetch agentic identity access token with status code: BadRequest, response: \"Failed to get agent application resources polisyagent, exception: Service invocation failed!\\r\\nRequest: GET eastus2.api.azureml.ms/agents/v2.0/subscriptions/xxxxx/resourceGroups/xxxxx/providers/Microsoft.MachineLearningServices/workspaces/xxxxx@xxxx@AML/applications/polisyagent\\r\\nStatus Code: 404 NotFound\\r\\nReason Phrase: Not Found\"","

Additional Finding: Copilot Studio Testing

Testing the same agent (polisyagent with MCP tools) via Copilot Studio:

• ✅ Connection works - Copilot Studio successfully connects to the published agent
• ✅ Simple questions work - "hi" returns normal response
• ❌ MCP tool invocation fails - requires MCP tool returns:

  We apologize, but something went wrong. Please try again. 
  ConversationId=19:..., ActivityId=1770635515019
  

Thank you!

[fosteramanda]

@bmis From what you described, you published this agent to M365/Teams in the Foundry UI. Once published to M365/Teams the responses api endpoint will not work anymore. Currently, only one application authorization policy is supported either Default (standard Azure RBAC) or Channels (for agents published to M365/Teams). You should be able to check with authorization policy your agent application supports by calling GET application.

@api_version=2025-10-01-preview
#------------------------------------------------------------------

Get Agent Applications

#------------------------------------------------------------------
GET https://management.azure.com/subscriptions/{{subscription_id}}/resourceGroups/{{resource_group}}/providers/Microsoft.CognitiveServices/accounts/{{account_name}}/projects/{{project_name}}/applications/{{application_name}}?api-version={{api_version}}
Authorization: Bearer {{token}}
Content-Type: application/json

[bmis]

Update: Tested with unpublished agent - same issue

I created a fresh agent with MCP tools that was NOT published to Teams or Copilot Studio to test if the authorization policy affects the identity behavior.

Configuration:

• Agent with MCP Server tools
• Published to Foundry (standard publish)
• NOT published to Teams/M365 Copilot
• Authorization policy: Default (confirmed via GET /applications API)

Testing Commands:

1. Test responses API endpoint:

TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)
curl -X POST "https://<foundry-endpoint>/api/projects/<project-name>/applications/<agent-name>/protocols/openai/responses?api-version=2025-11-15-preview" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"input":"Hi"}'

2. Check agent configuration:

TOKEN=$(az account get-access-token --resource https://management.azure.com --query accessToken -o tsv)
curl -X GET "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<foundry-account>/projects/<project-name>/applications/<agent-name>?api-version=2025-10-01-preview" \
  -H "Authorization: Bearer $TOKEN"

Result:
The responses API returns 404 NotFound with detailed error:

{
  "error": {
    "message": "Failed to fetch agentic identity access token with status code: BadRequest, response: \"Failed to get agent application resources <agent-name>, exception: Service invocation failed!\\r\\nRequest: GET <region>.api.azureml.ms/agents/v2.0/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.MachineLearningServices/workspaces/<workspace>@<project>@AML/applications/<agent-name>\\r\\nStatus Code: 404 NotFound\\r\\nReason Phrase: Not Found\"",
    "type": "invalid_request_error",
    "param": null,
    "code": "tool_user_error"
  }
}

Agent Configuration (via GET /applications API):

{
  "authorizationPolicy": {
    "authorizationScheme": "Default"
  },
  "agentIdentityBlueprint": {
    "kind": "AgentBlueprint",
    "type": "System",
    "clientId": "<agent-blueprint-client-id>",
    "principalId": "<agent-blueprint-principal-id>",
    "tenantId": "<tenant-id>",
    "subject": null,
    "provisioningState": "Creating"
  },
  "defaultInstanceIdentity": {
    "kind": "AgentInstance",
    "type": "System",
    "clientId": "<agent-instance-client-id>",
    "principalId": "<agent-instance-principal-id>",
    "tenantId": "<tenant-id>",
    "subject": null,
    "provisioningState": "Creating"
  }
}

Key Observations:

1. Authorization Policy is "Default" (not "Channels"), confirming this is not Teams/Copilot Studio related
2. Both identities show "provisioningState": "Creating" instead of "Succeeded", however the agent identity is visible and created in Entra ID