Azure Operations Agents: Deploy Narrowly, Investigate with Evidence
Set up Observability Agent and SRE Agent with explicit identity, telemetry, scope and autonomy boundaries, then verify an investigation safely.
A capable investigator still needs evidence and authority
An incident investigator can ask good questions without being allowed to restart every machine. Give an operations agent the same distinction: access to evidence, permission to act, and approval for a particular response are separate boundaries.
Product note, checked 30 October 2026: the Azure Copilot Observability Agent resource is documented as public preview. Azure SRE Agent’s setup, model availability, permissions, and billing follow its current service documentation. Do not infer universal availability, free use, or identical autonomy controls across these products. Check supported region, subscription eligibility, preview terms, and current pricing before provisioning.
Distinguish the two setups
| Area | Observability Agent resource | Azure SRE Agent |
|---|---|---|
| Focus in this lesson | Correlation, issue creation, and investigations grounded in monitored application telemetry | Connected code/telemetry and incident response through configured agents/plans |
| Identity | Chosen system- or user-assigned managed identity for autonomous tasks | Documented deployment creates identities; UAMI is used for connectors/RBAC |
| Scope | Application Insights resources under preview constraints | Connected sources and explicitly granted Azure scopes |
| Control | Choose enabled autonomous operations | Response plan autonomy and agent capability boundaries |
On-demand Azure Copilot Observability chat/deep investigation uses the signed-in user’s access and does not require the durable resource. That differs from autonomous runs under the resource’s managed identity.
Configure Observability Agent in a sandbox
The current documented portal flow requires:
- An Azure Monitor workspace in the same region as the agent resource.
- Monitoring Contributor on the resource group for resource creation/configuration.
- A managed identity with the needed monitoring/issue permissions.
- An Application Insights scope; in the portal flow it must be in the same subscription as the agent.
An Azure Monitor workspace is not simply another name for a Log Analytics workspace. Read the correct resource requirements instead of choosing whichever workspace appears familiar.
In the portal, find Observability Agents, create a resource, select subscription/group/region/workspace, and choose the identity. If using a UAMI, create it and grant the documented roles before resource creation.
The creation guide lists Issue Contributor on the Azure Monitor workspace and Monitoring Reader on relevant subscriptions for the identity. It also documents a broader Monitoring Contributor subscription-scope simplification. Prefer the least privilege that meets the documented operations, and review exact role/scope requirements with the resource owner.
On Operations, choose the monitored Application Insights resource. Autonomous correlation/issue creation and investigation are separate choices. To evaluate conservatively, leave automatic investigation off while reviewing correlated issues. Do not assume the default switches are conservative: inspect them.
The preview portal supports one Application Insights scope; the API supports up to ten. Provisioning is documented through portal or ARM/Bicep; do not invent an Azure CLI or Terraform resource command as a supported preview path.
After creation, verify the resource, identity grants, monitored scope, and enabled operations. A created resource with no authorized telemetry is not a working investigator.
Deploy and connect Azure SRE Agent
The setup guide requires Owner, or Contributor plus User Access Administrator, at the deployment scope. Adding Azure resource scopes also requires appropriate active role-assignment authority; activate eligible PIM roles through the approved process before setup.
- Open the documented SRE Agent onboarding surface and create an agent in a sandbox subscription/group.
- Select an available region/model provider and review costs and data-residency implications. Options vary.
- Review and deploy. Inspect the actual deployment result and supporting resources.
- Connect the relevant code repository through a supported authentication method.
- Connect a Log Analytics or Application Insights source. The portal’s supported Azure log connectors assign Log Analytics Reader and Monitoring Reader as documented.
- Add Azure resource access only if required. Start at resource-group scope rather than granting an entire organization by habit.
Current deployment creates both system- and user-assigned identities; the guide directs use of the UAMI for connector authentication and Azure RBAC. Do not guess which principal received a role from a similar display name.
Ask a bounded question such as “Show errors for this sandbox service during the last hour; cite the source query and timestamps.” Check the actual telemetry, not only the agent’s conclusion.
Configure incident routing without accidental autonomy
With an incident platform connected and a custom agent configured, create an incident response plan from the agent canvas. The current guide requires Contributor or Owner on the agent resource for this configuration.
Choose a narrow severity/service/title filter and Review autonomy for initial evaluation. The documented new-plan default is Autonomous, which can investigate and mitigate independently; select Review explicitly when approval is required.
Preview matching incidents and inspect which custom agent receives them. A quickstart response plan can run alongside custom plans and cause duplicate or unintended routing. Inspect existing plans before enabling another; do not blindly delete a shared plan.
For Azure Monitor incidents, a reinvestigation cooldown can merge recurring alert fires into an existing investigation. Disabling it on a noisy rule can multiply investigations and token use. Check actual event behavior before changing it.
Investigate, mitigate, then verify
Use a safe sandbox incident with a distinctive title. Require the investigation to state:
Observed symptom and time window
Source telemetry and affected resource
Competing hypotheses and evidence
Proposed mitigation, authority, and blast radius
Expected recovery signal and rollbackReview the proposed action before execution when using Review mode. After an approved mitigation, query the original customer-impact signal and relevant dependencies. An agent saying “resolved” is not sufficient.
If evidence is missing, fix telemetry access or scope first. Do not grant broad write access to solve a log-read problem. If the hypothesis is unproven, preserve that uncertainty.
A new SRE response plan should investigate test incidents but require approval before mitigation. Which configuration is essential?
Try it: design first, provision only if authorized
Prerequisites for hands-on provisioning: authorized sandbox subscription, required roles, supported region/features, Application Insights/monitoring resources, and acceptance of service/model/telemetry charges. This course does not claim these cloud exercises were executed on your behalf.
First complete a no-cost design sheet naming identity, scope, telemetry, autonomy, incident filter, and cleanup. If separately authorized to provision, follow the current source walkthrough, verify connector access, and use a harmless test incident under Review mode. Never inject a real production outage for training.
Expected observation: the agent cites accessible telemetry and routes only the intended test incident. Mitigation cannot be reported complete until target health is independently checked.
Cleanup: disable exercise response plans, inspect active investigations, and remove only resources/connectors/role assignments you created. Deleting a response plan does not automatically stop investigations already started. Check ongoing agent and telemetry billing.
Decision check: the agent found a likely cause
A likely cause is a hypothesis. Confirm it against source telemetry and a safe intervention or other discriminating evidence before claiming root cause or recovery.