What is secrets management?A working definition for developers.

Secrets management is the set of practices and tooling used to generate, store, distribute, rotate, and revoke the credentials a program presents to prove identity or authorize access: API keys, database passwords, TLS private keys, OAuth tokens, and the rest. It treats credentials as governed artifacts with access policies, audited delivery, and a controlled lifecycle. It does not treat them as configuration constants you paste into a source file or export in a shell.

That definition is denser than most. Each clause earns its place, and most common practices skip at least half of them. A .env file delivers a credential to a process, which is one clause. It does not encrypt at rest, scope access, rotate on a schedule, revoke on demand, or record who read what. Five of the controls are missing, and the setup still gets called "secrets management" because the credential reaches the program. The gap between delivery and management is the entire subject.

What counts as a secret

A secret is any value whose exposure gives an unauthorized party access to a system, account, or dataset they should not control. The category is broader than most developers assume on first pass.

API keys and bearer tokens. OpenAI, Stripe, Twilio, and equivalent service credentials. Often granted broad read and write scope, issued without expiry by default, and stored in plaintext by the provider's own SDK without surfacing that fact.

Database credentials. Connection strings carrying host, port, user, and password. A leaked database URL usually grants full read access to a production dataset, and the same string tends to appear in application config, infrastructure code, CI variables, and shell history at once.

TLS private keys. The private half of a certificate keypair. Exposure allows impersonation of the service or decryption of traffic captured in transit.

OAuth tokens and service-account credentials. Long-lived JSON files with project-wide permissions. These sit on developer machines for months and get copied to new machines at onboarding with no record of where the copies went.

SSH and encryption keys. A single private key can unlock every host it was ever authorized on. A leaked data-encryption key decrypts whatever it protected, including traffic an attacker captured earlier in anticipation of the compromise.

Not all of these carry the same risk. A read-only analytics key is not a cloud provider's admin key. One job of secrets management is classifying credentials by blast radius and applying controls in proportion to what each one can do.

How secrets escape

The MITRE Common Weakness Enumeration lists CWE-798, use of hard-coded credentials, among the most consistently exploited weakness categories, with likelihood of exploit rated high (cwe.mitre.org/data/definitions/798.html). Hardcoding in source is the most visible failure, but four other surfaces generate more real-world incidents.

Git history. A credential removed in a later commit stays in the repository's object graph. Force-pushing does not erase it from forks or from a hosting provider's CDN caches. The value is one git log -p away long after it disappears from the working tree.

Environment state and .env files. Credentials exported in a shell profile or loaded by a dotenv library are ambient: every process launched in that session inherits them. On Linux, /proc/$PID/environ exposes the full environment to any process under the same user, no privilege escalation required. Env vars handle delivery and leave storage, scoping, rotation, and audit untouched, which is the structural reason env vars are not secrets management.

CI/CD artifacts. Pipeline logs, build archives, and environment snapshots routinely capture interpolated credential values. One verbose debug step writes a key into pipeline history permanently.

Agent transcripts and logs. AI coding agents inherit your shell environment and write context to state files, conversation logs, and tool-call records. A value the agent reads from the ambient environment can land in a log that survives across sessions. This is the newest surface, and the least covered by tooling built before 2024. OWASP now tracks this class of failure directly in its Top 10 for Agentic Applications.

The scale is documented. GitGuardian's State of Secrets Sprawl counts tens of millions of new hardcoded secrets pushed to public GitHub every year, with the count rising at a double-digit annual rate and a majority of leaked credentials still valid days after detection. Commits co-authored by AI coding agents leak secrets at roughly twice the rate of human commits. Treat the exact figures as directional rather than independently audited, but the direction is not in doubt: the surface is growing, and automation is accelerating it.

The secrets lifecycle

Secrets management is not one decision at creation time. It is a lifecycle with seven stages, each of which fails on its own.

Generation. Create the credential through a process that sets an expiry at issuance and assigns the minimum scope the task needs.

Storage. Persist it in an encrypted store with access controls. Not a flat file beside the code, not a version-controlled .env, not a shell profile.

Distribution. Deliver it to the process that needs it, over an authenticated channel, scoped to that process and that invocation, rather than broadcast to the whole environment.

Access control. Enforce who reads which secret, under what conditions, for how long. This is what separates a secrets manager from a shared credential store.

Rotation. Replace the credential on a schedule or right after a suspected exposure. Rotation shrinks the damage window from an undetected leak. It does not fix insecure delivery.

Revocation. Invalidate a credential immediately, outside the rotation schedule, in response to an incident or an offboarding. Revocation has to be fast and has to reach every delivery point.

Destruction. Hard-delete the credential and its record once it is no longer needed, in line with retention policy.

Most ad-hoc practice handles distribution, and sometimes not even that part well. It does not encrypt at rest, enforce access control, rotate on schedule, revoke on demand, or leave an audit trail. That is five of seven stages running uncontrolled.

A precise vocabulary: the six-object model

Part of what makes this topic hard to reason about is loose terminology. "Secrets manager," "vault," "broker," and "credential store" get used as synonyms by vendors with genuinely different architectures. One useful framing comes from hasp's mental-model docs, which name six objects any secrets architecture has to account for. The value of the model is that it works regardless of tooling: it lets you ask exactly which object handles storage, which scopes access, which delivers, and which records.

Vault. The encrypted store that holds named credentials and returns an encrypted value on demand. It makes no access decisions. Its presence authorizes no one to read from it.

Binding. The record connecting a project to the set of references it is allowed to request. Bindings stop credentials registered for one project from being reachable by another project on the same machine under the same user. Cross-project leakage is a common failure in setups that rely on shell-level env vars alone.

Target. A named workflow within a project, declared in a project manifest. A target states which references a workflow needs and how they should be delivered. It describes requirements; it does not approve access.

Consumer. Anything that requests a credential at runtime: an application, a script, an AI coding agent, an MCP client. Consumers differ from the humans who configure the system, because they act on their own, often unsupervised, in contexts where a credential in the output is not visible to anyone watching.

Grant. Scoped permission to deliver a credential to a specific consumer, for a specific project, for a specific action, within a defined window. All four dimensions have to match. Vault access on its own is not a grant. This is the policy layer.

Broker. The mechanism that resolves a reference at the last moment and injects the value into a child process, without exposing the plaintext to agent context, transcript logs, or intermediate tooling. The broker is the object most often missing in developer setups, where a credential is fetched once and then left in the environment for the rest of the session. The glossary has canonical definitions for all six.

Map a failure against this model and it usually locates itself fast. A credential in a log means the consumer received plaintext, so the broker was missing or misconfigured. A credential reachable by the wrong project means the binding was too broad or absent. Unlimited-duration access means the grant carried no time scope.

The tooling spectrum

Three categories of tooling address different portions of the lifecycle.

Environment files and shell exports. .env files loaded by dotenv, plus credentials exported in shell profiles. Handles distribution only: no encryption at rest, no access control, no rotation, no audit. Fine for a throwaway local prototype with no security requirement. Not fine for anything that touches version control, runs in CI, or shares a machine with an AI coding agent.

Dedicated secrets managers. HashiCorp Vault, Doppler, AWS Secrets Manager, Infisical, and the cloud-provider equivalents. These cover the full lifecycle: encrypted storage, access policy, rotation, revocation, and audit. The right tool for production workloads, multi-developer teams, and compliance-bound environments. The cost is operational weight: a hosted control plane or self-hosted infrastructure, network reachability from every consumer, and policy configuration past what a solo developer needs.

Secret brokers. A broker sits between a store and the process that needs a credential, handling scope, delivery, and audit at the boundary. It does not replace a vault; it governs how values from a vault reach consumers. The three architecture patterns (forward-proxy interception, sidecar exec-wrapper, and process-tree scoping) each trade off transparency, portability, and access scope differently. What is a secret broker covers the patterns in detail. Tools like SOPS sit at the edge of this category: they encrypt files you commit to git, but decrypt to plaintext at read time, which a broker is built to avoid.

What this means for your stack

If you keep API keys in a .env file today, you are doing distribution and nothing else. The fastest improvement is not buying a platform. It is naming the controls you are missing. Run your current setup through the seven lifecycle stages and the six-object model above, and the gaps name themselves: no encryption at rest, no per-consumer scope, no revocation path, no record of access.

For a solo developer or small team, the honest answer is that a full secrets manager is often more than the workload needs, and a .env file is far less. The middle is a broker: hold values in an encrypted local store, deliver a scoped, short-lived reference to each consumer, redact the value from output, and log every access. That covers the controls a .env skips without the operational weight of a hosted platform.

hasp is one working implementation of that middle. It keeps credentials in a local vault and brokers scoped references to the process that needs them, so the value reaches a child process at exec time instead of sitting in the environment or an agent's context. Source-available (FCL-1.0), local-first, macOS and Linux, no account. The tool is secondary. The decision that changes your risk profile is moving from "the credential is delivered" to "the credential is governed," and the model on this page is how you tell which one you have.