What Is a Secrets Manager?

What a secrets manager is

A secrets manager is a tool that stores the credentials your software runs on, things like API keys, database passwords, TLS private keys, and OAuth tokens, and serves them to the machines and people authorized to use them at runtime. The credential lives in one encrypted, access-controlled system instead of being copied into .env files, baked into container images, or committed to a config file.

In practice it changes one habit. Instead of putting a database password on every server that needs it, you store it once in the secrets manager and each service fetches it when it starts. The credential moves out of source code, off laptops, and out of CI logs, into a system that encrypts it at rest, decides who can read it, logs every access, and rotates it on a schedule.

That is the whole job: keep secrets in one place, control who can use them, and keep a record of who used what.

Why secrets management matters more than ever

Secrets leak constantly, and most of the leaks never get cleaned up.

GitGuardian's State of Secrets Sprawl 2026 found 28.65 million new hardcoded secrets pushed to public GitHub in 2025 alone, a 34% jump over the year before and the largest single-year increase they have recorded. That is only the public surface. Internal repositories leak at roughly six times the rate of public ones.

The number that should worry you more is what happens next. 64% of the secrets GitGuardian confirmed valid in 2022 were still valid at the start of 2026. A leaked credential is not a one-time event. Left alone it is a working key sitting in a git history, a Slack message, or a backup, waiting for someone to try it. The same report ties the majority of policy breaches to long-lived secrets that were never rotated.

This is what a secrets manager exists to do: make credentials short-lived, scoped, traceable, and replaceable, so a leak becomes a contained incident instead of a standing liability.

What a secrets manager does

A real secrets manager does more than store strings. The core functions:

• Centralized, encrypted storage. Every secret lives in one system, encrypted at rest. You stop tracking which server holds which copy of which password.
• Access control. You decide which applications, machines, and people can read each secret, ideally down to the individual secret rather than all-or-nothing.
• Authentication. Before handing over a value, the manager has to know who is asking. This is the part that varies most between tools, and it matters more than any other feature.
• Rotation. Good managers replace a secret's value on a schedule or on demand and update it everywhere it is used, without an outage.
• Audit logging. Every read, change, and grant is recorded, so after an incident you can answer "who accessed this, and when" instead of guessing.
• Distribution. The manager delivers secrets to applications, CI pipelines, containers, and increasingly AI agents, through SDKs, a CLI, or an API.

How a secrets manager works

The lifecycle is similar across tools, even when the implementations differ:

1. Store. You add a secret. The manager encrypts it and records metadata: name, version, who created it.
2. Authenticate. A workload asks for the secret and proves its identity. How it proves that is the crux of the whole model.
3. Authorize. The manager checks whether that identity is allowed to read that specific secret.
4. Deliver. If the check passes, the value is decrypted and returned over an encrypted channel.
5. Audit. The access is written to an append-only log.
6. Rotate. On a schedule or on demand, the value is replaced and the old one retired.

Step two is where secrets managers quietly diverge, and where most of the risk lives.

Secrets managers vs .env files and environment variables

Plenty of teams "manage" secrets with a .env file and call it done. It works until it doesn't.

A .env file is a plaintext copy of a credential sitting on disk. It gets committed by accident. It gets shared over chat. It survives in shell history, CI logs, container layers, and backups. There is no access control, no rotation, and no record of who read it. GitGuardian's report found that 28% of secret incidents now originate entirely outside code repositories, in tools like Slack, Jira, and Confluence, which is exactly where a .env file ends up when someone needs to pass it along.

A secrets manager replaces the copy with a fetch. The credential is never written into your repo, it is retrieved at runtime by something that proved it was allowed to, and that retrieval is logged. Environment variables are fine as a delivery mechanism, injecting a secret into a process at runtime is a reasonable pattern. The problem is storing them as flat files anyone can copy.

Why teams avoid secrets managers

If secrets sprawl is this bad and the fix is this well understood, why do so many teams still keep their database password in a .env file?

The honest answer is complexity. Many secrets managers, especially the self-hosted ones, are a second system to learn and operate. Before you can store your first secret you are reading about seal and unseal procedures, an access-policy language, secret engines, leases, and storage backends. For a small team trying to ship a product, that is a crash course in vault administration nobody asked for, and the tool meant to reduce risk becomes a project of its own. The project gets postponed, and the .env file stays.

So the security gap in GitGuardian's numbers is partly an adoption gap. Teams know they should centralize their secrets. They just never find the week to stand up and learn the tooling, and an unused secrets manager protects nothing.

The way out is a secrets manager that does not ask you to become a vault operator before it does anything useful.

What separates a good secrets manager from a liability

Once you have decided to use one, the differences that matter are not the feature checklists. They come down to a few questions.

How does it authenticate a machine? Most secrets managers hand a workload a bearer token: a long string that proves identity by possession. Whoever holds the token is the machine, as far as the system is concerned. That token has to live on the workload to be usable, which means it can leak the same way every other secret leaks, and a copied token works from anywhere until someone notices and revokes it. It is the circular problem at the center of secrets management: you protect your secrets with another secret. A stronger model authenticates each request with a cryptographic signature from a key that never leaves the machine, so there is no reusable credential to capture in the first place. We covered why that distinction matters in depth.

Can your team actually run it? Features mean nothing if the tool sits unused. A secrets manager that needs a dedicated operator and a policy-language tutorial loses to the .env file every time. The one worth picking is quick to set up, obvious to operate, and out of the way once it is running.

Can you scope access per secret? Least privilege only works if you can grant one machine exactly the secrets it needs. All-or-nothing access means one compromised workload exposes the whole vault.

Does rotation actually verify? Rotating a database password is useless if the new value breaks the application. Rotation worth having applies the new credential, confirms it works, and only then promotes it as live.

Is the audit trail usable? Every manager claims an audit log. The useful ones let you filter by actor, action, and severity, keep critical events forever, and export to your SIEM.

What happens when an AI agent connects? This used to be a niche question. It is now central.

For a hands-on look at how different tools answer these, see our guide to the best secrets management tools in 2026.

Secrets management in the age of machine and AI identity

The secrets problem is shifting from humans to machines, and from machines to autonomous agents.

GitGuardian recorded an 81% year-over-year surge in leaked AI-service credentials in 2025, faster growth than any other category. More telling for where things are heading: they found 24,008 unique secrets exposed in MCP (Model Context Protocol) configuration files on public GitHub, the files that wire AI agents to the tools and data they act on. As teams hand more work to coding agents and autonomous systems, credentials are getting pasted into agent config the same way they once got pasted into .env files.

This breaks the assumption most secrets managers were built on, that a human or a human-configured service sits on the other end. An AI agent that can manage your infrastructure should not automatically be able to read every secret it can reach. That calls for a secrets manager where machine identity is a first-class cryptographic fact, and where an agent's ability to manage secrets is separable from its ability to read them.

Where SikkerKey fits

SikkerKey is a secrets manager built around per-machine cryptographic identity. Every secret request is signed with an Ed25519 key generated on the machine and never transmitted, so there is no bearer token to leak, copy, or replay. A captured request is useless: the signature is bound to one method, path, body, and timestamp, and every read traces back to a specific machine.

Around that primitive it does the things the questions above ask for:

• Per-secret access grants, so a machine gets exactly the secrets it needs and nothing else.
• Verify-before-promote rotation for PostgreSQL, MySQL, Redis, and MongoDB: the new credential is applied and tested before it goes live.
• A severity-tagged audit log where critical events are kept regardless of plan retention and export to CSV.
• Ephemeral machine identities for CI runners and autoscaling, with expiry baked in at enrollment.
• An AI agent identity class that is read-blind by construction: an agent can manage projects, rotate secrets, and configure policies, but the read paths physically do not accept an agent as the caller, so even a fully-permissioned agent cannot fetch a stored value.
• Canary secrets that lock a project the instant a compromised machine reads one.

It is also built to stay out of your way. There is no cluster to run, no access-policy language to learn, and no secret-engine setup standing between you and your first stored secret. You register a machine with one command, grant it the secrets it needs, and read them with a single SDK call. The whole mental model is three things: machines, projects, and the secrets you grant between them.

That simplicity is not a discount on security. It is the same design choice. Removing the bearer token is what makes retrieval both easier to run, with no token to issue, scope, rotate, or store, and harder to attack, with no reusable credential to capture and every read signed by a specific machine. The traditional model runs more machinery to deliver a weaker retrieval guarantee. SikkerKey runs less to deliver a stronger one.

Secrets are encrypted at rest with per-secret data keys under envelope encryption, and pricing is flat: unlimited projects and secrets on every plan, with a free tier to start.

Start for free and move your first secret out of a .env file in a few minutes.

Frequently asked questions

What is the difference between a secrets manager and a password manager?

A password manager stores credentials for people to type into login forms. A secrets manager stores credentials for software to use at runtime, and adds the machine-facing parts a password manager has no reason to: programmatic access through SDKs and APIs, machine authentication, automatic rotation, and audit logging keyed to workloads rather than people.

Is a secrets manager the same as a vault or a KMS?

"Vault" is a common name for a secrets manager's encrypted store. A KMS (key management service) is related but narrower: it manages cryptographic keys and performs encryption operations, often without ever revealing the key. Many secrets managers use a KMS underneath to protect their own encryption keys. In general you want a secrets manager for application credentials and a KMS for the keys that protect them.

Aren't secrets managers too complicated for a small team?

They can be, and that is the main reason teams stick with .env files. The complexity comes from tools that make you operate the vault yourself: clustering, an access-policy language, secret engines, and seal procedures. A managed secrets manager with a simple model removes that overhead, so a small team can adopt one without a dedicated operator or a week of setup.

Do small teams really need a secrets manager?

If you have more than one server, one secret, or one developer, you already have a small sprawl problem. The leaks in GitGuardian's report did not come only from large enterprises. A secrets manager is cheaper to adopt early, before credentials are copied into a dozen places, than to retrofit afterward.

Are environment variables secure?

Injecting a secret into a process as an environment variable at runtime is a reasonable delivery method. Storing secrets as committed .env files is where it goes wrong: those files have no access control, no rotation, and no audit trail, and they spread through chat, CI logs, and backups. A secrets manager keeps the convenience of env-var delivery while removing the flat-file copy.

If the server can decrypt a secret, how is it actually protected?

A secrets manager is not magic: to hand your application a usable password, something has to decrypt it. The protection comes from controlling what can trigger that decryption (strong machine authentication and per-secret access), encrypting everything at rest, and recording every read so an unexpected access is visible. The goal is to keep each credential scoped, traceable, and replaceable, so a leak is contained rather than catastrophic.

Can AI agents use a secrets manager safely?

They can, if the manager treats agent identity carefully. The safe pattern is to let an agent manage secrets (rotate, configure, audit) without granting it the ability to read stored values, and to give it a scoped, fully audited identity. SikkerKey's AI agent identity is built that way: read-blind on stored secrets by construction.