A deployment key sits in a vault. It has a rotation schedule, an access policy, and an audit trail. The pipeline that publishes application builds retrieves it when it runs. By every standard a secrets program sets, that key is handled.
The same key is also in a Slack thread from March, a log file attached to a Jira ticket, and a runbook in a repository. Those copies have no rotation schedule and no access policy. They authenticate exactly as well as the one in the vault.
Where the copies come from
Anyone who has worked near a production system can picture it. A build fails late at night, and someone pastes the configuration block into Slack so a teammate can see what the pipeline is loading. The key is in that block. Support attaches a verbose log to a Jira ticket so engineering can reproduce the bug. Someone writing a runbook includes the working example, because an example that does not work is not much of a runbook.
None of it feels like a security event at the time. It feels like fixing the build, closing the ticket, finishing the doc. The vault never comes up, because by then the value has already left it.
The original was governed. What spread was a copy, and a copy is not a weaker version of a secret. It represents the same identity, the same permissions, and the same reachable resources, now available from a place with different rules about who can read it.
Sprawl is not a number of places
It is tempting to measure this by counting. How many copies, how many locations, how many findings this quarter.
Counting locations tells you how far something traveled, not what you have to do about it. One key copied into five systems is five findings and one secret. Revoking it once ends the exposure in all five places at the same moment, and cleaning up four of the five while the key still authenticates ends nothing.
So the useful unit is not the copy. It is the secret, and the identity it authenticates as: one set of permissions, now reachable from places with different rules about who can read them. The question is how many live ones you have and how fast each stops working.
The copy gets found, and the secret keeps working
A scanner flags the key in a sandbox repository. The ticket goes to the engineer who pushed it. They delete the line, rewrite the commit so it disappears from history, and mark the ticket remediated. Everyone believes the issue is handled, and the repository is genuinely cleaner than it was.
Nothing in that sequence told the provider to stop accepting the key. It still authenticates from the Slack thread, the Jira attachment, the runbook, and the three local copies, none of which were part of the ticket. The secret is unchanged throughout.
We have measured how often this happens. In our research on GitLab and Bitbucket, we reported 22,000 live secrets to their owners and checked back six months later. Nearly two-thirds (63.7%) had made no attempt to fix them, and the most common fix among the rest was overwriting the file, which removes the secret from the latest version but leaves it in history, still working. Deleted commits do not always disappear either. On GitHub they can enter a dangling state still reachable through the API, so the cleanup that closed the ticket sometimes leaves the secret both live and retrievable.
Two things have to happen when a secret is exposed. The copy has to be cleaned up, and the secret has to be disabled. Only the second reduces the exposure, and a closed ticket is not evidence it occurred.
Copies travel further than the story suggests
Slack, Jira, and a sandbox repository are the comfortable version. Copies do not stop at the edge of the company.
When we looked at AI images shared across ten public Discord servers, 681 of them carried live API keys in their metadata. The key was in the workflow, the workflow was saved into the image, and the image was shared.
Those copies get used. In its 2026 State of NHI & AI Agent Breach Report, NHI Management Group analyzed more than 200 publicly reported breaches and found that secrets and passwords were the most exploited identity type, abused in 84 of them. The report’s explanation is the one this post started with: secrets get copied into places they should never be, including code, CI logs, container images, tickets, and chat. The places teams scan first are the places they already suspected.
This is also why AI tools belong in the conversation. An agent with access to a ticket queue or a shared drive has access to whatever secrets are sitting in them. The exposure is not new. What changes is how many things can read it.
What it takes to handle an exposed secret
A vault is authoritative about the secrets it holds. Once a copy lands anywhere else, the secret is exposed, and handling that exposure is a separate job. It comes down to five questions.
Where has the secret been exposed? Check the collaboration tools, ticket attachments, workstations, and public sources where leaked secrets end up.
Does the secret still authenticate? If it no longer works, each exposure is a cleanup task. If it still works, every exposed copy is an open door.
What does the secret reach? The permissions and resources of the identity it represents determine how urgent the exposure is.
Who can revoke the secret? Often not the person who leaked it. The engineer who pasted that configuration into Slack frequently cannot revoke the key inside it.
Did the secret stop working? Retest after the team acts, and record what came back.
That last one is the measurement that matters. A finding count rises when coverage improves, which makes it a poor signal of progress. Confirmed revocations only move when a secret actually stops working.
The vault was right
Nothing here argues against managing secrets properly. The vault did its job. It governed the secret it was given, rotated it on schedule, and recorded who retrieved it.
What it could not do is follow the value after it left. That is the gap sprawl lives in: one identity, governed at the source, live in every place it was copied to, and still live after the ticket says otherwise.
Finding a secret is not the same as eliminating the risk. The exposure ends when the secret stops working, and you know that only when something checks.
