Machines

What it is

A machine is any non-human actor that needs access to secrets: a backend server reading a database password, a CI runner pulling deployment credentials, a Kubernetes pod fetching API keys, an AI agent that calls internal services on your behalf. The defining property is that nobody is physically present to type a password. The actor authenticates with cryptography it carries, not with a session a human signed into.

The category goes by several names in the industry. Non-human identity (NHI) is the analyst-popularized term that's taken off since 2024, with a wave of vendors building products around it. Workload identity is the cloud-native term (GCP, Azure, and Kubernetes all use it for pod-bound and VM-bound identities). Machine identity is the older umbrella, used by SPIFFE/SPIRE and most secrets managers. SikkerKey calls them machines.

Why they're treated differently from users

Users are short-lived presences. A person signs in, does a few things, signs out. Their credentials carry session state, MFA challenges, sometimes an SSO redirect. Machines are constant presences. A CI runner that builds 200 times a day. A container that starts 10,000 pods a week. A backend that never sleeps. You can't put MFA in front of them and you can't ask them to log in interactively.

The structural problem this creates is that machine credentials accumulate. Every service that needs to talk to every other service needs a credential. Without dedicated machine identities, the answer historically has been long-lived bearer tokens stashed in .env files, config maps, or whatever the platform's "secret" primitive happens to be. Each of those is one leak from being abused, and each is shared across enough places that rotation is painful.

A real machine identity model gives every workload its own credential, scoped to exactly what that workload needs, with its own audit trail. A leaked CI runner credential doesn't let an attacker read your production backend's secrets, because they're held by a different machine identity with different grants.

Common kinds

• Long-running services. Backend processes, schedulers, daemons. One identity per service is typical.
• Containers. A pod or container gets an identity that lives as long as it does. Restart counts as a new instance, depending on the platform.
• CI runners. Build agents and pipelines. Usually one identity per job context, ephemeral or per-environment.
• Cron jobs and scheduled workers. Same as services but with thinner permissions.
• AI agents. A new category in 2024-2025: an MCP server or coding agent that calls APIs on your behalf. Same model, sharper access boundaries because the agent's instructions come from a context window an attacker might be able to influence.

How SikkerKey treats them

In SikkerKey, every machine has:

• An Ed25519 keypair. Generated locally on the machine during bootstrap; SikkerKey only ever sees the public key. Every request to the API is signed with the private key, and replay-protected by a ±5 minute timestamp window and per-machine nonce tracking.
• A name and a vault. Each machine belongs to exactly one vault and carries a name set during enrollment.
• An approval state. A newly bootstrapped machine starts as pending until you explicitly approve it from the dashboard. Pending machines can authenticate but cannot read anything. This stops a stolen bootstrap link from auto-granting access.
• An enabled flag. Lets you disable a machine without deleting it, useful when you want to investigate before you decide.
• A kind. standard for long-lived machines, ephemeral for fleet-enrolled identities with an expiry, or temp for single time-bounded identities (contractor-style work). The kind drives how SikkerKey handles expiration and cleanup.
• Project grants and per-secret grants. A machine has to be added to a project (project_machines), and then explicitly granted each secret it can read (machine_secrets). No grants means no reads, even with a valid signature.

Vault owners can turn on an IP allowlist that gates all machine authentication for that vault. With it enabled and empty, every machine request is refused. The allowlist applies to machines only. Humans signing into the dashboard aren't affected, so you can lock down workload access without locking yourself out.

A machine's audit trail records every read, every failed authentication, every grant change, and the IP each request came from. If a machine ever reads a canary secret, the project freezes before the response goes out and a CRITICAL alert fires.