Foundry agent blueprint & agent identity namse being too long and unable to add to the resources to allow list

Question

Foundry agent blueprint & agent identity namse being too long and unable to add to the resources to allow list

Rajender Akula 55 Microsoft Employee

Hi team,

We have a requirement to allowlist Foundryagent's SP to access some resources, and when they are trying to add it fails because of SP name being too long.

I cannot use a separate identity created and used for hosted agents, and do not have control over agents identity (blueprint & agent identity).

Is there a way to provide custom name for SP when the agents are getting created?
Help here much appreciated!

Rajender Akula 55 Reputation points Microsoft Employee

2026-05-06T20:55:23.7433333+00:00

Thank you,
On other note, I have few questions around identity being used for hosted agents.

I need to call ADO MCP to do the actions from my hosted agent and to make that call I have tried to use a custom UAMI which has access to ADO and tried to use in my code. It fails on the token acquisition when I deployed and tried to test.
Apparently, foundry agents not accepting it to use custom UAMI.

And I see we only have to use Foundry Agent identities (blueprint identity or agent identity). For this also, I noticed that this identity can change on every publish. So, using this also becomes allow listing the identities every time it changes.
Do you have any best practices to make it work for my scenario?

Thanks,
Rajender
Rajender Akula 55 Reputation points Microsoft Employee

2026-05-07T15:58:33.32+00:00

Thanks for the detailed response. I have a followup question, please let me know your response.

The statement says: “Foundry agent identities change on publish, as each agent publish operation can result in a new identity.”

Does this mean that even when we deploy the same agent as a new version (for example, v1 → v2), without creating a completely new agent, the agent identity still changes?

If so, this creates a significant challenge. Since the runtime identity changes, it becomes difficult to use a custom or stable identity for calling external services. Most external service integrations rely on Managed Identity (MI)–based allow‑listing, and identity rotation on every publish requires repeated reconfiguration.

Are there any upcoming features planned to support a stable or custom runtime identity for published agents? Or is this not something that will be supported in the near future?

Thanks,
Rajender
Karnam Venkata Rajeswari 5,340 Reputation points Microsoft External Staff Moderator

2026-05-07T19:56:25.27+00:00
Hello @Rajender Akula ,

Thank you for the detailed follow-up questions.

For Azure AI Foundry hosted agents, publishing creates a dedicated runtime identity associated with the published Agent Application. Current documentation confirms that publishing changes the identity boundary used for hosted execution and tool authentication, and permissions may need reassignment after publishing. However, public documentation does not explicitly guarantee whether the same identity will always persist across every publish or version update scenario (for example, v1 → v2).

Because of this, the recommended approach is to design integrations assuming that identity or permission reassignment may occasionally be required during publish or redeployment workflows. This is especially important for integrations relying on:

Managed Identity allow-listing

Service Principal Object IDs

Static RBAC mappings

External trust relationships

Hosted agent identities are platform-managed as part of the runtime security and lifecycle model. While this provides isolated execution boundaries and managed credential handling, identity lifecycle behavior is not currently customer-configurable. As a result, stable identity persistence across all deployment scenarios is not formally guaranteed.

At present, the following scenarios are supported:

Using Foundry-managed hosted agent identities

RBAC-based authorization where supported

PAT/OAuth authentication for external services

Externalized execution patterns using Azure services

The following are not currently supported:

Injecting a custom User-Assigned Managed Identity (UAMI) directly into hosted agents

Pinning a stable runtime identity across all publishes

Overriding runtime identity selection in deployment or code

Customizing generated service principal names

Please consider if the following workarounds help -

External execution layer - Use an external Azure service as the stable identity boundary: Hosted Agent → Azure Function / App Service / Container App → stable UAMI → downstream systems

PAT/OAuth authentication for Azure DevOps For Azure DevOps integrations:

Create a least-privilege PAT

Store securely in Azure Key Vault

Retrieve during runtime

Use for Azure DevOps REST or MCP operations

This avoids dependency on hosted agent identity lifecycle behavior.

RBAC instead of display-name allow-listing Where supported:

Assign RBAC roles directly to the runtime identity

Use:

Service Principal Object ID

or Application (Client) ID

Avoid display-name-based authorization

At this time, no public roadmap or committed timeline is available for stable reusable hosted agent identities or direct UAMI injection into hosted agents. For now, the recommended architecture is to treat hosted agent identities as platform-managed runtime identities and externalize long-term identity trust wherever stable identity governance is required.

Thank you
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Rajender Akula 55 Reputation points Microsoft Employee

2026-05-08T00:12:43.5833333+00:00

Thanks for the response, ADO team is using the clientID/objectId to allow list and I have also given a new SP using shorter foundry project name which gave shorter identity name,

So, seems like it's not a name length issue. For some reason ADO side when they are trying to allowlist my hosted agent SP. It is just saying they can't add the members at this time (they are seeing this issue always for my SP).

Do you know if there is a way that this hosted agent SP is properly created to be used by resources to be allow listed?
This is getting really difficult to use hosted agents when try to call the services.

Really appreciate your help here.
Karnam Venkata Rajeswari 5,340 Reputation points Microsoft External Staff Moderator

2026-05-14T18:19:03.45+00:00

Hello @Rajender Akula ,

Please allow us some time while we work on the case.

Thank you
Karnam Venkata Rajeswari 5,340 Reputation points Microsoft External Staff Moderator

2026-05-18T18:25:23.95+00:00

Hello @Rajender Akula ,

Thank you for your patience while we were working on this.Based on the complete analysis of this scenario, the behavior being experienced is not related to service principal name length or incorrect identifier usage. Instead, it aligns with how Azure AI Foundry hosted agent identities are created, classified, and consumed by downstream services.

Foundry hosted agents run using platform‑managed, non‑interactive workload identities. These identities are generated automatically as part of the hosted agent runtime and are tightly coupled to the agent’s execution lifecycle. While these service principals are valid and fully functional for Foundry‑managed execution and built‑in tooling, they are not designed to act as long‑lived, reusable enterprise identities for external allow‑listing or membership‑based authorization models.

Because of this design, some downstream systems - including ADO - apply additional validation when adding principals to allow‑lists or security groups. In such cases, Foundry‑generated hosted agent service principals may fail with generic errors such as “cannot add members at this time”, even when correct Object ID or Client ID values are used. This behavior is commonly observed when external systems attempt to consume platform‑managed workload identities that are not customer‑owned or explicitly created for service‑to‑service trust.

It is important to note that the hosted agent service principal is created correctly and securely. However, there is currently no supported mechanism to customize how this identity is generated, to convert it into a customer‑managed enterprise application, or to guarantee compatibility with all external allow‑listing systems.

In addition, hosted agent identities may change across publish or version operations, as publishing represents a new immutable runtime artifact. For this reason, relying on hosted agent identities as stable trust anchors for external services introduces operational challenges and repeated reconfiguration.

For scenarios requiring durable identity governance, stable allow‑listing or external service integration, externalizing identity ownership through a dedicated Azure service or PAT‑based authentication remains the supported and reliable architecture.

Thank you
Karnam Venkata Rajeswari 5,340 Reputation points Microsoft External Staff Moderator

2026-05-19T17:50:47.7+00:00

Hello @Rajender Akula ,

Hope the above response were helpful.

Since I’ve converted my earlier comment into an answer, could you please take a moment to mark it as Accepted with an upvote. This helps others in the community with the same question find the solution more easily.

Thank you!

Answer accepted by question author

Karnam Venkata Rajeswari 5,340 Microsoft External Staff Moderator

Hello @Rajender Akula ,

Thank you for the follow up question.

For hosted Azure AI Foundry agents, identity is fully platform‑managed. During execution, the agent runtime is allowed to acquire tokens only for Foundry‑managed identities (blueprint identity or agent identity).

Because of this:

A custom User‑Assigned Managed Identity (UAMI) cannot be injected or selected at runtime
Token acquisition for a custom UAMI fails by design
Identity configuration is not exposed in agent code or deployment settings

This explains the reason for token acquisition that works locally or in isolation, but fails once the agent is deployed and executed in the hosted Foundry runtime.

Foundry agent identities change on publish as each agent publish operation can result in:

A new agent runtime identity
Regeneration of the agent service principal
A different Object ID than the previous publish

This happens because publishing represents a new immutable runtime artifact, and identity rotation is part of the platform’s lifecycle and security model.

As a result:

Identity‑based allow‑listing tied to a specific Object ID can require updates after each publish
Relying on static identity names or IDs becomes operationally expensive

The supported best‑practice patterns for ADO MCP access would be

Using ADO Personal Access Token (PAT) stored securely For calling Azure DevOps MCP / REST APIs from a hosted agent, the most reliable pattern today is:
- Create a least‑privilege ADO PAT
- Store the PAT securely (for example, in Azure Key Vault)
- Retrieve the secret at runtime
- Use PAT‑based authentication for ADO calls
This works as there is
- No dependency on agent identity rotation
- No allow‑listing updates on every publish
- Fully supported by Azure DevOps APIs
RBAC‑only authorization wherever supported If the downstream service supports Azure RBAC instead of identity allow‑listing:
- Grant access at resource or project scope
- Avoid name‑ or ID‑based allow‑lists entirely
Please note that Azure DevOps currently has limited native Entra‑ID–based workload identity support for service‑to‑service scenarios, which is why PATs are often required.
External execution boundary as an advanced approach For scenarios requiring full identity control:
- Move ADO‑calling logic to an external service (Function App, App Service, Container App)
- Assign a stable UAMI to that service
- Call the external service from the Foundry agent
This allows:
- Predictable identity
- Stable allow‑listing
- Centralized identity and token management

Please note that the following are not supported as of today;

Using a custom UAMI directly inside hosted Foundry agents
Preventing identity regeneration on agent publish
Reusing the same agent identity across publishes
Selecting or overriding identity within agent code

Please let us know if the above response was helpful

Thank you

0 comments

1 additional answer

Your answer

Rajender Akula 55 Reputation points Microsoft Employee

2026-05-06T20:55:23.7433333+00:00

Thank you,
On other note, I have few questions around identity being used for hosted agents.

I need to call ADO MCP to do the actions from my hosted agent and to make that call I have tried to use a custom UAMI which has access to ADO and tried to use in my code. It fails on the token acquisition when I deployed and tried to test.
Apparently, foundry agents not accepting it to use custom UAMI.

And I see we only have to use Foundry Agent identities (blueprint identity or agent identity). For this also, I noticed that this identity can change on every publish. So, using this also becomes allow listing the identities every time it changes.
Do you have any best practices to make it work for my scenario?

Thanks,
Rajender
Rajender Akula 55 Reputation points Microsoft Employee

2026-05-07T15:58:33.32+00:00

Thanks for the detailed response. I have a followup question, please let me know your response.

The statement says: “Foundry agent identities change on publish, as each agent publish operation can result in a new identity.”

Does this mean that even when we deploy the same agent as a new version (for example, v1 → v2), without creating a completely new agent, the agent identity still changes?

If so, this creates a significant challenge. Since the runtime identity changes, it becomes difficult to use a custom or stable identity for calling external services. Most external service integrations rely on Managed Identity (MI)–based allow‑listing, and identity rotation on every publish requires repeated reconfiguration.

Are there any upcoming features planned to support a stable or custom runtime identity for published agents? Or is this not something that will be supported in the near future?

Thanks,
Rajender
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Rajender Akula 55 Reputation points Microsoft Employee

2026-05-08T00:12:43.5833333+00:00

Thanks for the response, ADO team is using the clientID/objectId to allow list and I have also given a new SP using shorter foundry project name which gave shorter identity name,

So, seems like it's not a name length issue. For some reason ADO side when they are trying to allowlist my hosted agent SP. It is just saying they can't add the members at this time (they are seeing this issue always for my SP).

Do you know if there is a way that this hosted agent SP is properly created to be used by resources to be allow listed?
This is getting really difficult to use hosted agents when try to call the services.

Really appreciate your help here.
Karnam Venkata Rajeswari 5,340 Reputation points Microsoft External Staff Moderator

2026-05-14T18:19:03.45+00:00

Hello @Rajender Akula ,

Please allow us some time while we work on the case.

Thank you
Karnam Venkata Rajeswari 5,340 Reputation points Microsoft External Staff Moderator

2026-05-19T17:50:47.7+00:00

Hello @Rajender Akula ,

Hope the above response were helpful.

Since I’ve converted my earlier comment into an answer, could you please take a moment to mark it as Accepted with an upvote. This helps others in the community with the same question find the solution more easily.

Thank you!

Answer 1

Hello @Rajender Akula

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

The allow‑list failure occurs because the configuration relies on the service principal display name generated by the Foundry agent blueprint.

This causes issues because:

Display names are system‑generated and can be long
They are not guaranteed to be unique or stable
They are not intended for authorization or allow‑listing decisions

In Azure identity and access control scenarios, display names are informational only. Authorization is designed to rely on immutable identifiers which are not names.

Azure AI Foundry automatically generates and manages service principals for agent blueprints and hosted agents. These identities are fully system‑controlled and follow internal naming conventions to ensure secure lifecycle management and governance.

At present:

Custom or shortened service principal names are not supported
The generated service principal name is read‑only and cannot be modified
Azure naming policies do not apply to Foundry‑managed service principals

For hosted Foundry agents, identity is tightly coupled with the platform‑managed execution model. As a result:

The agent runs under a Foundry‑managed identity
A manually created service principal cannot replace or override this identity
Identity selection is not configurable during or after blueprint deployment

This ensures consistent security boundaries and controlled identity lifecycle management for hosted workloads.

Please consider implementing the following approaches to update allow‑listing to use stable identity identifiers instead of display names.

Use one of the following:
- Service Principal Object ID (recommended)
- Application (Client) ID
These identifiers are:
- Fixed‑length GUIDs
- Unique within the tenant
- Fully supported for authorization and RBAC scenarios
Please follow the below steps to retrieve the identifiers:
1. Open Microsoft Entra ID > Enterprise applications
2. Select the relevant Foundry agent service principal
3. Copy either:
  - Object ID or
  - Application (Client) ID
4. Update the allow‑list using the GUID value
5. Allow a few minutes for permission propagation
Access model alignment using RBAC wherever applicable Where the target resource supports Azure role‑based access control, manual allow‑listing can often be avoided:
- Assign roles directly to the Foundry‑generated service principal
- Scope access at the resource or resource‑group level
- Use built‑in roles appropriate to the resource (for example, Storage Blob Data Reader or Key Vault Secrets User)
This approach aligns with least‑privilege principles and avoids dependency on identity display names.

Please note that:

Foundry‑generated service principal names cannot be modified
Hosted Foundry agents cannot switch to customer‑created identities
The Foundry‑managed identity must be used for execution and access

The following references might be helpful , please check them out

Please let us if you have any further queries and if the response was helpful

Thank you