Business Central 2026: Easier Copilot Agent Permission Requests and Admin Controls

The listing covers Business Central on the Web platform. It is marked General Availability and scoped to the Worldwide (Standard Multi-Tenant) cloud. Its status reads Launched, with an October 2026 availability date. That is a short description, but it touches the most sensitive part of putting AI agents into an ERP system: what the agent is allowed to touch.

What the roadmap actually says (and what it doesn't)​

The details are thin, so it helps to separate what Microsoft has published from what people will assume.

Confirmed by the roadmap metadata:

• Product: Dynamics 365 Business Central
• Capability: assign additional permissions to agents when they request them
• Platform: Web
• Release ring: General Availability
• Cloud instance: Worldwide (Standard Multi-Tenant)
• Status / timing: Launched, with general availability in October 2026

Not specified anywhere in the listing:

• Which agents can make permission requests (for example, Microsoft's first-party agents, partner agents or custom agents)
• What a request looks like in the interface, or where it appears
• Who can approve a request, and whether there's an audit trail
• Whether requests can cover any permission set or only certain ones

The wording is "assign," and that matters. Nothing in the listing says agents will get new access automatically. The sensible reading is that a human still decides, and the change makes that decision quicker to act on. Until Microsoft publishes documentation for the feature itself, that's as far as anyone can honestly go.

Keep in mind that Microsoft's roadmap calls its dates estimates. Entries can change, and they can be removed once a feature ships, is cancelled or is postponed. "Launched" with an October 2026 date is a strong signal, but it doesn't guarantee that every eligible tenant has the feature today, on October 1.

There is also a broader prerequisite. Microsoft's Business Central release-plan overview says Copilot and agents are available only to Business Central online customers. If you run Business Central on-premises, this feature isn't for you.

Section summary: This is a GA-labelled, web-only, multi-tenant cloud feature that makes it easier to grant agents extra permissions when they ask. The request and approval process has not been documented yet.

Why agent permissions are a big deal in Business Central​

The feature matters because of how Business Central treats agents. Microsoft's preview developer documentation explains that since agents are modeled as users in the system, they're assigned permissions via permission sets to govern what data, pages, and objects they can access. The same page describes a second layer, the system that controls, which human users have the ability to edit the configuration of an agent.

So an agent works much like a colleague with a user account. In an ERP system, that account can post documents, change customer records and touch financial data.

Microsoft's guidance on setting up agents applies the usual security principle: grant only the permissions necessary for the agent's intended functionality. Least privilege is easy to write down and hard to live with. Grant too little and the agent stalls halfway through a task. Grant too much and you have an automated account with SUPER-like reach, which no auditor wants to see.

Today's setup also has some friction. The same preview setup guide notes that permission sets can only be modified when the agent is deactivated. Microsoft has not said whether roadmap item 573370 changes that. Still, the documented behaviour shows why "easier" is a fair goal: under the preview flow, adjusting an agent's access is not a quick tweak.

The safety net: effective permissions are an intersection​

The most useful thing for administrators to understand before approving any agent request is how Business Central calculates what an agent can actually do.

According to Microsoft's agent permissions documentation (preview), when a user schedules a task for an agent, the task runs with the intersection of the user's permissions and the agent's permissions. The agent never exceeds the privileges of the person who scheduled the task. Microsoft's own example:

Two points follow:

1. Granting an agent a permission set doesn't let it outrank the user. If the scheduling user can't read items, the agent can't either, whatever its own permission sets say.
2. A user's broad rights don't flow down to the agent. A user who can post sales orders doesn't give that ability to an agent that lacks it.

There is one documented exception. If an agent makes a user-intervention request, the task continues with the permissions of whoever responds, and that person may not be the one who created the task. This is existing behaviour, and nothing says it is the same thing as the new "request permissions" flow. Even so, it's worth noting: who answers an agent's prompt can change what the agent is able to do.

Section summary: The intersection model is a built-in safety boundary. Approving an agent's request widens what the agent could do, but each task is still limited by the human behind it.

Multi-company tenants: scope matters​

Organizations running several Business Central companies need to watch company scope. Microsoft's documentation says:

• An agent with no permissions in a company doesn't appear on that company's role center.
• When an agent has permissions across several companies, a user can configure those permissions only in companies the user can access.
• During a task, the permission intersection considers only permissions assigned for that company or for all companies.

Standard Business Central assignment rules apply here too. Microsoft's granular-permissions guidance says that if you want a permission set to apply to more than one company, but not all companies, add the permission set specifically for each company separately. Leaving the Company field blank applies a set everywhere. That is convenient, but it's the opposite of least privilege when the requester is an agent.

Who gets to say yes?​

The roadmap doesn't name an approver role, but the existing model shows who controls agent configuration. An agent administrator is a user who has the "Configure All Agents" system permission. This permission is granted by the AGENT - ADMIN permission set. Agent administrators can see, configure, and create all agents across the companies where they have the permission assigned.

Microsoft's documentation adds that AGENT - ADMIN is included in the SECURITY permission set, and users with SUPER get the same privileges. Admins can also delegate configuration rights for individual agents without handing over the whole set, and they can revoke those rights later. For company-scoped administration, AGENT - ADMIN has to be assigned for the relevant company. In Microsoft's Cronus example, an admin assigned only for Cronus US can't configure an agent's permissions that also cover Cronus EU.

Whether the new request flow requires AGENT - ADMIN hasn't been documented. It's a sensible thing to check, though: a quick audit of who holds SUPER and SECURITY will tell you who can already change agent access today.

A practical checklist before you approve agent requests​

This is general security guidance built on Microsoft's documented permission model. It is not a published procedure for the new feature.

1. Match the request to the task. If an agent built to process payables asks for sales-posting rights, ask why before granting anything.
2. Prefer narrow, existing permission sets. Microsoft's setup guidance suggests you can assign existing permission sets to the agent, treating it like a user performing the intended tasks. Don't reach for SUPER as a shortcut.
3. Scope by company. Fill in the Company field instead of leaving it blank, unless the agent really works across every company.
4. Remember the intersection. If the agent's job is still blocked after you grant a permission set, the scheduling user may be the one missing the permission.
5. Audit your agent admins. Review who holds AGENT - ADMIN, SECURITY or SUPER, because those people can reshape agent access.
6. Developers: know that code replaces. In AL, Microsoft notes that the UpdateAccessControl method replaces any existing permission sets with the ones you provide, so custom code that "adds" a set can wipe out the previous ones.

Preview docs vs. GA feature: keep them apart​

One caution. The agent permissions documentation quoted above is labelled preview and is subject to change. It says the AI development toolkit runs only in sandbox environments, and the Agent SDK for AL is available in sandbox environments and, starting from version 28.1, also in production environments. Those notes apply to the toolkit and SDK. They don't mean roadmap item 573370 is sandbox-only or requires version 28.1, since the roadmap labels it GA for worldwide multi-tenant customers.

For context, this item shows up in the AI at Work roadmap rather than a classic release plan. Microsoft has said it will stop publishing Dynamics 365 release plans starting in September 2026, and new Dynamics 365, Power Platform and Dataverse capabilities will go to the AI at Work roadmap instead. Business Central admins who used to read the semi-annual release plans now have one more feed to watch.

The bottom line​

Granting agents more access when they ask sounds like a small convenience. In practice, it gives admins and consultants a cleaner way to fix a common problem: an agent stuck partway through a task because it lacks a permission. Business Central's intersection model limits how much damage an overgenerous approval can do, but company scope and admin rights are still the customer's responsibility. Until Microsoft documents the request experience itself, treat every agent request the way you'd treat a new hire asking for extra access, and check what it's for first.