Your people can keep building Copilot agents. From October 25, the question is what your upload setting says, and who decided it.

Two triggers, and both of them describe a package that can take an action. Everything else is basic, and basic uploads sit outside this control. Worth being precise about what the definition covers: it sorts packages by the capability they carry. Where the data goes is a separate question, and a basic package can still draw on outside data, because Microsoft's own guidance describes agent knowledge as able to connect external data through Microsoft 365 Copilot connectors.

Actions are the first trigger. Microsoft's own extensibility documentation describes a declarative agent as one you configure by adding "custom instructions, additional knowledge, and actions to automate business processes", and it is specific about what actions do: "Custom actions to integrate with APIs to interact with external systems in real-time." The overview page puts the consequence in plain language, saying agents can retrieve information, summarize data, "or even take actions like sending emails or updating records."

An agent without actions answers. An agent with actions can write, send, and call. That capability is the line the control is drawn on.

The second trigger is the one most people have not thought about yet

An MCP server is the other half of Microsoft's definition, and it is newer than most governance documents in a bank or credit union. Microsoft's extensibility guidance describes the relationship this way: plugins let declarative agents in Microsoft 365 Copilot interact with Model Context Protocol servers, or with REST APIs that carry an OpenAPI description. Connecting to one gives the agent access to that server's tools, which are functions a language model can call.

Microsoft's own worked example is a remote third-party server, reached over OAuth, with a token obtained on behalf of the signed-in user every time the agent calls it. In its words, Copilot uses the registration to "obtain an access token on behalf of the signed-in user each time the agent calls the MCP server." So the agent acts with the permissions of whoever is using it, against a service outside your tenant.

Read that sentence with a governance hat on and it says something sharp. With dynamic tool discovery, the approved package does not carry a fixed list of what it can do. The agent asks the server what tools it has, and it asks at runtime. An approval recorded on the day of upload describes the package. It does not necessarily describe everything that package will be able to do next quarter, because the answer lives on a server somebody else operates.

Microsoft documents the alternative in the same breath, and it deserves equal billing: a builder can pin a fixed, curated set of tools, which settles the list at build time. So this is a choice somebody makes, and it is a property of how the plugin was built. The governance question is simply whether anyone at your institution is in a position to know which choice was made.

Picture how an advanced agent actually arrives. A loan officer who is good with technology builds something useful, because that is what Copilot invites people to do and it is genuinely how work gets faster. It connects to a system the team uses every day. It saves an hour a week per person and it spreads by word of mouth, which is a good outcome and the reason to have Copilot at all.

Now the questions an examiner asks about third-party connections start applying to it. What data does it reach. Which service is on the other end. Who reviewed it. Who approved it. Those questions were always reasonable. What has been missing is a tenant-level place to stand when answering them, and that is what the setting provides.

The useful part is the record the decision creates. An institution that picks a named Entra ID group has a documented control with a named population behind it, which is a sentence you can put in a policy and an answer you can give without going and finding out first.

Worth keeping in proportion: declarative agents run inside a managed framework. Microsoft's extensibility documentation states that because they use Copilot's own infrastructure, model, and orchestrator, declarative agents "adhere to the security, compliance, and Responsible AI (RAI) requirements for Microsoft 365." They inherit that framework.

What that framework covers is worth reading carefully, and it is the reason actions and MCP servers are singled out. When an agent calls an MCP server, Microsoft's walkthrough has the user sign in to that service separately and has Copilot obtain an access token on behalf of the signed-in user for each call. The permissions on the far side of that connection belong to the other service, and they are configured there. So the useful question about an advanced package covers two things: what it can see in Microsoft 365, and what it has been authorized to do everywhere else.

So the risk being managed here is narrower than "AI in the tenant" and more specific than it sounds. It is about packages that can act, uploaded by individuals, into an environment where somebody will eventually be asked to produce a list of them. For an institution that has approved builders and some way of reviewing what they connect to, a named group tends to fit. For one that has neither yet, no users buys time to put them in place.