Secrets Management

What Is Secrets Management?

Secrets management is the process of safely storing, controlling, rotating, and auditing machine credentials, including API keys, passwords, access tokens, and certificates. Its primary goal is keeping sensitive access details out of source code and logs.

It governs a credential’s entire lifespan, from creation to when it is removed. Effective secrets management ensures that credentials are given on a need-to-know basis, assigned to clear owners, and easily rotated if compromised.

‍

What Counts as a Secret?

A secret is any piece of information that could let someone access a system, account, service, or protected data without the right permission. Common examples include:

• API keys: Credentials that let an application call an API.
• Access tokens: Credentials that allow a user, service or application to access a resource. See our guide to api token.
• Database credentials: Usernames and passwords, or other credentials, used to connect to a database.
• Certificates and private keys: Used to prove identity, secure connections or sign data.
• Service account keys: Credentials used by applications and automated services.
• Signing keys: Keys used to sign software, messages, tokens or other data.
• Connection strings: Configuration values that may contain database addresses, usernames and passwords.
• SSH keys: Keys used to authenticate connections to servers and other systems.
• OAuth client secrets: Credentials used by an application when it authenticates with an identity provider.
• Cloud credentials: Keys, tokens or other credentials that allow access to cloud resources.

These credentials need different controls. Good api key management starts with knowing what each credential does, where it is used, and who is responsible for it.

How Secrets Management Works

Secrets management covers the full process of creating, storing, granting access to, using, rotating and revoking credentials. Each step matters because a secret can be exposed at any point, not just while it is stored.

A typical process includes these steps:

1. Create the secret. Generate a strong credential for a specific application or task. Avoid reusing one credential across unrelated services.
2. Store it securely. Keep it in an approved secrets store rather than in source code, a container image or a shared document. Secrets should be encrypted at rest.
3. Set access rules. Give access only to the people, applications or workloads that need it. A service that reads reports should not automatically receive permission to change them.
4. Deliver it when needed. The application retrieves the secret at runtime or receives it through a controlled process. Avoid placing credentials directly in code or configuration files.
5. Rotate or replace it. Replace credentials according to their risk, lifetime and the systems that depend on them.
6. Revoke it when necessary. Remove access when a service is retired, an employee no longer needs it or a credential may have been exposed.
7. Keep an audit trail. Record relevant access, changes and rotation events. These records help teams investigate unusual activity.

Hardcoded secret vs runtime injection

A hardcoded secret is stored directly in the application code. Anyone who can read that code may be able to copy the credential.

Example:

For sensitive workloads, a secrets manager can deliver credentials through a protected file mount, a short-lived sidecar or a direct API call. The right method depends on the application and the platform. The key point is that credentials should not be permanently embedded in the software that uses them.

How Secrets Sprawl Starts

Secrets sprawl happens when credentials spread across repositories, tools, cloud services and teams without a reliable record of where they are or who owns them. It often starts with a small shortcut that solves an immediate problem but leaves a credential behind.

Common causes include:

• Source code repositories: A developer adds an API key to a configuration file and commits it. Deleting the line later does not remove it from the repository's history.
• CI/CD variables: Teams add credentials to build systems but do not record their purpose, access rules or expiry.
• Local environment files: Developers keep credentials in .env files on laptops and forget to remove them when a project ends.
• Container images: A secret is copied into an image during a build and remains there even after the source file changes.
• Shared credentials: Several teams use the same key, making it difficult to know which application used it or which one must be updated after a leak.
• Old services: Credentials remain active after a test environment, application, or cloud resource is retired.
• AI agent configurations: Credentials are added to agent settings, scripts, or tool configurations without a clear owner or review process.
• Logs and build artifacts: Debug output, test reports, and generated files retain values that should never have been recorded.

This is why secrets sprawl is a discovery problem as much as a storage problem. A company cannot protect or rotate a credential it does not know exists. Hence, the first step is to build an inventory. Identify where credentials are stored, which services use them, who owns them and what access they provide. Then check for duplicates, unused credentials and secrets that have no clear owner. That gives the security team a practical starting point for reducing exposure.

Vault vs Cloud-Native vs CI/CD Variable Stores

The main difference between a dedicated vault, a cloud provider's secret store and a CI/CD variable store is where each one fits into the software delivery process. They can all help protect credentials, but none removes the need to control access and track how secrets are used.

Secrets Management in CI/CD

CI/CD pipelines need credentials to build software, run tests and deploy applications, which makes them a common place for secrets to spread. If a pipeline can access a production key, anyone who can change or misuse that pipeline may be able to expose the key.

Masked variables help hide secret values in ordinary job output, but masking is not the same as secrecy. A job may still send a value to an external service, write it to a file, print it in an unexpected format or pass it to a process that should not receive it. Anyone with enough access to change the job may be able to misuse the credential.

Forks and pull requests need particular care. A workflow that runs code submitted by an untrusted contributor should not automatically receive access to sensitive secrets. A malicious change could try to send those values outside the build environment.

Example: a pipeline using a secret

The following simplified YAML shows a deployment step receiving a database credential through a protected CI/CD setting instead of storing the value in the workflow file.

Example:

Where possible, use short-lived credentials for build jobs instead of a long-lived key that remains valid between deployments. Give each job only the permissions it needs, and review which people can edit workflow files or change secret settings.

CI/CD security also needs to cover the pipeline's own credentials. A job that can retrieve secrets from a vault must authenticate to that vault somehow. Limit that access to the required secret paths and services, and avoid giving every pipeline a shared, broad-privilege credential.

Finally, keep an eye on build logs, test reports, artifacts and runner access. If a secret appears in any of these places, treat it as exposed and follow the incident response process rather than relying on masking alone.

Choosing a Secrets Management Tool

The right secrets management tool helps teams store credentials securely, control access, deliver secrets to applications and respond when something goes wrong. When comparing secrets management tools, focus on how well they fit your systems and how easily your team can manage the full life of each credential.

Use the following checklist when comparing secrets management solutions or secrets management software.

Before choosing a secrets management platform, test it with a real application and a realistic incident scenario. Ask your team to retrieve a secret, rotate it without breaking the application, identify who accessed it and revoke it after a simulated leak. This will show more than a feature list alone.

Secrets Management for AI Agents and Non-Human Identities

AI agents and non-human identities need credentials to interact with cloud services and APIs, but they can be created faster than security teams can keep up. Simply storing these credentials in a traditional vault isn't enough. A vault tells you where a key lives, but not who owns it, what it's for, or if it's still needed.

AI agents make this problem even trickier. They often hold access to multiple tools and services at once. Because teams frequently spin up agents for short-term projects or experiments, inactive agents often end up sitting around with live credentials long after the work is done.

There are several risks to watch out for:

• Credentials without clear owners: A key is created for an agent, but no team is responsible for reviewing or replacing it.
• Excessive access: An agent receives a credential that allows more actions than its task requires.
• Long-lived credentials: A key remains valid even after an agent is stopped or its purpose changes.
• Unclear usage: Security teams cannot easily tell which agent or service used a credential.
• Incomplete cleanup: An agent is deleted, but its credentials remain active in a vault, configuration file or external service.
• Credentials passed between tools: An agent or workflow may pass a secret to another component that does not need it.

Who, or what, uses a secret changes everything. While a developer can tell you when they no longer need an API key, an automated service will happily keep using a credential until it expires or breaks. That’s why relying on human memory doesn't work for machine access; you need clear rules, automated checks, and reliable records to clean up access.

Start by building an accurate inventory of your non-human identities and mapping them directly to their credentials. For every machine identity, track its owner, purpose, permissions, last active date, and expiration window. Then, evaluate whether static keys can be swapped out for short-lived tokens or workload identities.

Modern non-human identity management tools (like Token Security) help teams discover these hidden machine identities and get a clear, centralized view of all connected credentials.

Ultimately, secrets management for AI agents shouldn't live in a silo. It needs to be baked right into your broader identity and access strategy. Agents should operate on least privilege, use easily revocable credentials, and leave behind clear audit trails so you can quickly check if a secret is exposed.

Detection: Finding Secrets Already Leaked

Finding leaked secrets requires more than scanning the current version of a repository. Credentials may remain in old commits, build logs, container images, local files and generated artifacts, so detection needs to cover the places where developers and automated systems actually work.

A practical detection process should include:

1. Scan repositories and their history. Check current files and past commits for API keys, passwords, tokens, and private keys. Removing a secret from the latest version does not remove it from earlier commits.
2. Scan build outputs. Review CI/CD logs, build artifacts, test reports and container images for credentials that should not be present.
3. Check configuration and deployment files. Look for secrets in environment files, scripts, infrastructure configuration and agent settings.
4. Use ongoing checks. Run secret detection before code is merged and continue scanning after deployment. A one-time scan cannot find secrets introduced later.
5. Investigate the finding. Work out whether the value is a real credential, which system it accesses, what permissions it has and whether it may have been used.
6. Revoke, then rotate. Remove the exposed credential's access and replace it with a new one. Update the applications that depend on it through a controlled process.
7. Audit the impact. Review access logs and related activity to determine what the credential could reach and whether it was used in an unexpected way.

To learn about the risks of exposed credentials in automated systems, read about unsecured API keys. A documented token rotation process can help teams replace credentials without losing track of the services that depend on them.

Why Secrets Management Matters in Security

Secrets management matters because a stolen credential can give an attacker access that looks legitimate to the system being accessed. If the credential has broad permissions or remains valid for a long time, the attacker may be able to access data, change resources or move to other systems.

Good secrets management supports several important security goals:

• Limits damage: Credentials with narrow permissions reduce what an attacker can do if one is exposed.
• Speeds up response: A clear inventory and tested revocation process help teams act quickly after a leak.
• Supports audits: Access records and ownership details help explain how credentials are used and who is responsible for them.
• Reduces manual errors: Automated delivery and rotation reduce the need to copy secrets between files, messages and systems.
• Supports least privilege: Applications receive only the credentials and permissions needed for their tasks.

Encryption is important, but it is not enough on its own. A credential may be encrypted in storage and still be exposed when an application retrieves it, writes it to a log or passes it to another service. Teams need controls for storage, access, use, rotation and removal.

The OWASP Secrets Management Cheat Sheet provides guidance on these controls, including secret lifecycle management, CI/CD, monitoring and detection.

Common Use Cases of Secrets Management

Secrets management is used wherever applications and automated systems need credentials to access other systems. Common use cases include:

• Software development and deployment: Protecting credentials used by build jobs, tests and deployment pipelines.
• Cloud infrastructure: Managing credentials and access used by applications running in cloud environments.
• Databases: Controlling how applications retrieve database passwords and connection details.
• Kubernetes and containers: Delivering credentials to workloads without baking them into container images.
• APIs and SaaS applications: Protecting API keys and application credentials used to connect services.
• Industrial and connected devices: Managing credentials used by devices and services that may be difficult to update.
• AI agents and automation: Controlling credentials used by agents, scripts and other non-human identities.

The controls will vary by use case. A short-lived build job may need a temporary credential, while a database connection may require a rotation process that avoids interrupting a live application. The common requirement is to know which system uses each secret and how to remove access safely.

Best Practices for Secrets Management

The following practices help reduce the chance of credentials being exposed and make it easier to respond when a problem occurs.

1. Keep secrets out of source code. Use an approved secret store or controlled runtime delivery method instead of committing credentials to repositories or container images.
2. Limit access. Give each user, application and pipeline only the permissions it needs. Avoid sharing one credential across unrelated services.
3. Use short-lived credentials where possible. Reduce the time a stolen credential remains useful, and avoid keeping static keys active when a temporary credential will work.
4. Automate rotation and revocation. Plan how credentials will be replaced, how dependent services will receive the new value and how access will be removed after a leak.
5. Scan continuously. Check repositories, commit history, CI/CD logs, container images and configuration files for exposed secrets.
6. Protect CI/CD pipelines. Restrict who can edit workflows and access runners, protect sensitive deployment environments and keep secrets out of logs and artifacts.
7. Maintain an inventory. Record each secret's owner, purpose, permissions, location and usage where possible. Review old and unused credentials.
8. Monitor access. Keep audit records and look for unusual access, unexpected locations or activity that does not match the application's normal use.
9. Plan for incidents. Document how to revoke and rotate each type of credential, which services may be affected and who should respond.
10. Make the secure path easy to use. Provide clear instructions and simple tools so developers do not create workarounds to get their jobs done.

FAQ

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

A password manager mainly helps people store and use passwords and other login details. Secrets management is designed to handle credentials used by applications, services, automated jobs and other machine identities. It often includes access policies, runtime delivery, rotation, revocation, audit logs and integration with cloud or CI/CD systems. The two may share some security principles, but they solve different day-to-day problems.

How often should secrets be rotated?

There is no single rotation schedule that suits every credential. The right timing depends on the credential's permissions, how it is used, its exposure risk and whether it can be replaced safely. Short-lived credentials are preferable when the system supports them. Long-lived credentials should have a defined rotation plan, and any credential suspected of being exposed should be revoked or replaced promptly. Rotation should be tested so dependent applications do not unexpectedly lose access.

How do you manage secrets for AI agents?

Start by identifying the agents and tools that use credentials, assigning an owner to each identity and limiting permissions to the task required. Avoid placing long-lived keys directly in agent instructions or configuration files. Deliver credentials through a controlled runtime process, use short-lived credentials where possible, monitor their use and remove access when an agent is retired. Also check whether agents can pass credentials to tools or services that do not need them.

What should you look for in a secrets management tool?

Look for secure storage, detailed access controls, runtime delivery, rotation and revocation support, useful audit logs and integration with your existing cloud and CI/CD systems. The tool should help you find who or what uses each credential and support a clear response when one leaks. Consider open source and managed options based on your team's ability to operate and maintain them. Test the tool with a real application and a simulated leak before making a decision.

‍