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, upload knowledge base documents, add code repository connectors | Approve actions, create custom agents, delete resources |
| SRE Agent Author | Create custom agents, author response plans, configure incident management | Chat, approve actions, upload knowledge base documents, add code repository connectors, 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.
In the portal, knowledge base uploads and code repository connectors (GitHub, GitHub Enterprise, Azure DevOps, GitLab) are gated on the Microsoft.App/agents/memory/write data action, which the Author role does not carry. Author covers custom agents, response plans and incident management only — and it also lacks threads/write, so an Author cannot chat.
A user who needs to both customize the agent and connect repositories/upload knowledge needs two assignments: SRE Agent Standard User and SRE Agent Author — or a single SRE Agent Administrator assignment.
Azure Owner and Contributor do not help here: they grant control-plane Actions only and carry no SRE Agent DataActions. A subscription Owner with only the Author role still receives a bare 403 with an empty body from the agent API.
Repository and GitHub-credential resources can also be managed through the ARM extension surface (Microsoft.App/agents/{agent}/repositories/... and .../githubAuths/...). That surface is gated on extendedAgents/*, which Author does carry — so the same logical operation succeeds via ARM and fails in the portal for an Author.
This split is intentional in implementation (the ARM aliases were added without changing existing data-plane RBAC policies), but it is surprising in practice. Assign Standard User if you want the portal flow to work; do not rely on the ARM surface as the supported workaround.
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 or add a repository connector), 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. The 403 often has an empty response body, so check the role assignment before suspecting Key Vault, ARM or networking.
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 + upload documents | Browse documents | Upload + delete documents |
| Code repository connectors | View connectors | View + add, edit connectors | View 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.App/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 |