What Is Secrets Sprawl? 7 Places Keys Hide and How to Fix It

Secrets sprawl usually starts with a Slack message like "here's the prod key, just use mine for now." It unblocks a deploy in five minutes, and the key behind it is probably still valid two years later.

Multiply that message by every team, pipeline, and AI agent you run, and you've got one of the hardest enterprise security problems to govern, especially once business teams start vibe coding apps that each want their own credentials.

When IT and security leaders walk us through what worries them about AI-built apps, credentials come up fast (usually right after "we don't know what people are building").

The follow-up questions are predictable: how far does it go, what does it cost, and what do we fix first? Below are straight answers to all three, built on 2026 leak data.

What is secrets sprawl? The 30-second answer

Secrets sprawl is the uncontrolled spread of credentials, such as API keys, passwords, tokens, and certificates, across code, tools, pipelines, and machines, until nobody can say how many exist, where they live, or who can use them.

Sprawl describes the state of the whole estate: hundreds of untracked copies, no named owners, and no rotation schedule. That's the condition that lets one leaked key turn into a breach.

What counts as a secret

A secret is anything software uses to prove it's allowed in. The common types:

• API keys: for payment providers, AI models, CRMs, and every SaaS tool a team wires into an app.
• Database credentials: usernames, passwords, and full connection strings.
• Cloud access keys: AWS access keys, Azure service principal secrets, and GCP service account keys.
• Tokens: OAuth access and refresh tokens, personal access tokens, and session tokens.
• Private keys and certificates: SSH keys, TLS private keys, and code-signing keys.
• Webhook and signing secrets: the shared values that prove a request came from who it says it did.

The passwords people type into login screens belong to identity management. Secrets sprawl is mostly about the credentials machines use to talk to other machines, and there are a lot more machines than people.

How secrets sprawl happens

Nobody sets out to sprawl. Secrets spread because the fastest way to get something working is to paste a credential wherever the code can reach it.

• Speed during development: a key goes into a config file "temporarily" and ships with the release.
• Sharing by copy-paste: onboarding a teammate or a contractor means sending them the key in chat, a ticket, or a doc.
• Long-lived static credentials: a key that never expires never forces anyone to clean up after it.
• Too many places to store them: microservices, multiple clouds, and team-by-team tooling lead to several vaults, or none, with no shared inventory.
• Building outside IT: scripts, automations, and AI-built apps spun up by individual teams create credentials security never sees, the same pattern behind shadow AI.

Each habit is reasonable on the day it happens. The sprawl is the sum of a few thousand reasonable days.

Where secrets end up: 7 places sprawl hides

Secrets end up wherever people and machines swap information. These are the seven places to check first.

1. Source code and Git history

Hardcoded keys are the classic form of sprawl, and the volume keeps climbing. GitGuardian counted 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34% jump over the year before.

Private code looks worse. GitGuardian's 2026 State of Secrets Sprawl report found internal repositories are about six times more likely to contain hardcoded secrets than public ones (32.2% versus 5.6%).

Deleting the line doesn't remove the secret either, because Git history keeps every version. Our guide to hardcoded secrets covers the code-level fixes.

2. CI/CD pipelines and build logs

Pipelines need credentials to test, deploy, and publish, so they collect them in environment variables, pipeline settings, and build logs that print a token the moment a script runs in verbose mode.

Attackers know it. When GitGuardian analyzed machines hit by the Shai-Hulud 2 supply-chain attack, 59% of the compromised machines were CI/CD runners. Across all 6,943 machines, the team found 33,185 unique secrets.

3. Container images

A Dockerfile that copies in a .env file or passes a token as a build argument bakes that secret into the image. Docker's own docs warn that build arguments and environment variables are inappropriate for passing secrets because they persist in the final image.

Push that image to a registry, and anyone who can pull it can read the secret.

4. Slack and Microsoft Teams

Chat is where the "just use mine for now" message lives. GitGuardian's 2025 report found leaked secrets in 2.4% of corporate Slack channels.

Chat feels private, so people paste freely. Then the workspace picks up an AI assistant, a dozen integrations, and a few hundred new hires, and that old message is searchable by all of them.

5. Jira and Confluence

Tickets and wikis collect secrets during debugging ("here's the config that's failing") and onboarding ("staging DB credentials are below"). In the same 2025 data, 6.1% of Jira tickets exposed credentials, the highest rate of any collaboration tool GitGuardian measured.

GitGuardian's 2026 numbers put about 28% of incidents entirely outside code repositories, in tools like Slack, Jira, and Confluence. A repo scanner alone misses all of them.

6. Cloud storage and infrastructure files

Infrastructure-as-code holds more secrets than people expect. HashiCorp notes that Terraform stores secret values in its state and plan files, and local state is a plaintext file.

Those state files, along with Kubernetes manifests, config backups, and the odd "service accounts" spreadsheet, land in buckets and shared drives. One loose bucket policy exposes all of them at once.

7. Developer laptops and .env files

The .env file exists to keep secrets out of code, which works right up until it gets committed, zipped with a project, or synced to a personal cloud drive. Laptops also hold shell history, CLI config, and cached tokens for every tool a developer has signed into.

GitGuardian's 2026 report ties this to supply-chain attacks like Shai-Hulud, which turn local secrets into organizational risk. The developer machine is now part of the attack surface.

Warning signs you have a secrets sprawl problem

You can spot sprawl before you buy a scanner. If two or more of these sound familiar, you have it:

The rotation sign is the most telling. GitGuardian's 2026 policy data found long-lived secrets behind 60% of policy breaches, and a key usually lives that long because nobody's sure what breaks when it changes.

Why secrets sprawl is dangerous

A sprawled secret is dangerous for the same reason a spare house key under the mat is. It works for anyone who finds it, and you forget it's there.

Leaked secrets stay valid for years

Detection keeps getting better, and cleanup hasn't kept pace. GitGuardian tracked valid secrets it found in 2022, and four years later 64% were still active and exploitable.

Every untracked copy stays a working credential long after everyone forgot it existed.

One key leads to the next

Attackers rarely stop at the first credential. A token found in a repo gets them into a CI system, the pipeline's own secrets get them into a cloud account, and the cloud account holds the database password.

Sprawl shortens that chain, because the same key often works in more than one place.

A real example: Toyota's five-year-old key

In October 2022, Toyota disclosed that a website development contractor had uploaded part of the T-Connect site's source code to a public GitHub repository, where it sat from December 2017 to September 15, 2022.

The code contained an access key to the T-Connect data server, exposing the email addresses and customer control numbers of 296,019 people. Toyota changed the key on September 17 and said no secondary damage had been confirmed.

The fix took two days. The exposure lasted almost five years.

What it costs

IBM's 2026 Cost of a Data Breach report puts the global average breach at $4.99 million, and IBM says breaches take 247 days on average to identify and contain.

To be fair, credential abuse isn't the most common way in anymore. Verizon's 2026 DBIR executive summary shows credential abuse falling to 13% of initial access vectors, with vulnerability exploitation leading at 31%.

Sprawl still decides how far an attacker gets once they're in. Every secret they find on the inside extends their reach.

The everyday cost shows up in engineering hours. GitGuardian estimates teams lose over $172,000 a year per 10 developers to managing keys and credentials by hand, a modeled figure built on HashiCorp's estimate of three hours a week per developer.

How AI agents and non-human identities speed up secrets sprawl

Sprawl in AI is the uncontrolled growth of AI tools, agents, and AI-built apps inside a company, and every one of them needs credentials to do anything useful.

An agent needs a key for the model it calls, plus tokens for each system it touches. An automation needs a service account. An app a business team builds with an AI coding tool needs database credentials.

Those are non-human identities, and they already outnumber people by a wide margin. CyberArk's 2025 Identity Security Landscape study puts the ratio at 82 machine identities for every human.

GitGuardian's 2026 leak data shows the AI share climbing fast:

• AI-service keys: leaked AI-service secrets reached 1,275,105 in 2025, up 81% year over year.
• AI-assisted commits: commits co-authored with Claude Code leaked secrets at a 3.2% rate, about double the 1.5% baseline across public GitHub. A year earlier, public repos with GitHub Copilot active showed a 6.4% leak rate.
• MCP config files: GitGuardian found 24,008 unique secrets in MCP-related configuration files on public GitHub, including 2,117 valid credentials.

GitGuardian is careful to add that the leak still happens through a human workflow. The AI writes code faster, and people approve what it writes, including the key it inlined to make the demo run.

Vibe-coded apps carry their own keys

The fastest-growing source is business teams vibe coding their own tools. A prototype built in an afternoon often gets its keys the quickest way possible: pasted into the prompt, the code, or a frontend environment variable that ships to every browser.

Hardcoded secrets in generated code rank among the top risks in vibe coding security.

One IT leader put the result to us on a call: 'People are downloading secrets when they shouldn't. Nightmare.

Agents act on the credentials they hold

Agents raise the stakes, because they use their credentials on their own, at machine speed. Scoping what an agent's tokens can reach is the starting point for AI agent security, and reviewing how generated code handles keys belongs in your AI code governance policy.

Governance hasn't caught up yet. IBM's 2026 research found fewer than half of organizations are actively securing non-human identities, which leaves a big piece of any generative AI security program unfinished.

How to prevent secrets sprawl in 5 steps

OWASP's Secrets Management Cheat Sheet covers the same ground: centralized storage, access control, automation, auditing, and a defined lifecycle for creating, rotating, revoking, and expiring secrets.

1. Centralize secrets in a vault

Start with an inventory, because you can't move what you can't find. Then pick one system of record for secrets (AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, or similar) and make it the only approved home for a credential.

Apps should read secrets from the vault at runtime. A copy in a config file is a copy you'll chase later.

2. Enforce least privilege and short-lived credentials

Give each service, agent, and app its own credential with only the permissions it needs. When one leaks, you revoke one thing and the damage stays small.

Wherever the platform supports it, swap static keys for short-lived tokens issued through workload identity or OAuth. A token that expires in an hour can't sit in a repo for five years.

Brokering internal APIs through a gateway that holds credentials centrally helps here too, and it's one reason teams invest in enterprise API management.

3. Scan for what already leaked

A vault does nothing about the secrets that leaked last year. Scan source code and full Git history, CI/CD logs, container images, and collaboration tools, then block new leaks with pre-commit hooks and push protection. Our secrets scanning guide walks through the setup.

When a scan finds a live secret, work in this order:

1. Revoke or rotate it first. Deleting the commit won't help once the key has been copied.
2. Check the logs for any use since the exposure date.
3. Purge it from history so the next scan doesn't flag it again.
4. Move the replacement into the vault so it doesn't land in the same spot twice.

4. Automate rotation

Rotation is where programs tend to stall, because rotating a key by hand means finding every copy first. Once secrets live in a vault and apps read them at runtime, rotation becomes a scheduled job.

Rotate on a calendar, and rotate right away whenever a secret shows up somewhere it shouldn't.

5. Audit every access

Log which person, service, or agent read each secret and when. Those logs let you answer "was this key used?" in an hour, and they're the evidence auditors ask for. Our guide to an AI audit trail covers what to log for AI systems.

Vault or scan first? Our take

If you're starting from zero, I'd scan first. A scan gives you the inventory, the scale, and the handful of live leaks to rotate this week, and those numbers are what get a vault project funded.

Go vault-first if new apps are launching every week, especially AI-built ones. Each app built without a central place for credentials adds to the pile you'll be scanning next quarter.

How does Superblocks prevent secrets sprawl in AI-built apps?

Superblocks is the governed enterprise vibe coding platform, and it keeps credentials out of the apps business teams build: IT connects each integration once, and apps built with Clark by Superblocks use that connection with no copy of the key in their code.

Credentials live in centrally managed integrations

Admins set up integrations with credentials stored by Superblocks or referenced from a connected secret store through the sb_secrets object, which is fetched at runtime. Builders pick an approved integration, so a key has no reason to show up in a prompt, the code, or a chat thread.

That closes the copy-paste habit at the source, since the approved path is also the fast one.

Secret stores your security team already runs

Secrets Management connects to AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager, and HashiCorp Vault, per the Superblocks pricing page. Admins set caching policies per environment and can clear a store's cache after a rotation so apps pick up the new value.

Leaked-secret scanning before anything publishes

Static analysis runs at publish time and checks both source and built artifacts for hardcoded credentials of any kind. A secret found in the built bundle can block the publish, depending on the scan mode an admin sets, and builders can fix findings with Clark.

Access and audit you can query

RBAC controls who can build with each integration. Audit logs record credential and integration changes alongside builder and end-user activity.

When a token needs to die, the Revoke token button clears cached tokens for every user of an integration at once.

Secrets Management, audit logs, and security agents and scans sit on the Enterprise plan; RBAC is available from the Teams plan.

Give every new app a key it never has to hold

That Slack message from the top of this piece is still out there, and the next one is being typed by someone who just wants their app to work.

Shrinking secrets sprawl means giving that person a faster path than pasting: an approved integration that already holds the credential, with IT watching how it's used.

Superblocks gives business teams that path for every app they build with AI, and gives IT one place to see and control the credentials behind them.

With Superblocks, teams can:

• Connect apps to approved integrations that hold credentials centrally.
• Reference secrets from AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager, or HashiCorp Vault at runtime.
• Block publishes when static analysis finds hardcoded secrets in the built app.
• Control who can build with each integration through RBAC.
• Track credential and integration changes in audit logs.
• Revoke cached tokens for every user of an integration in one step.

When the approved path is also the fastest one, the "just use mine for now" message stops getting sent.

Book a demo to see how Superblocks keeps credentials governed across every app your business teams build.

Frequently asked questions

What is secret sprawl?

Secret sprawl is the uncontrolled spread of credentials like API keys, passwords, tokens, and certificates across code, pipelines, chat, and machines. It leaves an organization unable to say how many secrets exist, where they live, or who can use them, so leaks are hard to spot and slow to fix.

What is sprawl in AI?

Sprawl in AI is the uncontrolled growth of AI tools, agents, models, and AI-built apps across a company, often outside IT's view. Each one needs API keys and tokens, so AI sprawl feeds secrets sprawl directly. GitGuardian counted 1,275,105 leaked AI-service secrets in 2025, up 81% in a year.

How is secrets sprawl different from data sprawl?

Secrets sprawl and data sprawl differ in what spreads. Data sprawl is copies of business data scattered across systems, and secrets sprawl is copies of the credentials that unlock those systems. The two compound, since a sprawled key often opens a sprawled dataset.

What is secret scanning?

Secret scanning is the automated search for credentials in code, Git history, pipelines, container images, and collaboration tools, using pattern matching, entropy analysis, and validity checks. It finds leaked secrets and, paired with pre-commit hooks and push protection, blocks new ones.

How do you fix secrets sprawl?

You fix secrets sprawl by inventorying every secret, moving them into a central vault, scoping each credential to one service, scanning for and rotating anything that leaked, and auditing every access. Short-lived credentials help most over time, because they expire before they can spread.