# Members

A namespace’s members are the people who can sign in and see it. Manage them under **Team**.

![The Team page showing the Members tab with members and their roles](https://docs.shellhub.io/img/shots/members.png)

## Adding someone

Invite them from the Team page and assign a role. The role decides what they can do _in the console_ — see [User Roles](https://docs.shellhub.io/manage/team/user-roles).

On Community the invitation email is never sent, because the instance has no mail. The invitation is still created and the console gives you its link to copy — send it however you like. Or skip the person entirely: `user create` and `namespace member add` on the host put them in. See [Administration](https://docs.shellhub.io/selfhosted/administration).

## Membership and device access are different things

This is the distinction that matters most on this page, and the one people get wrong.

**Being a member does not grant access to any device.** In a new namespace, device access comes entirely from [access policies](https://docs.shellhub.io/manage/access-control/access-policies), and a new member matches none of them.

So adding somebody is two steps:

1. Add them as a member, with a role.
2. Write or extend a policy that grants them something.

A member with no policy can sign in, see the namespace, and connect to nothing. That is deliberate — default deny means access is something you grant on purpose.

The exception is the namespace owner, who is covered by the starter **Owner access** policy.

## Roles as policy subjects

The cleanest way to handle step 2 is to grant the **role**, not the person:

| Name               | Effect | Subject        | Devices          | Logins   |
| ------------------ | ------ | -------------- | ---------------- | -------- |
| Operators to fleet | allow  | Role: operator | tag `production` | `deploy` |

Now adding somebody as an operator grants them the fleet, and removing them takes it away, with no policy edited either time. Per-person policies are for genuine exceptions.

## Removing someone

Removing a member ends their access to the namespace.

Two things to do alongside it:

**Revoke their SSH identities.** Membership and identities are separate records. Revoke the keys bound to them on the [SSH Identities](https://docs.shellhub.io/manage/access-control/ssh-identities) page.

**Check for automation on their key.** If a pipeline was configured with a key of theirs, it stops working. That is why automation should connect as an API key with [its own SSH access](https://docs.shellhub.io/api/ssh-access) instead.

> **Careful**
>
> Neither removing a member nor revoking an identity interrupts a session already open. Authorization is evaluated when the connection is made.

## Where to go next

- [User Roles](https://docs.shellhub.io/manage/team/user-roles) — What each role can do.
- [Access Policies](https://docs.shellhub.io/manage/access-control/access-policies) — Granting device access.
- [Single Sign-On (SAML)](https://docs.shellhub.io/manage/team/single-sign-on) — Bringing members from an IdP.