Your AI Agents Need Governance Too: What Agent 365 Changes for IT

You can spend a lot of time getting an agent to answer the right question. But who owns it? Which identity does it use? And who turns it off when the project ends? Those questions deserve just as much attention.

Microsoft's 2 June Build security announcements bring agent governance further into the conversation. The Agent 365 SDK is generally available, while additional discovery and protection capabilities were announced as upcoming previews. That distinction matters: an announcement about the direction of the platform is not proof that every control is ready in your tenant.

What is Agent 365 actually for?

Think of Agent 365 as a management layer for an organization's agents, rather than another agent you ask to write an email. Microsoft's overview groups its purpose around observing, governing and securing agents.

My practical translation is simple: IT needs an inventory, someone accountable for each entry, and a way to make decisions about access. A friendly name and a successful demo are not a management process.

Before planning a rollout, check the applicable Agent 365 licensing and individual feature prerequisites. Do not assume that purchasing Microsoft 365 Copilot automatically includes every governance capability discussed at Build.

Start with an agent register you can understand

For a first review, I would record six things for every business agent: its purpose, business owner, technical owner, execution identity, connected systems, and the people allowed to use it. Add a review date and a clear decision: approved, pilot only, needs investigation, or ready to retire.

Those fields should describe the actual implementation. “Uses SharePoint” is not enough. Which sites? Does it only retrieve content, or can one of its tools also create or change something?

Imagine a fictional onboarding assistant. Answering questions from an approved employee handbook is one use case. Creating an account, assigning licenses and adding group memberships is a different one. I would review those capabilities separately, even when the user sees one chat window.

Permissions belong in the review, not in the prompt

Instructions such as “only use approved information” are useful, but I would not treat them as evidence that access is restricted. Ask the builder to show the actual connection, authentication method and permissions behind each tool.

My proposed test would use two ordinary test accounts with different access. Ask the same question, inspect the cited sources, and try a request outside the intended scope. For a tool that makes changes, require an explicit approval step and verify the outcome in the target system. Keep this testing in a controlled environment with synthetic data.

The question is not only whether the agent refuses an unsuitable request. It is whether the underlying permissions also prevent an unintended action.

Decide what happens after the pilot

Before inviting more users, agree who investigates failures, who approves new connections, and who reviews changes to the agent's instructions. Also record how to stop the agent and revoke its access. A former employee should not remain the only person who understands a production automation.

Your AI security dashboard can support the wider conversation. Pair the technical signals with decisions and named owners; otherwise you have an interesting dashboard and the same unanswered questions.

Final thoughts

I like the direction Microsoft is taking here. However, the useful first step is not enabling everything with “agent” in its name. Pick one agent, document what it can do, verify who is responsible, and test its boundaries.