When the Platform Holding Your Secrets Is Breached: Revoke Fast, Limit the Blast Radius
In October, several AI developer platforms disclosed breaches of stored secrets, and stolen keys were abused within hours. Here is how to revoke at the issuer, shrink what each key can do, and rehearse a rotation this week.
On 30 October 2026, the application hosting platform Northflank told customers to assume all environment variables had been decrypted and to rotate every key stored with it. Within hours, users were reporting unauthorised use of AI API keys they had stored on the platform. Northflank was not alone. Wiz's "Black October" write-up lists at least nine AI developer platforms that disclosed incidents that month, with reports describing attackers going after stored environment variables, especially ones that grant access to AI services.
The lesson is not about one provider. Every hosting platform, CI system and managed service that runs your code also holds your secrets. If that platform is breached, your credentials are exposed even though nothing in your own environment changed. What matters then is how fast you can revoke and replace everything, and how little each stolen secret can do in the meantime.
Why the clock is shorter than you think
Wiz reports that stolen AI keys were first tested within 30 minutes of credential access. In one case it describes, a key was then used for roughly 800,000 model calls over about 30 hours. Wiz estimates two such cases likely ran up over $100,000 in usage at list price, and says the number of different actors using the keys suggests a working market for them.
Compare that with the disclosure timeline. Northflank's own update says the first known decryption of secrets happened between 02:39 and 03:08 UTC on 30 October. The first alert came at 11:43 UTC, and customers were notified within about two hours of that, according to the status page. That is a fast response by industry standards, and it still left a gap of many hours in which the secrets were in someone else's hands.
The practical conclusion is uncomfortable: for a provider-side breach, you will usually learn about it after the secrets have been taken. Your defences have to assume that, and rotation has to be quick enough that it limits damage rather than documents it.
Rotation is not revocation
A common reflex is to generate a new key, redeploy, and call the incident closed. That replaces the secret your application uses, but it does not necessarily stop the old one from working. The OWASP Secrets Management Cheat Sheet puts it directly: restarting an application does not itself revoke stolen credentials, which stay valid until they expire or are explicitly revoked.
OWASP's containment order is a good default for any leaked secret:
- Revoke the exposed credential at the issuer, immediately.
- Rotate by issuing a replacement, ideally through an automated process.
- Delete the old value from wherever it was exposed, including code, logs and configuration.
- Log the lifecycle: who accessed the secret, when it was used and when it was replaced.
Revocation has to happen where the credential is accepted, not where it was stored. For an AI provider key, that means the provider's console or API. For a database password, it means the database. For a cloud access key, the cloud's identity service. Northflank's later guidance followed the same logic, telling customers to revoke credentials with their providers, update workloads, and review provider billing and usage logs.
Know what you would have to rotate
Most teams cannot answer a simple question quickly: which secrets does this platform hold, who owns each one, and how do we rotate it? OWASP recommends keeping metadata for every secret, including its owner, purpose, type, and creation and rotation history. Without it, a "rotate everything" instruction becomes a scavenger hunt.
Prioritise by what an attacker can do with each secret. Northflank's own ordering is sensible for most organisations: AI provider keys, cloud credentials, payment keys, private keys and database credentials first, because they can be monetised or used to reach data directly. Tokens for source control and connected integrations come next, since they open paths into other systems.
Remember the credentials you did not create by hand. Northflank says it revoked access tokens, sessions, version control integrations and cross-account cloud roles on customers' behalf where it could. Those platform-held grants deserve a place in your inventory too.
Make each stolen secret worth less
You cannot control whether a provider is breached, but you can control how much a stolen credential is worth. Several measures cut the value sharply.
- Prefer short-lived credentials. OWASP advises using dynamic secrets where possible, with short lease durations. A token that expires in an hour is a much smaller prize than a static key that has worked for two years.
- Use workload identity instead of stored keys. Where your platform and cloud support federation, let the workload prove its identity and receive temporary credentials, rather than storing a long-lived cloud access key in an environment variable.
- Scope keys narrowly. One key per service and environment, restricted to the models, buckets or tables it needs. OWASP is explicit that secrets should never be retrievable by everyone and everything.
- Set provider-side guardrails. Northflank recommended IP restrictions and budget limits where providers offer them. A spending cap or allowlist will not prevent theft, but it can turn an open-ended bill into a bounded one.
- Separate the key from its consumer. For data encryption keys, keep the key encryption key in a KMS or HSM you control, so that a copied configuration value is not enough to decrypt data. NIST SP 800-57 Part 1 remains the reference for key types, protection requirements and lifecycle functions.
A checklist for this week
- List every third-party platform that stores your secrets: hosting, CI/CD, build services, AI tooling and managed databases.
- For each, export or document the secrets it holds, with an owner and a rotation method. Flag any you cannot rotate without downtime.
- Confirm that each issuer (AI provider, cloud, payment processor, database) lets you revoke a key on its own, and record where.
- Pick one high-value static key, such as an AI provider key, and run a timed revoke-and-replace drill. Note how long it took and what broke.
- Turn on usage alerts, spending limits and IP restrictions at providers that support them.
- Replace at least one long-lived cloud key in an environment variable with workload identity or short-lived credentials.
- Write a one-page playbook for "our platform says assume all secrets are exposed": who decides, who rotates what, and which logs to review.
Conclusion
Provider-side breaches turn secret management from a hygiene task into an incident-response capability. The organisations best placed to absorb an event like this are the ones that know what their platforms hold, can revoke at the issuer quickly, and have already limited what each key can do. Those are ordinary engineering habits, and they can be built before the next status page update rather than after it.
If you are reviewing how your encryption keys are held and controlled, OXU KMS is Oten's key management service, built around making encryption simple and secure by design.