Security and secrets: why do most secrets leaks start with a tool nobody wanted to use?

In a growing organization, a new engineer joins on a Monday. By eleven, she needs the local config to run the app on her machine. Her onboarding buddy copies the connection string, the API keys, the whole block, and pastes it into a direct message on the internal communication tool of choice. She is unblocked in a minute. But that copy-paste is where the leak begins. Two weeks later a value changes, another paste happens, meaning another leak. And this sequence is something I have watched this play out with team after team.

This observation leads to a possible conclusion: secrets do not leak of carelessness alone. They leak because the secure path costs more effort than the insecure one, so people find a way around it. Let's call it the fit gap. Data leaks are bigger than most teams would like to admit. AI has added to it. The tools built to close it assume infrastructure most teams do not have. And the best way out is security designed for the team that already exists.

The source is always the channel within reach

The config file has become one of the most obvious places a company's secrets can escape, and the scale is not marginal. GitGuardian counted 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% jump over the prior year and the largest single-year rise it has recorded. Public GitHub is what is visible. But it is in internal repositories, where teams feel safe, that are six times more likely to hold a hardcoded secret. And 28% of leaks now start outside code, in Slack, Jira, and email, the channels people reach for when they are moving fast. The cost compounds. IBM puts the average breach that begins with a stolen credential at $4.67 million, and those take about 292 days to find and contain, longer than any other way in. This is deceptive, as it looks more like a login than an attack.  

AI may have made this easier

While AI coding did not invent this problem, it certainly stripped out the friction that once held it back. Work that took a week now takes an afternoon, written by more people, shipped faster, with the old habit riding along. GitGuardian found that AI-assisted commits leak secrets at about double the baseline rate. Credentials for AI services rose 81% in a single year. The latest surface is already leaking: 24,008 secrets turned up in Model Context Protocol config files in their first year, in part because the official setup guides tell developers to paste keys straight into the config. And most teams never clean that up. Of the secrets confirmed valid in 2022, 64% were still live in 2026. The issue here isnt finding the leak, but rather rotating it.  

The industry's answer assumes infrastructure that teams don't have

The industry has a fix, and it is the right one for large companies. Gartner's 2026 guidance and Forrester validate the fix too: “stop storing static credentials, move to secretless architectures and workload identity, let a service prove who it is instead of carrying a secret around like a spare key”. This works well when you have cloud-native infrastructure, an identity provider to federate against, and a platform team to run it. Most teams don't have any of the above.  

And the category-defining tool comes at a hefty price. For example, a production-grade vault cluster starts near $1,150 a month, before roughly $73/month add-on for every service that authenticates to it. Buyer's guides now advise teams not to adopt it until they pass fifty services. There is a free community edition, but you still have to stand up and run the infrastructure yourself, which is the part small teamscannot spare. These teams then choose from the options left: run infrastructure it has no people for, buy a per-seat cloud service and trust the vendor to hold its keys, or route around all of it. Most teams pick the third option, which is where the leak happens.  

If you can't buy, build security for the team you are

Security that fits a small team looks different from a shrunk enterprise vault. And it is essentially an "offline-first, zero cloud dependency" model. Three years ago, this would’ve sounded like a compromise. But today, it appears as a deliberate route, because the frontier now assumes infrastructure most teams will never build. Point the encryption at storage the team already owns, the shared drive it already trusts, and layer role-scoped access on top. In my POV, there is no attack surface at a storage tier that is not controllable. It costs nothing. And governance stops being a feature rented out and becomes a property of the setup: who can see what, enforced at the layer you run yourself.

I have built this way, and I would argue for it in any room. Security should be designed for the team as it exists.  

Leaked credentials and data are cheap to create, but expensive to survive. It sits quiet for months before anyone notices. The teams that stop leaking secrets will not be the ones who bought the most advanced vault. They will be the ones who designed security around how they work. Look at a team's last close call and ask one question: was anyone careless, or did the secure path cost too much?  Building systems that fit the business instead of the other way around is the best place to start. That's where I did.