User Roles and Permissions
Your agent can investigate issues, 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:
| Layer | Controls | Configured at |
|---|---|---|
| User roles (this page) | 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, with OBO as fallback | RBAC roles on resource groups |
Layer 1: User roles — four built-in roles
| Role | Can do | Cannot do |
|---|---|---|
| SRE Agent Reader | View threads, logs, incidents | Chat, request actions, modify anything |
| SRE Agent Standard User | Chat, run diagnostics, request actions, manage scheduled tasks | Approve actions, upload knowledge base documents, create custom agents, delete resources, modify connectors |
| SRE Agent Author | Create custom agents, upload knowledge base documents, author response plans, add connectors | Approve actions, create scheduled tasks, delete resources |
| SRE Agent Administrator | Approve actions, manage connectors, delete resources | — |
The user who creates the agent automatically receives the SRE Agent Administrator role.
Who should have which role?
| 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 issues |
| SRE Agent Author | SRE engineers who build custom agents, response plan authors, team members who customize agent behavior |
| 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. Access is enforced at two levels.
Level 1: No agent access
When you have no 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 blade. If you have Azure Owner or Contributor on the resource, you also see a banner offering to auto-assign the Administrator role.
Level 2: Backend enforcement
When you have an SRE Agent role but attempt an action beyond your permissions (for example, a Reader trying to send a message, a Standard User trying to create a custom agent, or an Author trying to approve an action), the backend blocks the action with a 403 error. The portal may let you navigate to a page or click a button, but the operation fails with a permission error when it reaches the server.
Some portal features proactively disable buttons when you lack write permissions (for example, connector management shows disabled buttons with tooltips). However, this is not yet consistent across all features — the backend always enforces the correct permissions regardless of what the UI shows.
What each role can access
| Area | Reader | Standard User | Author | Administrator |
|---|---|---|---|---|
| Chat | View threads (read-only) | Send messages, start threads | View threads (read-only) | Full access + approve actions, delete threads |
| Agent Canvas | View custom agents | View custom agents | Create, edit, delete custom agents | Create, edit, delete custom agents |
| Knowledge base | Browse documents | Browse documents | Upload documents | Upload + delete documents |
| Connectors | View connectors | View connectors | Add, edit connectors | Add, edit, delete connectors |
| Response plans | View plans | View plans | Create, edit, delete plans | Create, edit, delete plans |
| Managed resources | View resources | View resources | View resources | Add, remove resources |
| Scheduled tasks | — | Create, edit, delete tasks | — | Create, edit, delete tasks |
| Settings | View settings | View settings | View settings | Modify settings, stop/delete agent |
Assigning roles
Assign roles through the Azure portal (Access control (IAM) → Add role assignment) or 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 Author, SRE Agent Standard User, or SRE Agent Reader as needed.
Find your agent's resource ID
az resource show \
--resource-group <rg-name> \
--name <agent-name> \
--resource-type Microsoft.SREAgent/agents \
--query id -o tsv
How roles work together
An engineer requests an action, but only administrators can approve it:
| Step | Who | Action |
|---|---|---|
| 1 | Engineer (Standard User) | "Fix the config issue" |
| 2 | Author | Builds a custom agent with a response plan for config fixes |
| 3 | Agent | Drafts remediation plan |
| 4 | Agent | ⚠️ Cannot execute (needs Administrator approval) |
| 5 | Manager (Administrator) | Reviews and approves |
| 6 | Agent | Executes fix using managed identity or on-behalf-of authorization |
Learn how the access control layers interact
This page covers user roles — who can do what with the agent. To understand the full access control picture:
| Topic | 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 — Reader vs Privileged permission levels, RBAC roles, and OBO fallback when the agent lacks permissions |
| Agent identity | Agent Identity → | What identities get created with your agent, how connectors use them, and why we recommend UAMI |
| Audit | Audit Agent Actions → | Review what your agent did, who approved it, and which identity was used |