SikkerKey vs Infisical
Both manage secrets for applications and machines, but they authenticate workloads differently. SikkerKey signs every request from a private key that never leaves the machine; Infisical issues an access token from a Machine Identity's client secret, and the workload carries that token on every read.
Summary
Infisical and SikkerKey both manage secrets for applications, machines, and people, and overlap on the basics: encryption at rest, rotation, versioning, audit logging. They part ways on the one question that decides how exposed a workload is: what authenticates a request to read a secret.
Infisical authenticates with tokens. A Machine Identity using Universal Auth, the platform-agnostic method, holds a Client ID and Client Secret that Infisical's docs describe as akin to a username and password. It trades them for an access token, and that token is sent in the Authorizationheader on every secret read. The Client Secret defaults to infinite lifetime and unlimited uses, and the access token's default lifetime is 30 days. Both are values that have to live on the workload to be usable, which means they can be read off it.
SikkerKey authenticates every request with an Ed25519 signature computed from a private key that never leaves the machine. The request itself proves which machine made it. The signature commits to the exact method, path, body, and timestamp, so it is useless the moment the request is sent, and there is no token sitting on the workload for the next 30 days. The private key signs but is never transmitted, so the machine never holds a credential anyone could copy and replay.
Around that primitive, SikkerKey ships things Infisical has no native answer for: 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, and time-of-day guardrails baked in at issuance, and CI fleet enrollment from a single token.
The result: a model where the secure behaviour is the default, and a flat per-vault price rather than per-identity billing.
| SikkerKey | Infisical | Why it matters | |
|---|---|---|---|
| Machine authentication | |||
| Secret request | Ed25519 signed request. The signature is computed on the machine from a private key that never leaves it, and SikkerKey verifies it against the public key on file. | A Machine Identity trades its credential for an access token, which the workload then sends in the Authorization header on every secret read. The access token's default TTL is 30 days, and an Access Token Period can be set to make it never expire. | The signature is bound to one specific request and stops being valid the moment that request is sent. The next call needs a new signature, computed on the machine from the same private key, which stays on the host. There is no token sitting on the workload that keeps working for the next 30 days if it leaks. |
| Bootstrapping (secret zero) | Each machine generates its own Ed25519 keypair locally at bootstrap; the private key is written once on the host and never transmitted. A single-use bootstrap token registers the public key, so the value that authenticates the machine is created on the machine. | Universal Auth, the platform-agnostic method, hands the workload a Client ID and Client Secret that Infisical's own docs describe as akin to a username and password. The Client Secret defaults to infinite lifetime and an unlimited number of uses, so unless an operator tightens it, the machine holds a permanent reusable credential on disk. | Nothing the machine stores is a credential another party could read and reuse against the API. The private key signs requests but is never sent, so there is no stored client secret or bearer token to rotate, leak, or exfiltrate from the host. |
| CI fleet enrollment | One enrollment token registers up to N ephemeral machines, each with a hostname regex match, source CIDR check, and an automatic expiry. Auto-expired machines are soft-disabled and hard-deleted 30 days later. | No single enrollment-token primitive. CI runners onboard as individual machine identities, each provisioned and revoked on its own, or through per-platform auth methods. | An enrollment token issued from the dashboard provisions identities for new CI runners as they come online and revokes them when their machines disappear. Setting up a new runner means dropping a generated curl command into its startup script; per-runner credential management isn't something an operator has to track separately. |
| Identity primitives | |||
| AI agent identity | AI agents are a separate identity class with their own table, scope set, and Ed25519 signed-request authentication. The agent surface is structurally plaintext-blind: write actions accept plaintext input but never return stored values, and the read paths physically don't accept an agent identity as a caller. | Infisical markets itself for agents, but an agent there is a standard machine identity. Granted secret-read scope, it reads stored values like any other identity; no identity class is structurally barred from reading them. | Give an AI agent broad management permissions on your vault without any risk of it reading your secrets. The agent identity is structurally plaintext-blind, so even an agent granted every management scope cannot fetch a stored value. |
| Temporary machines | Single-use bootstrap tokens that mint time-bounded machines with optional per-machine IP allowlist, ISO-3166 country allowlist, and IANA time-of-day window. Bounded between 1 hour and 12 months at issuance; extensions are audited inline with full revert history. | Access can be time-bounded through token TTLs and Temporary Access Provisioning, and source IPs restricted through IP Allowlisting. Both sit behind the paid Pro tier, and per-machine country allowlists and time-of-day windows baked into the identity at issuance aren't expressible. | The bootstrap token bakes in the time window, source IP range, country allowlist, and lifetime at the moment of issuance. Those constraints attach to the machine identity itself, so they apply at every fetch without anyone having to remember to enforce them later, and they're part of every plan. |
| Secret model | |||
| Structured secrets | A secret can hold multiple named fields as one logical unit. A database credential is one secret with host, port, username, password fields, encrypted and versioned together. SDKs read fields directly. | Secrets are string key-values, with referencing and folders for organization. A single secret holding multiple named fields, each with its own access grant, rotated and versioned as one object, isn't a native primitive. | The whole credential rotates and audits as a single object, and each field can carry its own access grant. SDKs expose each field directly, so application code reads secret.password rather than parsing a serialized blob to find the field. |
| Database credential rotation | The agent runs on the host you choose: a Kubernetes pod, an EC2 instance, an on-prem box. SikkerKey generates the new value, the agent applies it via the database's admin protocol, verifies it works, then confirms back so SikkerKey promotes it as the new live version. Supports PostgreSQL, MySQL, Redis, MongoDB. | Infisical rotates static secrets on a schedule and issues dynamic secrets on demand from a broad set of engines. Scheduled rotation requires Pro and dynamic secrets require Enterprise, and Infisical connects to the database from its own side rather than an agent on your application host that connection-tests the new credential before promoting it. | Run the rotation agent on the host where your application already lives. The agent applies the new credential and tests a connection against the database before reporting back; SikkerKey only promotes the new value after that test passes. It's part of the platform rather than a tier you upgrade into. |
| Access controls | |||
| Per-secret access policies | Named policies you bind to specific secrets. Each policy can require a time window, an IP allowlist, a read-rate cap, a co-signing machine, TTL-based destruction, or rotate-after-N reads, in any combination. One policy binds to many secrets, and policies are part of every plan. | Access is governed through role-based access controls, approval workflows, and access requests. RBAC sits behind Pro and approvals behind Enterprise, and read-rate caps, co-signing machines, TTL-based destruction, and rotate-after-N-reads aren't expressible on an individual secret. | Lock down a high-value secret with constraints SikkerKey enforces at every fetch: time windows, IP allowlists, read-rate caps, co-signing, TTL destruction, or rotation triggers. The enforcement runs server-side, so the application receives either the secret value or a denial. |
| Canary secrets | A decoy secret you plant in a project alongside the real ones. Looks identical to any other secret to whatever reads it. | Not a native primitive. | A compromised machine in your vault triggers a complete project lockdown the first time it reads a canary, in the same database transaction as the fetch, before more of your secrets can be returned. An optional second layer extends the lockdown to every other project the same machine has access to. |
| History & observability | |||
| Audit log | One append-only log for every vault action by any actor (machine, AI agent, organization member, or you). Each entry carries action, actor, source IP, and a severity tag from info to critical. Critical events are exempt from the retention window and stay forever. | Infisical records audit logs. Retention is a Pro feature with a 90-day window; longer custom retention and streaming logs to a SIEM are Enterprise. | Critical events (canary trips, 2FA disabled, vault destruction) stay in the log forever regardless of your plan's retention window. Every entry streams live to your dashboard and exports to CSV for SIEM ingestion. |
| Alerts and webhooks | Email and webhooks for any of 60+ audit actions, opt-in per action. Webhook deliveries are HMAC-SHA256 signed, retried with exponential backoff, SSRF-protected by DNS pinning, and auto-disabled after 10 consecutive failures. | Webhooks fire on secret changes and failed rotations, with HMAC-SHA256 payload signing via a secret key (an x-infisical-signature header). Triggers are limited to those two events, rather than opt-in across the full range of audit actions. | Wire any audit action to email or to an HMAC-signed webhook, opt-in per event. The delivery layer retries with exponential backoff, refuses to call internal or private-range addresses, and auto-disables an endpoint that fails 10 deliveries in a row. |
| Operational | |||
| Pricing model | Flat monthly plans with a free tier and public pricing. Unlimited projects and secrets, no metering on stored secrets or API calls, and team size doesn't change the price. Each plan includes a set number of machines; additional machines are a flat per-machine monthly add-on. | Per-identity pricing at $18 per identity per month on Pro, and the identity count includes machine identities, not only human users. Controls like RBAC, IP allowlisting, and audit-log retention sit behind Pro, with dynamic secrets, SCIM, LDAP, and approvals behind a custom-priced Enterprise tier. | The SikkerKey bill doesn't move with team size or secret count. Pricing is public and flat per plan, and controls like per-secret policies, IP allowlists, and canary secrets are part of every plan. The one usage-based element is machine count beyond your plan's allotment, billed at a flat published per-machine rate. |
| Data residency | Stored secrets live only in the EU, on EU-owned infrastructure, under a single European jurisdiction. | Infisical Cloud offers a US region and an EU region. Both run on AWS, a US-headquartered hyperscaler, so the EU region's data sits on infrastructure operated by a US company. | For an EU team that needs its secrets to stay under European jurisdiction, the storage layer never sits with a US hyperscaler. There is one region and one legal regime, with nothing to configure to keep data in the EU. |