Skip to content

Control 2.8: Access Control and Segregation of Duties

Control ID: 2.8
Pillar: Management
Regulatory Reference: SOX 302/404 (SoD over financially relevant systems), FINRA 3110 (supervisory separation), FINRA 4511, FINRA 25-07, GLBA 501(b), SEC 17a-4, OCC Heightened Standards (12 CFR 30 Appendix D), NIST SP 800-53 AC-5 (Separation of Duties) and AC-6 (Least Privilege)
Last UI Verified: April 2026
Governance Levels: Baseline / Recommended / Regulated


Objective

Establish role-based access control mechanisms and segregation of duties (SoD) for AI agent governance. No single individual should be able to initiate, approve, and deploy agents to production without independent review.


Why This Matters for FSI

  • SOX 302/404: Helps support segregation of duties requirements for systems that are part of internal control over financial reporting (ICFR), including AI agents that read, transform, or summarize financial data. Auditors typically expect role separation across create / review / approve / deploy.
  • FINRA Rule 3110 (Supervision): Helps demonstrate supervisory separation — the person performing an activity should not also be the person reviewing it. For agent governance, the maker should not approve their own production publish.
  • FINRA 4511, FINRA 25-07: Access to books-and-records repositories (including agent transcripts) must be controlled, logged, and reviewable. Role-based access supports the WORM and supervisory-access expectations in these rules.
  • GLBA 501(b): Restrict administrative and developer access to systems that handle nonpublic personal information (NPI) using least privilege; agent makers and admins must be distinct populations with documented reviews.
  • SEC 17a-4: Modification of designated records (including agent output retained as a record) must be controlled; SoD between record producers and record administrators helps meet this expectation.
  • OCC Heightened Standards (12 CFR 30 App. D) and OCC 2011-12 / Fed SR 11-7: Independent model risk management requires that model developers, model validators, and model approvers are separated. AI agents in scope of MRM inherit this expectation.
  • NIST SP 800-53 AC-5 / AC-6: Provides the canonical control language (Separation of Duties, Least Privilege) that examiners frequently map FSI controls back to.

Automation Available

See Segregation Detector in FSI-AgentGov-Solutions for role conflict detection for Maker/Checker enforcement in agent pipelines.

Control Description

This control defines role-based access, approval workflows, and continuous access monitoring to prevent unauthorized changes:

Capability Description FSI Application
Role Separation Distinct roles for create, review, approve, deploy SOX SoD requirements
Least Privilege Minimum access needed for job function Data protection
Access Reviews Quarterly recertification of access rights Audit compliance
Just-in-Time Access PIM for administrative roles Attack surface reduction
Continuous Monitoring Real-time access analytics Anomaly detection

Agent Governance Role Matrix

Role Create/Edit Review Approve Deploy Configure
Agent Developer Yes No No No No
Agent Reviewer No Yes No No No
Agent Approver No No Yes No No
Release Manager No No No Yes No
Platform Admin No No No No Yes

Key Configuration Points

  • Create Entra ID security groups for each agent governance role (Developer, Reviewer, Approver, Release Manager, Platform Admin) and prefer role-assignable groups for any group that grants directory roles.
  • Configure Power Platform / Dataverse security roles with least-privilege table and column privileges; reserve Dataverse System Administrator for break-glass only.
  • Separate Copilot Studio authoring (Environment Maker + Copilot Studio author Dataverse role) from Copilot Studio administration (Power Platform Admin / Environment Admin) — the same identity should not hold both in Zone 3.
  • Implement Entra Privileged Identity Management (PIM) for Roles for Power Platform Admin, Entra Global Admin, AI Administrator, and Dataverse System Administrator; implement PIM for Groups for the SG-Agent-Approvers and SG-Agent-ReleaseManagers groups in Zone 3.
  • Build approval workflows that mechanically reject self-approval (creator email = approver email → reject) and record the SoD evaluation in the audit log.
  • Enable quarterly Entra Access Reviews on every SG-Agent-* group and on PIM-eligible assignments, with auto-apply and reviewer-of-record (group owner + AI Governance Lead).
  • Configure Continuous Access Evaluation (CAE) and risk-based Conditional Access for Power Platform, Copilot Studio, and Microsoft 365 admin endpoints.
  • Monitor for stale and orphaned accounts (no interactive sign-in > 90 days, owner-less service principals, makers no longer in HR feed).

Service Principal Security Group Bypass

Role assignments verified through security groups may not apply to Service Principal identities performing automated actions. Service Principals authenticate with application credentials without user group membership, bypassing group-based role controls.

Compensating Control:

  • Audit Service Principal permissions separately using Entra ID Enterprise Applications blade
  • Document Service Principal role assignments in a dedicated tracking spreadsheet or Dataverse table
  • Review Service Principal API permissions quarterly as part of access reviews
  • Apply least-privilege principle by granting Service Principals only required Power Platform security roles (not System Administrator)

See Environment Lifecycle Management solution for Service Principal governance patterns.

Regression Detection for Access Control Changes

When access control policies or role assignments change, sequential agent evaluations can help detect unintended behavioral regressions. Running evaluation comparisons before and after access control modifications helps validate that agents continue to operate within expected boundaries. See Control 2.18 - Automated Conflict of Interest Testing for the full evaluation methodology.


Zone-Specific Requirements

Zone Requirement Rationale
Zone 1 (Personal) Default user access; self-service; no SoD enforcement required, but maker activity must still be logged via Purview audit Low blast radius, individual productivity use; logging supports later supervisory review
Zone 2 (Team) Team owner approval required to publish or share; creator must differ from approver; annual access review of team-scoped Dataverse roles Shared agents touch multiple users' data and require accountable second-person review
Zone 3 (Enterprise) Full four-role SoD: Creator ≠ Reviewer ≠ Approver ≠ Release Manager; PIM-gated activation for Platform Admin and Dataverse System Administrator; quarterly access reviews with auto-apply; documented break-glass procedure with monitored alerts Customer-facing, financially relevant, or NPI-handling agents require auditable, examiner-defensible separation aligned to SOX 404 and OCC Heightened Standards

Roles & Responsibilities

Role Responsibility
Power Platform Admin Configure Dataverse security roles, environment-level access, and Power Platform DLP; does not assign Entra directory roles
Entra Privileged Role Admin Configure PIM for Roles and PIM for Groups; assign eligible (not active) admin role members
Entra Identity Governance Admin Create and operate Access Reviews on SG-Agent-* groups and PIM-eligible assignments
AI Administrator Manage Copilot tenant settings and AI feature access; coordinates with Power Platform Admin but holds no Power Platform tenant authority
AI Governance Lead Owns role definitions, SoD policy, exception register, and reviewer assignments
Compliance Officer Independent oversight of access reviews, sign-off on documented exceptions, evidence retention

Control Relationship
1.1 - Restrict Agent Publishing Publishing requires appropriate role
1.18 - Application-Level RBAC Agent-level access control
2.3 - Change Management Approval workflows
Agent Sharing Access Restriction Detector Enforces zone-based sharing policies with approval workflows
2.12 - Supervision and Oversight Oversight access requirements

Implementation Playbooks

Step-by-Step Implementation

This control has detailed playbooks for implementation, automation, testing, and troubleshooting:


March 2026 Preview Updates

Environment or environment-group authentication controls

⚠️ Preview feature: Power Platform enhanced admin controls entered public preview in March 2026 and are scheduled for April 2026 general availability. Microsoft notes that delivery timelines can change before release.

Microsoft documents new settings at the environment or environment group level for agent sharing, anonymous access endpoints, and approved authentication providers. For Control 2.8, these settings add a platform-level backstop that helps keep authentication and sharing decisions aligned across related environments.

Capability Segregation-of-duties relevance
Approved authentication providers Prevent makers from introducing unapproved identity paths that reviewers cannot independently validate
Anonymous access endpoint blocking Removes unsupervised access paths that bypass assigned roles and approvals
Shared policy scope Helps keep dev, test, and production-aligned environments on the same access baseline
Runtime validation Blocks deployments that drift away from the approved SoD design after review

Safe sharing and credential oversharing

⚠️ Preview feature: Safe-sharing enforcement that detects credential oversharing enters public preview in April 2026 and is scheduled for June 2026 general availability.

Microsoft documents that Copilot Studio can identify agents and flows that rely on connections marked as not safe for sharing, surface inventory and advisor guidance, and block publishing or sharing of unsafe assets before exposure. This directly supports maker/checker enforcement by preventing a creator from promoting an agent that still depends on the creator's personal or reused system credentials.

FSI implementation guidance: - Require the checker or approver to review unsafe-sharing signals before approving production release - Treat flagged maker credentials as a SoD exception that must be remediated before publish/share approval - Continue running periodic role-conflict detection because preview safe-sharing controls focus on identity reuse, not every SoD conflict pattern


Verification Criteria

Confirm control effectiveness by verifying:

  1. Entra security groups exist for all agent governance roles, are owner-assigned (not orphaned), and any group granting directory roles is marked role-assignable.
  2. Power Platform / Dataverse security roles are configured with least-privilege table and column privileges; the population of Dataverse System Administrator in each Zone 3 environment is documented, reviewed quarterly, and PIM-gated.
  3. Copilot Studio authoring identities (Environment Maker + Copilot Studio author) are disjoint from Copilot Studio administrative identities (Power Platform Admin / Environment Admin) in Zone 3; deviations are recorded in the SoD exception register.
  4. Automated SoD check (see PowerShell playbook) returns zero conflicting-role overlaps, or each overlap has an active, time-boxed exception signed by the Compliance Officer.
  5. Entra Access Reviews are scheduled at the cadence required by the zone (annual / quarterly / monthly), have a named reviewer of record, and are auto-applying.
  6. PIM is configured for Power Platform Admin, AI Administrator, Entra Global Admin, and Dataverse System Administrator with required justification, MFA, and (Zone 3) approver workflow.
  7. The publish/deploy approval workflow rejects self-approval programmatically and emits an audit event for every approve / reject decision.
  8. Where the enhanced admin controls or safe-sharing previews are enabled, approved authentication providers are enforced and unsafe maker-credential reuse is blocked, documented as an exception, or remediated before publish.

Additional Resources

Advanced Implementation: Environment Lifecycle Management

For implementing segregation of duties in environment provisioning (requester cannot approve own request), see Environment Lifecycle Management.


Implementation Note

Organizations should verify that their implementation meets their specific regulatory obligations. This control supports compliance efforts but requires proper configuration and ongoing validation.

Updated: April 2026 | Version: v1.4.0 | UI Verification Status: Current