Verification Checklist

  • ✓Does the same-day offboarding checklist explicitly list "revoke all cloud sub-accounts (RAM or equivalent) and their API keys for this employee," rather than only "disable OA account" and "collect badge"
  • ✓Is the gap between when HR initiates offboarding and when IT actually revokes the sub-account tracked as a measurable interval, rather than left unrecorded
  • ✓Is the current way you catch a departed employee's still-working sub-account a monthly billing reconciliation, or is there a more proactive check triggered on offboarding day itself
  • ✓Have you actually read your multi-user/sub-account provider's documentation on whether disabling an account immediately invalidates its existing API keys, rather than assuming based on experience
  • ✓If the same employee held sub-accounts with more than one vendor (say, both DeepSeek and Qwen), was revocation carried out separately for each vendor, not just the one used most

1. Two separate timelines: HR offboarding and IT access revocation

Most companies run offboarding through an HR system: the employee submits a resignation, it goes through approval, and on the last day HR flips the employee's status to "departed," which typically triggers disabling the OA account, freezing the corporate email, and reporting the access badge lost — things directly tied to physical access and daily office tools, usually completed the same day. Cloud-platform RAM sub-accounts and LLM API keys, though, are usually provisioned and managed separately by IT or engineering, with no automated link back to the HR system. For IT to revoke access, it first has to learn the person left — typically via a separate email or ticket from HR — and then manually locate and act on the corresponding sub-account in the cloud console. That handoff from "HR knows" to "IT acts" already involves a manual relay step, and the odds of it being delayed or dropped entirely are not low.

2. As long as the sub-account exists, the key still works — revocation isn't one atomic step

Even once IT receives the offboarding notice, actually shutting things down isn't a single click. Take Alibaba Cloud RAM as an example: a departed employee may have a RAM user, one or more bound AccessKeys, and attached permission policies all still in place, and fully cutting off their ability to call an LLM API usually requires disabling the RAM user's login, deleting or disabling its AccessKey, and detaching the relevant policies — missing any one of these steps can leave a gap through which the API can still be called. For services like the DeepSeek open platform or Qwen (Alibaba Cloud Model Studio / DashScope), when a company distributes call permissions through its own multi-user or sub-account system, "revoking access" effectively spans two layers: the cloud account's sub-account permissions, and the vendor-side API key or credential itself. If those two layers aren't linked by the same system, missing either one leaves a working key that keeps generating charges.

3. Why monthly billing review is always a step behind

The method many companies currently rely on to catch "access wasn't fully revoked" issues is a monthly finance or IT review of the bill, looking for unusual swings in usage or spend. That approach works, but it's structurally slow: billing cycles typically run monthly, so by the time someone flips through the statement and notices usage on a sub-account or key that shouldn't be active, it may already be three or four weeks — or longer — since the employee actually left. The charges from that window have already been incurred, and the only thing left to do at that point is revoke the access after the fact; the money is largely unrecoverable. It gets worse if the departed employee's usage volume was small to begin with — the anomaly can get lost inside the overall bill, making manual review an unreliable detection method.

4. What companies should actually do: put sub-account revocation on the same-day IT checklist

Instead of relying on monthly billing review, a more workable approach is to make "revoke LLM API sub-account access" an explicit, checkable item on the same-day offboarding IT checklist — executed on the same day, alongside disabling the OA account and collecting the badge, rather than through a separate, manually-triggered process that lags behind. Concretely, this means keeping a queryable inventory of every cloud sub-account and LLM API key issued to each employee, having IT walk through that inventory item by item on the employee's last day to disable and revoke each one, and having that step signed off on the offboarding handoff form so any gap can be traced back to exactly where it broke down. For larger organizations with many sub-accounts, it's also worth exploring the cloud platform's own automation — linking sub-account permissions to the corporate identity system, for instance — to shrink that gap further. But whatever the technical approach, the requirement that revocation happen on the employee's last day shouldn't be allowed to slip into "we'll catch it on the next billing cycle."

5. Vendor rules differ — follow the official documentation for the specifics

It's worth noting that sub-account and RAM-style access revocation mechanics differ by vendor in the details — for example, whether an already-issued AccessKey is invalidated immediately or after some caching delay once its parent account is disabled, and whether the vendor-side LLM API key automatically follows the sub-account's status. No publicly available source found for this article states a single, cross-vendor guarantee on this behavior. When designing an offboarding revocation process, companies should follow the current official documentation of the specific cloud platform and LLM vendor they actually use, and when in doubt, confirm directly with that vendor's support or ticketing channel exactly when "disabling the account" and "revoking the key" take effect and what they cover. These details vary by vendor and can change as products evolve, so don't extrapolate from one vendor's behavior to another's.