With Dynamics 365 Business Central 2026 release wave 1 (tracked under Microsoft's AI at Work Roadmap ID 576841 and reaching general availability in June 2026 for Worldwide Standard Multi-Tenant web environments, aligned with version 28.2 per Dynamics 365 Lab ), Microsoft is giving IT teams and auditors a cleaner way to inspect the books. The update introduces a dedicated set of read-only APIs built directly onto the Business Central permission system, alongside a specialized permission set to govern who can call them.
Instead of logging into the ERP interface to click through user cards one by one, governance teams can now pull structured security data directly into external reporting tools like Power BI, or wire it up to intelligent agents via Microsoft Copilot Studio and the Model Context Protocol (MCP) Server for Business Central.
Why Read-Only Permission APIs Matter for ERP Governance
In any serious compliance framework—whether you are dealing with SOX, ISO 27001, or internal corporate governance—the principle of least privilege is king. Yet, proving that your ERP environment actually follows least privilege is notoriously difficult when the system's security architecture is multi-layered.
As documented in Microsoft Learn's administration and developer guides, Business Central controls access using a combination of license-based entitlements, Microsoft Entra security groups, user-defined or system permission sets, and granular object-level rights. Until recently, reviewing how all those pieces fit together required interactive sessions inside the client using pages like Effective Permissions or the Permissions Overview page. Worse, viewing other users' effective permissions inside the UI requires being assigned the SECURITY or SUPER permission sets—hardly the kind of keys you want to hand out casually to an external consultant or an automated reporting service account.
By introducing strictly read-only inspection APIs alongside a dedicated permission set specifically for using those APIs, Microsoft separates observability from administration. As Microsoft's release plan notes, this new permission set should not be granted to standard end users, but can be bundled into security-related permission sets for auditors, compliance officers, and governance automation accounts.
Key Capabilities of the Release Wave Update
According to Microsoft's roadmap and 2026 release wave 1 documentation, the read-only permission API capability centers on four core pillars:
- Permission Set Inspection: Querying the core Permission Set, its Scope (such as System vs. Tenant/User-Defined), Extension information (which app introduced the permissions), and the underlying Permission Set Object details.
- Security Group Mappings: Retrieving how Permission Sets are mapped to Microsoft Entra Security Groups (which replaced legacy user groups).
- User Mappings: Inspecting direct and group-derived mappings between Permission Sets and individual Business Central users.
- Isolated API Authorization: A new, dedicated permission set that grants access to query these permission APIs without granting broader administrative mutation rights or exposing standard users to the security model.
Under the Hood: The Automation API Security Endpoints
While the high-level roadmap announcement describes the business categories you can query, Microsoft Learn's Introduction to automation APIs documentation reveals the concrete technical structure used to inspect security and permissions in the microsoft/automation v2.0 API namespace.
Unlike the standard administrative Automation APIs—which allow delegated administrators or privileged users to POST, PATCH, or DELETE user permissions and company configurations—the security inspection endpoints strictly support GET requests. They cannot create, modify, or delete security settings, guaranteeing that an external analytics pipeline or AI agent cannot accidentally (or maliciously) alter ERP access controls while reading them.
| Endpoint Name | Returned Data & Auditing Purpose | Important Coverage Boundaries |
|---|---|---|
usersPermissions | Returns users along with their identity, state (e.g., Enabled), license type, and application information. | Includes Full User, Limited User, Device Only User, External User, External Administrator, and External Accountant licenses. |
userPermissionSets | Returns permission set assignments for users, detailing assignment type, company, security group, scope, and originating app. | Accessible via a company route, though results are not restricted solely to that company. |
accessControls | Returns access control assignments that connect users, specific companies, and permission sets. | Reflects company-specific vs. all-company assignment boundaries. |
aggregatePermissionSets | Returns permission set identifiers, names, scopes, and the originating extensions/apps. | Excludes internal permission sets whose originating app name matches the *_Exclude_* pattern. |
expandedPermissionSets | Returns granular, object-level Read, Insert, Modify, Delete, and Execute permissions inside each permission set. | Exposes the low-level permissions required for segregation-of-duties (SoD) analysis. |
How the API Request Structure Works
According to Microsoft Learn, callers query these endpoints using standard Bearer token authentication over the Automation API v2.0 route:
GET [url]https://api.businesscentral.dynamics.com/v2.0/[/url]{environment name}/api/microsoft/automation/v2.0/companies({companyId})/usersPermissions
Authorization: Bearer {token}To inspect the other facets of the permission model, an administrator or developer simply swaps usersPermissions at the end of the URI with userPermissionSets, accessControls, aggregatePermissionSets, or expandedPermissionSets.
Architectural Quirks and Traps Auditors Must Know
If you are an IT administrator or BI developer preparing to wire these endpoints into a Power BI semantic model or a Copilot Studio agent, simply pulling the JSON payload is only half the battle. Based on how Business Central's security architecture operates under the hood, there are several critical boundaries documented by Microsoft Learn that you must account for so your audit reports don't lie to you:
1. The Cross-Company Route Illusion
Notice how the API URL requires a companies({companyId}) segment? In almost every other Business Central API, passing a specific companyId scopes the returned records strictly to that legal entity. However, Microsoft Learn explicitly warns that while you access the security and permission inspection endpoints through a company route, their results are not limited to the company specified in the route.
Why does this happen? In Business Central, a permission set assigned to a user or security group with a blank company field applies across all companies in the environment. If your Power BI developer assumes that querying companies(CRONUS_US)/userPermissionSets only returns access rights for the US subsidiary, their report will misinterpret tenant-wide assignments. Always filter and group by the company field returned inside the payload (userPermissionSets and accessControls), not by the company ID used to open the door.
2. Permissions vs. License Entitlements
What a permission set grants and what a user can actually do are two different things in Business Central Online. As detailed in Microsoft Learn's Entitlements and permission sets overview, Business Central evaluates access using two layers:
- Entitlements: What objects a user is allowed to touch based on the subscription license purchased from Microsoft (e.g., Essential, Premium, Team Member) or their Microsoft Entra role.
- Permissions: What objects an administrator has granted via permission sets.
Entitlements always set the ceiling. For instance, you can assign the god-mode SUPER permission set to a user with a Team Member license, and that user will still have vastly less access than a user with an Essential license and SUPER. When analyzing expandedPermissionSets alongside userPermissionSets in an external tool, remember that raw permission sets show administrative grants, whereas effective access is still bounded by the license type returned in usersPermissions.
3. Excluded Internal Sets and Pseudonymous Partner Accounts
Two additional nuances can trip up an unprepared auditor:
- Hidden Internal Sets: The
aggregatePermissionSetsendpoint automatically filters out internal permission sets whose app name matches*_Exclude_*. Your inventory report should note this exclusion rule so compliance officers understand why internal plumbing sets aren't listed. - GDAP Partner Users: If your environment is managed by a reselling partner using Granular Delegated Admin Privileges (GDAP), those partner technicians are automatically logged in the Business Central user table when they access the environment. To protect personal privacy, Business Central masks their identities with pseudonymous names like
[email][email protected][/email]. WhenusersPermissionspulls external administrators into your Power BI dashboard, don't panic thinking you have been breached by mysterious numbered accounts—verify them against your partner's GDAP relationships.
Real-World Scenarios: Power BI and Copilot Studio
How does this actually change Tuesday morning for a Windows and Microsoft 365 systems administrator? Let's look at the two primary integration scenarios Microsoft highlights in the release plan.
Building a Segregation of Duties (SoD) Matrix in Power BI
Inside the Business Central web client, the Permissions Overview and Effective Permissions pages are great for spot-checking a single user or troubleshooting why Bob in Accounting can't post an invoice. They are terrible for cross-referencing 400 users against 50 custom extensions across five snapshots in time.
By connecting Power BI to the five read-only endpoints:
- You can ingest
usersPermissionsanduserPermissionSetsto map every human and service account to their assigned roles and Microsoft Entra security groups. - You can join that data with
expandedPermissionSetsto flag toxic combinations—such as any user who simultaneously holdsModifyorInsertpermissions on the Vendor table andExecuterights on payment posting codeunits. - Even better, you can build an automated alert for privilege escalation vectors. Microsoft Learn specifically warns administrators to exercise extreme caution with
InsertorModifypermissions on table9001(User Group Member) and table9003(User Group Permission Set), as users with access to those objects can effectively elevate their own privileges. A Power BI report queryingexpandedPermissionSetscan highlight any non-admin permission set granting direct write access to those sensitive tables in seconds.
Conversational Auditing with Copilot Studio and MCP Server
The roadmap entry also points to building agents with Microsoft Copilot Studio and the MCP Server for Business Central. By exposing read-only permission APIs to an MCP-enabled agent, an IT director or internal auditor doesn't even need to write DAX queries.
Provided the agent's identity is granted the new permission API permission set, a security analyst can ask natural-language questions like:
- "Which users have direct Delete permissions on General Ledger entries across our European companies?"
- "Show me all permission sets introduced by third-party Marketplace extensions and list which security groups have them assigned."
Because the underlying APIs only accept GET requests, the security team can let the AI agent analyze the permission graph with zero risk of the agent hallucinating a DELETE or POST call that locks out the finance department.
Step-by-Step Implementation Checklist for IT Teams
If you want to put these read-only permission APIs to work in your Business Central environment, follow a structured deployment approach:
- Verify Environment Version: Confirm your Business Central online tenant has received the 2026 release wave 1 update (generally available as of June 2026, version 28.2+ ).
- Provision a Dedicated Audit Identity: Set up a dedicated Microsoft Entra application registration (for service-to-service authentication) or a dedicated auditor account. Note that if you use delegated admin access, Microsoft Learn states the Entra application must be added to the
AdminAgentsgroup to avoid pre-consent errors. - Assign Least-Privilege API Access: Instead of granting
SUPER, assign the new permission set designed specifically for the permission APIs to your reporting identity or security-related permission set. - Ingest the Five Inspection Endpoints: Configure your data pipeline or Power BI dataflow to query
usersPermissions,userPermissionSets,accessControls,aggregatePermissionSets, andexpandedPermissionSetsvia the Automation API v2.0 URL. - Stamp Your Audit Snapshots: Because API calls return the live state of the system at the moment of the
GETrequest, always append a UTC retrieval timestamp, the tenant ID, and the environment name to the ingested dataset in your data warehouse. An audit report is only useful if you can prove when the access state was observed.
Section Summary & The Bottom Line
Microsoft's addition of read-only permission APIs in Dynamics 365 Business Central (Roadmap ID 576841) is one of those unglamorous infrastructure updates that solves a massive headache for enterprise IT and compliance teams. By exposing user states, Microsoft Entra security group mappings, company access controls, and object-level CRUD/Execute rights through safe, GET-only endpoints—and gating them behind a dedicated permission set—Microsoft makes it practical to treat ERP permissions like any other auditable dataset in Power BI or Copilot Studio. Just remember to account for cross-company route behavior and license entitlement ceilings when building your dashboards, and your next quarterly audit might actually finish before lunch.