Microsoft Agent 365: governing Business Central agents in production

Governance begins before the first business action

A Business Central agent can produce a useful answer and still be unsafe to operate. Who owns it? Which company may it access? Can it read a purchase order, amend it or post it? What happens when its sponsor leaves? For a production purchasing assistant, these questions are acceptance criteria alongside answer quality. Governance is the operating discipline that connects ownership, authorised access, evidence, monitoring and retirement. It should be designed before the agent is allowed to change business records.

What Microsoft Agent 365 does

Microsoft Agent 365 is Microsoft’s central control plane for observing, governing and securing agents across supported Microsoft and connected third-party platforms. Its registry and administration experience help organisations see what agents exist and manage their lifecycle. Microsoft describes three connected responsibilities: observe agent activity and health; govern ownership, access and lifecycle; secure identities, data and interactions. It became generally available for commercial customers on 1 May 2026. For a Business Central agency, its value is a shared administrative view of the agents around the ERP—not another place to write AL code.

Where Copilot Studio and Foundry fit

Copilot Studio and Microsoft Foundry are places to build and operate agent solutions. Agent 365 supplies oversight across supported integrations; it does not replace their engineering environments. A purchasing assistant built in Studio still needs connector and environment policies. A custom Foundry agent still needs project access, operational monitoring and release controls. Business Central remains responsible for its company permissions, business validation and posting rules. In our recommended architecture, the governance layer sits around the complete process: employee request, agent, authorised tool, Business Central operation and audit evidence.

Start in the Microsoft 365 admin center

Sign in at admin.microsoft.com using the customer’s authorised administrative account, then open Agents → Overview and the agent registry. Review discovered agents, ownership gaps, pending requests and risk signals. Check the licence and role before assuming an unavailable control is a configuration failure. Dashboard visibility does not itself grant permission to manage an agent. Begin a Business Central pilot by locating its registry entry, confirming the owner and audience, and documenting the connected environment. Check the supported onboarding route if a custom agent is absent; the registry is not guaranteed to discover every unpublished or disconnected runtime.

Give the agent an identity and a responsible person

Microsoft Entra Agent ID provides identities for agents, with governance capabilities such as sponsors and access packages. A sponsor is a human responsible for access and lifecycle decisions. For an illustrative purchase-exception agent, name a purchasing process owner and a technical maintainer, then record the actual identity used by every Business Central connector or API. Do not assume its agent identity automatically replaces an existing connector credential. Where supported, request narrowly scoped access with an expiry and review process. Test owner departure and access revocation as part of handover.

Protect business data and investigate behaviour

Agent 365 works with Microsoft Purview for data protection and compliance, and Microsoft Defender for threat detection and investigation. Microsoft Entra supplies identity and access controls. Their effectiveness depends on supported integrations, licences and configuration. For a Business Central assistant, map supplier records, purchase documents and retrieved policies to the controls that actually apply. Define which activity must be retained, who may inspect it and how an incident reaches the responsible team. A registry entry is not proof that every payload is inspected or that every Business Central field is automatically protected by a sensitivity label.

A worked Business Central governance design

Consider an illustrative supplier-delay assistant. It reads an approved supplier message, retrieves the purchase order for one authorised company and proposes a revised receipt date. Its business owner is the purchasing manager; its technical owner maintains the integration. Its initial permission is read-only. A separate authorised action updates the order only after the required approval. Production release requires tests for a wrong company, an unknown order, a malicious attachment and a revoked identity. The evidence should connect the request, retrieved record, proposal, approval and final operation. Agent 365 supports the administrative oversight; the application and Business Central must enforce those business boundaries.

How to introduce it without losing control

Start with one sandbox purchasing process. Inventory its agents and tools, assign owners, and classify each action as read, propose or change. Confirm the agent’s supported registration and identity path, then configure the applicable governance policies. Test restricted access and failures before approving a small production audience. Review activity, exceptions and permission changes during the pilot. Agree the conditions for expanding access and for withdrawing it. This is our recommended implementation sequence, not a claim that a single Agent 365 switch configures every downstream system.

Blocking an agent is not always stopping its runtime

Microsoft’s lifecycle documentation distinguishes actions by agent type. For Foundry agents, blocking access in Microsoft 365 can affect availability in Copilot Chat without stopping the underlying infrastructure; supported start-and-stop actions need the appropriate Azure role. For a Business Central integration, test every entry point: chat, API, scheduled trigger and connected workflow. A useful incident plan identifies how to stop further business actions, revoke the relevant access and reconcile any in-flight operation. Do not assume that hiding an agent from users cancels work already running.

Licensing and prerequisites to check

Microsoft lists Agent 365 as a standalone subscription for eligible Microsoft 365 subscriptions and as included in Microsoft 365 E7. Some foundational registry and lifecycle capabilities are included with existing Microsoft plans; premium capabilities have additional requirements. Entra governance for agent identities requires Agent 365 with at least Entra P1 or Microsoft 365 E3, or the relevant E7 bundle. Check the current service description and customer entitlements before purchase. Business Central licences, Copilot Studio consumption and Foundry usage remain separate considerations. Buying Agent 365 does not make those workloads free or automatically give an agent ERP access.

What production readiness should demonstrate

For the purchasing assistant, ask for evidence of an accountable owner, a bounded business purpose, correct company access, approved tools, protected data, traceable operations and a tested stop procedure. Include source freshness and grounded-answer tests for RAG, alongside permission and approval tests for actions. Repeat the checks after a model, connector, policy or permission change. Agent 365 makes governance more visible and manageable; production confidence comes from verifying the complete Business Central process.

Microsoft sources and further reading

• Microsoft Learn: Agent 365 overview and availability
• Microsoft Learn: admin center access, registry and governance tasks
• Microsoft Learn: Entra agent identities, sponsors and prerequisites
• Microsoft Learn: Agent 365 plans and feature availability
• Microsoft Learn: governance and lifecycle actions by agent type
• Microsoft Learn: Copilot Studio security and governance
• Open the Microsoft 365 admin center