Teams
Inviting team members, managing permissions, and sharing project access in SikkerKey.
Multi-user collaboration on SikkerKey now lives in the Organizations feature.
Teams let vault owners share project access with other SikkerKey users. Team members have no access by default. The vault owner grants access per-project and controls machine permissions explicitly.
Inviting a Team Member
From the Teams page, enter the email address of a SikkerKey user in the Invite Member card and click Send Invite. The invitee receives an email notification. If they are logged into the dashboard, the invite also appears on their Teams page in real time.
You cannot invite yourself. You cannot invite someone who is already a team member. Duplicate pending invites to the same email are rejected.
Invite Lifecycle
| Status | Meaning |
|---|---|
| Pending | The invite has been sent. Waiting for the invitee to respond. Shown in the "Pending Invitations" card. |
| Accepted | The invitee accepted. They are now a team member. |
| Declined | The invitee declined. The invite is closed. |
Invites expire after 7 days. Expired invites cannot be accepted and must be re-sent.
You can cancel a pending invite at any time from the Pending Invitations card.
Accepting an Invite
When you receive an invite, it appears on your Teams page under Vault Invitations. Click Accept to join the vault or Decline to dismiss it.
After accepting, the vault owner's projects appear in your sidebar grouped under the owner's username. You will not see any secrets or machines until the owner adds you to a project.
Permissions
Permissions are granted per-project. A team member with access to one project has zero access to other projects in the same vault unless explicitly granted.
Secret Access
Adding a team member to a project gives them full secret management within that project: view metadata, create, delete, replace, version history, and notes.
Important: "view" means secret metadata (name, note, version, machine count). The dashboard never displays decrypted secret values. Reading the actual plaintext requires an authenticated machine with a per-secret grant.
Machine Permissions
Machine permissions are self-scoped. They let a team member manage only their own machines in a shared project, never the vault owner's machines or another member's. Granted explicitly per project.
| Permission | What it allows |
|---|---|
machine_view | See the member's own machines in the project |
machine_add | Attach the member's own machines to the project |
machine_remove | Detach the member's own machines from the project |
machine_configure | Change which of the project's secrets the member's own machines can access |
Provision Permissions
Provision permissions govern capabilities that mint identity material out of SikkerKey. Kept separate from machine permissions because the trust decision is different (the keypair is delivered to the member, not bound to a machine they already control).
| Permission | What it allows |
|---|---|
machine_provision | Pre-provision machine identities for containers in the project. Generates an Ed25519 keypair server-side and delivers it to the member once as a downloadable bundle. |
Policy Permissions
Policy permissions govern the access constraint layer for the project's secrets. Kept separate from both machine and provision permissions because shaping access constraints is the power to weaken security on credentials someone else owns. Bundling that with secret management or machine permissions would make every team member with project access a de-facto policy author, which defeats the constraint layer entirely.
| Permission | What it allows |
|---|---|
policy_manage | Create, edit, and delete access policies in the project; bind and unbind secrets to those policies. See Access Policies for the full model. |
The permission is binary by design. A read-only or attach-only split would create real security gaps (an attach-only member could bind any secret to an existing over-permissive policy; a read-only member could disclose the constraint shape attackers use to plan around). Either you can shape how this project's secrets are accessed, or you cannot.
Without policy_manage, the Policies sub-page is hidden from the project sidebar and every CRUD plus binding route returns 403 server-side.
A team member with no machine, provision, or policy permissions can still fully manage secrets in their assigned projects.
Managing Permissions
Click Permissions on a team member row to open the permissions modal.
Adding Project Access
Use the dropdown at the top of the modal to select a project, then click Add. This adds the project to the member's access list, granting them full secret access in that project.
Granting and Revoking Permissions
Click a project in the member's access list to expand the permission editor. Permissions are displayed in two columns:
- Available: permissions not yet granted.
- Granted: permissions currently active.
Each column groups permissions by category (Machine Permissions, Provision Permissions, Policy Permissions) with a category header. Individual permissions have a ? help icon that describes what the permission grants when hovered or keyboard-focused.
Click an individual Grant or Revoke button to flip one permission. Or tick the checkboxes on multiple rows and use the bulk Grant / Revoke action in the column header. Click Save permissions to apply changes. The team member is notified in real time if they are online.
Removing Access to a Project
Click the x button next to a project in the permissions modal to remove the member from that project entirely. This revokes all permissions for that project, detaches any of the member's machines from it, and revokes those machines' grants on the project's secrets. The member keeps their membership in the vault and any other projects they have access to.
Team Members Table
The Teams page shows a table of all team members with:
- Username and email
- Joined date
- Projects: chips showing which projects the member has access to
- Permissions button: opens the permissions modal
- Remove button: removes the member from the vault
Search, sort, and filter are available for vaults with many team members.
Removing a Team Member
Click Remove on a team member. This permanently:
- Removes their team membership
- Deletes all their project access and permission grants across every project
- Detaches every machine the member had attached to any of your projects
- Revokes those machines' grants on every secret in your projects
The member loses access immediately. Shared projects disappear from their sidebar. A team_revocation entry is recorded on the member's own audit log so they have visibility into the event on their side. This cannot be undone. You would need to re-invite them to restore access.
Machines the member owned outside your vault, and secrets those machines had already fetched and stored, are outside SikkerKey's control. Rotate any secrets that might have been captured if the removal is a response to compromise.
What Team Members See
After accepting an invite and being added to projects, the vault owner's projects appear in the team member's sidebar grouped under the owner's username.
Team members see secret metadata (names, notes, versions, field names, machine counts) in projects they've been added to. They never see decrypted secret values through the dashboard.
Machine pages are gated by the machine_view permission. Without it, the team member cannot see the project's machines tab.
If the vault owner's account is suspended, all team member access to that vault is blocked immediately. Team members are not informed of the suspension reason.
Audit Trail
All team-related operations are audit-logged. See Audit Logging for the full severity classification of each action.
| Action | Logged for |
|---|---|
team_invite | Vault owner |
team_invite_accepted | Vault owner |
team_invite_declined | Vault owner |
team_invite_cancelled | Vault owner |
team_joined | Team member |
team_member_remove | Vault owner (owner-initiated full removal) |
team_revocation | Team member (mirrored entry on the member's log when the owner removes them) |
team_project_remove | Vault owner (owner-initiated per-project removal) |
team_project_revocation | Team member (mirrored entry for per-project removal) |
team_left | Vault owner and team member (member-initiated departure) |
team_permission_update | Vault owner |
Actions performed by team members on shared projects (creating secrets, attaching machines, configuring access, pushing sync, provisioning containers) are logged primarily under the vault owner's audit trail with the team member named in the detail. For operations that change state on the member's own side as well (attaching or detaching their own machine, granting secret access on their own machine), a secondary entry is mirrored to the member's audit log so both sides have visibility.