The Pulse
Microsoft Details Four Layers for Letting AI Agents Act in Production
Microsoft describes a four-layer design for AI agents handling Azure network incidents, with limits on identity, tools, production changes and repeated tasks. The design lets agents investigate independently but requires human approval befo
AI.info Team · Written with AI ·
Microsoft wants AI agents to diagnose live network faults and identify fixes; its proposed boundary is that any change to production must stop for human approval. In a post published October 13, Arun Malik, a principal software engineer in Azure Networking at Microsoft, describes a system that can investigate incidents and prepare actions while restricting what the agent can actually change. The tension is central to the design: an agent may know the fix, but that does not mean it gets permission to apply it.
A BGP fix is where the demo gets serious
Malik’s example begins with a link flapping inside a datacenter and alarms combining into a single incident. An agent gathers device state and telemetry, correlates recent changes, classifies the failure and writes a summary before the on-call engineer has finished logging in. It may also identify a fix, such as shutting a BGP session carrying live customer traffic.
That last step changes the risk. A diagnostic result can be reviewed before anyone acts; a production write has immediate consequences. “The hard part of autonomy is authorization, not intelligence,” Malik writes.
“The hard part of autonomy is authorization, not intelligence.”
Arun Malik, principal software engineer, Azure Networking, Microsoft
Four boundaries shape the agent’s authority
Microsoft’s design divides control into four layers: identity, tool access, approval for production changes and a path from model-driven reasoning to repeatable automation. The agent acts with the permissions of the person who invoked it, or with a service identity if needed, but the more restrictive permission set applies. Tool access belongs to the teams responsible for those tools, with permissions changed through reviewed code changes.
The agent also works through a typed, logged tool interface rather than receiving unrestricted access to a shell. Microsoft does not rule out command-line tools: Malik says a command can be exposed as a narrow, declared tool, while a raw shell makes it difficult to attach specific permissions, schemas and an audit trail. He presents MCP as appropriate for calls that cross trust boundaries, citing least privilege, credential isolation, structured audit, approval hooks and rate limits.
The third boundary is a hard pause before a production mutation. Diagnostics can run without waiting for a person, but code in the execution engine—not a prompt—holds changes for approval. Microsoft says any exception must be earned for a specific procedure and action type; a model’s apparent competence is not enough to skip the gate.
Routine incidents could leave the model out
The fourth layer addresses what happens after the system encounters the same incident repeatedly. Microsoft says the agent can first reason through a new case, then turn a successful reasoning path into a deterministic playbook. Once that happens, routine repetitions can run with no model calls, reducing the cost and variability of repeated reasoning, according to the post.
For a network-status example, the model parses unstructured device output into fields such as interface, status and VLAN. Ordinary code checks the result against a schema and decides whether the status warrants recovery; a write step still waits for a person. Malik calls the approach “deterministic skeleton, probabilistic filling”: the model interprets, while conventional software validates and controls the action.
The proposal is an architecture, not a launch
Microsoft’s argument is that none of the four boundaries can carry the safety burden alone. Without identity limits, an agent could act with broader credentials than the person who called it; without a controlled tool interface, a shell command could bypass fine-grained authorization; without an approval gate, a plausible but faulty configuration could reach a device. Replacing repeated model reasoning with a playbook addresses a different concern: keeping solved, routine cases from depending on a fresh model decision every time.
The Command Line post describes Microsoft’s engineering approach, not a product release. It gives no availability date, pricing, benchmark results or named customer deployment. Its clearest operational limit is also its most concrete: agents can investigate network incidents on their own, but production-changing actions pause for human approval.