Rediger

Del via

User roles and permissions in Azure SRE Agent

Your agent can investigate problems, take actions on production infrastructure, and access sensitive data across your environment. Access control determines who can request actions, who can approve them, and who can modify the agent's configuration.

Access control overview

Access control works across three layers.

Diagram of access control hierarchy showing user roles, run modes, and agent permissions.

Layer Controls Configured at
User roles (this article) What users can do with the agent Azure IAM on the agent resource
Run modes Whether the agent asks before acting Per response plan and per scheduled task
Agent permissions What the agent can access on Azure, which includes managed identity RBAC roles and on-behalf-of fallback RBAC roles on resource groups

Layer 1: User roles

Your agent includes three built-in Azure RBAC roles.

Role Can do Can't do
SRE Agent Reader View threads, logs, incidents Chat, request actions, modify anything
SRE Agent Standard User Chat, run diagnostics, request actions Approve actions, delete resources, modify connectors
SRE Agent Administrator Approve actions, manage connectors, delete resources (Full access)

The user who creates the agent automatically gets the SRE Agent Administrator role.

Screenshot of SRE Agent roles in Azure portal IAM showing Administrator, Reader, and Standard User.

Who should have which role

Use the following guidance to assign roles based on team responsibilities.

Role Give to
SRE Agent Reader Auditors, compliance teams, stakeholders who need visibility
SRE Agent Standard User L1/L2 engineers, first responders, anyone who diagnoses problems
SRE Agent Administrator SRE managers, cloud admins, incident commanders

How the portal enforces permissions

The portal checks your Azure role assignments when you access the agent. The portal enforces access at two levels.

Level 1: No agent access

When you don't have the SRE Agent role assignment, the portal shows an Access Required screen with a shield icon and a Go to Access Control button that opens the Azure IAM window. If you have Azure Owner or Contributor on the resource, you also see a banner offering to autoassign the Administrator role.

Level 2: Backend enforcement

When you have an SRE Agent role but attempt an action beyond your permissions, the backend blocks the action with a 403 error. The portal might let you navigate to a page or select a button, but the operation fails with a permission error when it reaches the server.

Note

Some portal features proactively disable buttons when you lack write permissions (for example, connector management shows disabled buttons with tooltips). However, this behavior isn't yet consistent across all features. The backend always enforces the correct permissions regardless of what the UI shows.

What each role can access

The following table summarizes the access level for each role across different areas of the portal.

Area Reader Standard User Administrator
Chat View threads (read-only) Send messages, start threads Full access, approve actions, delete threads
Agent Canvas View custom agents View custom agents Create, edit, delete custom agents
Knowledge base Browse documents Upload documents Upload and delete documents
Connectors View connectors View connectors Add, edit, delete connectors
Response plans View plans View plans Create, edit, delete plans
Managed resources View resources View resources Add, remove resources
Settings View settings View settings Modify settings, stop/delete agent

Assign roles

Assign roles through the Azure portal (Access control (IAM) > Add role assignment) or by using the Azure CLI.

az role assignment create \
  --assignee user@company.com \
  --role "SRE Agent Administrator" \
  --scope <AGENT_RESOURCE_ID>

Replace the role name with SRE Agent Standard User or SRE Agent Reader as needed.

To find your agent's resource ID, run the following command:

az resource show \
  --resource-group <RESOURCE_GROUP> \
  --name <AGENT_NAME> \
  --resource-type Microsoft.SREAgent/agents \
  --query id -o tsv

How roles work together

The following example shows how roles interact during an action approval workflow. An engineer requests an action, but only administrators can approve it.

Step Who Action
1 Engineer (Standard User) "Fix the config issue"
2 Agent Drafts remediation plan
3 Agent Can't execute (needs Administrator approval)
4 Manager (Administrator) Reviews and approves
5 Agent Executes fix using managed identity or on-behalf-of authorization

Learn how the access control layers interact

This article covers user roles which includes who can do what with the agent. To understand the full access control picture, see:

Article Page What you'll learn
Run modes Run modes How Review and Autonomous modes control whether the agent asks before acting. Only Administrators can approve in Review mode
Agent permissions Agent permissions How the agent gets access to Azure resources. This includes Reader vs Privileged permission levels, RBAC roles, and OBO fallback
Audit Audit agent actions Review what your agent did, who approved it, and which identity was used
  • Last updated on