Governance Is Now a Named Layer in Microsoft’s Stack
GitHub COO Kyle Daigle introduced Agent HQ on October 28, 2025 as an open ecosystem that brings coding agents from Anthropic, OpenAI, Google, Cognition, and xAI into a single platform, reachable through paid Copilot subscriptions. The announcement’s centerpiece for developers was mission control, a command center spanning GitHub, VS Code, mobile, and the CLI. The centerpiece for enterprises sat one paragraph lower: a control plane giving administrators security policies, audit logging, the power to designate which agents are permitted, model access definitions, and org-wide usage metrics.
Four months later the governance half stopped being a preview. GitHub’s Enterprise AI Controls and agent control plane reached general availability on February 26, 2026, with a consolidated AI administration view, session-activity search filtered by agent — including third-party agents — and API support for applying enterprise-wide custom agent definitions.
Then Build 2026 extended the same pattern from the repository to the whole estate. Microsoft announced the Agent 365 registry, which surfaces unmanaged agents discovered across Defender, Entra, and Intune — more than 20 agent types, including coding agents, AI desktop applications, and local and remote MCP servers. Windows 365 for Agents went generally available, running agents in isolated, policy-governed cloud PCs under Intune controls. And on June 2, 2026, Microsoft published the Agent Control Specification (ACS), an open industry specification for placing deterministic safety and security controls at checkpoints throughout agentic workflows. Each announcement names governance as its category. None of them treats it as a feature.
What the Control Plane Actually Governs
The platform stack now covers a specific set of questions. Which agents may run: Agent HQ’s control plane lets an administrator allowlist agents and define model access. Who an agent is: GitHub manages agent identity and access policies the way it manages a human team member’s, and branch controls decide when CI runs for agent-generated code. What an agent did: audit logs and session activity record actions down to session detail. Where an agent executes: Windows 365 for Agents pins execution inside an Intune-governed cloud PC. What an agent may do mid-run: ACS defines five validation checkpoints across an agent’s lifecycle — input, model call, state, tool execution, and output — where policy gets evaluated deterministically.
The Foundry team’s framing for ACS is the most candid statement of where this is heading: “Just as Model Context Protocol (MCP) standardized how agents connect to tools and Agent2Agent (A2A) standardized how agents communicate with each other, ACS provides one open standard for safety controls that any framework can adopt.” Tool access got a protocol. Agent communication got a protocol. Now runtime control is getting one. That is what an infrastructure layer looks like while it hardens.
The Pattern: Every Infrastructure Wave Grows a Governance Layer
Cloud adoption ran ahead of control, and a security and compliance industry grew to close the gap. Kubernetes shipped, and policy engines followed. CI/CD made deployment continuous, and observability became a category. Agents are repeating the sequence on a shorter clock, and the forcing statistic is already public: Verizon’s 2026 Data Breach Investigations Report found shadow AI activity in DLP datasets up fourfold year over year. Microsoft built Agent 365 specifically to find agents nobody registered — an admission that deployment velocity has outrun oversight inside its own customer base.
The same lag shows up one layer down, in the codebase. Agent output volume has outrun the review capacity meant to check it, which is why the agent manager is becoming a control plane for software development and why Microsoft now isolates agents at the operating-system boundary. The platforms are converging on the same conclusion from different directions: when actors multiply and act at machine speed, control has to be engineered, not reviewed.
Governance Is Bigger Than Permissions
Everything the platform stack governs shares one property: it is about the agent. Which agent, whose identity, what access, which sandbox, what audit trail. Software governance has a second half that is about the work. Architectural decisions, engineering standards, repository policies, framework conventions, deployment constraints — the accumulated record of how this system is supposed to be built. An agent can be allowlisted in the control plane, authenticated through Entra, sandboxed in a cloud PC, pass every ACS checkpoint, and still bypass your service layer, duplicate an existing abstraction, or violate a dependency rule your team settled two years ago. Every platform control passed. The architecture still drifted.
Platform governance asks: is this agent allowed to act? Architectural governance asks: is the thing it built allowed to exist? An agent fleet needs both answers, and the platform only gives you the first.
| Question | Platform governance | Architectural governance |
|---|---|---|
| Governs | Agent access, identity, audit | Decisions and structure of the code |
| Enforced at | Platform boundary | Generation and verification time |
| Scope | One vendor’s surfaces | Every execution surface |
| Catches an unapproved agent | Yes | Not its job |
| Catches a bypassed service layer | No | Yes |
The Multi-Platform Problem
Agent HQ’s own premise undercuts any single control plane. The product exists because teams already run agents from five different vendors; its integrations list — Slack, Linear, Microsoft Teams, Azure Boards, Jira, Raycast — concedes that work crosses platform boundaries constantly. A team running GitHub’s coding agent today also runs Cursor, Claude Code, OpenCode, Warp, and an internal agent or two, and each of those ships its own settings, its own rules format, its own definition of a policy. Configure your architectural constraints inside one vendor’s control plane and they stop existing the moment an agent works anywhere else.
Decisions about your architecture cannot live in someone else’s platform settings. They need to be model-independent and platform-independent: recorded once, in the repository they govern, retrievable by any agent, and verified by checks that produce the same verdict no matter which harness ran the code. Governance propagation is the property that matters — the rule reaching every surface where work happens — and deterministic enforcement is what makes the rule mean the same thing on each of them. ACS demonstrates that even Microsoft considers deterministic, checkpoint-based control the right shape for agent policy. The open question is who supplies the policies worth enforcing, and those are yours.
What Happens Next
The trajectory from here is reasonably legible. Governance becomes a standard layer in every agent platform, the way audit logging became standard in every SaaS product. Policies become machine-readable and portable — ACS is the first open specification to attempt it, and it will not be the last. Enforcement becomes explainable, because two-thirds of IBM’s surveyed tech leaders already say they are accountable for systems they don’t fully control, and accountability without explanation does not survive an audit. And architectural governance separates from runtime governance as teams discover that the two answer different questions at different layers — the separation the emerging agent infrastructure stack already shows.
Most coverage of Agent HQ and Build 2026 counted agents and benchmarked models. The durable story is the diagram underneath: a platform company drew governance as a layer of its agent stack, shipped it as products, and published an open spec for part of it. That is strong evidence for governance as the next AI infrastructure category. The part no platform will ever ship is the layer that carries your decisions — the architecture your team chose, encoded once, enforced everywhere your agents work.