Roles and permissions
Control what each person can administer in MintMCP by creating roles that match how your organization works. Instead of choosing between "member who can do nothing org-wide" and "admin who can do everything", you define roles from a supported permission set and hand each team exactly the administrative reach its job requires.
This page covers one of two separate access-control layers:
| Layer | Governs | Covered in |
|---|---|---|
| Roles and permissions | Who can administer MintMCP: create MCPs, manage members, view org-wide logs, change enterprise settings | This page |
| Virtual MCP access policies | Which connectors and tools AI clients can see and call | Role-based access control |
The two are independent. A role decides what someone can administer; a Virtual MCP's access policy decides which tools show up in their MCP store. Someone can hold broad tool access with zero administrative rights, or run the entire connector estate without ever calling a tool.
Roles are managed on the Team management page (the Team entry in the navigation).
Built-in roles
Two roles are built in:
| Role | What it grants |
|---|---|
| Member | The default for everyone who joins. Members use the Virtual MCPs shared with them and see their own activity, with no org-wide administrative permissions. |
| Admin | Every permission, including capabilities that custom roles cannot grant: managing roles themselves, billing, and organization-level auth configuration. Admins also bypass Virtual MCP access policies. |
Built-in roles cover the two ends of the spectrum. Custom roles cover everything in between, so the admin role can stay with a small number of organization owners.
Security properties
- Non-escalating by design. Custom roles cannot grant full admin access, role management, or billing, so a role holder can never widen their own reach or mint an admin.
- Member management can't escalate either. A role with Member management can invite and remove members, but can only invite them as Member; assigning any higher role takes an admin.
- Enforced server-side on every request. The role someone holds is the actual boundary, not just what the UI shows them.
- Directory-governed. With SCIM group mapping, administrative rights follow the same joiner-mover-leaver process as the rest of your enterprise.
Custom roles
Admins create org-specific roles from the supported permission set in the Custom roles section of the Team management page. Each role has a name, an optional description, and a set of permissions chosen from the table below.
To create one:
- Open Team management and scroll to Custom roles.
- Click New role.
- Enter a Role name and an optional Description.
- Under Permissions, check the org-level actions the role should be allowed to take. Permissions are grouped by area, and each group can be selected as a whole.
- Click Create role.
Editing a role takes effect for everyone who holds it. Deleting a role that is still assigned removes it from all affected members; anyone left with no other direct or mapped role falls back to the default Member role.
Permission reference
| Area | Permission | What it grants |
|---|---|---|
| MCP authoring | Create MCPs | Create and edit your own MCPs |
| Programmatic MCP access | Create API keys | Create API keys for any MCPs that you can call |
| Org MCP administration | Share MCPs | Share MCPs with anyone in the organization |
| Org MCP administration | Edit all MCPs | See and edit all MCPs, even private ones |
| Security | View org-wide logs | View org-wide MCP dashboards, logs, and cross-user activity |
| Security | Guardrail management | Create and update organization-specific guardrails |
| Security | View guardrails | Review rules and shared middleware definitions across the organization |
| Administration | Member management | Invite, remove, and manage organization members |
| Administration | Agent management | Manage GitHub agents, tasks, and skills |
| Administration | Enterprise settings | Manage Slack, OTEL, and other enterprise integrations |
| Administration | View secret providers | View external secret provider configuration and test status |
| Administration | Manage secret providers | Create, edit, test, and delete external secret providers |
| Administration | Manage credential brokers | Create, edit, and delete shared credential brokers (OAuth and AWS SSO) for the organization |
The permission set is deliberately non-escalating: see Security properties for the boundaries that hold regardless of which permissions a role combines.
Example roles
Custom roles give you real separation of duties over the AI gateway: each team administers its own slice, and nobody needs full admin to do their job.
| Permission | Platform engineering | Security | IT | Developer |
|---|---|---|---|---|
| Create MCPs | Yes | Yes | ||
| Create API keys | Yes | Yes | ||
| Share MCPs | Yes | |||
| Edit all MCPs | Yes | |||
| View org-wide logs | Yes | |||
| Guardrail management | Yes | |||
| View guardrails | Yes | |||
| Member management | Yes | |||
| Agent management | Yes | |||
| Enterprise settings | Yes | |||
| View secret providers | Yes | |||
| Manage secret providers | Yes | |||
| Manage credential brokers | Yes |
- Platform engineering deploys and manages the entire connector estate, including the secrets and shared credentials behind it, without touching membership, guardrails, or enterprise settings.
- Security owns guardrails and org-wide visibility, and can review secret provider configuration, without being able to deploy or edit a single connector.
- IT owns membership and enterprise integrations (Slack, OTEL, and other enterprise settings) without seeing guardrail internals or the MCP estate.
- Developer authors and iterates on their own MCPs and issues API keys for the MCPs they can call, with no org-wide reach at all.
Teams that consume tools rather than administer them, like Sales, don't need a role here: which tools the Sales team can call is governed by Virtual MCP access policies, not by administrative permissions.
Assigning roles
Each member holds one directly assigned role, so assigning a custom role takes the place of Member (or whatever they held before). Roles mapped from directory groups stack on top of the directly assigned one; see Assigning roles through directory groups. Only admins can assign roles other than Member.
Assign a role directly on the Team management page:
- When inviting: click Invite user, enter the email address, and pick the role from the Role select. Custom roles appear alongside Member and Admin.
- For an existing member: open the row menu, choose Change role, pick the new role, and click Save.
Assigning roles through directory groups
When SCIM provisioning is configured, directory groups from your identity provider sync into MintMCP and appear in the Synced directory groups section of the Team management page, each with its member list and a Sync now control. You can map these groups to roles so that group membership in your directory, not manual assignment, decides who holds which role.
To set up the mapping, click Assign groups to custom roles below the group list. This opens the SCIM setup flow; continue to step 6, Assign roles, and map each directory group to the role its members should hold.
Once mapped, the same joiner-mover-leaver process that governs the rest of your enterprise governs the AI control plane:
- When someone joins a mapped directory group, the next sync grants them the role.
- When they leave the group, the sync removes that role; with no other direct or mapped role remaining, they return to the default Member role.
- Someone in several mapped groups holds all of those roles, and their permissions are the union.
Directory group sync and group-to-role assignment require SCIM provisioning (Configure SSO and SCIM) and are available on Enterprise plans. Creating custom roles and assigning them directly works without SCIM.
How roles relate to Virtual MCP access
Roles and Virtual MCP access are orthogonal. Granting someone the Security role above gives them guardrails and org-wide logs; it does not add a single tool to their MCP store. Likewise, putting someone in the sales-team directory group can grant them the Sales Virtual MCP without any administrative permissions. The one exception is the built-in Admin role, which bypasses Virtual MCP access policies entirely.
Both layers can key off the same directory groups: one group can drive an administrative role here and a Virtual MCP access policy in Role-based access control, so a single directory change updates both what a person can administer and what tools they can call.
Related
- Role-based access control: the tool-access layer, Virtual MCP access policies driven by directory groups
- Configure SSO and SCIM: getting SSO and directory groups into MintMCP
- Operational controls: incident-time levers for administrators