Five Minutes From GitHub Commit to Azure Breach: Why Secrets Hygiene Needs to Be a Managed Service

A developer pushes a commit at 9:14am. By 9:19am, an attacker is reading the contents of an Azure Key Vault that should never have been reachable from the public internet. No phishing email. No clever social engineering. No weeks of patient reconnaissance. Just a connection string left in a config file, scooped up by an automated agent that did in five minutes what a human attacker used to spend an afternoon on.

This is not a hypothetical. Security researchers and incident responders have now documented attack chains exactly like this one, and the common thread is the same: a secret that leaked into a public or semi-public repository, discovered and weaponised by AI agents that scan, test, pivot and exfiltrate without a person at the keyboard. The speed is the story. What used to be a slow race — you rotate the key before someone finds it — is now a sprint you've already lost by the time you notice.

For anyone running a small or medium business in Nottingham or anywhere else, the lesson is uncomfortable but useful. Secrets hygiene has quietly moved from a thing your developers were supposed to handle to a thing that needs owning, monitoring and billing like any other managed service.

How the five-minute breach actually works

Let's walk the chain, because the detail matters.

Step one: the leak. A developer hardcodes an Azure credential — a storage account key, a service principal secret, a connection string — into source code. They mean to pull it out later. They don't. Or they add it to a .env file that was supposed to be in .gitignore but wasn't. The commit lands in a repository. Sometimes that repo is public. Sometimes it's private but shared across a sprawling org with hundreds of contractors. Either way, the secret is now sitting in commit history, which is forever unless someone rewrites it deliberately.

Step two: discovery. This is where things have changed. There have always been bots trawling GitHub for exposed keys — it's why cloud providers now scan public repos themselves and sometimes auto-revoke keys. But agentic AI does more than pattern-match for a string that looks like a secret. It reads the surrounding code to understand what the secret is for. It works out that this particular key talks to an Azure storage account, and that the same repo references a Key Vault, and that a service principal with broad permissions is probably sitting behind it.

Step three: validation and pivot. The agent tests the credential. It works. It then uses the access it has to enumerate what else is reachable — other storage accounts, the Key Vault, any identity whose permissions it can borrow. Where a human would be reading documentation and typing commands one at a time, the agent chains these steps automatically, following the path of least resistance.

Step four: exfiltration. The Key Vault contents — which often include more secrets, because that's what vaults are for — get pulled out. Now the attacker has the keys to databases, APIs, third-party services, payment integrations. One leaked credential has become a master key.

The entire sequence, start to finish, has been reproduced in minutes. The window in which a human defender could have spotted the leak and rotated the key no longer exists in any practical sense.

Why 'tell the developers to be careful' has stopped working

The standard advice has always been: don't commit secrets, use a vault, rotate your keys. All correct. All insufficient.

Developers are not careless as a rule, but they're human, they're under deadline pressure, and the tooling has historically made doing the right thing slightly harder than doing the convenient thing. A single mistake in a single commit, buried in history and never noticed, is all it takes. You cannot train your way to zero leaks, and even if you could, you'd still have years of legacy repositories full of secrets nobody has audited.

The asymmetry is the problem. The attacker's side is now automated and instant. Your side — if secrets hygiene is an occasional manual chore — is slow and reactive. That gap is exactly the sort of thing a managed service exists to close.

What a secrets hygiene managed service actually covers

This is where MSPs can offer something concrete rather than vague reassurance. A proper secrets hygiene service has a few clear components.

Continuous secrets scanning. Not a one-off audit, but ongoing scanning of repositories — including full commit history — for exposed credentials. When something is found, it's flagged and triaged immediately, not at the next quarterly review. Tools like GitHub's own secret scanning, GitGuardian and TruffleHog form the backbone here, but someone has to own the alerts and act on them.

Automated credential rotation. Finding a leaked secret is only half the job. The secret has to be revoked and replaced, ideally fast enough to beat the agents. Where rotation can be automated — and for many Azure resources it can be — it should be. Where it can't, there needs to be a defined, practised runbook so nobody is improvising during an incident.

The migration to managed identities. This is the real prize, and it's a project an MSP can scope and sell today. Azure managed identities remove the secret from the equation entirely. Instead of a service holding a credential that can leak, Azure itself vouches for the identity of the resource. There's no connection string to commit, no key to rotate, nothing for an agent to find in a repo because there's nothing there. Moving an estate from secrets-in-config to managed identities is real, billable work with a clear security outcome.

Monitoring and alerting on the vault itself. Even with managed identities in place, you want eyes on Key Vault access patterns. Unusual enumeration, access from unexpected locations, a spike in secret retrievals — these are the signatures of the attack chain above, and catching them buys back some of the time the automation took away.

How to sell it, how to scope it

The neat thing about this as a managed service is that it has a clear before-and-after. You can walk a prospect through their own exposure in an afternoon: run a scan across their repositories, show them the secrets sitting in history, and let the results speak. Almost every estate has something.

From there the engagement structures itself. A one-off remediation project to clean up what's already leaked and rotate the live credentials. A scoped migration to managed identities for the services that support it, phased by risk. Then an ongoing monitoring and rotation service billed monthly, because the scanning never stops and new code gets written every day.

For the client, the pitch is simple and honest. The threat got faster. Your defences need to be automated and owned, not occasional and hoped-for. For roughly the cost of a minor incident's cleanup, you get the thing that stops the incident happening.

The five-minute breach is a genuinely alarming development. But it's also clarifying. It takes a problem that was always real and always under-prioritised, and makes it urgent enough to act on. That's exactly the kind of problem a managed service should be solving — before the next commit lands at 9:14 in the morning.