D365 agent governance: 4 checks before autonomy

The symptom: an agent running with standing access

In most projects I see, an agent gets switched on in a demo with the access of whoever configured it. It works, the demo is convincing, and that access just stays there. The problem doesn't show up immediately: it shows up when the agent starts acting on real processes and no one knows anymore what permissions it's running with or who is accountable for what it does.

On D365 F&SCM the stakes are concrete. An agent that recalculates stock, proposes a reorder or moves a delivery date touches data that ends up in the books and on the shop floor. If it holds standing admin access inherited from a user, the risk surface is no longer the single mistake, but everything that identity can do, always, with no expiry.

The symptom is almost always the same: a powerful, useful agent with no guardrails at all. That's not a model problem. It's an identity governance problem, and it has to be addressed before you move from pilot to production.

What actually changes with Agent 365

Until recently an agent almost always acted by delegation: it used a user's credentials and inherited their permissions. If I couldn't do something on D365, neither could the agent. That was a limit, but also an implicit safety net.

With Agent 365, now generally available, the model changes: an agent can have its own identity, credentials and permissions. It no longer necessarily acts in someone's place, but as an entity of its own. That's a real jump in capability, because it lets the agent work autonomously even when the user isn't there. But it's also a jump in accountability: an identity that acts on its own needs the same controls you'd give a new hire, not a badge that's valid forever.

The practical point is this: Microsoft has extended to agents the identity governance tooling that already exists for people. Access packages with scoped, time-bound permissions through Entra ID Governance, an accountable owner, action audit with Purview, execution in isolated environments. You don't need to invent a new governance model: you need to apply the one you already use for users to agents, explicitly.

The four-check framework

These are the four checks I verify before handing an agent the keys to an F&SCM process. They're not optional: if even one is missing, the agent stays in pilot, it doesn't go to production.

• Own identity or delegation? Decide deliberately whether the agent acts on a user's behalf or with its own credentials. Those are two different levels of risk: delegation inherits and limits, an own identity frees but exposes. Defaulting to an own identity just because it's more convenient is the most common mistake.
• Time-bound permissions, not standing ones. Use Entra ID Governance access packages to grant the agent only the permissions it needs, with an expiry. An agent that recalculates stock doesn't need to touch payments, and doesn't need to be able to do it forever.
• An owner with a name. Every agent must have an accountable, identifiable owner, not a generic team. It's the person who answers for what the agent does, who shuts it down if something goes wrong, and who reviews its permissions on a schedule.
• Auditable and isolated. The agent's actions must be verifiable after the fact with Purview, and execution must run in isolated environments with controlled network traffic. If you can't reconstruct what an agent did and in what context, you don't have an autonomous agent: you have an unmeasured risk.

When not to give an agent autonomy

Good governance doesn't mean giving everything autonomy. In several cases the right answer is to keep the agent in suggestion mode, with a human approving. I do that when the action is hard to undo, when the upstream process is messy, or when there's still no reliable track record of behavior.

An agent that autonomously changes a delivery date for a strategic customer, or releases a production order, touches decisions that are better routed through human approval until trust is built. And if the underlying process is chaotic, autonomy doesn't fix it: it just exposes it faster. The agent amplifies the process it finds, good or bad.

There's also an organizational maturity limit. If you don't yet have a clear owner, a working audit and a fast way to revoke permissions, autonomy is premature no matter how good the model is. In those cases the right control is to slow down, not speed up.

Where to start

You don't need a reorganization. You need to apply the four checks to the first agent you're about to put into production, before you turn it on. Start with a single, well-scoped, low-impact process, and use it as a test bench for your governance, not just for the agent's capabilities.

Concretely: inventory the agents already running and check what permissions they hold today, assign each one a named owner, replace standing access with time-bound access packages through Entra ID Governance, and turn on audit with Purview before you widen the scope. Only once those four points are in place does it make sense to move from suggestion to autonomous action.

The question to keep on the table is simple: does your next agent on D365 already have an owner and a time-bound permission, or is it still running with standing access? If the answer is the second one, the work to do isn't on the model. It's on governance.