Microsoft Foundry Responses API succeeds without required OpenAI DataActions

Summary

A Microsoft Foundry resource accepts an Azure OpenAI v1 Responses API

request from a Microsoft Entra ID user who does not appear to have any

OpenAI or Cognitive Services DataActions.

The request succeeds with HTTP 200 and returns a valid model response.

I would like to confirm whether this is expected authorization behavior,

a documented exception for subscription Owners, or a potential

authorization issue.

This may require investigation by the Microsoft Foundry Models /

Azure OpenAI authorization team.

Resource configuration

• Resource type: Microsoft.CognitiveServices/accounts
• Resource kind: AIServices
• Local authentication: disabled
• properties.disableLocalAuth = true
• API endpoint: POST https://<resource-name>.openai.azure.com/openai/v1/responses
• Authentication method: Microsoft Entra ID bearer token
• Token audience: https://ai.azure.com
• Token identity type: user
• Token scope: user_impersonation

The request body specifies an existing model deployment and contains a

simple text input.

Actual result

The following request succeeds:

• Method: POST
• Path: /openai/v1/responses
• Authentication: Microsoft Entra ID bearer token
• Result: HTTP 200
• The deployed model returns a valid response

Local/API-key authentication is disabled, so the request is not using an

API key.

Effective Azure RBAC permissions

The requesting user currently has the following Azure RBAC assignments:

1. Owner

• Scope: subscription
• Assignment method: Microsoft Entra security group
• Actions: *
• DataActions: none

2. Storage Blob Data Contributor

• Scope: subscription
• DataActions are limited to Azure Storage blob operations

The user does not have the following roles on the target Microsoft

Foundry resource:

• Cognitive Services OpenAI User
• Cognitive Services User
• Foundry User
• Cognitive Services OpenAI Contributor
• Any known custom role containing OpenAI or Cognitive Services DataActions

A Foundry User assignment exists on a different Microsoft Foundry

resource in the same resource group, but not on the resource whose

Responses API endpoint is being called.

The two resources are separate sibling resources, so that assignment

should not be inherited by the target resource.

Effective permission verification

I queried the following API for the target resource:

Microsoft.Authorization/permissions

The returned effective permissions included:

• Subscription Owner control-plane permission: Actions: *
• Azure Storage blob DataActions

However, no DataActions matching the following were returned:

• Microsoft.CognitiveServices/*
• Microsoft.CognitiveServices/accounts/OpenAI/*
• Microsoft.CognitiveServices/accounts/OpenAI/responses/*
• Microsoft.CognitiveServices/accounts/OpenAI/responses/write

The effective-permissions result did not contain any OpenAI,

Cognitive Services, or Microsoft Foundry data-plane permission.

Token verification

The bearer token used for the successful API request was decoded

locally.

The following was confirmed:

• The token oid matches the signed-in Azure CLI user's Object ID
• The token audience is https://ai.azure.com
• The identity type is user
• The token was newly issued
• The request is not being made by a service principal or another user

Therefore, the successful request is not explained by a different

Azure CLI identity or an old token belonging to another principal.

Questions

1. Is a subscription-level Owner intentionally authorized to invoke the Microsoft Foundry Azure OpenAI v1 Responses API through its control-plane permission Actions: *, even though the role has no OpenAI DataActions?
2. Is the expected DataAction for this request the following? Microsoft.CognitiveServices/accounts/OpenAI/responses/write
3. Does the AIServices resource kind use an authorization path that differs from the Azure RBAC DataActions returned by Microsoft.Authorization/permissions?
4. Is this expected and documented behavior, or could it be an authorization issue in the Microsoft Foundry Responses API?

Expected result

A principal that does not have the required OpenAI data-plane

permission should receive HTTP 403 when invoking:

POST /openai/v1/responses

The expected access-control design is:

• Assign Cognitive Services OpenAI User to a Microsoft Entra security group
• Scope the assignment to the target Microsoft Foundry resource
• Add or remove users from that security group to control access to the deployed coding model

However, the current subscription Owner can invoke the model without

that role.

Because this issue may require examination of service-side

authorization logs, please escalate it to a private Microsoft Azure

support case or the Microsoft Foundry Models / Azure OpenAI

authorization team if it cannot be resolved through Microsoft Q&A.