✅ BenefitsLeadershipIntermediate✨ AI-assisted

Benefits of an Agent 365 Off Switch for Foundry Agents

WittyTech Daily··4 min read
#agent 365#microsoft foundry#ai governance#incident response

A Foundry agent starts misbehaving at 2 a.m., its developers are asleep, and the only people awake are in IT. The Agent 365 Foundry controls in the Microsoft Admin Center now cover that night: enable and disable actions for Foundry agents are generally available, so an admin can decide whether an agent runs across the organization without involving the developers. Below are five benefits, and where the feature is thinner than the headline.

What the Agent 365 Foundry controls actually do

In the Microsoft 365 admin center, open Agents > All agents. Every Foundry agent you publish appears in the Agent 365 registry automatically. Select one and you can Disable it, which takes the agent endpoint offline while the agent definition and its versions stay intact, or Enable it again.

Per Microsoft's Foundry agent governance guide, the agent runs only when both the developer configuration and the admin governance state allow it.

Five benefits for leaders and on-call admins

1. Containment in minutes, with no developer in the loop. Picture an agent pasting customer records into its replies. Instead of a ticket, a wake-up call and a hunt for the right project, an admin picks the agent and chooses Disable. Microsoft says an agent's effective state can take up to 10 minutes to reflect a change, so write 10 minutes into your incident runbook instead of assuming instant.

2. One inventory for IT and compliance. The registry lists agents built in Foundry and Copilot Studio, agents registered by administrators and shadow agents discovered in the tenant, and it tracks ownership for attestation workflows. When compliance asks which agents exist and who owns them, that is one list instead of a tour of Azure subscriptions.

3. Separation of duties. Developers keep the Enable toggle for their own configuration, but Microsoft states that Enable is separate from governance Unblock and doesn't remove an Entra restriction. Tenant-wide governance sits with Entra Global Administrators and AI Administrators, so for newer agents the team that built an agent can't quietly switch back on what governance turned off.

4. A reversible action that keeps the evidence. Disable is not delete. The definition and versions stay put, so reviewers can inspect the agent as it was when it misbehaved. The Azure resource's Activity Log shows who recently took management actions.

5. The same switch works from a terminal. The Foundry docs expose disable and enable as data-plane REST actions, so an on-call engineer who lives in a shell can use the same lever. This flips the developer configuration layer.

az rest --method POST \
  --uri "https://<account-name>.services.ai.azure.com/api/projects/<project-name>/agents/<agent-name>:disable?api-version=v1" \
  --resource https://ai.azure.com

Swap :disable for :enable to turn it back on. The --resource https://ai.azure.com flag makes az rest request a token for the right audience, and you need at least the Foundry User role on the resource.

The catches: rollout, older agents and when to skip it

Rollout is uneven. The announcement covers enable and disable only. It says block, unblock, delete, restore and owner reassignment "continue to expand". Microsoft Learn already describes several of them, but the pages disagree: the admin center actions page says blocking a Foundry agent only affects its availability in Microsoft Copilot Chat, while the governance guide says Block disables the agent. Test each action in a non-production tenant before it goes into a runbook.

Older agents are a special case. Foundry enforces admin state for agents created on or after October 23, 2026 at 16:00 UTC. Earlier agents bypass Entra block and delete through a legacy exception, though the docs say that exception doesn't override disabling the agent in Foundry. For those agents, Disable is your lever.

Roles and licensing need checking. Entra roles don't automatically grant Azure resource access, so check who holds the Foundry User role. The Agent 365 integration page also says data flows from Foundry to Agent 365 only after admin enablement, and lists a Microsoft 365 Copilot license and Frontier preview enrollment as requirements, so confirm both against your tenant.

When it's not worth it. If you run two agents in one team and the same people own the Azure project and the admin center, the Foundry portal's status toggle gives you the same off switch with no extra layer.

If you deploy AI in production, decide before launch who can turn each agent off, then rehearse it once so the 10-minute delay isn't a surprise during a real incident.

← More in Leadership