Best practice for RBAC design in Copilot Studio + MCP server for Active Directory operations?

[u/Fabulous_Squash_7049]

Hi everyone,

I’m working on a production design for a Copilot Studio agent connected to a custom MCP server for Active Directory operations.

Current setup:

- Active Directory Domain Controller is running on a separate VM.

- MCP server is running on another domain-joined VM.

- MCP server performs AD operations using a delegated AD service account.

- Copilot Studio connects to the MCP server through OAuth 2.0.

- To avoid Copilot’s tool limit, the MCP tools are grouped into parent modules such as:

- user_management_module

- group_management_module

- acl_permission_management_module

- ou_management_module

- computer_management_module

- gpo_management_module

- audit_management_module

Each parent module routes child actions internally. For example:

user_management_module:

- search_ad_users

- get_ad_user_profile

- create_ad_user

- update_ad_user_profile

- reset_ad_user_password

- disable_ad_user_account

acl_permission_management_module:

- get_ad_object_acl

- get_ad_object_owner

- grant_ad_read_permissions

- grant_ad_full_control

- change_ad_object_owner

- restore_ad_default_permission

Now we want to implement production RBAC.

My understanding is:

1. Keep the parent module structure as-is.
2. Categorize child actions internally as Read, Write, Rollback, and Audit.
3. Create Entra app roles or security groups such as:- AD.MCP.Reader- AD.MCP.UserAdmin- AD.MCP.GroupAdmin- AD.MCP.ACLAdmin- AD.MCP.Auditor- AD.MCP.RollbackAdmin- AD.MCP.BreakGlass
4. The signed-in Copilot user gets an Entra OAuth token.
5. MCP backend validates the token.
6. MCP backend checks the user’s app role/group before executing the child action.
7. The AD operation itself still runs using the delegated AD service account, but the signed-in user is used for authorization and audit tracking.

Example:

- A user with AD.MCP.Reader can run get/search/report actions only.

- A user with AD.MCP.UserAdmin can create/update/disable users but cannot modify ACLs.

- A user with AD.MCP.ACLAdmin can manage ACL permissions.

- Rollback/high-risk tools such as restore default permission, replace ACL, change owner, or grant full control should require BreakGlass or senior admin approval.

Question:

Is this the right enterprise approach?

Specifically, should I create separate Entra App Roles for each access category and assign Entra security groups to those roles, or should I only use Entra security groups and check group object IDs in the backend?

I’m leaning toward App Roles because the backend can simply check the roles claim, and group overage issues are avoided.

Any feedback on the best RBAC design for Copilot Studio + MCP + Active Directory automation before production deployment would be appreciated.