TL;DR
It applies, because the rules attach to roles and an agent holds roles. Microsoft own example is receipt of goods against payment to the vendor.
Yes — and Microsoft's own canonical example is this exact process. The illustration in the product documentation is not letting the same person acknowledge the receipt of goods and process payment to the vendor. An agent holds security roles, so the rules apply to it the way they apply to anyone holding those roles.
Why does it apply at all?
Because the rules attach to roles, and an agent has roles.
Microsoft's security model is explicit about where access comes from: "In role-based security, you don't grant access to individual users, only to security roles. Assign users to roles." And the consequence is stated just as plainly: "A user not assigned to any role has no privileges."
The connector changes none of it. "The roles, duties, privileges, record-level security, and data security policies assigned to that user apply to every request", and "Finance and operations security, not the MCP server, enforces authorization."
So there is no separate agent rulebook. Whatever your segregation rules say about a combination of duties, they say it about an identity holding that combination — human or not.
Microsoft's own example is this process
This is the sentence to put in front of an auditor:
"For example, you might not want the same person to acknowledge the receipt of goods and to process payment to the vendor."
That is procure-to-pay, and it is Microsoft's illustration of the whole concept. The canonical segregation risk in the product documentation is the exact pair of duties a receipts-and-payables agent would be tempted to hold.
### Why that matters for scoping An agent that confirms a receipt and also settles the invoice is the textbook violation, named in the documentation. An agent that only posts the receipt, and leaves payment to the existing process, is not. The design question answers itself if you read Microsoft's own example before drawing the architecture.
The purpose is stated too: segregation of duties "helps you reduce the risk of fraud, and it also helps you detect errors or irregularities", and can be used "to enforce internal control policies."
How is a rule actually built?
Six fields, at a published path.
At System administration > Security > Segregation of duties > Segregation of duties rules, a new rule takes:
| Field | What Microsoft says it is for |
|---|---|
| Name | the rule's name |
| First duty | "Select the first duty that the rule controls" |
| Second duty | "Select the second duty that the rule controls" |
| Severity | "Select the severity of the risk that occurs when the same user or role performs both duties" |
| Security risk | "Enter a description of the security risk" |
| Security mitigation | "Enter a description of the actions that you take to mitigate the security risk" |
Duties are the right granularity here, because that is the layer the model uses: "Duties correspond to parts of a business process… In the security model, duties contain privileges."
And the mitigation field is not decoration. Microsoft's examples of what to write in it are operational: "you can mitigate the risk by conducting more detailed reviews of the process, by conducting a monthly managerial review, or by sharing resources with other departments."
You must be a system administrator to create one.
The trap nobody mentions
Creating a rule does not test it.
"Compliance with the rules for segregation of duties isn't verified when you create a rule. You can create a rule that creates a conflict for existing roles. Existing user role assignments can also conflict with the new rule. You must validate compliance after you create or modify a rule."
Read that against an agent rollout. You can write a sound rule, assign an agent a sensible-looking set of roles, and have a live conflict that nothing announced. The validation is a separate, deliberate step.
This cuts both ways and the second way is worse. A rule written after the agent was deployed can put the agent instantly out of compliance, and nothing in the creation flow will tell you. If your segregation rules are maintained by a governance team and your agents by a delivery team, that is a gap between two calendars.
What it means for designing an agent
Three consequences, and the first is a scoping rule.
Give the agent duties, not roles-by-convenience. The temptation is to copy an existing user's role so the agent "can do what Sam does". Sam's role may combine duties that are fine for a supervised human inside a review culture and wrong for an identity acting at three in the morning.
Keep the posting and the paying apart. Microsoft's own example tells you which pair to avoid. An agent that posts product receipts should not also be able to release payment — and the honest version of that sentence is that it should not hold both duties, rather than that it merely will not use both.
Validate after every change, on both sides. New rule, or new role assignment — either can create the conflict, and Microsoft says the check is yours to run.
What this is not: it is not a claim that an agent is inherently riskier than a person holding the same roles. The platform treats them identically, which is the reassuring part. The risk is that an agent is created by a project and a human is created by a process, and only one of those has a compliance step in it.
About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/
Agentic ERP. We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on Azure OpenAI, Microsoft Fabric and Copilot Studio. We build these on request, against your data and your environment.
More on the boundary between what Copilot does and what you build: Agentic ERP on Dynamics 365.
If an agent is being scoped against an existing user's role, that is the conversation worth having before the build. Bring the role and the duties to a 15-minute call.
Sources
- Set up segregation of duties · fetched and read in full 2026-10-21
- Role-based security · fetched and read in full 2026-10-21
- Security for Dynamics 365 ERP MCP · fetched and read in full 2026-10-21
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | "In role-based security, you don't grant access to individual users, only to security roles"; "A user not assigned to any role has no privileges" | T1 — verbatim ×2 | role-based-security | PASS |
| 2 | 1 | "The roles, duties, privileges, record-level security, and data security policies assigned to that user apply to every request"; "Finance and operations security, not the MCP server, enforces authorization" | T1 — verbatim ×2 | mcp-security | PASS |
| 3 | 1 | There is no separate agent rulebook | T2 — ours, the conclusion from 1 and 2 | — | PASS |
| 4 | 2 | "For example, you might not want the same person to acknowledge the receipt of goods and to process payment to the vendor" | T1 — verbatim | set-up-segregation-duties | PASS — the article's spine, and it is Microsoft's own illustration of the concept |
| 5 | 2 | "helps you reduce the risk of fraud, and it also helps you detect errors or irregularities"; "to enforce internal control policies" | T1 — verbatim ×2 | Same page | PASS |
| 6 | 2 | An agent holding both duties is the textbook violation | T2 — ours, read directly off claim 4 | — | PASS |
| 7 | 3 | The path System administration > Security > Segregation of duties > Segregation of duties rules | T1 — verbatim. Not invented navigation | Same page | PASS |
| 8 | 3 | All six fields with Microsoft's own descriptions | T1 — verbatim ×4 for the quoted descriptions; field names character-exact | Same page | PASS |
| 9 | 3 | "Duties correspond to parts of a business process… In the security model, duties contain privileges" | T1 — verbatim | role-based-security | PASS |
| 10 | 3 | The mitigation examples — detailed reviews, monthly managerial review, sharing resources | T1 — verbatim | set-up-segregation-duties | PASS |
| 11 | 3 | System administrator required | T1 — verbatim ("You must be a system administrator to complete the procedure") | Same page | PASS |
| 12 | 4 | "Compliance with the rules for segregation of duties isn't verified when you create a rule… Existing user role assignments can also conflict with the new rule. You must validate compliance after you create or modify a rule" | T1 — verbatim, from Microsoft's own Important callout | Same page | PASS |
| 13 | 4 | The governance-calendar gap between rule authors and agent builders | T2 — ours, an organisational argument, no figure attached | — | PASS |
| 14 | 5 | The three design consequences | T2 — ours, method | — | PASS |
| 15 | 5 | An agent is not inherently riskier than a human with the same roles; the platform treats them identically | T2 — ours, and deliberately stated to avoid fear-selling. Supported by claims 1 and 2 | — | PASS |
Tier summary: 10 × T1 (all verbatim), 5 × T2 — 0 × T4.
### 🔴 SOX is deliberately not mentioned, and that is a guardrail Microsoft's own segregation documentation elsewhere references regulatory drivers, and it would be easy to reach for compliance language here. The source document governing this cluster bans it outright: never "SOX-compliant", never "100% audit-ready", because we have not been audited and compliance is the client's determination, not ours. This article therefore describes the mechanism and never the certification. It says what the rules do and what the validation step is. It does not tell anyone they will pass anything.
### 🔴 Other guardrails applied | Rule | Compliance | |---|---| | Never "least-privilege" | The article says "give the agent duties, not roles-by-convenience" and quotes Microsoft's own model. The banned phrase does not appear | | Never fear-sell the agent as uniquely risky | §5 explicitly says the opposite — the platform treats both identities the same, and the gap is procedural | | Never a customer name, saving or percentage | None appears |
🔴 No pricing. No rate, cost or currency anywhere.
No unbounded absence claimed. "Compliance… isn't verified when you create a rule" is Microsoft's own Important callout, quoted with its scope intact.
No figures of ours. No volume, no conflict counts, no customer, no result.
Share this article
Procure-to-Pay Agent Operations
Topic Cluster
