A password reset is an incomplete recovery plan when the stolen material includes session tokens and API keys. In research published on September 9, Okta examined infostealer logs released on August 2: 5,871 machine folders spanning 162 countries. It found 1,843 JWTs and encrypted JWTs whose expiry dates had not passed when the dump was released, plus 24 API keys it identified as still valid across four AI services.
Those are observations from one sample, not a count of confirmed account takeovers. The Hacker News covered the findings; its reporting does not independently reproduce Okta's measurements. Google's separate September 8 threat report describes malware targeting AI developer configuration secrets, providing independent context for the broader pattern rather than verification of this particular dataset.
What the findings establish
Okta describes stolen authentication material that could enable access without another password or MFA challenge. An unexpired token is not necessarily usable: revocation, device binding and access policies can change the outcome. The publication does not establish which accounts were successfully accessed or whether the keys remain usable today. This is a new study of an earlier sample, not evidence of a new breach at every provider represented in it.
Give each kind of access its own recovery step
For an incident coordinator, the useful unit of work is an access path. A developer may have a browser session for an AI assistant, a separate API key in a local tool and a cloud identity that can create more keys. Closing one path does not demonstrate that the others are closed. Our recommended recovery record has one row per service and credential type, with an owner, a containment action and evidence that it worked.
- Establish a clean recovery device. Isolate the suspected endpoint under your incident procedure. Use a managed device the response team trusts for administrative work. Do not create replacement secrets on the machine still being investigated.
- End existing sessions. Use each affected service's session and connected-application controls. Check whether the action also revokes refresh tokens and application sessions; record gaps that need provider support.
- Revoke exposed API keys separately. Identify the key's owner and dependent applications. During a confirmed compromise, prioritize cutting off attacker access; coordinate the resulting service interruption with that owner.
- Review ways to regain access. Inspect recovery contacts, registered authenticators, application grants and newly created keys or identities. Remove unauthorized changes before returning the account to normal use.
- Check use and cost. Preserve the relevant sign-in, key-management and usage records. Review unexpected workloads and charges with the provider. A quiet billing graph alone does not prove that private content was untouched.
Keep the incident ticket useful without copying the secret
A good ticket can say who revoked a key, which application needs a replacement and when the new configuration passed its health check. It does not need the complete old or new key. Use the provider's non-secret key identifier, a timestamp and the result of the administrative action. Keep sensitive forensic material in the team's restricted evidence store, with access and retention rules appropriate to the investigation.
Avoid requesting browser-profile exports or authentication headers in ordinary support conversations. When troubleshooting needs a request example, redact authorization values and cookies before it enters a shared ticket. Also inspect screenshots: a key visible in a settings panel becomes another copy even when the text of the message contains no credentials.
Make the replacement handoff a controlled task
Prefer having the authorized operator create a narrowly scoped credential directly in the approved secret store. When a person must deliver a temporary value to another person, verify the recipient through a known contact method and agree on the destination before generating it. Send only what that task requires, with the shortest practical lifetime. Never send a browser session cookie as a shortcut to shared account access.
Secretus can provide a one-time encrypted link for an authorized replacement API key or temporary password. Keep the full link private and use a short expiry. After receipt, the operator should place the value in the approved destination rather than pasting it back into chat. This reduces persistent plaintext copies during delivery; it cannot revoke the old credential or protect a secret displayed on an infected device.
Close the incident with evidence
Ask the application owner to confirm three outcomes: the old access is revoked in the provider's controls, the replacement works only where intended, and service operation has recovered. Record any sessions that cannot be terminated immediately and their expected expiry. Continue monitoring those exceptions instead of treating password rotation as the finish line. For future handoffs, assign a distinct key to each workload so the next revocation has a clear owner and a limited operational cost.