Azure AI Foundry server-side Memory Store: project managed identity gets 403 on ChatCompletions_Create (surfaced as wrapped 500) even with Cognitive Services OpenAI User

Matias Leoni (ZS Associates Inc) 0 Reputation points Microsoft External Staff
2026-08-06T15:10:14.3833333+00:00

Summary

A Foundry server-side Memory Store (orchestrator tier) in a BYO-hosting project cannot complete a write/search. The client receives a misleading wrapped 500 "The Azure OpenAI service encountered a general API error." The real backend failure, confirmed via AzureDiagnostics, is a 403 Forbidden on ChatCompletions_Create made by the project's system-assigned managed identity against the project's own gpt-4.1 deployment. The 403 is principal-specific and is not resolved by assigning Cognitive Services OpenAI User to the managed identity.

Environment

  • Foundry project: BYO-hosting (disableLocalAuth=true, AAD-only, no key auth)
  • Account (Azure OpenAI / Cognitive Services): westus3
  • Store: chat_model = gpt-4.1, embedding_model = text-embedding-ada-002
  • Inference API version seen in logs: 2024-12-01-preview
  • Auth at inference time: project system-assigned managed identity

What happens

The Memory Store extracts/embeds memories server-side, which requires a chat-model inference call. That call is made by the project's system-assigned managed identity and is rejected with 403.

Client-side error: {"message":"Provided Azure resource encountered an error.", "deployment":".../deployments/gpt-4.1", "details":{"type":"APIError","status_code":500, "description":"The Azure OpenAI service encountered a general API error."}}

Backend truth (AzureDiagnostics on the account → Log Analytics):

  • OperationName: ChatCompletions_Create
  • ResultSignature: 403
  • caller objectId = the project system-assigned managed identity
  • DurationMs: 5–7 (instant reject), responseLength ~192, ResultDescription empty
  • Reproduced continuously: 90/90 recent calls = 403, all from that MI.

What I have already ruled out

  • Network/firewall: 403 persists with the account networkAcls.defaultAction=Allow and bypass=AzureServices. Not the cause.
  • Propagation: role grants are hours old; 403 persists 60+ minutes after each change.
  • Deny assignments: none on the account.
  • ABAC on the grant: none (clean ServicePrincipal assignment, condition=null).
  • Missing data action: the MI has Foundry User, whose dataAction is Microsoft.CognitiveServices/* and whose notDataActions do not exclude chat completions.
  • Model/deployment health: my user identity (Foundry Owner, same wildcard dataAction) calls the same gpt-4.1 deployment successfully (HTTP 200). So the failure is specific to the managed-identity principal, not the model or endpoint.
  • Explicit inference role: an admin assigned Cognitive Services OpenAI User to the MI on the account scope; verified present via az role assignment list (MI now holds both Foundry User and Cognitive Services OpenAI User). Still 403 60+ minutes later.

The puzzle

Cognitive Services OpenAI User is documented as the least-privileged role that grants "Make inference API calls with Microsoft Entra ID," yet the managed identity holding it is still denied at ~5ms, while a user principal with an identical/broader wildcard dataAction succeeds against the same deployment. One notable role detail: all Foundry and Cognitive Services roles explicitly DENY the .../UserIdentityImpersonation/action data action.

Questions

  1. Does the Foundry server-side Memory Store perform the chat-model inference call using the project managed identity's own token, or via an on-behalf-of / UserIdentityImpersonation flow? If the latter, that data action is denied by every assignable role, which would explain an unfixable 403.
  2. Is there a known limitation with server-side Memory Stores in BYO-hosting projects where the project MI cannot perform inference regardless of assigned roles?
  3. What is the exact, supported role/permission the project managed identity needs to authorize ChatCompletions_Create for server-side memory extraction?

Repro

This is not specific to my SDK code — it also reproduces entirely within the Foundry portal:

  1. SDK path: a minimal script builds a sync AIProjectClient(allow_preview=True), writes one memory item to a scope, then searches. WRITE fails with the wrapped 500 above.
  2. Foundry portal path: in the same project I created an agent and attached the same memory to it. When I ask the agent to write something to that memory, it fails with: "Error: The server had an error processing your request." (See screenshot). Same underlying backend 403 on ChatCompletions_Create from the project managed identity.

Happy to share a correlation ID and the AzureDiagnostics rows privately.

User's image

Foundry Tools
Foundry Tools

Formerly known as Azure AI Services or Azure Cognitive Services is a unified collection of prebuilt AI capabilities within the Microsoft Foundry platform

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jerald Felix 18,680 Reputation points Volunteer Moderator
    2026-08-07T01:34:09.6366667+00:00

    Hello Matias,

    Greetings! Thanks for raising this question in the Q&A forum.

    The role Microsoft specifies as required for a project's managed identity to perform Memory Store operations, including the server-side chat-model inference call used for extraction, is Foundry User assigned to the managed identity at the resource (account) scope, not Cognitive Services OpenAI User. Since you already confirmed the managed identity holds Foundry User with its wildcard Microsoft.CognitiveServices/* data action, and adding Cognitive Services OpenAI User on top of that still produced the same instant 403, this rules out a simple missing-role misconfiguration on your side. The behavior you're describing, a principal-specific rejection at 5 to 7 milliseconds (too fast to be a real authorization evaluation against the resource's role assignments) that only affects the system-assigned managed identity and not a user principal with equivalent or broader permissions on the same deployment, is not consistent with normal RBAC propagation delay or misassigned roles. That pattern points toward the server-side Memory Store orchestrator resolving or presenting the caller identity differently than a standard direct inference call, which lines up with your own hypothesis in question 1 about an on-behalf-of or internal identity resolution path rather than the project MI's own token being used as-is against ChatCompletions_Create.

    Since Memory (preview) and the Memory Store API (preview) are both explicitly preview features, this looks like either a known limitation specific to BYO-hosting projects with disableLocalAuth=true, or a service-side defect in how the orchestrator tier authenticates for server-side extraction calls. Either way, this is not something resolvable purely through additional role assignments from the customer side, it needs review from the Foundry engineering team.

    Isolate whether this is specific to system-assigned identity. As a diagnostic step, try creating a user-assigned managed identity, assign it Foundry User at the same account scope, attach it to the project instead of the system-assigned identity, and reproduce the memory write. If a UAMI succeeds where the system-assigned MI fails, that strongly confirms a system-assigned identity resolution issue specific to BYO-hosting projects rather than a role or data-action gap.

    Confirm whether local auth affects the path. If you have a non-production project where you can temporarily set disableLocalAuth=false, test whether key-based auth against the same account allows the Memory Store write to succeed. This does not fix your AAD-only production project, but it helps confirm whether the 403 is tied specifically to the AAD-only, BYO-hosting combination.

    Preserve your diagnostic evidence exactly as you have it. Keep the correlation ID, the AzureDiagnostics rows showing the 403 on ChatCompletions_Create from the project MI's object ID, and the contrasting successful 200 from your user identity against the same deployment. This is exactly the evidence the product team will need and will significantly speed up triage since you have already isolated it to the principal type.

    Open a technical support ticket rather than relying on community answers for this one, since it requires engineering visibility into the Memory Store orchestrator's internal auth flow. In the Azure portal, go to Help + support, Create a support request, Issue type Technical, Service Azure AI Foundry (or Cognitive Services if Foundry isn't listed as a separate service in your support catalog), and in the problem description reference this exact symptom: server-side Memory Store write/search on a BYO-hosting project failing with a masked 500 client-side, backend 403 on ChatCompletions_Create from the project's system-assigned managed identity, reproducible even after assigning both Foundry User and Cognitive Services OpenAI User. Include your correlation ID, the managed identity's object ID, the account region (westus3), and the API version (2024-12-01-preview) so it routes to the right team quickly.

    Also file this on the Memory Store preview feedback channel. Preview features often move faster through direct engineering feedback than general support routing. Check the Azure AI Foundry feedback link at the bottom of the Memory documentation page, or the azure-ai-docs GitHub repository, and file an issue there in parallel with your support ticket, referencing the same correlation ID.

    If this answer helps you kindly accept the answer which will help others who have similar questions.

    Best Regards

    Jerald Felix.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.