# Roles, members & seats

systemHUB controls who can see and do what through **roles** and **member assignments**. This page explains the model an agent needs to reason about access — and where the current MCP boundary sits.

## The access model

A document's access is the union of two mechanisms:

- **Role-based access** — a document is assigned to one or more **roles** (e.g. a department or job function). Every member holding that role gets access.
- **Direct assignment** — an individual member is assigned to the document specifically, regardless of role.

A member can therefore have access that is **direct**, **role-based**, or **both**. The `get_document_members_and_roles` tool returns exactly this: the roles on a document, plus each member's name, email, role title(s), and access type.

Present an access picture as an audit: roles first, then members grouped by how they got in (direct vs role-based vs both).

## Seats

A **seat** is a licensed member of the workspace. Seat/member management — inviting people, allocating seats, changing who holds which role — is done in the **systemHUB app UI**.

> **MCP boundary (important for connecting agents):** the MCP server can **read** the full access picture (members, roles, assignment type, agreement status, training progress) but does **not** currently expose **write-side user or seat management**. An agent can audit and report on access; it cannot add members, change seats, or reassign roles through the MCP. Attempting to do so is out of scope — direct the user to the app UI.

## What agents can audit today

- `get_document_members_and_roles` — who can access a document, and how.
- `get_document_agreement_status` — who has agreed/signed off on a document (e.g. a policy acknowledgement).
- `get_document_training_progress` — for trainings, each assigned user's completion percentage and status.
- `list_documents_by_owner` — everything a given person owns across systems, policies, and trainings, in one call.

Together these cover "who owns / can see / has completed what" — the read side of governance. The write side (provisioning) stays in the app for now.

Next: **[Authoring content →](/docs/concepts/authoring-content)**