650,000 Callable Actions Is Not a Capability. It’s an Inventory Problem.
What matters is what that number implies. For as long as ERP systems have existed, what a piece of software could do was bounded by what somebody had built — an integration, a workflow, a report. Building was the constraint, and it was slow enough that it doubled as a filter: nothing got connected to the system without somebody deciding, in the course of building it, that it should be.
That filter is gone. When the callable surface is measured in the hundreds of thousands, capability has stopped being the constraint on what an agent can do. Something else has to be.
What the Number Actually Describes
The 650,000 figure is an aggregate across seven modules, and it is considerably less granular than the pieces underneath it. Look at any one module’s own MCP server and the picture gets much smaller and much more specific: Microsoft’s Dataverse MCP server is documented as roughly 15 named tools — create a record, update a record, search, read schema, and a handful of others in that shape. The Customer Service MCP server is documented at over 90 tools. These are the kind of numbers a person can actually read through in an afternoon.
Multiply small, readable numbers like that across every module, every entity, every field-level operation an agent could theoretically invoke, and 650,000 stops looking like a feature and starts looking like what it is: an API surface area measurement. It answers “how much of the system is technically reachable,” which is a different question from “how much of the system should any given agent be allowed to touch.” Microsoft’s own materials answer the first question in detail. Nobody has built a comparably detailed answer to the second, because the second question was never anyone’s job when the system was smaller.
Selection, Not Capability, Is Now the Constraint
Here is the shift this number actually represents: the interesting decision an organization makes about an agent is no longer “can it do this.” At this scale, the plain answer to “can it do this” is almost always yes. The decision that matters is “may it do this” — and that decision now has to be made deliberately, for every agent, because the platform will not make it by default.
This is a smaller version of a familiar problem. Giving a new employee a login used to come with an implicit, common-sense boundary on what they’d plausibly need to touch — nobody handed a receptionist edit access to the general ledger, not because a policy said so, but because it would never have occurred to anyone to ask. An agent has no such common sense, and it can be pointed at all 650,000 actions as easily as it can be pointed at twenty, because the cost of reaching further is zero. The boundary that used to be implicit now has to be explicit, for every single agent, or it defaults to nothing at all.
There is also no natural fatigue to slow this down. A person expanding their own reach inside a system runs into friction eventually — a ticket to file, a manager to ask, a habit of not touching screens they were never trained on. An agent configured to call an action it has never called before pays no such cost. It either has the underlying permission or it doesn’t, and if it does, nothing about the platform pauses to ask whether it should. Scale removed the technical ceiling. It also quietly removed the social one.
Today’s Permissioning Is Shaped Around Data, Not Actions
The tooling available right now was not built with this decision in mind, and the gap deserves a precise description rather than a general one.
Dataverse’s MCP server, per Microsoft’s own documentation, “respects Dataverse security roles and row-level security,” and Microsoft states plainly that “no additional MCP-specific access controls are needed beyond standard Dataverse security configuration.” That is a statement about data: which records, which fields, which rows a given identity can see or touch. It says nothing about which of the specific callable actions available against that data an agent should be permitted to invoke. A security role that grants read/write on a customer record grants it for every action capable of touching that record — creating, updating, or anything else the record supports — because the role was designed to scope data, not to scope a list of individually approved verbs.
Copilot Studio’s data loss prevention settings tell the same story from a different angle: they let an administrator allow or block an entire connector, but they do not let an administrator allow one action within that connector and block another sitting right next to it. Microsoft’s own guidance for autonomous agents recommends scoped permissions and narrow decision boundaries as a design principle — sound advice, and advice that currently has no dedicated feature behind it. Applying it means somebody sits down, by hand, and decides.
What “the Few Dozen” Actually Requires
For any agent actually doing something in a live environment, the realistic number of actions it needs is not 650,000 or even 90. It is usually a few dozen — often fewer. A payables agent needs to read invoices, match them against purchase orders, and draft a payment recommendation. It does not need to delete a vendor record, alter a chart of accounts, or touch a module it has never been asked about. Everything past the few dozen it actually needs is exposure with no corresponding benefit.
Producing that list is not a technical task so much as a discipline nobody has been forced to practice yet. It means going through what an agent is meant to do and writing down, specifically, the small set of actions that accomplishes it — and then, just as importantly, writing down that everything else is deliberately excluded, so that the exclusion is a decision on record rather than an accident of nobody having asked.
There is a useful, cheap way to start that does not require reading a 650,000-row list top to bottom: look at what an agent has actually invoked over a real operating period, not what it theoretically could invoke. Most agents in production settle into a narrow, repeated pattern of calls almost immediately, because the underlying business process itself is narrow and repeated. That observed pattern is a far better starting draft for an allowlist than any attempt to reason abstractly about what a payables agent, in principle, might one day need. The gap between the observed pattern and the full available surface is, roughly, the size of the exposure nobody asked for.
Where This Argument Runs Into Trouble
The case against a strict allowlist is a real one. An agent boxed into twenty pre-approved actions will hit its ceiling constantly, need its list revised every time a legitimate edge case shows up, and generate exactly the kind of change-request friction that made people want agents doing this work in the first place. Microsoft is not exposing 650,000 actions by accident — flexibility is the actual selling point, and a rigid list fights against it.
The reasonable position is not “minimize the list at all costs.” It is “know what the list is, keep it deliberately short relative to what’s available, and treat growing it as something that gets decided rather than something that happens by default because nobody set a boundary.” A list that grows because someone reviewed a real need and approved it is a different thing entirely from an agent that was never given a list at all.
What an Audit of One Agent Actually Turns Up
Imagine sitting down with the team that owns a single live agent and asking for its action allowlist — the specific, finite list of things it is permitted to invoke, as opposed to the module it’s licensed under. In most environments today, that conversation ends quickly, because the list doesn’t exist as a written artifact. What exists instead is whatever the agent’s underlying security role happens to permit across every record type it can reach — a boundary shaped by a data-access decision made for an entirely different purpose, standing in for a decision nobody has separately made.
That gap is not the same failure as the other agent-governance questions worth watching in Dynamics 365 right now — one agent answering to two different oversight regimes at once, one agent’s authority becoming unclear the moment it crosses a legal entity, or a chain of agents where no single one owns the outcome they jointly produced. Those are all real, and none of them is this one. This is about scale specifically: the surface got large enough that leaving it unaddressed became, itself, a choice — made by default, by whoever didn’t ask the question first.
The 650,000 number was never the risk. An unexamined role standing in for a list nobody wrote is.
DAX Software Solutions works with Dynamics 365 teams on exactly this kind of gap — turning an implicit, data-shaped boundary into an explicit, documented one for the agents already running. Get in touch if you want a hand producing that list for an agent you already have live.