SikkerKey FAQ

#What's the difference between machine authentication and the bearer tokens every other secrets manager uses?

A bearer token is a string the workload presents on every API call to prove identity. Anyone who reads the string can present it back and authenticate. Most secrets managers issue these tokens at deploy time and route them through the workload's environment or filesystem.

SikkerKey uses Ed25519 signed requests. Each request carries a signature computed on the machine from a private key that never leaves the host. The signature commits to the method, path, body, timestamp, and a one-time nonce, so it's only valid for that exact call. The next request needs a new signature; nothing about the previous one is reusable.

The practical difference: a bearer token remains a working credential until it expires or is rotated. A signature on a captured request is already invalid by the time anyone reads it, and the private key that produces signatures never leaves the machine. More on the underlying model: machine authentication.

#Why are AI agents treated as a separate identity class?

AI agents on a vault typically need to manage things: rotate secrets, configure access policies, audit reads, attach machines to projects. Reading the actual values of stored secrets isn't part of that job, and granting an agent that capability widens the attack surface every operation it performs against the vault.

SikkerKey models agents as a distinct identity class in a separate database table, with their own scope catalog (machines, projects, policies, audit, alerts, and so on). The routes that return decrypted secret values look up the machine table; they physically don't accept an agent identity as a caller. An agent granted every management scope still can't fetch a stored secret, because the read path doesn't recognize agents at all.

The boundary is the database schema rather than a policy check applied at request time, so the separation lives in the data layer itself. More on the model: AI agents.

#How are secrets protected at rest?

Each secret is encrypted with its own AES-256-GCM data key. That data key is encrypted with a per-project master key, which in turn is encrypted with a decryption root that lives only in memory while SikkerKey is running. The decryption root is never written to disk, and it isn't held in a managed KMS — it's supplied at boot and held in process memory.

Each version of a secret has its own data key, so rolling back to a prior version means decrypting that version's row independently. Old versions stay decryptable across the secret's lifetime without sharing keys with newer ones.

#How does rotation work without breaking my application?

You install an agent on a host where the database is reachable: a Kubernetes pod, an EC2 instance, an on-prem box, anywhere a single binary can run. When a rotation triggers, SikkerKey generates a new credential and writes it as a pending value. The agent applies it to the database via the admin protocol, opens a fresh connection with the new credential, and confirms back that the connection works. SikkerKey only then promotes the new value to live.

Your application keeps reading the previous value during the rotation. The new credential becomes the live one only after the agent has proven it works against the database.

Supported providers: PostgreSQL (including the Supabase variant), MySQL, Redis, and MongoDB. The agent host is a regular SikkerKey machine, provisioned via the same enrollment or temp-bootstrap flow as any other machine in your vault.

#What's a canary secret, and when would I use one?

A canary is a decoy secret you plant inside a project alongside real ones. It looks identical to any other secret to whatever reads it: same fetch endpoint, same returned plaintext value, same metadata shape. It isn't connected to any real system.

The first time any machine reads a canary, the entire project locks down in the same database transaction as the fetch, before the next secret request in that project can return. An optional second layer extends the lockdown to every other project the same machine has access to.

Use it on a high-value project where you want a tripwire. The canary trips on the read of itself, not on the read of any real secret, so the first attempt is the trigger.

#Does SikkerKey lock me into a specific cloud?

No. The signed-request auth proves which machine made the call from a key that lives on the machine itself. It doesn't depend on a cloud identity broker like AWS IAM, GCP Service Accounts, or Azure Entra ID.

The same bootstrap script runs on EC2, GKE, AKS, a Hetzner box, a Vercel function, a Fly machine, an on-prem rack, or a developer laptop. There's no federation layer to set up for cross-cloud or non-cloud workloads, no IAM Roles Anywhere trust anchor to maintain, no OIDC bridge to configure.

One vault grants and audits machines across whichever cloud or on-prem environment they happen to be running in.

#Can SikkerKey run on-prem?

SikkerKey is a SaaS product — the vault, dashboard, API, audit log, and rotation worker run on SikkerKey's infrastructure. Your workloads run wherever you run them.

The machine-auth model was designed specifically so on-prem workloads aren't second-class. A Hetzner box, an on-prem rack, or a colocated server bootstraps with the same script as an EC2 instance and signs every request from a local key. The vault treats it the same as any cloud-hosted machine.

If running the vault itself in your own data center is a hard requirement, SikkerKey isn't the right choice; it's SaaS-only.

#How do CI runners and temporary worker machines get vault access?

For CI fleets and autoscaling pods, you issue an enrollment token from the dashboard. The token registers new machines on first contact, applies pre-baked project and secret grants, and auto-expires the machine after its lifetime. Optional constraints on the token: hostname regex match, source CIDR range, name template. Auto-expired machines are soft-disabled and hard-deleted 30 days later.

For a single temporary worker, a one-off TTL-bounded server, or a contractor laptop, you issue a single-use temp-bootstrap token. The token mints one machine with a configurable lifetime (between 1 hour and 12 months), an optional per-machine IP allowlist, ISO-3166 country allowlist, and IANA time-of-day window. Extensions are audited inline with full revert history.

#How does pricing work?

A flat monthly subscription. Each plan has stated limits on machines, projects, secrets, team members, secret versions, audit retention, webhooks, and a few other axes. Within those limits everything is included: rotations, webhook deliveries, SDK / CLI / MCP downloads, integrations, and support.

The subscription price doesn't change with how many secrets you store or how often your workloads fetch them. Outgrowing a plan moves you to the next tier rather than ringing up overage charges.

#Is there a free tier?

Yes. The free tier covers a small number of machines, projects, secrets, and team members, with audit retention bounded to a shorter window than paid tiers. It has no time limit — it's a permanent plan, not a trial.

Paid plans raise the limits and add features (more team members, longer audit retention, more webhooks, additional integrations); see the pricing page for current numbers.

#Do you charge per user, per secret, or per API call?

No to all three. The plan price is the same whether your vault holds 5 secrets or 500 (within the plan's secret limit), whether your application fetches once an hour or once a second, and whether your team has 2 people or 20.

Larger teams that need more team-member seats move to a plan with a higher limit rather than paying per seat. The same applies to secret count, project count, and the rest of the limits. There are no per-call, per-stored-secret, or per-seat charges added at the end of the month. See pricing for the current limits per tier.

#How is SikkerKey different from other secrets managers?

Most secrets managers authenticate workloads with a bearer token presented on every API call. AWS Secrets Manager uses IAM-issued bearer tokens from STS. Doppler uses Service Tokens (dp.st.*). The other cloud-native and SaaS-native managers in this space follow the same pattern: a token the workload reads from its filesystem or environment and presents on each call to authenticate.

SikkerKey replaces the bearer token with per-call Ed25519 signatures. Each request is signed on the machine from a private key that never leaves the host, and the signature commits to the exact method, path, body, timestamp, and one-time nonce. It's only valid for that specific call; the next request needs a new signature, and there's no transferable credential sitting on the workload's filesystem to leak.

Around that primitive, SikkerKey ships several features other secrets managers don't have natively: structured secrets with per-field grants, canary secrets that lock a project on first read, an AI agent identity class that's structurally read-blind on stored values, temporary machines with IP / country / time guardrails, and HMAC-signed webhooks with SSRF protection.

Side-by-side comparisons:

• SikkerKey vs AWS Secrets Manager
• SikkerKey vs Doppler