Your Security Roles Are Now Your AI Control Model

“Agent-ready,” according to Microsoft’s own definition from July 2026, means agents “can connect to and operate inside the transaction layer of the business application, using the same data models, rules, permissions, security guardrails and audit trails as any user of the system.”

The same announcement puts it even more plainly a few paragraphs later: when an agent qualifies a lead, adjusts a forecast, or processes a transaction, “it runs within the Dynamics 365 transaction layer, using the same data, rules, permissions, and audit trails already in place.”

Read that as reassurance and it’s a reasonable way to read it. Nothing new had to be built. The controls a finance or operations team already trusted are the controls the agent now runs under.

Read it as a warning and it’s just as accurate. Whatever your security role design already permits, an agent now does. Not a new control — an inherited one, including every weakness that was already sitting quietly inside it.

What “Same Guardrails” Actually Means, Technically

A human silhouette and a robotic arm both reach toward a shared glowing credential badge, each fitting into a matching receiving slot, showing the same access token accepted equally by both

An agent doesn’t get a parallel permission system built just for it. Per Microsoft’s own agent-identity model, an agent is provisioned a dedicated identity — an Entra Agent ID, paired with a corresponding user record in Dataverse. An administrator then assigns that identity a security role: the same infrastructure, the same role definitions, the same duties and privileges, the same combinations that were designed, at some point, with a person in mind.

That detail carries more weight than it first appears to. It means a role isn’t evaluated any differently depending on who — or what — is going to occupy it.

A role that has always technically allowed a single identity to both create a vendor and approve that vendor’s payment was exactly as risky yesterday as it is today. Only humans could hold it then. An agent can hold it now. Nothing about the role changed. What changed is who might actually exercise every permission it grants, every time, without exception.

The Weakness Was Always There

A single keyhole mechanism branches into two lever paths from one shared credential slot, one path bright and polished from frequent use, the other faintly dusty and dim from rarely being touched

Dynamics 365 Finance and Operations has a real, named feature for this: segregation of duties rule sets, which let an organization define which combinations of duties and privileges conflict and flag roles that carry both. It is a genuine, mature piece of tooling.

It is also, per Microsoft’s own documentation, not automatically enforced. Compliance with a segregation-of-duties rule isn’t verified the moment the rule is created. Validating a role against the ruleset is a separate, deliberate action — somebody has to run it, and re-run it, on their own initiative. A role can carry a real conflict for years without anyone noticing, because the tooling that would catch it doesn’t watch continuously by default.

For a human occupying that role, the conflict mostly stays theoretical. People are inconsistent in ways that, by accident, function like a compensating control. Somebody who technically could approve their own vendor payment usually doesn’t think to. Or they don’t get around to it. Or a colleague glances at the screen out of habit. Or they simply move slower than the conflict needs to become a pattern.

None of that hesitation is written down anywhere. It was never a control — just a side effect of the role being occupied by a person with other things on their mind. That side effect is the only reason a lot of latent SoD conflicts have never produced a real incident.

What Changes at Machine Speed and Volume

The same keyhole mechanism with two lever paths, now both equally bright and glowing amber with motion-blur streaks showing rapid repeated cycling on both paths at once

An agent inheriting that same role has none of that hesitation. There was never anything in the role definition producing it in the first place. If the role permits both halves of a conflicting pair of duties, an agent working through its queue will exercise both — whenever the workflow presents the opportunity.

Not out of malice. Not because of a design flaw. Just because permission is permission, and executing quickly and consistently isn’t a violation of how the agent was built. It’s doing exactly what it was authorized to do, over and over, at whatever pace the workload demands.

That is the actual shift. A conflict that surfaced rarely, by accident, in a role occupied by a person becomes a conflict that fires reliably, as a pattern, in a role occupied by an agent. Not because the role got worse. Because the thing standing between “technically permitted” and “actually happens” was never a control — it was a person’s inconsistency. The agent doesn’t come with any.

Take a plausible, illustrative version of this rather than a documented incident. A role built years ago for a small operations team lets its holder both create a new vendor record and approve that vendor’s first payment. Reasonable enough at the time — the team was three people who all knew each other’s work, and a second set of eyes happened informally, even though nothing forced it.

Hand that same role to an agent processing a batch of new vendor onboarding requests. There is no colleague glancing at the screen. No habit of routing the unusual case to somebody else. No faint discomfort that slows a person down before they approve their own setup.

The agent creates the vendor and approves the payment because the role lets it — every time the batch contains that pattern, for as long as nobody changes the role.

Why This Needs Testing Ahead of Go-Live

Most agent rollouts treat security and governance as something to firm up in parallel — or to audit once the agent is already live and producing results. That ordering makes sense for problems that are new.

It makes much less sense here. The problem isn’t new. It’s a role design decision made years ago, for an org chart that assumed every occupant of that role would be a person whose behavior quietly bounded what the role’s permissions actually implied.

Once an agent can occupy the same role, that bounding assumption is gone. The role itself needs re-examination before anything runs against it in production — not as a follow-up item, but as a condition of go-live.

The practical difference is sequencing. Testing the role an agent will actually inherit before the agent starts working is a small, specific task. Discovering after three months of live operation that the role always permitted something nobody meant to permit is a much larger one — and by then it has a transaction history attached to it.

Where This Overstates the Risk

The fair objection: not every role needs this scrutiny. Treating full SoD re-validation as mandatory before every agent deployment would recreate exactly the kind of heavyweight project agentic tools were supposed to help organizations avoid.

Most roles were built with reasonable care. Most agents are scoped to a narrow slice of a process. Re-testing an entire duties matrix because one agent needs one role is disproportionate.

The narrower, defensible version isn’t “re-validate everything.” It’s “validate the specific role or roles this specific agent is about to inherit, before it goes live” — a bounded, proportionate check rather than a standing program. That distinction is what keeps this a pre-deployment gate rather than a new source of the same project overhead agents were meant to reduce.

What to Check Before an Agent Goes Live

A short, specific set of questions, run against the exact role an agent is about to be assigned — not the org’s roles in general:

What security role, or combination of roles, will this agent’s identity actually carry?
Has that specific role been run against the segregation-of-duties ruleset recently, or is its last validation older than the agent deployment being planned?
If every conflicting permission that role technically allows were exercised every time the opportunity arose, rather than occasionally, would the result be something the organization could live with?
Is there a named person who signs off that this particular role is fit to be held by a non-human identity, distinct from whoever approved the agent’s business case?

These four questions are a pre-deployment check, not an objection to deploying agents at all. They’re answerable in days against one role, using tooling that already exists — the segregation-of-duties ruleset doesn’t need to be built, only run and read.

The reason this check gets skipped is not difficulty. It’s that nobody put it on the path the deployment has to pass through. It competes for attention with everything else on a project plan, and usually loses.

This sits close to two other questions already worth asking about agents in Dynamics 365: whether a given agent’s control status is legible to both finance and IT governance at once, and whether the sheer size of what’s technically callable has been narrowed to what a specific agent actually needs.

This one is upstream of both. It’s about whether the role being handed to the agent was ever actually sound, for anyone, before the question of scope or ownership comes up at all.

DAX Software Solutions works through exactly this kind of role and permissions review ahead of an agent deployment, so the go-live decision is made with the role already tested rather than discovered afterward. Get in touch if you have an agent deployment scheduled and haven’t yet run this check against the role it will inherit.