Skip to content
Fathom Layer
GlossaryGlossary9 MIN READ

What is secrets management?

Conceptual protected key-storage hardware and sealed enclosure on a server tray
AI-generated editorial illustration · Conceptual scene

Secrets management is the practice of creating, storing, distributing, rotating, revoking and auditing the credentials software needs to run — API keys, database passwords, tokens, SSH keys, certificates — so they never sit in plaintext in source code, config files, logs or an AI agent's context. OWASP's cheat sheet frames the problem directly: many organizations have secrets hardcoded in source code and scattered through configuration files, and because services often share the same secrets, finding the source of a leak becomes hard.

The lifecycle of a secret

OWASP lists four lifecycle stages (creation, rotation, revocation, expiration) and treats storage, access control and auditing as separate requirements. Put together, a secret's life looks like this:

Stage What good practice looks like (OWASP)
Creation Generated securely, cryptographically strong enough for its purpose, with the minimum privileges its role needs
Storage In a central, access-controlled system; encryption keys are not stored next to the secrets they encrypt unless those keys are themselves encrypted
Access Policies limit how many entities can read or write each secret; production and development can be separated
Rotation Regular, so a stolen credential only works for a short time. User passwords are the exception: rotate them only on suspicion or evidence of compromise
Revocation and expiry Revoke secrets that are no longer needed or may be compromised; set expiry where possible, and have applications check a secret is still active before trusting it
Audit A tamper-resistant log of who requested which secret, whether it was approved, when it was used, updated or expired, and any attempt to reuse an expired one

Static vs dynamic secrets

A static secret is a long-lived value someone stores and later rotates. A dynamic secret is created on demand for one consumer and invalidated when that consumer goes away. OWASP says this reduces the chance of leakage and makes misuse easy to spot: a credential used from anywhere other than its consumer stands out.

One example is HashiCorp Vault's database secrets engine. HashiCorp says it generates database credentials dynamically from configured roles, so services request credentials from Vault instead of hardcoding them, and because every service gets unique credentials, auditing gets easier. Vault attaches a lease with a time-to-live to every dynamic secret and can revoke the secret automatically when the lease expires.

Dynamic secrets do not remove static ones. OWASP notes that creating dynamic secrets usually requires a long-term static secret, and some key material has to outlive a single deployment (storage encryption keys, TLS keys) or belongs to services that cannot issue temporary credentials.

Secret manager vs environment variables vs KMS

These three are often confused because they overlap. The table is this index's synthesis of the sources below.

Secrets manager Environment variables Key management service (KMS)
Holds Credentials the app uses: passwords, API keys, tokens Configuration passed to a process Encryption keys that encrypt other data
Rotation and revocation Scheduled; some services rotate the value, others only notify Changed between deploys, outside the app Key lifecycle managed inside the service
Audit of each read Yes No Varies by provider
Main risk Its own credentials become the most valuable secret Visible to other processes, logs and crash dumps Not designed to hand plaintext secrets to apps

The twelve-factor methodology recommends keeping config in environment variables because they change between deploys without code changes and are less likely than config files to be committed by accident. OWASP is more cautious about secrets specifically: in its section on containers, it says environment variables are generally accessible to all processes and may end up in logs or system dumps, so it does not recommend them unless other methods are impossible. Our reading of the two: environment variables are an improvement over hardcoding, and OWASP's guidance points to a secrets manager for anything sensitive.

AWS draws the line between a secrets manager and a KMS in its own documentation. It points database credentials, OAuth tokens and API keys to Secrets Manager, and encryption keys to AWS KMS. KMS protects the root keys at the top of an encryption hierarchy, and those keys never leave the service unencrypted. NIST SP 800-57 is the standard reference for managing cryptographic keys themselves.

Options, per their own documentation

  • HashiCorp Vault: HashiCorp describes centralized, encrypted and audited management of static secrets, dynamic credentials, certificates and identities.
  • Infisical: says it is an open source platform covering secrets rotation, dynamic credentials, access approvals and credential-free access for AI agents.
  • AWS Secrets Manager: AWS says it replaces hardcoded credentials with a runtime call, and supports automatic rotation schedules. Some AWS services, such as Amazon RDS and Aurora for master user credentials, offer managed rotation without a Lambda function; other secrets rotate through a Lambda function.
  • Google Cloud Secret Manager: Google describes storage of API keys, passwords and certificates, with secret versions and replication choices. Its rotation schedules send a notification to a Pub/Sub topic when a rotation is due; Google says you must configure a subscriber to act on it, for example by creating a new secret version and deploying it.
  • Azure Key Vault: Microsoft positions it for secrets, encryption keys and TLS certificates in one service, with access logging.
  • 1Password: its Secrets Automation gives apps and infrastructure access to 1Password vaults through service accounts or self-hosted Connect servers.- Doppler: says it provides fine-grained access controls, logs, versioning and a CLI, with sync integrations to platforms such as GitHub Actions and GCP Secret Manager.

Each vendor describes the product it sells. This index has not tested any of them.

Secret sprawl and leak scanning

GitHub defines secret sprawl as "the uncontrolled proliferation of credentials across repositories." Its secret scanning checks the full Git history on every branch for known credential types, and push protection blocks pushes that contain secrets before they reach the repository. By default, anyone with write access to a repository can bypass that block by giving a reason, and GitHub logs an alert when they do. Availability depends on the plan: as of 29 September 2026, GitHub says secret scanning runs free on public repositories, while organization-owned private repositories need GitHub Secret Protection on GitHub Team or Enterprise Cloud. OWASP recommends catching secrets before commit (in the IDE or a pre-commit hook) and running more than one detection tool.

Finding a leaked secret is only half the job. OWASP's containment order is to revoke the exposed key immediately, issue a replacement (preferably through automation), then remove the secret from the exposed system.

AI agents

An agent that calls authenticated APIs is a new place for secrets to leak. OWASP's AI Agent Security cheat sheet lists "Sensitive Data Exposure" (credentials included in agent context or logs) as a risk category, alongside prompt injection. Our analysis: a secret in the agent's context is exposed to prompt injection and to poisoned tools (see MCP tool poisoning), so one design answer is brokering, where the agent never holds the real key. Infisical's Agent Vault is one example of this pattern, not the only way to do it. Infisical says it routes the agent's API calls through a proxy that attaches the real credentials on the way out, only for allowed services and only until the session expires or is revoked.

When a dedicated manager is worth it

It is worth it once more than one person, service or environment shares credentials, once you need to rotate or revoke without redeploying, or once auditors ask who read what. For a single developer on one machine, a password manager plus git-ignored local config may be enough, as long as a leak scanner guards the repository. That is a judgment call, not a rule from any source above.

In the index

Infisical, one of several secrets managers named on this page, has a profile in the cybersecurity category. For agent-specific risks, see prompt injection, MCP and the guide to MCP security and agent vulnerabilities. Vendor descriptions on this page were checked against their documentation on 29 September 2026.

Sources

END OF ANALYSIS

In the Fathom index

Tools in the index for managing secrets. Matched on each item's own record and sorted A–Z, not by merit.

Browse Cybersecurity →

Related Intelligence