Every major incident we get called in to clean up has one thing in common. Not a clever exploit. Not a zero-day. Not some sophisticated nation-state attack. It's always a credential that was trusted when it shouldn't have been. The shape of the problem changes. The root cause doesn't.
Three very different stories, one identical failure
Look at what happened when ConnectWise had to kill seven application identities after attackers used them to walk straight into Microsoft 365 tenants. Nobody kicked down a door. The system did exactly what it was designed to do: it saw a valid identity and said "come on in." The credential was real. The holder was not who the system assumed.
Now look at what happened in Savannah. A police officer handed her Flock license-plate-reader login to her husband, an ICE agent, because he needed access and she had it. Same structural failure. The system authenticated successfully. It had no idea the person on the other end was not the person it thought it was. The credential was valid. The context was completely wrong.
Then look at how most webhooks are built. The dominant pattern is symmetric HMAC signatures, meaning the sending server holds a secret for every endpoint it talks to. If that secret leaks . from a breach, a misconfigured log, a developer copy-pasting it into Slack . every endpoint on the other side of that trust relationship is exposed. One secret, unlimited blast radius.
Three domains. Security software, law enforcement surveillance infrastructure, webhook authentication. Same story every time: the credential became the vulnerability.
Why this keeps happening
The honest answer is that we build systems to authenticate identity, but we barely think about what identity actually means under pressure. A username and password confirm that someone knows a secret. They say nothing about whether that person is the right person in the right context with the right intent. We confuse the signal for the thing it's supposed to represent.
This is exactly what Anthropic's research into how AI models reason internally keeps surfacing: systems that appear to be doing one thing are often doing something subtly different underneath. The behavior looks correct until it doesn't. The same is true of authentication. Access looks controlled until you realize you've been measuring the wrong thing the whole time. You measured "did the credential match?" You should have been measuring "does this access make sense?"
And look at what happens when you get the incentive structure right. Dhar Mann Studios scaled from YouTube to Disney and Fox deals by building fast feedback loops into every decision. Rapid audience testing, short production cycles, constant signal from the real world. They didn't trust the assumption that something would work. They built systems to verify it continuously. That's the discipline missing from most access control: you set a policy once, you never revisit it, and you assume it's still true six months later. It isn't.
What you're probably getting wrong right now
If you're running any kind of product that talks to third-party services, you almost certainly have shared secrets sitting somewhere they shouldn't be. Environment variables in a repo. API keys in a legacy deploy script. Webhook secrets in a Notion doc someone made "just for the team." Every one of those is a ConnectWise incident waiting to happen. The attack doesn't need to be sophisticated. It just needs to find the secret.
If you have employees with system access, you almost certainly have accounts that haven't been audited since the person was onboarded. People get promoted, change roles, leave. The credential stays. The access stays. Nobody checks. The Savannah situation isn't a story about a bad actor. It's a story about what happens when access management runs on the honor system.
And if you're building integrations between systems, you almost certainly defaulted to HMAC because it's what every tutorial shows and every library supports out of the box. That's fine. But you probably haven't thought about what happens when one of your shared secrets gets out, because nothing bad has happened yet and you've been busy shipping features.
The three things worth doing this week
First: audit your application identities. Not next quarter. This week. List every service account, every OAuth connection, every API key with write access to something that matters. For each one, ask: if this credential was compromised today, what's the blast radius? If the answer is "a lot," that's your first fire.
Second: treat departures and role changes as security events, not just HR events. Every time someone's relationship to a system changes, their access should be reviewed. Not assumed to be fine. Reviewed. The policy doesn't need to be punitive. It just needs to exist and actually run.
Third: if you're building a webhook system or any kind of event-driven integration, think hard about whether symmetric signatures are the right call for your threat model. Asymmetric approaches force a cleaner separation between who can send and who can verify. That separation is worth the engineering investment if you're building something people will stake real operations on.
The thing nobody says out loud
Most credential breaches aren't the result of sophisticated attacks. They're the result of nobody being explicitly responsible for the question "who has access to what, and should they?" That question lives in the gap between engineering, ops, and whoever runs HR. It falls into that gap constantly. And the only time it surfaces is after something goes wrong.
We've been building on the web for 25 years. The same gap has existed the entire time. It's not a technology problem. It's an ownership problem. Assign it or it won't get done. The attacker doesn't need to be clever. They just need to find the thing nobody owns.
Your credential surface is probably bigger than you think. Map it before someone else does it for you.