Explain This: The Apple offboarding lawsuit is really about access residue
Offboarding is only complete when systems prove access, tokens, devices, and inherited permissions no longer work.
Apple's lawsuit against OpenAI has the headline shape of a trade secrets fight.
The operational lesson is simpler and more useful: offboarding is not done when HR marks someone terminated. It is done when the systems prove that access, devices, tokens, shared repositories, sync clients, VPN profiles, and delegated permissions no longer work.
According to TechCrunch, Apple alleges that former employee Chang Liu accessed confidential Apple files after leaving for OpenAI. Apple says he exploited a rare, previously unknown authentication bug that allowed continued access to network storage. Apple also alleges that the files included unreleased product materials, engineering presentations, specifications, and project data.
That is not just an insider-risk story.
It is an access-residue story.
What it is: access residue after offboarding
Access residue is what remains after a company believes an identity has been removed.
It can look like an old laptop that still syncs.
It can look like a VPN profile that still authenticates.
It can look like cloud storage permissions inherited through a group that no one owns anymore.
It can look like a former employee using someone else's active device or credentials.
The risk is not limited to malice. Sometimes residue comes from sloppy entitlement design. Sometimes it comes from emergency exceptions that became permanent. Sometimes it comes from SaaS sprawl where each system tells a slightly different story about who is still allowed in.
Why it matters legally
Trade secret cases often turn on control.
A company claiming trade secret protection has to show that it took reasonable steps to keep the information secret. That does not mean perfect security. It does mean the company should be able to explain what controls existed, how access was limited, how departures were handled, and how suspicious activity was detected.
If a former employee can still reach sensitive repositories weeks after leaving, the legal question gets uncomfortable fast.
Was this an unknown authentication flaw, a deprovisioning failure, an overbroad group permission, a device-control gap, or some combination of all four?
The answer matters because it changes the story from "someone stole our secrets" to "our systems still trusted someone we said no longer belonged here."
That distinction matters in litigation, insurance, vendor diligence, customer trust, and board reporting.
The AI-company wrinkle
The OpenAI angle makes the story louder, but not conceptually different.
AI companies are hiring aggressively from firms with valuable technical, product, and research roadmaps. That makes employee mobility a governance issue, not just a recruiting issue.
Companies should assume that high-value employees move with muscle memory: saved workflows, local notes, synced folders, private repositories, credentials, model evaluation artifacts, design docs, and informal access patterns.
Some of that is legitimate knowledge. Some of it is proprietary material. Some of it sits in the gray zone until a lawsuit forces everyone to define it under oath.
That is why access governance cannot live only in policy language. It has to show up in logs.
What to do this week
Start with the last 90 days of departures, especially employees who had access to product strategy, source code, security tooling, customer data, legal files, or AI research materials.
For each person, confirm five things:
- Their primary identity is disabled across identity provider, email, device management, source control, cloud storage, ticketing, VPN, password manager, and privileged access tooling.
- Their devices are returned, locked, wiped, or explicitly marked as unrecovered with compensating controls.
- Their group memberships no longer grant inherited access through shared drives, admin groups, legacy teams, or project folders.
- Their tokens, SSH keys, API keys, OAuth grants, sync clients, and service-account relationships are revoked or rotated.
- Their post-departure activity logs show no successful access after the termination timestamp.
Do not stop at the HR system. HR tells you who left. It does not prove the network stopped trusting them.
What legal and compliance teams should ask for
Ask for an offboarding evidence packet, not a policy PDF.
The packet should include:
- termination timestamp
- identity-disable timestamp
- device status
- privileged-access revocation
- repository and cloud-drive access review
- post-termination access search
- exceptions and who approved them
- remediation steps if anything remained active
If the company handles trade secrets, regulated data, AI training data, source code, or customer confidential information, this packet should be routine.
It should not be invented after an incident.
The operator lesson
Every company has a version of this problem.
The names change. The systems change. The risk does not.
A former employee should not be able to discover a rare bug by trying old access and finding that the door still opens. A current employee should not be able to lend an active device into a dispute. A cloud repository should not rely on everyone remembering which shared folder matters.
Offboarding is not a checklist.
It is a control test.
If the test cannot prove that access died, the access is not dead.
