Unrevoked OAuth tokens and stale permissions create a significant security risk, allowing access to internal systems to silently outlive an employee’s tenure long after they depart.
Apple has accused OpenAI of misusing its confidential information, like any lawsuit, the courts will have to sort these claims out. But one part of the story doesn't wait on a verdict: Apple’s claims that a former employee kept reaching Apple's internal systems for months after termination could only occur if a key offboarding step never happened.
An offboarding step didn't happen, and a former employee's access quietly outlived his employment. That mistake isn't exotic: it's one of the least monitored parts of enterprise security, and it doesn't take a sophisticated attacker to find it. It just takes someone who still happens to have the keys.
One of Apple’s key claims alleges that confidential information left the company in part through a former employee who kept access to Apple's internal systems after his termination, the result of an authentication flaw Apple has since fixed.
What isn't really in dispute is the offboarding gap itself. An access grant that should have ended on someone's last day quietly didn't, and that's true no matter how the lawsuit resolves. It's also not unique to Apple. It's a pattern our research team maps constantly in enterprise Google Workspace environments: an authorization that was reasonable on the day it was granted, and was never revisited on the day it stopped being reasonable.
Whether the mechanism is an unpatched authentication bug or an ordinary OAuth grant nobody remembered to revoke, the shape of the exposure is identical: access that outlives the relationship that justified it.
Offboarding checklists are built around the accounts people know to look for: email, SSO, the badge that opens the building. They are far less consistent about the long tail of authorizations an employee accumulated on their way through the organization: file-server access, connected apps, delegated permissions, service tokens. That long tail is exactly where access tends to survive.
This Is Not an Edge Case. It's a Category.
In our OAuth Risk Report, we analyzed 22,332 OAuth-connected applications across 21 enterprise Google Workspace environments. A meaningful share of that population is defined by exactly the same pattern: access with nobody left to account for it.
A useful fact most security teams learn the hard way: suspending an account does not revoke the OAuth tokens tied to it. An app that had access before someone left can keep reading files or sending on that account's behalf after they're gone, and nothing about that looks anomalous from the outside: there's no alert, no failed login, no unusual timestamp. It's simply access that was never told to stop.
In our dataset, 463 of those zero-user, still-live apps hold sensitive or restricted scopes: full Gmail, full Drive, in some cases admin-level permissions. These are not obscure integrations. They are some of the broadest access types Google's platform allows, sitting on accounts no one is actively watching.
Standard offboarding suspends the account. It rarely touches everything the account was ever authorized to do. That gap is where every one of these 1,064 tokens lives.
You Can't Protect What You Can't See
The offboarding gap is one half of the problem. The other half is more basic: most organizations don't have a clear picture of what a working credential (theirs or a former employee's) would actually find.
That specific case is about one file share at one company. But the broader question it raises applies everywhere: if someone with a still-live credential started browsing your file storage today, would you know what they found before they found it?
In early research our team has run across enterprise Google Drive environments, that question tends to have an uncomfortable answer. In one representative environment, scanning roughly 5.7 million files turned up close to 223,000 (about 4%) containing sensitive data: source code, financial reports, credentials, payroll records. Separately, close to 277,000 files were shared as "anyone with the link," including more than 130,000 with edit access. None of that requires a bug or a former employee. It’s what accumulates by default when sharing decisions are made once and never revisited.
The security industry has spent decades building better locks: perimeter defenses, phishing filters, credential hygiene, employee training. All of that matters. None of it answers the question that a story like Apple’s actually raises, which is what’s sitting inside the workspace for someone to find once they’re in, whether "in" means a phished password, an unpatched bug, or credentials nobody thought to revoke.
A locked front door doesn’t matter much if the filing cabinet inside was never locked either. Perimeter defenses answer "can they get in?" Very few organizations can answer "what happens if they do?"
Where This Leaves Security Teams
It will be up to a court to decide what happened in the Apple case and who, if anyone, is responsible. That process will take time, and speculating about the outcome isn't the point of this post. The point is that the mechanism at the center of it, access that quietly survives the end of an employment relationship, is not a rare failure mode. It's a structural one, and it shows up in ordinary enterprise environments far more often than in lawsuits, because most of the time nobody ever finds out.
The uncomfortable truth is that some version of this exposure exists in nearly every organization right now. Not because anyone did something wrong, but because granting access is a single click and revoking it requires someone to actively decide to do so, for every app, every file share, every departure. That asymmetry is where the gap comes from, and it doesn't close on its own.
A breach story like this one is a reminder, not an anomaly. The question worth asking isn’t "could this happen to us?" It’s "how would we know if it already had?"
Three Places to Start
None of these prevent every possible incident. They target the specific gaps this story illustrates: the ones most likely to still be open in your own environment today.
01 - Make offboarding cover more than the primary account
Suspending SSO and email is necessary but not sufficient. Build a checklist item (and ideally an automated check) for connected apps, OAuth grants, file-share permissions, and any device or credential that outlived the employee's last day. If it can't be verified as revoked, treat it as still live.
02 - Set a dormancy threshold for app access, and enforce it
Ninety days without activity is a reasonable line. Anything that crosses it should trigger a simple question: does anyone still need this? Start with the highest-risk subset: access with zero active users and sensitive or restricted scopes, since that's where dormant access and meaningful exposure overlap.
03 - Know what's actually sitting in your file storage
Access controls only matter relative to what they're protecting. Getting a real inventory of sensitive content in Drive and shared storage, and fixing the broadest sharing settings first, shrinks what any credential, current or former, active or forgotten, can actually reach.
About this piece: This post discusses allegations from Apple Inc. v. OpenAI, Inc. et al., filed July 10, 2026 in the U.S. District Court for the Northern District of California, as reported by TechCrunch, Fortune, and CNBC. The claims described are allegations from a civil complaint and have not been proven or tested in court. Nothing in this post is intended to suggest wrongdoing by any individual or company named in that litigation.
OAuth statistics: from our OAuth Visibility Gap report (22,332 applications across 21 enterprise Google Workspace environments). Drive statistics: preliminary Material Security research on one anonymized enterprise environment, ahead of a full report publishing soon.
