Team
A Team is the people primitive.
SSO-group-backed (Google Workspace, Okta, …). Members hold roles (org admin, project admin, agent owner, auditor). Every action TapPass takes is gated by team membership — who can author Policy at which level, who can revoke a Sandbox, who sees which Audit.
At a glance
Section titled “At a glance”| Backed by | SSO groups (managed in your IdP, mirrored automatically in TapPass) |
| Members hold roles | Org admin · Project admin · Agent owner · Auditor |
| Owns | one or more Projects |
| Gates | every action — Policy authoring, Sandbox provisioning, Audit access |
What it is, concretely
Section titled “What it is, concretely”When an operator signs in, TapPass reads their SSO groups and resolves which Teams they belong to. Their role on each Team determines what they can do:
| Role | Org level | Project level | Agent level |
|---|---|---|---|
| Org admin | Author org Policy floor; manage all teams | Inherits all project rights | Inherits all agent rights |
| Project admin | — | Author project Policy floor; manage Agents in the project | Inherits agent rights |
| Agent owner | — | — | Author agent overrides; provision Sandboxes; view this agent's Audit log |
| Auditor | View org-wide audit | View project audit | View agent audit (read-only) |
Adding someone to the eu-data-team SSO group automatically gives them project-admin access on the projects that team owns. No manual TapPass-side membership management — the IdP is the source of truth.
Why this matters
Section titled “Why this matters”Without Teams, every TapPass action is either fully open or requires custom RBAC inside TapPass. Both fail at scale. With Teams (SSO-backed):
- Onboarding = add to the SSO group; TapPass picks it up automatically.
- Offboarding = remove from SSO; TapPass loses access in the next session.
- Audit = "who did this?" traces back to a real human identity in your IdP.