---
title: "Does segregation of duties still apply to an AI agent?"
canonical_url: "https://cognilium.ai/blogs/segregation-of-duties-and-ai-agents"
slug: "segregation-of-duties-and-ai-agents"
section: "blogs"
date_published: "2026-10-21"
date_modified: "2026-10-21"
word_count: 1127
reading_time_minutes: 5
author: "Mudassir Marwat"
author_identifier: "0009-0008-1927-2598"
person_same_as:
  - "https://www.linkedin.com/in/mudassir-marwat/"
  - "https://orcid.org/0009-0008-1927-2598"
  - "https://github.com/mudassirmarwat"
  - "https://medium.com/@mudassir-marwat"
  - "https://www.youtube.com/@mudassir-marwat"
  - "https://dev.to/mudassirmarwat"
  - "https://hashnode.com/@mudassirmarwat"
  - "https://huggingface.co/mudassirmarwat"
  - "https://bsky.app/profile/mudassir-marwat.bsky.social"
  - "https://substack.com/@mudassirmarwat"
  - "https://topmate.io/mudassirmarwat"
  - "https://fueler.io/mudassirmarwat"
  - "https://www.instagram.com/mudassirmarwat/"
  - "https://www.facebook.com/mudassir.marwat"
  - "https://www.reddit.com/user/mudassirmarwat/"
  - "https://www.f6s.com/member/mudassir-marwat"
  - "https://cognilium.ai/founder"
entities: []
related: []
---
# Does segregation of duties still apply to an AI agent?

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.

## Key takeaways

- Segregation of duties applies to an agent because it applies to roles, and an agent holds roles. There is no separate rulebook.
- Microsoft's canonical example is this exact process — not letting the same party acknowledge receipt of goods and process vendor payment.
- An agent that posts receipts and also releases payment is the textbook violation. One that posts receipts and leaves payment alone is not.
- A rule is built from two duties, a severity, a risk description and a mitigation description, and only a system administrator can create it.
- Creating a rule does not verify compliance. Microsoft states that existing assignments can conflict and that you must validate afterwards.
- The platform treats an agent identity and a human identity the same way. The gap is procedural — agents get created by projects, people by processes.

**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:

**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](/erp-ai).

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](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/fin-ops/sysadmin/set-up-segregation-duties) · **fetched and read in full 2026-10-21**
- [Role-based security](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/sysadmin/role-based-security) · **fetched and read in full 2026-10-21**
- [Security for Dynamics 365 ERP MCP](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/copilot/mcp/mcp-security) · **fetched and read in full 2026-10-21**

## Fact-check

**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.

## Frequently asked questions

### Why does it apply at all?

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."

### How is a rule actually built?

At System administration > Security > Segregation of duties > Segregation of duties rules, a new rule takes:

---

Canonical HTML: https://cognilium.ai/blogs/segregation-of-duties-and-ai-agents