What Is the Microsoft Agent Control Specification? Network-Layer Enforcement for AI Agents

The Microsoft Agent Control Specification is Microsoft Foundry's open control plane for AI agents, released at Microsoft Build 2026. It gives enterprises a single specification file for declaring what any AI agent is allowed to do: which tools it can call, which models it runs on, and what its policy boundaries are. The specification is open source, published on GitHub, and authored to work across vendors and clouds, not as an Azure-only feature.

That last point is what makes it worth understanding beyond the Build announcement. The Microsoft Agent Control Specification is not a product you buy. It is a standard you implement. The standard is only as useful as what enforces it, and the thing it was not designed to do on its own is enforce policy at the network layer: across AWS, Azure, Google Cloud, and on-premises Kubernetes simultaneously.

This article explains what the Microsoft Agent Control Specification is, how it works, and why network-layer enforcement is the one component no in-process control can replace.

AI agents are not software in the traditional sense. They acquire credentials, call external tools, generate their own instructions, and reach outbound destinations at machine speed without asking a human for permission. They run on LangChain, Strands, AutoGen, and frameworks that did not exist twelve months ago. They deploy across every cloud and every Kubernetes runtime an enterprise has adopted.

The security problem that creates is structural. By 2027, many enterprises are projected to run more agent instances than human employees. Each one carries credentials. Each one has network reach. Each one will, at some point, behave in ways the organization did not intend.

The OWASP Top 10 for Agentic Applications, the first formal taxonomy of risks specific to autonomous AI agents, peer-reviewed by more than 100 security researchers and released in December 2025, catalogs exactly how those failures play out: goal hijacking, tool misuse, identity abuse, memory poisoning, and cascading failures across multi-agent workflows. What those risk categories share is that they all produce traffic at the network layer. The agent acts. The network carries that action. That is where enforcement must hold.

The existing control stack was not designed for this. SDK guardrails only work inside the process they instrument. Identity systems govern the user, not the agent's tool surface. Posture tools surface risk on a dashboard; they do not enforce policy on live traffic. None of those controls survives a poisoned dependency, a jailbroken prompt, or a hallucinated tool call that the in-process runtime believes is legitimate.

The Microsoft Agent Control Specification is the first serious attempt at an industry-wide standard for declaring agent behavior before any of those failures occur.

The Microsoft Agent Control Specification is Microsoft Foundry's open-source control plane for AI agents. It provides a single file format, .guardrails.yaml, for declaring an agent's allowed tool surface (which external tools and APIs the agent can call), model constraints (which models the agent is permitted to use), and policy boundaries (what the agent is explicitly prohibited from doing).

The specification lives on GitHub and is designed to be implemented across any vendor, cloud, or agent framework. An agent built on LangChain and one built on AutoGen can both carry the same .guardrails.yaml file and be evaluated against the same policy. That consistency across frameworks is the point.

The Microsoft Agent Control SDK enforces these constraints inside the agent's runtime, at the level of tool names and argument values. It knows what the agent has been told to do, what tools it is trying to call, and whether those calls are within policy.

That is the in-process half of the picture.

The agent runtime can be deceived. The network cannot.

An SDK guardrail enforces only what runs inside the process it instruments. When an agent is jailbroken by adversarial input that overrides its original policy, the SDK may believe the resulting tool call is legitimate. When a dependency is poisoned through a supply chain compromise, the SDK has no visibility into what changed upstream. When a prompt injection causes the agent to hallucinate a tool call, the in-process control has no independent verification mechanism.

The LiteLLM supply chain attack in March 2026 demonstrated this at scale. The malicious payload in LiteLLM versions 1.82.7 and 1.82.8 ran inside the trusted process, with access to AWS, GCP, and Azure credentials, harvesting them to an external endpoint. No SDK guardrail inside the LiteLLM process saw a policy violation because the compromised code was the process. The organizations that stopped the exfiltration did not detect it faster. They had network-layer architecture that governed every outbound path before the breach occurred.

The network has none of those blind spots. Wherever a packet has to travel, enforcement holds. The destination is real. The protocol is observable. The identity of the workload generating the traffic can be verified at Layer 7. That is where containment happens: not because the network is smarter than the SDK, but because it operates independently of whatever the agent believes it is doing.

This is the problem that network-layer enforcement solves, and it is the problem the Microsoft Agent Control Specification was explicitly designed to let the ecosystem address.

Aviatrix's Cloud Native Security Fabric is the first multicloud, multi-framework enforcement substrate for the Microsoft Agent Control Specification. The integration carries a single policy file from the agent runtime into live network enforcement across AWS, Azure, Google Cloud, and on-premises Kubernetes.

The division of labor is clean. Microsoft authors the standard. The Microsoft Agent Control SDK enforces tool-name and argument-level controls inside the agent's runtime. The Cloud Native Security Fabric enforces destination, protocol, identity, and policy on every outbound connection the agent attempts, at the wire, not inside the process.

In practice, the integration is one file in Git and two steps running in parallel — executable through GH Actions, Argo, Flux, or any CI runner.The first deploys the agent to a supported Kubernetes runtime. The second compiles the specification into an Aviatrix Distributed Cloud Firewall custom resource definition, which the Aviatrix controller reconciles into live policy across the customer’s entire cloud estate within minutes.Aviatrix translates the policy file into DCF enforcement through your existing CI pipeline — Argo, Flux, GH Actions, or any runner. The Aviatrix controller reconciles it into live network policy across your cloud estate. Works on K8s (EKS, AKS, GKE) and directly via API for VM and serverless agents.[C1] 

 [C1]Integration mechanics section: old GH Actions pipeline text still present alongside new text. Blocked on Chris confirming new integration mechanics post Rego/CEL/Cedar architecture change. Replaced with holding language.

The result is two enforcement planes governed by the same source of truth. When the SDK cannot see a call because the agent has been jailbroken or a dependency has been poisoned, the network layer still stops it. For enterprises already running Aviatrix for multicloud security, the integration extends that existing policy plane to cover every AI agent workload without requiring separate tooling or additional spend.

Network-layer enforcement in this context means policy that operates at the wire, on every outbound connection an agent attempts, with three specific properties that in-process controls cannot deliver.

Detection-independent. Enforcement holds before, during, and after a compromise, without requiring that the compromise first be detected. Most credential-based intrusions produce no anomalous signal — the traffic looks legitimate because valid credentials are being used. An agent running a poisoned tool call that looks legitimate to the SDK will produce the same kind of signal, or none at all. Network enforcement does not wait for an alert that may never arrive. 

Path-complete. Every communication path the agent can take is governed, including paths that bypass centralized inspection points. An agent does not have to pass through a chokepoint for its traffic to be inspected. If a path exists, policy governs it.

Identity-aware at Layer 7. Policy operates at the granularity of workload identity and application protocol, not IP addresses and ports. The enforcement boundary is myproject@github.com, not github.com. That distinction matters when an agent is allowed to reach a legitimate destination but not a specific endpoint within it.

Together, these properties define what the Aviatrix Cloud Native Security Fabric delivers at the network layer: enforcement that is independent of what the agent believes it is doing, coverage of every path the agent can take, and granularity that matches the actual threat model. The Aviatrix agentic AI security blog covers why east-west visibility and egress control are the two controls that matter most once agents are in production.

AI agents make the Blast Radius question structural.

Blast Radius is the set of systems, data, and functions that compromised workload code can reach when it runs. For most workloads, Blast Radius is bounded by network policy, credential scope, and access controls deliberately configured by a security team. For AI agents, those boundaries are harder to maintain because agents are ephemeral (defeating agent-based defense), highly privileged (concentrating non-human identity risk), and shipped fast enough to outrun security review.

When an agent is compromised through a jailbroken prompt, a poisoned dependency, or a hallucinated tool call, the Blast Radius is determined by what it can reach, not by what it was supposed to do. That is what network enforcement bounds: the reachability of a compromised agent before any human is alerted, independent of whether the in-process control failed.

The architectural reality is that you cannot meaningfully reduce Blast Radius at the SDK layer alone. The agent controls the SDK. The network controls the agent.

AgentGuard, Aviatrix's product for discovering, containing, and governing AI agent workloads, addresses this directly. Its Discovery and Risk tier inventories every agent running across VMs, Kubernetes clusters, and serverless functions, including shadow agents that were never authorized, before any containment policy is applied. You cannot bound the Blast Radius of an agent you do not know is running.

For a security architect evaluating the integration, the end-to-end flow works as follows.

The agent team authors a .guardrails.yaml file that declares the agent's allowed tool surface, model constraints, and policy boundaries. That file is committed to Git. Two steps run in parallel at deploy time — executable through GH Actions, Argo, Flux, or any CI runner. 

The first Action deploys the agent to the target Kubernetes runtime: Amazon EKS, Azure AKS, Google GKE, or on-premises Kubernetes.

The second Action compiles the Microsoft Agent Control Specification into an Aviatrix Distributed Cloud Firewall custom resource definition. The Aviatrix controller picks up the custom resource definition and reconciles it into live network policy across the customer's cloud estate. The same policy file governs both planes.

Supported runtimes include AKS, EKS, GKE, and on-premises Kubernetes. Supported agent frameworks include Strands, LangChain, AutoGen, and any conformant runtime built to the Microsoft Agent Control Specification. The integration is available as a Validated Containment Architecture. Deployment requires Aviatrix Enterprise, available as a 30-day free trial on AWS or Azure Marketplace.

The Microsoft Agent Control Specification is worth understanding separately from the Microsoft product announcement because its value is architectural, not commercial.

Before a shared specification existed, every agent framework carried its own security model. A LangChain agent and an AutoGen agent built by the same team had no common policy language. A CISO trying to govern both had to negotiate separately with each framework's native controls, which meant inconsistent enforcement, inconsistent auditability, and no shared source of truth.

The .guardrails.yaml format changes that. One file declares what an agent is allowed to do, regardless of which framework built it. One SDK enforces those constraints at the process layer. One network-layer implementation, the Cloud Native Security Fabric, applies the same policy across every cloud the enterprise uses, including those where Microsoft Foundry does not operate.

That is what makes the Microsoft Agent Control Specification a genuine industry standard rather than an Azure feature: the enforcement ecosystem is what gives the specification enterprise reach, and the ecosystem is explicitly designed to work across vendors. Microsoft's own open-source Agent Governance Toolkit, released in April 2026 under an MIT license, reinforces this. The intent is clear: Microsoft authors the specification and the reference implementation; the ecosystem carries it everywhere.

Any network enforcement layer for AI agents should be testable against five properties before deployment.

Path-complete: Does enforcement govern every communication path the agent can take, including paths that bypass centralized inspection? Ask the vendor to show you a path the agent can take that does not traverse enforcement. If one exists, policy has a gap.

Identity-aware at Layer 7: Does policy operate at the granularity of workload identity and application protocol, not just IP address and port? The distinction matters when an agent is allowed to reach a legitimate domain but not a specific endpoint within it.

Detection-independent: Does enforcement hold before a compromise is detected? An enforcement layer that depends on receiving an alert from in-process monitoring inherits all the blind spots of in-process monitoring.

Compute-model agnostic: Does enforcement reach every workload type without requiring agent installation on each? Serverless functions, managed services, and ephemeral containers defeat agent-dependent architectures by design.

Universally propagated: Does a single policy change enforce across providers, regions, and clusters in subseconds? An enforcement layer that requires per-appliance configuration is not the same source of truth that the Microsoft Agent Control Specification promises.

The Cloud Native Security Fabric delivers all five. Enterprises looking to validate their current posture before deploying the specification can use the Aviatrix Workload Attack Path Assessment, a free and agentless tool that reveals how attacks would move through a cloud environment at runtime, including the egress paths an AI agent could exploit. The Agent Control Specification VCA includes a jailbroken-agent scenario in which the in-process SDK misses the malicious call and the network layer stops it: the gap that makes network enforcement necessary is made visible. 

For organizations that want validated deployment blueprints for specific AI platforms, Aviatrix's Validated Containment Architectures provide lab-tested insertion patterns, SmartGroup models, and baseline Distributed Cloud Firewall policy packs for Bedrock AgentCore, Azure AI Foundry, Google Vertex AI, and other named platforms, purpose-built so the customer deploys containment in hours, not quarters.

For security architects and CISOs evaluating the integration:

• Agent Control Specification VCA

• AgentGuard (discover, contain, and govern AI agent workloads)

• Workload Attack Path Assessment (free, agentless, reveals runtime breach chains)

The specification is open. The enforcement is the question every enterprise running AI agents now has to answer.