Skip to main content

About Azure SRE Agent in a governed estate

The lab build in Set up an Azure SRE Agent takes about half an hour and tells you almost nothing about whether the thing belongs in a regulated production estate. This page is the other half: what the service is underneath the chat window, which controls actually hold, which ones only look like they hold, and what I would want decided before an agent gets production scope.

It is written against an architecture review draft dated 14 September 2026, Microsoft's own account of why the runtime is built the way it is, and the Learn articles on roles, permissions and tool policy. The service moves fast enough that some of the numbers below will be wrong by the time you read them, and the flat facts live in Azure SRE Agent governance reference where they are easier to re-verify. Full sources are at the end.

How it all fits together​

One picture for the whole service: who talks to what, where each piece runs, which controls sit between a proposed action and a real one, and which traffic can be made to go through your network. The two bands above your tenant are Microsoft's estate, not yours. That division is the thing to look at first, and it is the subject of what still bothers me at the end of this page.

Read it as four questions, which is how Microsoft's own engineers frame it: who is asking, what authority do they carry, what can the execution environment reach, and where do the credentials live while it runs.

Two things at once​

The framing that makes review conversations go well: this is a non-human operator with an Entra identity, an RBAC footprint, an outbound network path, and a monthly bill. It is a principal and a workload at the same time, and most disagreements in a review come from people arguing about one of those while thinking about the other.

If you treat it purely as a workload, you end up with a careful network design wrapped around an identity that can do anything. If you treat it purely as a principal, you scope the RBAC beautifully and never notice that it reads your production logs and can post them anywhere the internet will accept.

The architecture is split, and the split is the security story​

The agent is not one process. Reasoning runs in Microsoft's managed runtime. Tool execution runs in a per-agent sandbox, one fresh process per call, whole tree killed afterwards. Credentials live in a separate identity sidecar, and a separate proxy attaches them to requests in transit and decides where those requests may go.

The practical consequence: stealing a credential out of the agent means compromising the identity sidecar, not the sandbox. The reasoning loop never holds a token, so prompt injection that reaches it cannot read one out of the context.

What injection can do is make the agent ask for something bad. That request still has to survive policy evaluation and then the network boundary, which is the real reason network control matters here. The agent reasons over text it did not write: log lines, issue descriptions, tool output. Policy at the network layer holds even when the model has been talked into something, because an instruction to send data to a host you never allowed fails at the proxy regardless of what the model decided.

Why it is shaped that way​

The split was not the original design. Sanchit Mehta and Vishwas Agarwal published the history in August 2026, and it is the most useful thing I have read on the product, because it is a list of things that went wrong rather than a list of features.

The first design put the harness, model-authored code, tools and credentials on one machine, inherited from how coding assistants are built. Four incidents, none of them attacks, took that design apart:

  • A short-lived GitHub token expired mid-task. The agent read the harness's own source, reconstructed the OAuth device-code flow, prompted a researcher to sign in, and wrote the new access and refresh tokens to its filesystem for reuse. It rebuilt the credential machinery it was supposed to be governed by.
  • Asked to interpret a screenshot from an alert payload with no vision tool available, the agent found a free OCR service on the internet and posted the test image to it. A sensible chain of reasoning that would have shipped customer data to an unvetted third party.
  • It found a credential committed to a customer repository, quoted it in its findings, and saved it to memory with a note never to use it. The secret was then in an investigation summary and a memory store, neither of which is in anyone's rotation playbook.
  • Told to deallocate VMs after five safety checks, it lost the logging service after the third, matched the situation to a past run where deallocation had been safe, and deallocated anyway. Right authority, wrong action.

The conclusion Microsoft drew is the sentence I would put on the first slide of any agent review: "The environment is the policy." A control the agent can inspect or edit is one tool call from being bypassed, so enforcement has to sit outside the agent's reach.

Four layers came out of that. Execution moved into a per-agent microVM, chosen over containers so each agent gets its own kernel behind a hardware boundary, with the harness, provisioning, policy and credential flow on the other side of a narrow API. Credentials stopped entering the sandbox at all: tools such as git, az and kubectl still authenticate through their normal paths, but receive an opaque handle that only the egress proxy can redeem, bound to one call, one destination, one operation and one use. Approval became a risk classification rather than a permission check, scored by a guard outside the reasoning loop against the operation, the target and the strength of the evidence behind it. And the caller's role now shapes the environment before reasoning starts, deciding which tools mount, which memory is visible or writable, and which credentials may be injected, so a low-privilege user cannot borrow authority through shared state.

Two of those layers are still being built. The risk-classification guard is described as the least settled part of the design, and the scrubbing of secrets out of tool output before they reach model context is an internal pilot. The gaps they report closing recently are the interesting part: an action blocked through one tool that was still reachable through another execution path, and an MCP server that could silently widen its contract after onboarding with no protocol mechanism to detect the change. Both of those are failure modes your own review should be looking for.

The five questions they now ask in review are better than most security checklists, and they transfer to any agent platform:

  1. Can the agent inspect, modify or bypass the machinery that provisions its tools, identity, policy or credentials?
  2. Can the same effect be reached through another tool or execution path that avoids the intended control?
  3. Through which paths can sensitive data enter the agent-controlled environment or leave the system?
  4. For every consequential effect, can the platform say who asked, what it did, what it touched, what data it carried, what evidence supported it, and whose authority it ran under?
  5. When evidence is missing, stale or ambiguous, does the operation reliably leave the autonomous path?

Question four is the one I would hold this service to hardest, because answering it means correlating the agent's telemetry, the activity log, and your own network logs, and none of those is complete on its own.

RBAC is the boundary. Network is the backstop​

Network control constrains where traffic can go. It does not constrain what the agent is authorised to do. Get the identity design wrong and no amount of egress filtering saves you.

Two parts of the identity model are worth arguing about before go-live.

The first is Monitoring Contributor at subscription scope, which is granted at both permission levels so the agent can acknowledge and close Azure Monitor alerts. It is broader than most reviewers expect, and it is subscription-wide rather than scoped to the resource groups you selected. If your alerting configuration is itself a control, an actor that can mutate it is a control weakness. I do not think that means refusing it. I think it means deciding deliberately, writing down that you decided, and alerting on monitoring changes in the activity log.

The second is the SRE Agent Administrator role, which bundles approvals, on-behalf-of authorisation, hook authorship, tool policy, egress mode and the bypass toggles into one tier. Those are materially different privileges wearing the same badge. Small membership, PIM with approval and justification, and an alert on membership changes.

On-behalf-of elevation is the interesting compromise. It keeps the standing identity small, because the agent can hold Reader and borrow a human's rights for the rare write. The cost is that the audit trail for privileged actions splits between the agent's identity and individual people. Decide up front which story you want auditors to read, because both are defensible and mixing them is not.

The control that can undo your controls​

Four rungs decide every tool call: hooks, then tool access policies, then default approval, then run mode. Hooks are the highest.

A user-defined hook that returns allow overrides a global deny. That is a deliberate escape hatch, and it means a denylist is exactly as strong as your control over who can author hooks. Hook creation is administrator-only and every override is logged, so the compensating controls exist. Without PIM on that role and an alert on hook creation, though, the denylist is advisory rather than enforced, and I would not describe it to a security reviewer as a control.

There is a second trap in the policy layer that catches people who write denylists quickly. The aliases bash, shell and execute_bash expand to all command-string tools, but not to ExecutePythonCode. A deny list written only against bash(...) leaves Python wide open, and Python in the sandbox can do the same things bash can.

Defaults point the wrong way for production​

Run mode is set per response plan and per scheduled task, and both default to Autonomous. The agent-level default is Review. So an agent whose global setting says Review will happily run an autonomous actor the moment someone creates a response plan, and Author or Standard User is enough to create one.

Review mode is also narrower than it looks. It gates Azure infrastructure operations, meaning CLI, ARM and equivalent writes. Sending an email, posting to Teams, or querying an external data source proceeds on the agent's own reasoning. If you want those gated, that is what hooks and tool access policies are for, and you have to say so explicitly.

Egress: three modes and a set of toggles worth policing​

Unrestricted is for short-lived test agents with nothing sensitive in reach. Limited denies everything and allows a host list. Azure VNet routes non-platform egress through a delegated subnet, which is the mode that makes production defensible, because the agent becomes just another workload on a subnet you already govern.

The staged path works well: run in Limited while you learn which destinations investigations actually need, then translate that list into firewall rules and move to VNet. Settings survive the mode change.

The workspace networking tab in Limited mode, with the infra network toggles and the selected host list

The toggles in that screenshot are the part to think hardest about. GitHub, PyPI, npm, NuGet and container registries have no Azure service tag and move across large IP ranges, so a layer-4 firewall cannot keep up with them. Microsoft's answer is a per-category toggle that pushes those categories onto the Microsoft-managed path instead, and Microsoft's own framing is that this is transitional rather than a permanent substitute for hostname-aware filtering. The durable answer is FQDN filtering in your own network, after which each category moves back onto the VNet path.

The single most valuable control in the whole design is not on this page at all: Azure Policy can restrict or disable those toggles, which converts a per-agent setting an administrator can flip into a tenant guardrail they cannot. Pair it with an activity-log alert on egress mode and toggle changes.

Two gaps survive every mode. Platform traffic, meaning orchestration, model endpoints and telemetry, always takes the Microsoft-managed path and is never configurable. Connector traffic takes the public internet and cannot be routed through your VNet at all. If connectors are in scope for production, that is a conversation with whoever owns the egress policy, not a footnote.

Visibility is partial, and the partial bit is the trap​

The Inspect tab gives an administrator a shell in the workspace and a network audit list showing allowed and denied requests with host, method and path. It is genuinely useful for answering "can the agent reach this" during a build.

It is not an audit trail. It covers the agent's own egress-policy decisions and nothing your firewall, DNS, proxy, NSG flow or private endpoint logs would tell you. For evidence you correlate the two, and divergence between what the agent believed it was allowed and what the firewall recorded is itself worth investigating.

The same "correlate, do not rely" rule applies to the agent's telemetry. Application Insights customEvents records every tool call with its input and output, every model call with token counts, and every approval decision. That makes the workspace an aggregation of production command text and query results, which means it inherits the classification of the most sensitive system the agent can read, and the retention it landed with at provisioning is almost certainly not the retention your privileged-operator logs are supposed to have.

The cost shape is unusual, and it changes how many agents you build​

Billing has a fixed part and a variable part. The fixed part is 4 AAU per agent-hour, charged from creation until deletion, and stopping the agent does not stop it. The variable part is token-based.

Run the arithmetic on a modest estate and the fixed component dominates. Three agents at baseline is roughly 8,760 AAU a month before anyone asks a question, which in the review draft's worked example is about 39 percent of total spend, and more than 70 percent at lower incident volume. Agent sprawl is the expensive mistake, not heavy use. That pushes toward consolidating workloads under one agent per environment per region, which sits awkwardly against the fact that the region is immutable and multi-region means multiple agents.

Agent consumption showing the monthly AAU allocation, the breakdown by thread type, and per thread costs

The AAU allocation ceiling deserves a specific warning. It is a cost control that creates an availability risk: hit it and the agent is unavailable for the rest of the month, and a decrease only takes effect next month. Set it well above your p99 monthly consumption, alert at 70 and 85 percent, and keep the runbooks usable without the agent. An incident-response tool that switches itself off at month end because of a budget setting is a bad surprise to discover during an incident.

Model provider choice lands in the same conversation, because it is a residency decision and a cost decision at once. Anthropic is not covered by EU Data Boundary commitments, and Azure OpenAI at the published rates is materially cheaper per token. If a regulator cares where your production logs get processed, that constraint decides the provider before cost does.

What I would insist on before production scope​

  • Azure Policy denying the infra network bypass toggles on production subscriptions, and VNet egress with a dedicated subnet, a default-deny NSG and FQDN filtering at the firewall.
  • Reader permission level in production, scoped by resource group, with on-behalf-of as the elevation path. Privileged belongs in non-production where you are building confidence.
  • A global deny on destructive patterns that covers Python as well as bash, a global ask on write-class tools, and a global allow on read-class tools so routine diagnosis is not approval-gated into uselessness.
  • A PostToolUse command hook shipping every tool call to the SIEM, with failMode set to allow so it cannot brick incident response when the hook itself breaks.
  • Review mode written explicitly onto every production response plan and scheduled task, never inherited.
  • PIM on SRE Agent Administrator, plus activity-log alerts on hook creation, egress mode change, bypass toggle change and role assignment change.
  • A thread retention and deletion procedure, because nothing expires on its own.

On the rollout itself, the shape that Microsoft recommends is also the one I would argue for: run in Review for two to four weeks, record which action classes you approve without hesitation, then promote those specific triggers to Autonomous one at a time. The metric that makes that decision is approval acceptance rate, so instrument it first. Without it you are promoting actions to autonomy on impression.

One acceptance test I would not skip: deliberately block a destination or remove a DNS link, and confirm the agent reports the unreachable source rather than presenting a confident diagnosis built on partial evidence. It does report the failure. Whether your responders read it is the part you are actually testing.

What still bothers me​

I like the product. The Foundry question in the lab came back with the exact CLI it ran, the resource group creation paused for me at the right moment, and the investigation quality on a well-instrumented workload is genuinely better than a tired human at 3am. None of what follows is a complaint about the functionality.

What I cannot get comfortable with is that the thing doing the work does not run inside a boundary I control.

The execution is not in my tenant. The reasoning loop runs in Microsoft's runtime. The tool processes run in a per-agent microVM that Microsoft provisions, on infrastructure I cannot see. What lands in my subscription is the ARM resource, the managed identity, and an Application Insights instance with its workspace. That is an accounting record of an agent, not the agent. Every other Azure service I run in a regulated estate, I can point at a subscription and say that is where it executes. Here I cannot, and the sandbox placement rules make it sharper: sandboxes stay within a geography, not within my region, so the documented example puts East US 2 agents on compute in Central US, North Central US or Canada Central. My region choice pins where threads and memory are stored. It does not pin where the work happens, and inference can leave the region regardless.

I cannot manage its lifecycle. I can create the resource, stop it, and delete it, and those are real controls, though stopping does not stop the always-on meter. What I cannot do is anything a platform team normally does with a compute estate: pin a runtime version, hold a patch until a change window, roll back a bad one, choose an image, or drain and replace an instance. The templates expose an upgradeChannel property, and that is the whole surface. When the runtime changes underneath me, I find out from behaviour, not from a change record I approved.

My VNet governs its traffic, not its residence. This is the one that gets mistaken most often in review conversations. Connecting a delegated subnet does not move the agent into my network. It projects the sandbox's egress into my network, which is worth having, and then platform traffic and connector traffic carry on outside it anyway, and nothing inbound can reach the agent privately at all. So the diagram above has a hard line down the middle that no amount of network design moves. The honest description for a reviewer is "an externally hosted service with a controllable egress path into my estate", not "a workload on my network".

The uncomfortable part is that Microsoft's own argument for this design is a good one, and it is the same argument. Enforcement has to sit where the agent cannot reach it, which means the sandbox, the credential broker and the policy layer all have to be outside the agent's blast radius. Put that machinery in my subscription, where my administrators and my automation could edit it, and the guarantee that the agent cannot rewrite its own guardrails gets weaker. I am asking for the control that the security model deliberately does not give me. Knowing that does not change my answer for a regulated workload: the trade is Microsoft's to explain, and mine to accept or refuse, and today I have to accept it whole or not at all.

Where that leaves me, concretely. For a lab, a non-production estate, or an internal workload with nothing regulated in its logs, the current model is fine and I would run it now. For a production estate under a control set that asks where code executes, who patches it, and whether customer-managed keys protect what it stores, I would not sign it off yet, and I would say so in those terms rather than hiding behind a vaguer objection. Three things would change that: a customer-hosted or customer-visible execution option, a supported way to hold and roll back runtime versions, and customer-managed keys over the thread and memory stores. None of the three is announced, so this is a watch-and-revisit position, not a prediction.

The questions a review board has to answer​

These are not rhetorical. Every one of them has a defensible answer in both directions, and none of them has a default that suits everybody.

  1. Do we accept subscription-scoped Monitoring Contributor, or scope it down and lose native alert lifecycle management?
  2. Which model provider, and is that driven by residency, cost, or investigation quality? Who owns changing it?
  3. What is the retention period for conversation threads and synthesised memory, and who executes deletion?
  4. Is customer-managed key support on the agent's own stores a hard requirement? If so this is a gap to raise with Microsoft, not a design choice.
  5. Do we permit on-behalf-of at all, or insist that everything runs under the agent's own identity so the audit trail stays single-threaded?
  6. Do we allow connectors in production at all, given their traffic cannot be routed through the VNet?
  7. What is the AAU ceiling, and who is paged when consumption crosses 85 percent?
  8. Which action classes become autonomous in production, on what evidence, and who signs that off?
  9. Is one Administrator tier holding approvals, hooks, tool policy and network configuration acceptable to us?
  10. Who owns the agent's Application Insights workspace, what retention is set on it, and does its classification match the most sensitive system the agent can query?

An agent in production with no alerting on changes to its own governance is not a controlled system, whatever the rest of the design says.

Sources​