A Dynamics 365 agent can do anything the user can. Close that gap before you turn it on.

Microsoft's ERP Copilot plugin is generally available, and the agentic future it promises for Dynamics 365 is real and close. But there's a sentence in the governance detail that every Finance and IT owner should read twice before activating anything:

An agent acting for a user can currently do anything that user can do.

That's not a flaw Microsoft is hiding — it's in the coverage of the GA announcement. The plugin gives each user's full permissions to an agent that then acts on natural-language instructions. Microsoft says new role-based access controls "will allow organizations to define additional restrictions" when a user operates through Cowork or agents — but gives no availability date and no preview status.

Read plainly: the capability to act is here now; the capability to constrain the action is not. The gap between those two is where the risk lives, and it's wide open today.

Why this is bigger for an agent than for the user

A person with broad permissions is self-governing — they know not to post the entry, raise the PO, or release the payment without the right check, because they understand consequence and context. An agent doesn't. It has the permissions and it follows the instruction.

So the same broad role that was tolerable on a human becomes a real exposure on an agent that:

• acts on a natural-language instruction that may be ambiguous or adversarial,
• acts fast, at volume, without the pause a person takes,
• and, until Microsoft ships the controls, inherits the whole permission set, not a scoped-down one.

If your role design has drifted over the years — and in most long-lived Dynamics estates it has — that drift is now an agent's blast radius.

The practical move: fix the architecture first, agents second

The advice from the GA coverage is blunt and correct: organizations whose role design has drifted should fix that first. Here's the shape of what "fixing it first" actually means, in Dynamics terms:

1. Audit the roles agents will inherit. Map what each role can actually do today versus what it was meant to do. The question isn't "is this role fine for a person" — it's "is this role safe handed to an agent acting on instructions."
2. Re-establish segregation of duties. The agent must not be able to both create and approve the same transaction. If a human role quietly accumulated both, that's the first thing to split.
3. Put approval before posting, by design. The safe pattern for an ERP is the one Microsoft's own flagship demo uses: the agent prepares the work — pulls the RFQ lines, scores the bids, drafts the recommendation — and a person approves before the PO is created and the award email goes out. Make "a human approves anything irreversible" an architectural rule, not a hope.
4. Scope the agent, don't just scope the user. Where a process genuinely needs tighter limits than the user's role, build the constraint at the action layer — expose only the specific, governed operations the agent is allowed to perform, inside the security roles, rather than handing it the full surface. (This is where governed MCP Action tools earn their place.)
5. Keep the audit trail. Every agent action traceable to the instruction, the approval, and the record it touched. In a regulated or audited environment, that trail is not optional.

None of this is anti-agent. It's the opposite — it's what lets you turn agents on confidently, on the exact day the capability lands, instead of pausing a rollout while the business nervously watches what the agent might do.

Where Microsoft's controls land, and where you still need to build

Microsoft is building toward this — role-based controls for agents, and "business skills" that let you define procedures as governed, reusable context managed through security roles. That's the right direction and worth waiting for.

But two things remain yours to own regardless of Microsoft's roadmap: the state of your role design (no vendor can un-drift your permissions for you), and the controls on your own customizations — the X++ and ISV logic a generic agent can't safely touch (see why agents stumble on customized Dynamics 365 F&O). Those are the parts that need an engineer who is fluent in both the AI and the ERP.

If you're planning to activate agents on Dynamics 365 and want the governance architecture sorted before you do, tell us what your role design looks like today — the first conversation is about whether you're ready to turn agents on safely, and sometimes the honest answer is "fix the roles first."