---
summary: Each crew member is its own ScaiKey service account.
title: Crew-member identities
path: authentication/identities
status: published
---

# Crew-member identities

Each crew member **is a ScaiKey service account**, provisioned on its first publish. Every substrate
action the member takes happens *as that identity*, which means:

- **Attributable** — every action traces back to a specific member.
- **Independently revocable** — disable the member's identity and it loses access immediately.
- **No ambient authority** — a member can only reach what its identity's ACLs allow. ScaiCrew adds
  no extra power on top.

## Provisioning

On first publish, ScaiCrew creates a **tenant-scoped service application** in ScaiKey for the
member. The member then runs under tokens minted for its own identity, so — for example — inference
calls are attributed to the member, not to ScaiCrew.

The direction of travel is for a member to run with the **same permissions a human in that role
has** — the same files, databases, and connectors — because access derives from its ScaiKey
identity, not from ambient grants. That is the whole point of per-member identity.

## Roles

Human callers carry a role, ascending `viewer < operator < author < admin`:

| Role | Can |
|---|---|
| `viewer` | Read crews, members, runs |
| `operator` | Start runs, act on approvals |
| `author` | Create and edit members, publish |
| `admin` | Manage the workspace and its members |

Service callers (other trusted services) are authenticated at the audience level and bypass role
gating.