Every business unit with a corporate card and a bright idea has been able to stand up an AI agent that reads mail, queries data, and calls tools—and until now, nobody in the platform team had a supported way to say no. That changed this month. Microsoft moved enable/disable controls for Foundry agent objects to general availability inside the Agent 365 governance surface in the Microsoft Admin Center, marking the first GA-grade governance capability for the platform.
It is also, let’s be honest up front, a light switch. A very important light switch. But if you were expecting the full Azure governance stack to arrive fully formed, put the champagne back in the fridge.
First, what a Foundry agent actually is
Microsoft Foundry is Azure’s platform for building and orchestrating AI agents—the models, the tool-calling plumbing, the memory, the connectors to your data. An agent is the unit that matters here: a named, deployed thing that takes a goal, decides on steps, and calls tools or APIs to get there. Think of it less like a chatbot and more like a service principal with initiative. It can read a mailbox, hit a database, call an internal API, and burn tokens and compute the entire time.
Copilot and Agent 365 are the consumption layer on top. When a business user “adds an agent” to their Copilot experience, or a team publishes a custom agent for a workflow, the thing being added is a Foundry agent object. That’s the connection worth understanding: the friendly Copilot tile in someone’s sidebar and the token-hungry orchestrator running on Azure are the same object, seen from two ends.
The reason this needs governance is the same reason service principals need governance. An agent is an identity with permissions, a cost profile, and a data-access footprint. Left ungoverned, agents multiply exactly the way SharePoint sites and Power Platform environments did—enthusiastically, invisibly, and with nobody owning the cleanup. We have watched this movie before. Shadow IT, shadow SaaS, shadow low-code, and now shadow AI. Same plot, faster villain.
What the switch does—and only that
Enable/disable is exactly what it says. A tenant administrator can toggle whether a specific Foundry agent is available for use across the organisation. Enabled means users can add and run it. Disabled means the object stays registered but nobody can invoke it. It is a tenant-scoped on/off—a circuit breaker, not a dimmer.
The right mental model is the enterprise-application toggle in Entra, or a resource provider you disable at the subscription. You are not deciding who gets the agent or how much they can spend or what it can reach. You are deciding whether the agent exists as a usable thing at all. That single bit of state is genuinely useful—a disabled agent can’t leak data, can’t run up a bill, and can’t be quietly adopted by a department that read about it on LinkedIn. When a security review flags an agent, or a vendor connector turns out to be sloppier than advertised, you now have a supported way to pull the plug that doesn’t involve deleting anyone’s work or filing a ticket with a product group.
The controls live in the Agent 365 governance area of the Microsoft Admin Center rather than in the Azure portal. That placement tells you something about how Microsoft sees this: it’s positioned as a tenant administration surface alongside the rest of the Microsoft 365 admin experience, not as an Azure control-plane resource you’d manage with az or wire into a landing zone. As of GA the management path is the portal UI. There is no documented Azure Policy definition, no ARM/Bicep resource type, and no CLI verb for it yet—so resist the urge to bake it into your infrastructure-as-code pipeline. It isn’t there.
On who can flip the switch: this is tenant-level administration, which means it sits with high-privilege directory roles rather than with a scoped, agent-specific RBAC role—because that scoped role doesn’t exist yet. Treat it as Global Administrator territory until Microsoft publishes a least-privilege alternative, and check the current licensing prerequisites for Agent 365 in your tenant before you assume the blade is even present. That’s the honest answer, and the honest answer is the whole point of this piece.
The five things this does not do
Here is where I’d rather tell you the truth than sell you the roadmap.
- No per-user or per-group RBAC. It’s all-or-nothing across the tenant. You cannot say “finance gets this agent, contractors don’t.” Compare that to Azure RBAC, where you’d scope a role assignment to a group at a resource scope and move on. That granularity isn’t here.
- No cost allocation or budgets. Agents consume tokens and compute, and that consumption is the single most predictable way this bites you in six months. There is no per-agent budget, no chargeback tag, no Cost Management alert wired to agent activity. You can turn an agent off after it spends your money, not before.
- No centralised audit log for the governance action itself. If you want a defensible record of who disabled which agent and when, you’re relying on whatever tenant admin logging you already trust—not a purpose-built audit trail for agent lifecycle events.
- No Azure Policy integration. This is the big one for anyone running a mature landing zone. There is no declarative “deny agents that reach these data sources” or “audit agents without an owner tag.” Everything is manual, in a UI, done by a human who remembered to do it. Declarative enforcement is how Azure governance scales; agents aren’t in that model yet.
- No delegation. Because there’s no scoped role, you can’t hand agent governance to a platform team without also handing them the keys to the tenant.
What to actually do with this now
Zero Trust for agents rests on the same three pillars as Zero Trust for anything: verify explicitly, enforce least privilege, assume breach. This GA release touches exactly one of them—it gives you an explicit enforcement point to deny by default. So use it that way.
My concrete advice for the next quarter: inventory every Foundry agent already registered in your tenant, because you almost certainly have more than you think. Default to disabled for anything without a named owner and a stated business purpose. Enable deliberately, one agent at a time, the same way you’d approve a new enterprise application. And keep your real least-privilege and cost controls where they still live—on the Azure resources, managed identities, and data connectors the agents call through—because that’s the blast radius the tenant toggle doesn’t touch.
The switch is a floor, not a framework. Microsoft shipped the part that was easy to ship and genuinely needed. The parts that make governance actually govern—scoped RBAC, budgets, audit, Policy—are the parts still on the whiteboard. Build for the day they arrive, and until then, keep your finger near the off switch.