Skip to main content
When working with Hosted agents in Microsoft Foundry, it’s important to understand the various permissions involved. There are several classes of permissions involved in Hosted agent development, spanning the Azure Resource Manager control plane and the Foundry data plane:
  • Permissions granted to users or principals working with Foundry resources
  • Permissions granted to the Foundry project
  • Permissions granted to the agent
This article is a companion to Role-based access control for Microsoft Foundry, which introduces role-based access control (RBAC) concepts and the built-in roles available in Microsoft Foundry. You should familiarize yourself with that article before proceeding. This article covers the operations involved in Hosted agent development and deployment, the permissions required to perform those operations, and which built-in roles cover those permissions. For end-to-end deployment and lifecycle tasks, see Deploy a Hosted agent and Manage Hosted agent lifecycle. For identity-specific behavior, see Agent identity.
Always adhere to the principle of least privilege when assigning permissions. Only grant the permissions necessary for users and agents to perform their tasks, and regularly review and update permissions as needed.

Roles in this article

Azure AI Foundry permissions span two planes: the Azure Resource Manager (ARM) control plane and the Foundry data plane. Owner and Contributor roles have broad ARM control plane permissions but don’t include data plane permissions. Data plane operations—such as creating agents or interacting with them—require specific Azure AI Foundry roles like Foundry User, Foundry Project Manager, or Foundry Owner.
The Foundry RBAC roles were recently renamed. Foundry User, Foundry Owner, Foundry Account Owner, and Foundry Project Manager were previously named Azure AI User, Azure AI Owner, Azure AI Account Owner, and Azure AI Project Manager. You might still see the previous names in some places while the rename rolls out. The role IDs and core permissions are unchanged by the rename.
This article references the following built-in roles. For information about custom role definitions, see Azure custom roles.
RolePurpose in Hosted agent deployment
OwnerFull permissions to create and manage Azure resources
ContributorCreate and manage Azure resources
Role Based Access Control AdministratorCreate role assignments on Azure resources
Foundry UserCreate agents, perform model inference, and interact with agents
Foundry Project ManagerManage projects, create agents, perform model inference, interact with agents, and create role assignments
Foundry Account OwnerCreate deployments, manage projects, and handle account-level resources. Create role assignments for control plane operations only. Can’t perform data plane operations such as creating or interacting with agents.
Foundry OwnerFull control plane and data plane permissions over account resources, but can’t create role assignments
Container Registry Repository ReaderPull container images from the registry
Container Registry Repository WriterPush container images to the registry
AcrPullPull container images from the registry
AcrPushPush container images to the registry
Log Analytics Data ReaderRead telemetry data for evaluations
Cognitive Services OpenAI UserAccess account-level OpenAI endpoints directly
Cognitive Services UserAccess account-level capabilities (Speech, Vision, Language) directly
Although it might sound like an appropriate role for a developer working with Hosted agents, the Azure AI Developer built-in role is insufficient for Hosted agent scenarios. This role is scoped to Azure Machine Learning and Foundry hubs, not to the Foundry project resources used by Hosted agents, and it doesn’t include the resource management permissions required for Hosted agent deployment.

Quick diagnosis by symptom

Use these links to jump directly to sections that address common permission issues:

Hosted agent solution architecture

A completed Hosted agent setup involves multiple Azure resources, identity assignments, and connections working together. The following diagram shows the key components and their relationships:
Foundry Account
├── Model Deployment
└── Foundry Project (has managed identity)
    ├── Hosted Agent
    │   └── Agent Version → references container image
    ├── Connection to Azure Container Registry
    └── Connection to Application Insights

Separate Azure Resources:
├── Azure Container Registry → contains container image
├── Application Insights → logs to Log Analytics Workspace
└── Log Analytics Workspace

Role assignments:
• Foundry Project → Foundry User role on Foundry Account
• Foundry Project → Container Registry Repository Reader role on Azure Container Registry
• Foundry Project → Log Analytics Data Reader role on Log Analytics Workspace

Optional (Teams / M365 Copilot publishing):
└── Azure Bot Service → connected to agent application (Channels auth mode)
The diagram above shows how resources are organized hierarchically and which role assignments enable communication between them. The following sections provide detailed configuration requirements for each component.

Required Azure resources

Each Hosted agent deployment requires these Azure resources to be properly configured:
  • A Foundry account
    • A role assignment allows the project managed identity to access the account for model access. Foundry User is the recommended built-in role.
  • A model deployment (in the account)
  • A Foundry project (in the account)
    • The project has a managed identity. The project also gets an agent blueprint and agent identity when its first agent is created.
    • Role assignments allow client users or principals to interact with agents in the project at runtime. Foundry User is the recommended built-in role.
    • Some advanced scenarios might require explicit role assignments for the agent identity on the project. For more information, see Explicit project-level access.
  • A Hosted agent (in the project)
    • The agent automatically gets an agent blueprint and agent identity.
  • An agent version (in the Hosted agent object)
  • An Azure Container Registry (ACR)
  • An Application Insights component
  • A Log Analytics workspace (linked to the Application Insights component)
    • A role assignment allows the project’s managed identity to read telemetry for evaluations. Log Analytics Data Reader is the recommended built-in role.
  • Several connection resources (in the project):
    • A connection is created for the Azure Container Registry, which the project uses for image pulling.
    • A connection is created for Application Insights, which the project uses to emit telemetry for its agents. This connection doesn’t use identity by default.
Some set of users or principals needs permission to create and manage these resources. This article assumes a configuration where the Azure resources are all within the same resource group, and shows granting write access over that resource group. This resource group approach is a common configuration for many teams, but your specific setup may vary. If you have a different resource organization strategy, you might need to split up permissions across the resource groups you use. This list doesn’t include networking resources. However, the user or service principal that provisions the Azure resources may also need permission to create and manage virtual networks, subnets, and private endpoints to secure the resources.

Agent applications

If you use agent applications, the list also includes:
  • An agent application (in the project)
    • The agent application automatically gets an agent blueprint and agent identity. If you configure any explicit role assignments for the Hosted agent’s agent identity (such as for advanced scenarios), repeat those assignments for the agent application’s agent identity.
  • An agent deployment (in the agent application)

Azure resource setup

Foundry account setup

Creating a Foundry account requires the Microsoft.CognitiveServices/accounts/write permission at the scope of the resource group.
Built-in roleScopeCan assignee create a Foundry account?
OwnerResource group✔ Yes
ContributorResource group✔ Yes
Foundry UserResource group✗ No
Foundry Project ManagerResource group✗ No
Foundry Account OwnerResource group✔ Yes
Foundry OwnerResource group✔ Yes
The project’s managed identity needs access to the Foundry account to perform model inference through the project endpoint. The project’s access is covered by the Foundry User role at the scope of the Foundry account. This role assignment might be created automatically when the project is created, depending on the permissions of the user or service principal creating the project. More role assignments might be needed if your agent code accesses the account-level OpenAI endpoint directly or other account-level capabilities not proxied by the project endpoint. For more information, see Account-level access.

Model deployment

Creating a model deployment requires the Microsoft.CognitiveServices/accounts/deployments/write permission at the scope of the Foundry account.
Built-in roleScopeCan assignee deploy a model to a Foundry account?
OwnerFoundry account✔ Yes
ContributorFoundry account✔ Yes
Foundry UserFoundry account✗ No
Foundry Project ManagerFoundry account✗ No
Foundry Account OwnerFoundry account✔ Yes
Foundry OwnerFoundry account✔ Yes

Project setup

Creating a Foundry project requires the Microsoft.CognitiveServices/accounts/projects/write permission at the scope of the Foundry account.
Built-in roleScopeCan assignee create a Foundry project?
OwnerFoundry account✔ Yes
ContributorFoundry account✔ Yes
Foundry UserFoundry account✗ No
Foundry Project ManagerFoundry account✔ Yes
Foundry Account OwnerFoundry account✔ Yes
Foundry OwnerFoundry account✔ Yes
If the creator of the project has the ability to assign the Foundry User role at the scope of the account, the system automatically creates two role assignments:
  • The project creator is granted the Foundry User role at the scope of the Foundry account.
  • The project’s managed identity is granted the Foundry User role at the scope of the Foundry account.

Azure Container Registry setup

Creating an Azure Container Registry requires the Microsoft.ContainerRegistry/registries/write permission at the scope of the resource group.
For Hosted agents, the container registry must currently be reachable over its public endpoint. Placing ACR behind a private network (private endpoint with public network access disabled) isn’t currently supported. For the full list of network constraints, see Limitations.
Built-in roleScopeCan assignee create a container registry?
OwnerResource group✔ Yes
ContributorResource group✔ Yes
Foundry UserResource group✗ No
Foundry Project ManagerResource group✗ No
Foundry Account OwnerResource group✗ No
Foundry OwnerResource group✗ No
The project’s managed identity needs permissions to pull the image from ACR. There are two built-in roles suitable to this task, which should be assigned at the ACR registry resource scope: Creating that role assignment requires the Microsoft.Authorization/roleAssignments/write permission at the scope of the ACR registry. For details on assigning roles in Azure, see Create Azure role assignments.
Built-in roleScopeCan assignee create a role assignment?
OwnerACR registry✔ Yes
ContributorACR registry✗ No
Foundry UserACR registry✗ No
Foundry Project ManagerACR registry✗ No1
Foundry Account OwnerACR registry✗ No1
Foundry OwnerACR registry✗ No
Role Based Access Control AdministratorACR registry✔ Yes
1 These roles have roleAssignments/write but are constrained to only assign the Foundry User role, which doesn’t cover ACR permissions. The user or service principal that pushes images to the registry also needs a role assignment. For more information, see the Hosted agent deployment section.

Application Insights and Log Analytics setup

Creating an Application Insights resource requires the Microsoft.Insights/components/write permission at the scope of the resource group.
Built-in roleScopeCan assignee create an Application Insights resource?
OwnerResource group✔ Yes
ContributorResource group✔ Yes
Foundry UserResource group✗ No
Foundry Project ManagerResource group✗ No
Foundry Account OwnerResource group✗ No
Foundry OwnerResource group✗ No
Creating a Log Analytics workspace requires the Microsoft.OperationalInsights/workspaces/write permission at the scope of the resource group.
Built-in roleScopeCan assignee create a Log Analytics workspace?
OwnerResource group✔ Yes
ContributorResource group✔ Yes
Foundry UserResource group✗ No
Foundry Project ManagerResource group✗ No
Foundry Account OwnerResource group✗ No
Foundry OwnerResource group✗ No
If you plan to use the evaluations feature, the project’s managed identity needs permissions to read from the Log Analytics workspace. You can enable this access by granting the Log Analytics Data Reader role to the project’s managed identity at the scope of the Log Analytics workspace. Creating that role assignment requires the Microsoft.Authorization/roleAssignments/write permission at the scope of the Log Analytics workspace. For details on assigning roles in Azure, see Create Azure role assignments.
Built-in roleScopeCan assignee create a role assignment?
OwnerLog Analytics workspace✔ Yes
ContributorLog Analytics workspace✗ No
Foundry UserLog Analytics workspace✗ No
Foundry Project ManagerLog Analytics workspace✗ No1
Foundry Account OwnerLog Analytics workspace✗ No1
Foundry OwnerLog Analytics workspace✗ No
Role Based Access Control AdministratorLog Analytics workspace✔ Yes
1 These roles have roleAssignments/write but are constrained to only assign the Foundry User role, which doesn’t cover Log Analytics permissions.

Connections setup

Creating a connection requires the Microsoft.CognitiveServices/accounts/projects/connections/write permission at the scope of the Foundry project.
Built-in roleScopeCan assignee create a connection?
OwnerFoundry project✔ Yes
ContributorFoundry project✔ Yes
Foundry UserFoundry project✗ No
Foundry Project ManagerFoundry project✔ Yes
Foundry Account OwnerFoundry project✔ Yes
Foundry OwnerFoundry project✔ Yes
The user or service principal creating the connections also needs the connection information for the Application Insights component and the container registry. The connection details can be provided by the user or service principal that created those resources, or by having read access over those resources.
Hosted agents often use tools and connections that target more Azure resources. Those resources might require extra role assignments for the calling identity or the agent identity at the target resource scope. For example, tools that access Storage, Azure AI Search, Key Vault, or databases typically require their own data plane permissions in addition to core setup permissions documented in this article.

Agent applications

If you use agent applications, you need to create an agent application in the Foundry project. Creating an agent application requires the Microsoft.CognitiveServices/accounts/projects/applications/write permission at the scope of the Foundry project.
Built-in roleScopeCan assignee create an agent application?
OwnerFoundry project✔ Yes
ContributorFoundry project✔ Yes
Foundry UserFoundry project✗ No
Foundry Project ManagerFoundry project✔ Yes
Foundry Account OwnerFoundry project✔ Yes
Foundry OwnerFoundry project✔ Yes
agentDeployment objects are also ARM resources, but they’re created as part of the Hosted agent deployment process. For more information, see Hosted agent deployment.

Agent creation

Agents are created through a data plane operation. Creating an agent requires the Microsoft.CognitiveServices/accounts/AIServices/agents/write permission at the scope of the Foundry project.
Built-in roleScopeCan assignee create an agent?
OwnerFoundry project✗ No
ContributorFoundry project✗ No
Foundry UserFoundry project✔ Yes
Foundry Project ManagerFoundry project✔ Yes
Foundry Account OwnerFoundry project✗ No
Foundry OwnerFoundry project✔ Yes
The agent has implicit access to core capabilities within its own project, such as model inferencing. No explicit role assignment is needed for the standard case. For advanced scenarios that require explicit access, see Agent access beyond defaults.

Hosted agent deployment

Hosted agent deployment operations are control plane operations. For step-by-step deployment guidance, see Deploy a Hosted agent.

Push an image to the registry

The user or service principal deploying the agent needs permission to push the image to ACR. There are two built-in roles suitable to this task, which should be assigned at the ACR registry resource scope:

Create a new agent version

Creating an agent requires the Microsoft.CognitiveServices/accounts/AIServices/agents/write permission at the scope of the Foundry project.
Built-in roleScopeCan assignee create an agent version?
OwnerFoundry project✗ No
ContributorFoundry project✗ No
Foundry UserFoundry project✔ Yes
Foundry Project ManagerFoundry project✔ Yes
Foundry Account OwnerFoundry project✗ No
Foundry OwnerFoundry project✔ Yes
If you use agent applications, you also need to create an agentDeployment object that references a newly deployed agent version. This is a management plane operation. Creating an agentDeployment object requires the Microsoft.CognitiveServices/accounts/projects/applications/agentDeployments/write permission at the scope of the agent application.
Built-in roleScopeCan assignee create an agentDeployment object?
OwnerFoundry account✔ Yes
ContributorFoundry account✔ Yes
Foundry UserFoundry account✗ No
Foundry Project ManagerFoundry account✔ Yes
Foundry Account OwnerFoundry account✔ Yes
Foundry OwnerFoundry account✔ Yes

Update the agent to use the new version

If you use the agent endpoint, version selection is configured on the agent object. Updating the agent to use the new version requires the Microsoft.CognitiveServices/accounts/AIServices/agents/write permission at the scope of the Foundry project.
Built-in roleScopeCan assignee update the agent version?
OwnerFoundry project✗ No
ContributorFoundry project✗ No
Foundry UserFoundry project✔ Yes
Foundry Project ManagerFoundry project✔ Yes
Foundry Account OwnerFoundry project✗ No
Foundry OwnerFoundry project✔ Yes
If instead you use the agent application, version selection is configured on the agent application object. Updating the agent application to use the new agentDeployment object requires the Microsoft.CognitiveServices/accounts/projects/applications/write permission at the scope of the agent application.
Built-in roleScopeCan assignee update the agent application?
OwnerFoundry account✔ Yes
ContributorFoundry account✔ Yes
Foundry UserFoundry account✗ No
Foundry Project ManagerFoundry account✔ Yes
Foundry Account OwnerFoundry account✔ Yes
Foundry OwnerFoundry account✔ Yes

Azure Bot Service setup

Publishing your agent to Microsoft Teams or Microsoft 365 Copilot is optional. When you do, the publishing flow performs control plane operations to create an Azure Bot Service resource and configure its channels, then updates either the agent or the agent application to allow requests from Bot Service.

Creating the bot service

Creating the bot service resource requires the Microsoft.BotService/botServices/write permission at the scope of the resource group.
Built-in roleScopeCan assignee create a bot service?
OwnerResource group✔ Yes
ContributorResource group✔ Yes
Foundry UserResource group✗ No
Foundry Project ManagerResource group✗ No
Foundry Account OwnerResource group✗ No
Foundry OwnerResource group✗ No
Azure Bot Service is a separate resource type from Foundry. Azure AI–scoped built-in roles don’t include Microsoft.BotService/* permissions.

Configuring channels

Configuring the Teams and Microsoft 365 Extensions channels on the bot service requires the Microsoft.BotService/botServices/channels/write permission at the scope of the bot service resource.
Built-in roleScopeCan assignee configure channels?
OwnerBot service✔ Yes
ContributorBot service✔ Yes
Foundry UserBot service✗ No
Foundry Project ManagerBot service✗ No
Foundry Account OwnerBot service✗ No
Foundry OwnerBot service✗ No

Updating the agent or agent application

The publishing flow sets Channels (Azure Bot Service) as the authentication mode on the agent or agent application. The object that is updated depends on your scenario:
  • Agent application scenario: The agent application object is updated. This is a control plane write operation. The same role requirements apply as documented in Agent applications.
  • Agent endpoint scenario: The agent object is updated. This is a data plane write operation. The same role requirements apply as documented in Create a new agent version.
For step-by-step guidance on publishing to Teams or M365 Copilot, see Publish agents to Microsoft 365 Copilot and Microsoft Teams.

Agent interaction

Interacting with the agent requires the calling user or service principal to have a data plane permission. To interact with an agent application, they need Microsoft.CognitiveServices/accounts/AIServices/applications/invoke/action at the scope of the agent application.
Built-in roleScopeCan assignee interact with the agent?
OwnerFoundry project✗ No
ContributorFoundry project✗ No
Foundry UserFoundry project✔ Yes
Foundry Project ManagerFoundry project✔ Yes
Foundry Account OwnerFoundry project✗ No
Foundry OwnerFoundry project✔ Yes

Agent observability

Viewing telemetry data

Accessing agent telemetry data requires read permissions on the Application Insights resource. This includes viewing traces, logs, and metrics through the Azure portal, Foundry portal, APIs, and monitoring tools. Assign Monitoring Reader at the Application Insights resource scope. The */read permissions in this role access the underlying Log Analytics workspace data without requiring a separate workspace-scoped assignment. If you need to work against the Log Analytics workspace directly, also assign Log Analytics Reader at the workspace scope.
Built-in roleScopeCan assignee access agent telemetry data?
OwnerApplication Insights✔ Yes
ContributorApplication Insights✔ Yes
Foundry UserApplication Insights✗ No (sees metrics, but not traces)
Foundry Project ManagerApplication Insights✗ No
Foundry Account OwnerApplication Insights✗ No (sees metrics, but not traces)
Foundry OwnerApplication Insights✗ No
Monitoring ReaderApplication Insights✔ Yes
Log Analytics ReaderLog Analytics Workspace✔ Yes (from workspace directly)

Cost display in billing currency

Viewing costs in billing currency in the Foundry portal requires the Microsoft.Billing/billingProperty/read permission. This permission requires a subscription or billing-account-scoped assignment. Resource group scope doesn’t cover this permission. This permission is for portal display convenience and isn’t required for Hosted agent functionality. You can safely omit this permission for most users.
Built-in roleScopeCan assignee view costs in billing currency?
OwnerSubscription✔ Yes
ContributorSubscription✔ Yes
Cost Management ReaderSubscription✔ Yes
Foundry UserSubscription✗ No

Agent access beyond defaults

By default, an agent has implicit access to core capabilities within its own project. No explicit role assignment or additional configuration is needed for the standard case. Implicit access covers:
  • Model inferencing through the project endpoint
  • Session storage read and write
Additional permissions might be needed when an agent uses connected tools that access external resources, references data outside its own project, or operates at account-level scope.

Explicit project-level access

Some advanced scenarios might require explicit role assignments for the agent identity on the Foundry project. This section outlines the permission needs as if the agent didn’t have its implicit access to the project. In the absence of implicit access, the agent identity would need the following permissions at the scope of the Foundry project to perform model inferencing with the project endpoint:
  • Microsoft.CognitiveServices/accounts/AIServices/responses/*
  • Microsoft.CognitiveServices/accounts/AIServices/agents/storage/read (for custom definitions, use Microsoft.CognitiveServices/accounts/AIServices/agents/*/read)
  • Microsoft.CognitiveServices/accounts/AIServices/agents/storage/write (for custom definitions, use Microsoft.CognitiveServices/accounts/AIServices/agents/*/write)
Built-in roleScopeCan assigned agent perform model inferencing?
OwnerFoundry project✗ No
ContributorFoundry project✗ No
Foundry UserFoundry project✔ Yes
Foundry Project ManagerFoundry project✔ Yes
Foundry Account OwnerFoundry project✗ No
Foundry OwnerFoundry project✔ Yes
Foundry User is the least-privilege built-in role that can perform model inferencing with the project endpoint. However, it includes a broader set of permissions than strictly necessary for this operation. To lower the privilege given to your agent, consider creating a custom role with only Microsoft.CognitiveServices/accounts/AIServices/responses/*, Microsoft.CognitiveServices/accounts/AIServices/agents/*/read, and Microsoft.CognitiveServices/accounts/AIServices/agents/*/write. Remember, the default case does not require a role assignment, so you only need to add this in advanced scenarios.
Creating that role assignment requires the Microsoft.Authorization/roleAssignments/write permission at the scope of the Foundry project. For details on assigning roles in Azure, see Create Azure role assignments.
Built-in roleScopeCan assignee create a role assignment?
OwnerFoundry project✔ Yes
ContributorFoundry project✗ No
Foundry UserFoundry project✗ No
Foundry Project ManagerFoundry project✔ Yes for Foundry User role1
Foundry Account OwnerFoundry project✔ Yes for Foundry User role1
Foundry OwnerFoundry project✗ No
Role Based Access Control AdministratorFoundry project✔ Yes
1 Both Foundry Project Manager and Foundry Account Owner have a constraint that they can only assign the Foundry User role. If you plan to use a custom role definition for the agent to access the project, Foundry Project Manager and Foundry Account Owner won’t be able to assign that custom role.
Because the role assignment is needed against the agent identity, it can’t be created until after the agent is created. Therefore, the user or principal that creates the agent also needs permission to create role assignments. Foundry Project Manager at the project scope is the recommended role assignment for agent creators in this scenario, as that role includes both the required data plane permissions and the ability to assign the Foundry User role.

Account-level access

When you use the Foundry SDK and the project endpoint for model inference, the project proxies inference calls to the account-level deployment using its own managed identity. However, if your agent code bypasses the project endpoint and calls the account-level OpenAI endpoint directly (for example, https://{account}.cognitiveservices.azure.com), the agent’s identity needs one of the following roles at account scope: Account-level capabilities aren’t proxied by the project endpoint. These capabilities include Speech, Content Safety, Computer Vision, Document Intelligence, Language, and Translator. They require a role assignment at account scope if your agent accesses them directly. For these capabilities, assign one of the following roles at account scope:
  • Cognitive Services User - covers Speech, Vision, Language, and other non-OpenAI capabilities.
  • Foundry User - covers all CognitiveServices data actions, including OpenAI and the capabilities listed previously, with a single grant.