How do enterprises control what agents can do?

Illustration showing governed and ungoverned tool access for enterprise AI agents. Users interact with an enabled agent connected only to approved, scoped tools, showing that admins can review and approve capabilities. A blocked path shows a disabled agent or denied tool access, indicating that risky capabilities can be shut off centrally. The key message is that agent risk is defined by tool permissions and actions, so governance should control which tools are available and enforce boundaries at the tool level.

An agent is only as capable, and only as risky, as the tools it can use. On its own it can reason and respond, but it can't retrieve a record, send a message, or update a system until it's given the means to act. As agents move from prototypes into real workflows, each tool carries its own scoped permissions, so the set of tools an administrator approves is what determines the work an agent can actually do on a user's behalf. Agent 365 makes that set something an organization decides deliberately rather than inherits.

Where the risk concentrates

An agent that can retrieve a document is not the same as one that can send mail, delete records, or reach a customer system. Risk comes from what a tool can touch and what it can do, not from the agent's existence alone. A single tool often bundles several of those actions into one connection.

Without a governed view of tools, an organization takes on that risk without being able to see it: which capabilities are in use, who published them, and whether anyone ever approved them.

What counts as a tool

Four different-looking things all grant an agent the same kind of reach, so governing only the familiar ones leaves gaps. A tool is any capability an agent uses to reach data or take action in another system, and in practice that means connectors, Model Context Protocol (MCP) servers, skills, and plugins. Together they're the difference between an agent that can describe a task and one that can complete it.

This surface has evolved quickly. Applications reached data through APIs, then through connectors that standardized the pattern. Agents reach it through MCP servers, an open standard that exposes a system such as SharePoint or a line-of-business customer relationship management (CRM) system as actions an agent can call. A skill is a single packaged ability an agent can perform, such as filing an expense or summarizing a case. Plugins go a step further, bundling skills with MCP servers so the plugin can select the right capability for a task.

How Agent 365 governs tools today

Agent 365 brings agentic tools into the Microsoft 365 admin center, the same place it governs agents, so tools are managed the same way. An administrator can see the tools available across the organization, understand what each one can do, and approve them individually. Custom and bring-your-own MCP servers enter the same approval and observability model, so internally built capabilities don't become invisible infrastructure.

With Agent 365, that control operates at the tool level as a single switch. When Microsoft Defender detects a tool moving data outside the organization, an administrator blocks it once in the Microsoft 365 admin center, and every agent that depends on it loses that capability immediately, without anyone having to work out which agents used it or change them individually.

That switch is deliberately absolute. A widely used MCP server can carry several capabilities that many workflows depend on, and blocking it withdraws all of them, not only the one that caused concern. When a tool is actively dangerous that is the right trade, and it is the reason finer-grained control matters.

Where tool control goes next

Tool-level control is the starting point, and Agent 365 is working to extend it in two directions. The first is finer granularity: governing individual functions within a tool, so an administrator could allow an agent to retrieve mail while blocking send or delete, keeping the capabilities that create value and removing only the ones that carry risk. The second is discovery: surfacing tools that were never centrally registered, so unmanaged capabilities come into view before they become a liability.

Governed this way, agent capabilities stop being a hidden risk surface and become a managed enterprise asset. That is what gives leaders the confidence to let agents act on their users' behalf: with Agent 365, the boundary is one the organization set and can change.

Related content

• Agent tools overview