Projects
How projects group secrets, machines, and access in SikkerKey.
Projects are the organizational unit inside your vault. Every secret belongs to exactly one project. Machines are added to specific projects. Team members are granted access to specific projects. Nothing crosses a project boundary without an explicit grant.
Creating a Project
From the Overview page, click the + icon on the Projects card to open the new project dialog. The sidebar also has a + next to the Projects label that opens the same dialog.
Name the project (up to 100 characters), optionally add a description, and create. It appears in the sidebar under Projects.
Project IDs
Every project gets a unique ID in the format proj_ followed by 10 random alphanumeric characters (e.g. proj_x9y8z7w6v5). The ID is what you pass to the SDK and CLI. You can copy it from the project header on the secrets page.
What a Project Groups
- Secrets you create inside it (single-value, structured, managed, or TTL)
- Machines you have added to it
- Team members you have granted access to
- Access policies scoped to it (see Access Policies)
Adding any of these to a project never implies access by itself. Each relationship is a separate explicit grant.
The project sidebar surfaces three sub-pages for each project: Secrets, Policies, and Machines. Policies are project-scoped reusable bundles of access constraints (time windows, IP allowlists, rate caps, co-sign, lifecycle triggers) that you bind to secrets opt-in. Read the dedicated Access Policies page for the full model.
Machines in a Project
A machine registered with your vault is not automatically in any project. From the project's Machines tab, click the + icon (hover tooltip: "Add machine to project") and pick the machine.
Adding a machine only makes it eligible to receive secret grants in the project. It cannot read anything until you configure the grants.
Granting Secret Access
Click Configure next to the machine to open the access panel. Move secrets from Available to Granted and save. The machine can now read the granted secrets and nothing else.
There is no wildcard, no "grant all", no inheritance. A machine in a project with access to the database password cannot read the Stripe key in the same project unless you grant it explicitly.
To revoke access, move secrets back to Available and save. The revocation takes effect on the machine's next request.
Removing a Machine from a Project
Removing a machine from a project revokes all its secret grants within the project immediately. The machine itself stays registered in your vault and can be added to other projects without re-bootstrapping.
Team Members
Team members are added to specific projects, not to the vault as a whole. A team member sees only the projects they have been granted access to.
Within an assigned project, a team member can fully manage secrets: create, update, delete, replace values, view version history, edit notes. Secret management in the dashboard never exposes plaintext. Reading the raw value always requires an authenticated machine with a per-secret grant, regardless of team permissions.
Granular Permissions
Beyond basic project access, each of the following can be granted individually per member per project:
| Permission | 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 |
machine_provision | Pre-provision machine identities for containers in the project |
policy_manage | Create, edit, and delete access policies in the project; bind and unbind secrets to those policies |
Machine and provision permissions are self-scoped. A team member can manage their own machines or provision identities they control in a shared project, never the vault owner's or another member's.
policy_manage is the one project-scoped permission that affects every member's access to bound secrets, not just the holder's. It is the power to shape (and therefore weaken) the constraint layer applied to credentials owned by the vault owner. Grant deliberately.
Permissions are configured from the Teams page.
Renaming or Editing
In the sidebar, hover over a project to reveal the edit icon. Click it to open the edit dialog and update the name or description. This is a metadata-only change: encryption, machines, secrets, and grants are unaffected.
Deleting
Hover over a project in the sidebar to reveal the delete icon. Deletion requires you to type the project name exactly as confirmation.
Deleting a project permanently removes:
- All secrets in the project, including full version history
- All rotation schedules and managed secret agent configurations
- All TTL secrets created in the project
- All access policies scoped to the project, and the bindings that referenced them
- All machine-to-project memberships for this project
- All machine-to-secret grants for the project's secrets
- All team member permission rows scoped to this project
Machines and team members remain in your vault. They lose only their relationships to the deleted project.
This cannot be undone.