Containment Plugin for Microsoft Agent Control Specification

TL;DR

• AI agent governance frameworks define policy in code, but cannot guarantee that every agent process in an enterprise will load and honor it. A vendor-shipped agent or a workload outside the governed runtime still reaches the same tools, unguarded.

• Microsoft’s Agent Control Specification (ACS) is an open, portable policy contract for AI agent behavior. It says what an agent should be allowed to do. It does not enforce that at the network.

• The Aviatrix Containment Plugin for Microsoft ACS closes that gap. An open-source plugin compiles an ACS policy file directly into Aviatrix Distributed Cloud Firewall (DCF) rules — SmartGroups, WebGroups, allow and deny policy, and inline pattern guards.

• Enforcement happens at the network, outside the agent’s trust boundary, so an agent that ignores its own policy file still cannot reach an unauthorized tool. One policy file produces the same posture across every framework, cloud, and runtime.

• Layer 4 enforcement and traditional intrusion prevention guards are validated and available today. A coverage report shows exactly which rules are enforced now and which require the Guardrail Profile feature, targeted for late summer 2026.

Enterprises are not standardizing on a single AI agent platform. A typical large organization is running LangChain in one business unit, AutoGen or CrewAI in another, Semantic Kernel and Microsoft Copilot Studio somewhere else, and a handful of vendor-shipped copilots that arrived bundled with software no one in security picked. Those agents run across Kubernetes, virtual machines, serverless functions, and managed cloud agent services, often across more than one cloud at once.

Every one of those agents makes outbound calls. It reaches Model Context Protocol (MCP) servers for tools, large language model (LLM) APIs for reasoning, and internal endpoints for data. And here is the structural problem: agent governance frameworks define what an agent is allowed to reach in code, inside the framework wrapper. They cannot guarantee that every agent process in the estate actually loads that policy and honors it.

• A vendor-shipped agent has no integration point.

• A legacy workload was never wired in.

• A compromised agent process can simply ignore its own policy file.

In each case, the agent still reaches the same MCP servers and the same LLM APIs — unguarded.

This is the same lesson the Containment Era has taught across every workload class: you cannot rely on the workload to police itself. The 82% of intrusions that now ride valid credentials through legitimate channels produce no anomaly for detection to catch. An AI agent is the archetypal case: autonomous, non-deterministic, making outbound calls on behalf of a model, often deployed through a trust chain of dependencies no one fully audited. When that agent is compromised or simply misbehaves, the only control that holds is one that governs what it can reach, independent of whether the agent cooperates. That control is Communication Governance, and it has to live at the network.

Introducing the Containment Plugin for Microsoft Agent Control Specification

Microsoft’s Agent Control Specification (ACS) is an open standard for governing AI agent behavior across frameworks and deployment environments. It provides a portable, declarative policy contract — a guardrails file — that defines interception points across the agent lifecycle and produces a normalized verdict (allow, deny, warn, escalate, or update) at each one. ACS is framework-agnostic and requires no proprietary runtime. It is a genuinely good specification. What it does not do, by design, is enforce itself at the network.

Aviatrix is the enforcement plane the specification needs. It is built entirely on the Aviatrix Distributed Cloud Firewall (DCF) and ships as an open-source shim alongside the ACS version 2 launch. The plugin reads an ACS policy file and compiles it directly into enforceable network rules:

• Resource catalog → WebGroups. The MCP servers, LLM APIs, and Hypertext Transfer Protocol (HTTP) endpoints an agent is allowed to reach become destination groups, classified by fully qualified domain name and Uniform Resource Locator (URL) path.

• Agent identity → SmartGroup. The agent workload becomes a policy source identified by what it is — cloud tag, Kubernetes label, namespace — not by an IP address that changes when the workload scales or moves.

• Block and allow policies → DCF rules. Unconditional allow and deny statements become DCF rules inside a default-deny posture: anything not explicitly permitted is denied and logged.

• Pattern guards → inline inspection. Input and output validation patterns are applied inline at the gateway using traditional intrusion prevention system (IPS) rules today, with semantic detection and redaction via advanced AI guardrails coming later this year.

The foundational invariant is the part that matters most: no unguarded path to a tool endpoint exists. Even an agent process that never loaded its ACS policy — a vendor-shipped copilot, a third-party agent, a compromised workload — cannot reach an unauthorized MCP server or LLM API, because the gateway blocks it at the wire. The agent platform is the team’s choice, but the security policy is not.

Notes from the Lab

For security architects and platform engineers, here is how the architecture works in practice and why each design decision matters to the people who have to deploy and defend it.

The plugin does the compilation work, not just the transport

A command-line tool reads the ACS guardrails file and emits DCF SmartGroup, WebGroup, and policy objects, then optionally applies them through the Aviatrix REST Application Programming Interface (API) or the Terraform provider. This is the difference that defines the category. Microsoft’s own reference architecture uses a service mesh for transport — it carries the policy file to the sidecar and stops there. It does not translate policy into enforcement rules, does not apply pattern-guard inspection, and covers only the Kubernetes mesh. The Aviatrix plugin does the actual enforcement work, and it does it as code that ships in the same repository and is reviewed in the same pull request as everything else.

Why it matters: policy becomes infrastructure-as-code with an auditable approval trail, not a document someone hopes is being followed.

Enforcement sits outside the agent’s trust boundary

DCF evaluates every outbound connection at the gateway, before it leaves the environment. There is no sidecar requirement and no mesh dependency. Because enforcement is a property of the network path rather than a process inside the agent, a compromised agent cannot disable it — there is nothing on the workload to kill.

Why it matters: this is the property that separates containment from in-framework filtering. The wall exists before the breach and holds regardless of what the agent code does.

Coverage is not gated on framework integration

Any agent workload that generates network traffic and runs in an environment served by an Aviatrix gateway is covered — LangChain, AutoGen, CrewAI, the OpenAI and Anthropic agent toolkits, Semantic Kernel, Microsoft Copilot Studio, and vendor-shipped agents, all equally. Deployment environments span Kubernetes on any cloud, virtual machines, serverless functions, managed cloud agent platforms, and on-premises workloads.

Why it matters: an enterprise running three agent frameworks across two clouds gets one consistent security policy and one unified audit trail, instead of three partial integrations and a set of agents no framework can see.

Observability spans both planes

DCF flow logs and audit events record every rule hit in CoPilot today, and map those back to the agent’s identity wherever possible.

The Outcome: A Bounded Blast Radius for Every Agent

Detection asks whether an agent is behaving badly, while containment asks a different question: when an agent is compromised, ignored its policy, or was never integrated at all, what can it actually reach? With ACS policy compiled into default-deny DCF rules, the answer is “only the tools this agent was explicitly permitted to use.” The agent may misbehave; the Blast Radius does not grow past the wire.

Conclusion

AI agents are arriving faster than any single governance framework can wrap them, and no framework can guarantee that every agent in the estate will honor its policy. The Containment Plugin for Microsoft Agent Control Specification resolves that by separating the two questions enterprises have been forced to answer together: which agent platform to run, and how to enforce security across all of them. The platform stays the team’s choice. The policy becomes one file, compiled into network enforcement that holds whether or not the agent cooperates: across every framework, every cloud, and every runtime, with one audit trail.

It is a direct bridge from an open agent governance specification to enforced network policy, a claim no other network security approach can make today. Layer 4 enforcement and traditional pattern guards are validated and available now; the Guardrail Profile feature extends enforcement to deeper, stateful constructs in late summer 2026, with the coverage report keeping the line between the two visible at every step.

Ready to see it in your environment? Schedule a demo of the Containment Plugin for Microsoft Agent Control Specification. We will map your current agent fleet, identify the tool-call paths you cannot see today, and show you exactly where enforcement goes.