Microsoft Made a Decision Your Company Didn't

The form has nine fields. Eight of them were easy.

The administrator got stuck on the first one.Authorized by.The cursor sat in the empty box while she checked the ticket queue, then the change calendar, then an email folder going back to April.

The built-in Teams agents had been allowed in her tenant since the rollout reached it two weeks ago. Facilitator, Channel Agent, Copilot Agent. Every Copilot-licensed user, about nine hundred people in her organization, could invoke them in chats, channels, and meetings without asking anyone.

There was no request ticket. No approval thread. Not one email where a person asked for these agents and another person said yes.

The agents were available because the default said so.

So here is the question this edition answers.When the vendor makes the permission decision, what does your authorization record actually record?

Start with what shipped. Microsoft announced the change in Message Center post MC1387573 in mid-June, tied to Microsoft 365 Roadmap ID 564766, with general availability running early-to-mid July 2026 across Worldwide and GCC tenants. The roadmap wording carries the load: these agents areenabled by default for licensed users.

Decode both halves, because both get misread. Licensed means Microsoft 365 Copilot-licensed, so the population is your Copilot estate, not every Teams user. Enabled means allowed: a user still invokes the agent, and Facilitator still gets toggled on per meeting.

Then there is the second sentence, and it deserves more attention than the first. Per MC1387573, built-in Teams agentswill no longer be governed by the org-wide app setting for Microsoft apps.They get their own page: Teams admin center, Teams apps, Built-in Teams agents.

Your other controls still exist. Per-agent allow and block, user and group scoping, the license gate itself. What changed is the baseline, because the setting many organizations treated as their AI policy proxy no longer decides whether these agents are allowed.

Every policy panel has these two switches. The third one is new. Who set it to Allow?

Sit with that. A lot of organizations spent the past year encoding their AI posture into that org-wide setting, believing the configuration was the policy.

Some needed four meetings and a steering committee to agree on the words. One engineer translated them into a settings page in an afternoon.

That page now governs everything in the tenant except its newest class of AI. The new class arrived already permitted, on a page most admins have not opened yet.

And Microsoft's rollout notes contain one more sentence worth reading twice: no action is required before rollout. In twenty-six years of enterprise change records, that phrasing is reliable in one way. The changes requiring no action before rollout are the ones generating the most action after it.

Every deployment record ever filed has a requester. A person wanted the thing, a person approved the thing, and the form holds both names. There is no dropdown value for "the platform decided."

The Accountability Assumption is the implicit belief that accountability for an agent's behavior lives with the vendor or the platform, somewhere upstream, with someone else. Every enterprise carries a version of it.

This rollout is the purest expression of it I have seen. The vendor did not just hold the assumed accountability this time. The vendor made the permission call.

Which is where this stops being philosophical, at least for anyone who answers to an examiner.

The record that eventually gets written for these agents will hold two dates. One is the date the tenant began allowing them, which Microsoft set. The other is the date someone in your organization reviewed that permission and chose to retain, restrict, or disable.

An examiner does not need a model failure to notice the gap. The chronology is enough, and reading it takes about four seconds. AI agents were permitted in a regulated environment for weeks before anyone accountable looked.

An old temptation waits right there, the one internal audit has chased since paper files. Make the paperwork remember a decision that never happened. That temptation now has a rollout schedule.

The permission decision did happen. Just not in your building.

The fix is small and it is specific. Add a default-state review clause to the Agent Authorization Document. Three fields.

Origin: permitted by the organization, or inherited from a vendor default. Reviewed by: a name, with a date. Decision: retain, restrict to defined groups, or disable.

The origin field is the one that matters. It makes the record honest about which permissions your organization granted and which ones it inherited. A record written after go-live gets marked retroactive, both dates visible, so the document tells the truth about the sequence instead of flattering it.

The whole exercise takes one afternoon.Open the Built-in Teams agents page, review Facilitator, Channel Agent, and Copilot Agent against your Copilot-licensed population, and create the clause for each one.

Most reviews will land on retain, and that is fine. The defaults may be perfectly reasonable. The record exists to prove a named person looked.

One footnote for government tenants: the admin page ships to GCC while Teams meeting Copilot agents are not yet available there, so in some environments the control surface has arrived before the agents it controls. File that under sentences nobody expected to write about enterprise software.

Microsoft built a better control surface than the setting it replaced. What no vendor can ship is the decision to use it.

Right now, the most accurate answer to who permitted the newest agents in your tenant is: nobody in your building.That stays true until a name goes in the first field, and every week it stays true, the two dates drift a little further apart.