Concepts

Definitions for the things you work with in SikkerKey, organized for lookup. For how they fit together as one story, read the Introduction; for a hands-on walkthrough, see Quickstart.

Vaults and projects

Vault

Your vault is the top-level container that owns everything else: projects, secrets, machines, members, and billing. It has a public ID like vault_a1b2c3d4e5 that machines use to find it. A vault is either personal, where you are the only person who acts on it, or an organization, where you have invited members. See Organizations.

Application

An application is one service, and creating it sets up the same three projects together: a prod, a staging, and a dev. The three are managed as a set, so you do not rename or remove them on their own, and deleting the application removes all three. An application is an organizing layer in the dashboard only and has no effect on access, which always resolves per project. See Applications.

Project

A project holds secrets and the machines allowed to read them, and it carries its own encryption key. Every secret belongs to exactly one project. A project is either one of an application's three or standalone, in which case you name it whatever fits.

Secrets

Secret

A secret is a value you store, like an API key, a password, a token, or a certificate. Each secret belongs to one project, and a machine reads it only through a grant.

Secret types

A stored secret is one of five types:

• Single secret. One value with a name, read with getSecret(). Can rotate on a schedule.
• Structured secret. Several named fields, like host, username, and password, in one secret, read whole or field by field. Fields rotate individually.
• Managed secret. A database credential that SikkerKey rotates on a schedule and applies to your database through a local sync agent. See Managed Secrets.
• Leased credential. An on-demand database login that SikkerKey mints per machine at read time, governed by a lease policy, and removes when the lease ends. See Leased Credentials.
• Canary. A tripwire credential. The moment a machine reads it, SikkerKey freezes the project, records a critical audit event, and fires every alert set for it, while still returning the value so the intruder keeps moving. See Canary Secrets.

TTL secrets are a separate thing: one-time share links for handing a credential to a person, protected by a passphrase and destroyed on first view. Machines cannot read them.

Rotation

Any single or structured secret can rotate on a schedule you set, with an interval, length, and character set; structured secrets rotate per field. Managed secrets always rotate. Each rotation creates a new version.

Versioning and trash

Every change to a secret's value keeps the previous version, so you can roll back, with no per-plan cap on history. A deleted secret moves to the trash and stays recoverable for 30 days before it is removed for good, along with its machine grants and rotation schedule.

Machines

Machine

A machine is any server, container, or job that reads secrets. It holds an Ed25519 keypair and is registered to your vault. Before it can read anything, you approve it and it must be enabled, and you add it to the projects it needs and grant it specific secrets there. Every request it makes is signed with its key. See Machines and the signature scheme.

Machine kinds

• Standard. A long-lived machine with no expiry, registered either by running a one-time bootstrap command on the host or by pre-provisioning it from the dashboard for a container.
• Ephemeral. A short-lived machine that a CI runner or autoscaled host enrolls for itself with an enrollment token, under a policy that fixes its projects, secrets, and lifetime. It expires on its own.
• Temporary. A single time-boxed machine for a scoped job like a contractor engagement or an incident, with an expiry from one hour to twelve months and optional per-machine guardrails on IP, country, and time of day. See Temporary Machines.

Grant

A grant is the single connection between one machine and one secret. A machine reads a secret only when you have granted it that exact secret; adding a machine to a project does not, on its own, give it any secret in that project.

Access

Access requirements

For a machine to read one secret, a few things have to hold: its request signature verifies, with a timestamp inside a five-minute window and a nonce it has not used before; the machine is approved and enabled; the project is not frozen; the machine is in the project; and it holds a grant for that secret. The Security overview covers the full check in order.

Access policies

A secret can be bound to an access policy that adds conditions on every read: a time window, a per-secret IP allowlist, a read-rate cap, a co-signer, a TTL that destroys the secret after a set time or number of reads, or a rotation once it has been read N times. Policies are opt-in; an unbound secret uses the requirements above. See Access Policies.

IP allowlist

You can turn on a vault-wide IP allowlist so machine requests are refused unless they come from a CIDR range you listed. It is checked before the signature. See IP Allowlist.

Organizations and AI agents

Organization

Converting a vault to an organization lets more than one person act on it. Each member signs in as themselves and is scoped by two roles: a vault role for what they manage across the vault, and an access role for which projects they reach and what they can do there. See Organizations.

AI agent

An AI agent is a separate identity for an AI client like Claude Code or Cursor to manage your vault. It can work with projects, policies, canaries, machines, the audit log, and more, but no tool returns the plaintext of a stored secret. Its scopes and project reach are set in the dashboard. See the MCP server.

Audit and encryption

Audit log

Every action on the vault is written to an append-only audit log, each entry carrying a severity from info to critical. Entries stream to the dashboard live and can trigger email or webhook alerts. See Audit Logging.

Encryption

Every secret is protected with envelope encryption: a per-secret data key, wrapped by a per-project key, wrapped in turn by a root key that lives on separate, isolated infrastructure. See the Security overview for the full model.