Left Unsupervised: 10 Times Access Outlived Its Authorization

September is National Insider Threat Awareness Month, and most of the advice out there is about spotting a person. The insider here is rarely a person. It’s a credential nobody rotated, or an agent nobody kept watching. Each was access granted on purpose, then left unmonitored. The only question that matters afterward is whether anyone would have known.

That’s the generous read on what follows, because most of the 10 incidents below came with no warning at all. Even Troy got one. The Trojans did check the horse, though that’s usually the part that gets left out of the story. Laocoön put a spear in its flank, Cassandra warned anyone who’d listen, and an argument was recorded. The doubts were explained away, and the horse wheeled through the gate regardless. That’s the myth; but what follows isn’t.

Once someone detects an incident like this, the industry average for containing it in 2025 was 67 days, down from 81 days the year before. That clock assumes someone already sounded the alarm. Nobody did here. There’s no spear thrown or argument to explain away either, just access left running the whole time, unsupervised.

1. Data that should have been deleted: a $13 million fine for AT&T

In January 2023, a breach at a cloud vendor led to exposed billing and account details for 8.9 million wireless customers. The data itself was unremarkable. The date on it was the problem. Under the terms of the contract, the vendor should have destroyed those records years before the relationship ended, and that destruction was never confirmed. AT&T agreed to a $13 million settlement with the Federal Communications Commission in September 2024 over the failure to confirm the data was gone.

Would you have known? 

Only at the exit, and that's the check most programs skip. Add a closeout step to vendor offboarding that requires written certification of destruction, the date it happened, and the systems it covered, then store that evidence against the vendor record the same way you store a completed questionnaire. Most third-party risk programs assess a vendor at onboarding and again at renewal. Add the third gate at termination, because that's the moment the data stops being anyone's job.

2. Old OAuth tokens became an attacker’s way in for GitHub

In April 2022, an attacker used stolen OAuth tokens issued to two integrators, Heroku and Travis-CI, to download private repository contents from dozens of organizations, including npm. GitHub's advisory made it clear that the theft occurred at the integrators. The tokens were valid grants, approved once by developers who wanted two tools to talk to each other, and they kept working long after anyone remembered approving them.

Would you have known? 

Your own logs would show a trusted integration pulling repositories, exactly what the token was issued to do. GitHub caught it centrally and told the affected organizations. To answer it yourself, pull the list of authorized OAuth applications across your source control, identity provider, and productivity suite, and work down it on a fixed cadence: who approved this, what does it still need, and when does it expire. Keep that answer on record, not just in someone's memory, because six months later "who approved this" is a question only the log can answer. Set the expiry at the point of approval, while someone still remembers why the grant exists. A token nobody's using is a token nobody's watching, and integrations outlast the people who set them up.

3. Exposed in 2017, it became a five-year blind spot for Toyota

A subcontractor building Toyota's T-Connect service pushed part of the application's source code to a public GitHub repository in December 2017, including an access key for a customer database. It stayed there until September 2022, with nearly 300,000 customer records reachable the whole time. Toyota said it couldn’t confirm whether anyone accessed them.

Would you have known? 

Only if something was scanning, because a committed key just sits there, working, until someone looks. Run automated secret scanning with push protection on every repository you own, then extend the requirement by contract to the subcontractors writing code on your behalf and ask for evidence that it's switched on. That turns a five-year window into a five-minute one. Retain access logs for how long a credential could plausibly remain valid, not just your compliance minimum; otherwise, discovery becomes a second blind spot instead of an answer. The failure here is structural: a pipeline built to ship fast will ship a secret just as fast, unless something is watching for it.

4. Ignored 11 times, a freeze led to a deleted database for Replit

In July 2025, SaaStr founder Jason Lemkin was nine days into building an app with Replit's AI coding agent when it deleted his live production database of 1,206 executives and roughly 1,200 companies, during a freeze he'd repeated in capital letters. The agent then told him rollback was impossible. It worked fine. Replit's chief executive called the incident unacceptable, refunded Lemkin, and shipped automatic separation between development and production databases within days.

Would you have known? 

You'd have known the database was gone within minutes, because Lemkin did. The hidden failure was trusting the agent to log its own actions. Give each agent its own credentials scoped to non-production, put an approval gate in front of destructive operations so a human can confirm the drop, and log agent actions in a separate store under human control. That last control matters most: the agent misreported its own actions twice, first by generating fake records over the gap and then by ruling out a rollback that worked. Always keep an independent account of what the agent did.

5. Credentials marked unused became a second breach for Cloudflare

After attackers breached Okta's support system in October 2023, Cloudflare rotated the exposed credentials. One service token and three service accounts remained in place and were assessed as unused. On Thanksgiving Day a month later, a suspected nation-state actor signed in with those four and reached Cloudflare's internal wiki, bug database, and source code management system. Cloudflare published the full timeline itself, including that detail.

Would you have known? 

Cloudflare did. Detection worked, and the response was documented. What failed earlier was a judgment call: four credentials were assessed as unused and left in place. So make rotation scope automatic. When a third party discloses a breach, every credential in that blast radius is rotated, and any exception must be justified with a last-used timestamp from the logs. A credential is exactly as live as your logs say, whatever the label on it claims.

6. Buried in a crash dump, a two-year exposure for Microsoft

A Microsoft consumer signing key ended up inside an internal crash dump in 2021 and sat there for two years, outside every system built to manage keys. In 2023, a China-based actor Microsoft tracks as Storm-0558 used it to forge authentication tokens and read email at roughly 25 organizations, including US government agencies.

Would you have known? 

One customer did. The US State Department flagged the activity in June 2023 after spotting mailbox access events associated with an unfamiliar application ID, using audit logging in the premium tier at the time. The other organizations lacked the telemetry to see forged tokens opening their own mailboxes.

Two moves come out of that. Point your secret scanning at crash dumps, memory captures, and diagnostic logs as well as source code, because a key keeps working wherever it comes to rest. Then audit your own logging tier against the events you'd need for an investigation, confirm that data access is one of them, and upgrade the tier if it falls short. Microsoft moved those events into the standard tier afterward, under pressure from the Cybersecurity and Infrastructure Security Agency, but that puts the fix on the vendor's schedule. Owning your logging tier keeps it on yours.

7. Never reviewed twice, a shared exposure spread across Salesloft Drift

In August 2025, attackers obtained OAuth tokens tied to Drift, an AI chat integration. They used them to query and export Salesforce data from hundreds of organizations, including Cloudflare, Google, and Zscaler. The tokens belonged to software, so the export traffic looked exactly like an integration doing its job.

Would you have known? 

Most affected organizations found out from a notification, because the queries arrived through an approved integration at a plausible rate, carrying a token their own team had granted. Route AI tool connections through the same intake as a new hire's access request: least privilege on the scopes, a named owner inside the business, and a review date on the calendar. Keep a log of what each integration pulls, separate from the integration's own reporting, so if a token's grant is ever questioned, you have your own record to check it against rather than the vendor's word. Then set an alert on export volume per integration, since the thing that separates a chatbot from an exfiltration tool is how much it pulls.

8. Valid since 2020, a 560 million-record breach for Ticketmaster

Nobody broke into Snowflake in 2024; they just signed in. The credentials came from infostealer malware, some of it circulating since 2020, and still worked on customer accounts protected by a password alone. The campaign caught around 165 organizations, and Ticketmaster alone had 560 million customer records exposed.

Would you have known? 

A valid login produces a successful login, the one event your alerts are built to wave through. Enforce multi-factor authentication at the platform level on every third-party system that holds customer data, so every account inherits it, and close the carve-outs for service accounts, read-only users, and demo environments, where the exceptions are collected. Where a workload genuinely can't take multi-factor authentication, wrap it in an allowlisted network range. Maintain login records that capture device and location alongside the timestamp, not just success or failure, so if a credential turns up on a criminal marketplace years later, you can check whether it was ever used from anywhere your own people weren't. A password stays valid however old it gets, and four years is long enough for everyone to forget a credential except the person selling it.

9. An overscoped role became an open door for Capital One

In March 2019, a server-side request forgery flaw in a misconfigured firewall exposed an attacker to credentials for a cloud role that could access more than 700 storage buckets, far beyond what the firewall needed to do its job. The distance between what the role was for and what it could touch turned one misconfiguration into 106 million exposed customer records.

Would you have known? 

Capital One found out roughly four months later, from an outside researcher who emailed its responsible disclosure address, because until then the role was doing what a role with those permissions is permitted to do. Audit what a role can reach in practice, which is a different number from what it was assigned: run your cloud provider's access analyzer against every role, compare what it can reach to what it used in the last 90 days, and cut the difference. Permissions accumulate quietly, because widening a role takes five minutes and narrowing one means finding out what breaks.

10. One stolen token, a self-replicating crisis across npm

First seen in September 2025, the Shai-Hulud worm steals a developer's npm publish token, pushes infected versions of every package that token controls, and collects the next set of tokens from whoever installs them. After the first infection, the worm spreads on its own. The second wave in November 2025 compromised hundreds of packages and exposed thousands of secrets across nearly 500 organizations.

Would you have known? 

An infected release looks like a version bump from a package you already trust, published by the token that always publishes it. Move publishing to short-lived, provenance-backed credentials your build system mints per release, so each token dies with the release it published, and pin dependencies with a lockfile so every new version passes through a review before it lands. Each of the incidents above required someone to come along and use the open access. This one runs on its own. It's what standing credentials look like when the thing that finds them is automated and moves faster than any review cycle was built to.

‍