The Security Experts Protecting America Just Got Caught Doing the Thing They Tell You Never to Do

You've been lectured about password hygiene. Told to use two-factor authentication. Warned never to leave credentials lying around where someone could find them.

A couple weeks ago, the Cybersecurity & Infrastructure Security Agency — CISA, the federal team literally responsible for protecting America's critical infrastructure — got caught doing exactly what they've been telling you not to do for twenty years.

A contractor working for CISA left Amazon Web Services access keys sitting in a public GitHub repository. Not for a few hours. Not accidentally. For months. Anyone could see them. Anyone could use them. These weren't keys to a personal Dropbox. These were government cloud credentials — the kind that unlock access to systems that protect pipelines, power grids, and election infrastructure. We talked about it on issue 8 of identity decoded.

But it gets worse.

While CISA was leaving keys in public view, Microsoft shipped billions of Android app downloads with a debug flag turned on. Word, Excel, PowerPoint — all of them. That flag disabled a security check designed to stop other apps on your phone from stealing your Microsoft 365 login tokens.

Translation: any random app you installed — a flashlight app, a photo editor, a game your kid downloaded — could grab your work login and use it. No password needed. No two-factor prompt. Just access.

Microsoft didn't catch it. Security researchers did.

Same week: hackers figured out they could ask Meta's AI chatbot to hand over control of high-profile Instagram accounts by pretending to be the owner and requesting an email change. The AI — designed to be helpful — just… did it. No verification. No human review.

This isn't a string of bad luck. It's a pattern.

The organizations building and operating the systems you depend on are making amateur mistakes at industrial scale. And the consequences don't stay inside the enterprise. They land on you.

Here's what changed.

Five years ago, developers worked in controlled environments. Security reviews happened before code shipped. Someone checked the settings.

Now, AI writes half the code. Teams ship updates daily. Cloud infrastructure spins up in minutes. Every app connects to twelve other services. And speed matters more than safety — because if you're not shipping faster than your competitor, you're losing.

The tools got more powerful. The teams got smaller. The pressure got higher. And nobody's checking whether the debug flag is still on when the app goes to three billion phones.

CISA's contractor wasn't malicious. Microsoft's developers weren't careless. Meta's AI team wasn't ignoring risk. They were all moving fast in complex systems where one overlooked detail creates a vulnerability that affects millions of people who have no idea it exists.

You can't patch what you don't know is broken.

And the people responsible for knowing? They're overwhelmed, under-resourced, and working in environments where a single line of leftover code can sit in production for months before anyone notices.

You can't fix CISA's GitHub hygiene. But you can reduce your exposure to the next one.

1. Assume every app on your phone can see more than it should.

Go to Settings → Privacy → scroll through every app. Revoke permissions that don't make sense. A flashlight app does not need access to your contacts. A photo editor does not need your location all the time.

2. Use different accounts for different things.

One Microsoft account for work. A separate one for personal email. If one gets compromised, the other stays safe. Inconvenient? Yes. Effective? Also yes.

3. Turn on login alerts.

Microsoft, Google, Apple — they all offer alerts when someone logs into your account from a new device or location. Turn them on. If you get an alert you didn't trigger, change your password immediately.

4. Check what's connected.

Go to your Google, Microsoft, Apple, and Meta account security pages. Look at the list of devices and apps with access. Remove anything you don't recognize or don't use anymore. Do this quarterly.

5. For business owners: ask your IT team one question.

"Do we have a process to find and remove debug flags, test credentials, and leftover access keys before code goes to production?" If they hesitate, you have a problem.

I've been on the other side of these reviews. Early in my career, doing an access rights audit for a mid-size financial services firm, we found AWS access keys hardcoded directly into a production application — keys that had been sitting there, in the clear, for over two years. Nobody had put them there maliciously. A developer had needed to test something quickly, committed the file, and then moved on. Nobody reviewed it. Nobody flagged it. The keys just... stayed.

What struck me wasn't the mistake itself — it was how invisible it was. The application worked fine. Deployments ran fine. There was nothing to indicate anything was wrong, because nothing had gone wrong yet. That's the nature of credential exposure: you don't know it's a problem until someone decides to make it one.

After we cleaned it up, I asked how many other repositories we should check. Silence. Nobody knew. That audit turned into a three-month project.

The CISA contractor who left those AWS keys in GitHub wasn't reckless. They were busy. That's the real lesson here. In environments moving fast, the dangerous things don't announce themselves. You have to go looking — and most teams aren't looking.

Have you ever discovered a setting, an old login, or a permission that should've been turned off months ago — but wasn't? What was it, and what made you finally notice?

Identity Decoded publishes every week at identity-decoded.com