Agent Permissions

When you create an agent, a user-assigned managed identity (UAMI) is automatically created alongside it. This UAMI is how your agent authenticates and interacts with your Azure resources — it acts on your behalf without you having to manage secrets or credentials.

For details on the identity itself — what gets created, why, and how connectors use it — see Agent Identity.

Permission levels

During agent creation, you choose a permission level that determines which RBAC roles get assigned to the UAMI on the resource groups you select:

Level	What it grants	Best for
Reader	Core monitoring roles + resource-type-specific reader roles	Read-only diagnostics. The agent prompts for temporary elevation (via OBO) when it needs to take action.
Privileged	Core monitoring roles + resource-type-specific contributor roles	Full operational access. The agent can take approved actions directly.

Preconfigured roles (always assigned)

Regardless of the level you choose, these roles are always assigned:

Role	Scope	What it allows
Reader	Resource group	View resources and properties
Log Analytics Reader	Resource group	Query logs and workspaces
Monitoring Reader	Resource group	Access metrics and monitoring data
Monitoring Contributor	Subscription	Acknowledge and close Azure Monitor alerts, update monitoring settings

Monitoring Contributor

Monitoring Contributor is assigned at the subscription level during agent creation so your agent can manage Azure Monitor alert lifecycle (acknowledge, close) out of the box.

If you chose Privileged, additional contributor roles are granted based on the resource types detected in your managed resource groups (for example, Container App Contributor if the resource group contains Container Apps).

Default state

If you don't assign resource groups when creating an agent, the managed identity has no permissions. You must explicitly grant access for the agent to do anything.

Grant access to resources

Assign resource groups to your agent, then grant RBAC roles to the managed identity:

# Grant Reader access to a resource group (view resources, query logs)
az role assignment create \
  --assignee <agent-managed-identity-id> \
  --role Reader \
  --scope /subscriptions/<sub-id>/resourceGroups/<rg-name>

# Grant Reader access to entire subscription (for broader visibility)
az role assignment create \
  --assignee <agent-managed-identity-id> \
  --role Reader \
  --scope /subscriptions/<sub-id>

# Grant Contributor access to a resource group (modify resources)
az role assignment create \
  --assignee <agent-managed-identity-id> \
  --role Contributor \
  --scope /subscriptions/<sub-id>/resourceGroups/<rg-name>

tip

For read-only access across multiple resource groups, assign Reader at the subscription level instead of resource group by resource group. For write access, assign specific roles at the resource group level. To find your agent's managed identity ID, see Finding your agent's UAMI.

Modify permissions

You can adjust the UAMI's permissions anytime by updating IAM settings on the managed resource groups.

• Grant more access: Add role assignments in the resource group's IAM settings
• Add a resource group: Adding a resource group to the agent's scope automatically assigns the UAMI's roles to it
• Remove a resource group: Removing a resource group revokes all access to it

note

You can't remove individual permissions — only entire resource groups.

Permission flow

When your agent needs to perform any action, it follows this flow:

This applies to everything the agent does — interactive chat, incident threads, scheduled runs, and autonomous operations.

On-behalf-of (OBO)

When the managed identity lacks permissions for an action, the agent can temporarily use your permissions via on-behalf-of flow. This is especially common if you chose the Reader permission level — the agent has read access but needs your credentials to take write actions.

warning

Only users with the SRE Agent Administrator role can authorize OBO requests. Standard Users cannot provide OBO authorization. Personal Microsoft accounts cannot authorize OBO regardless of role — only work or school (Entra ID) accounts support on-behalf-of token exchange. See User Roles for details.

Example

You ask the agent to scale a Container App, but the managed identity lacks write permissions:

The agent explains what happened and asks you to grant your credentials:

"The agent tried to execute this command using its managed identity but received an authorization error. If you grant permissions, the command will be re-executed using your credentials (OBO) with scope: [scope]"

Click Grant permissions to proceed. The button text distinguishes OBO requests from standard approvals — you see "Grant permissions" when the agent needs your credentials, and "Approve action" when the agent has sufficient permissions in Review mode.

Your OBO token is encrypted and stored on the approval record. For deep investigations, the token is reused for all operations within that investigation task. It is not reused across other tasks or sessions. After the task completes, the agent returns to using its managed identity.

When OBO is used

Scenario	What happens
Reader-level agent needs to act	Agent has Reader permissions but user asks it to restart a service → requests Administrator authorization
Autonomous incident response	Agent is triggered to remediate but managed identity only has Reader → requests Administrator authorization
One-time privileged operation	Interactive sessions where an Administrator has permissions the agent doesn't
Personal account user	OBO authorization is unavailable — a work or school account Administrator must authorize instead

Related

Resource	Why it matters
Agent Identity →	What identities get created and how connectors use them
User Roles →	What users can do with the agent
Run Modes →	How the agent handles approvals
Audit Agent Actions →	Audit what the agent did with its permissions