> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Access Control

> How access control works in MCP Manager: roles grant capabilities (what you can do), teams grant gateways (which you can reach), and a user's access is the intersection of the two — why each user has exactly one role but can belong to many teams, plus the per-server identity and feature-provisioning layers that scope it further.

In MCP Manager, **access control** decides two things for every person in your workspace: *what* they are allowed to do, and *which* gateways they can reach. Those two questions are answered by two independent building blocks — **roles** and **teams** — and a user's effective access is the **intersection** of the two. Two finer, per-server layers narrow it further. This section is the reference for all of them.

<Note>
  Access control is administered under **People** at [People](https://app.mcpmanager.ai/settings/people), gated by a set of fine-grained People capabilities — **Manage roles**, **Manage teams**, **Manage user role assignments**, **Manage user team assignments**, **Remove users**, and **View all teams**. Holding any one of them reveals the **People** section; each then unlocks its own actions. If the **People** link is missing from your left-hand navigation, your role has none of them. Access is governed by capabilities, not by any fixed role name.
</Note>

## Roles and teams are the two halves of access

MCP Manager keeps *what you can do* and *which gateways you can reach* as two separate concepts and combines them with an **AND**:

* A **role** is a named bundle of [capabilities](/deployment/rbac-and-roles/capabilities) — granular permissions such as "Basic gateway management" or "View and export logs." Every user holds **exactly one** role — which keeps the answer to "what actions is this person allowed to take?" unambiguous, with no overlapping roles to reconcile.
* A **team** grants access to specific [gateways](/mcp-gateway-concepts/mcp-gateways). A user can belong to **zero, one, or many** teams, and it answers "which gateways can this person reach?"

A user can act on a gateway only when **both** halves agree: their role grants the capability for the action, and one of their teams provisions the gateway. Holding a capability does not widen which gateways it applies to, and joining a team does not, by itself, grant any administrative action. A small family of "view all" capabilities — **View and use all gateways**, **View all servers**, **View all identities**, **View all teams**, and **See all alerts** — deliberately overrides team scoping for administrators who need a workspace-wide view.

## The finer, per-server layers

Roles and teams set the broad boundaries; two further controls scope access **within** a gateway, one server at a time:

* **Identity scheme** — whether each server is reached with the user's own identity or a shared service account. See [Identity Controls](/features/identity-controls).
* **Feature provisioning** — which tools, resources, and prompts each server exposes on a gateway. See [Feature Provisioning](/features/feature-provisioning).

There is no per-person or per-resource access list, so you express fine-grained access by separating servers onto different gateways and provisioning each gateway to the right team. See [Gateway Deployment Strategies](/deployment/gateway-deployment-strategies).

## The pieces of access control

<CardGroup cols={3}>
  <Card title="Roles" icon="user-shield" href="/deployment/rbac-and-roles/overview">
    The capabilities a user holds — what they're allowed to do. Every user has exactly one role.
  </Card>

  <Card title="Teams" icon="users" href="/deployment/teams">
    The gateways a user can reach. A user can belong to zero, one, or many teams.
  </Card>

  <Card title="Capabilities" icon="key" href="/deployment/rbac-and-roles/capabilities">
    The complete reference of every permission a role can grant, grouped as they appear in the product.
  </Card>
</CardGroup>

## Further reading

<CardGroup cols={2}>
  <Card title="Roles" icon="user-shield" href="/deployment/rbac-and-roles/overview">
    Start here — the three built-in roles, custom roles, and how a role is assigned.
  </Card>

  <Card title="Identity Controls" icon="id-card" href="/features/identity-controls">
    Per-server identity schemes that scope what a user reaches within a gateway.
  </Card>

  <Card title="Feature Provisioning" icon="filter" href="/features/feature-provisioning">
    Per-server tool, resource, and prompt exposure — the finest layer of access.
  </Card>

  <Card title="Gateway Deployment Strategies" icon="sitemap" href="/deployment/gateway-deployment-strategies">
    How to package gateways so each team gets exactly the access it should.
  </Card>
</CardGroup>