The tool I use every day announced, on Friday night, that it had been hacked. The credentials that leaked belonged to the users.
The official statement describes the incident: unauthorized access to a legacy system OpenCode was decommissioning. Inside were the provider keys (OpenAI, Anthropic, Google) saved in the Console, the hosted service where the team uses the models without ever seeing the key. The official guidance was direct: revoke and replace the keys in the provider panels, update the applications that use them, and review recent usage for strange activity.
The confirmed scope
1.4% of Console users, all with an external provider linked. The company notified that group by email on Saturday morning, with the subject Action Required: Potential provider key breach, and the official word is this: whoever did not receive the email was not affected. The keys at risk are the ones pasted into the Console; the CLI client and desktop keys live in a local database on your machine.
The attackers did not stay in read mode
According to TechCrunch, they ran workloads on users'' AI accounts and generated cost. The security market reads it as distillation: inference with someone else''s key to harvest outputs and train on them.
That is the detail that separates a credential leak from a data leak: the stolen key keeps working after the incident, on your account, on your invoice. That is why the response starts with revocation, but does not end there.
The lesson lives at the key''s address
Whoever stores the credential in a vendor''s console inherits the vendor''s incident, and the incident''s bill arrives at the key''s owner. The agent''s perimeter is called credential, and this week''s case showed that sometimes it lives in someone else''s house.
It is the same design we documented in the PocketOS case: the agent used the authority it was given, and what was missing was IAM. Here the authority was not even yours: it was hosted in a third party''s console that got compromised. And the trust chain of agent tooling is the same vector the TrapDoor campaign exploited in configuration files.
What I recommend, in this order
- Revoke every key stored in a third party console and issue a new one, directly at the provider.
- Review invoice and usage logs for activity you do not recognize.
- Adopt the pattern that survives the next notice: an agent key is revocable, has a spending cap, and is never the only one.
At Tech86, credential inventory is the first job of agent governance: where each key lives, what it can do, when it becomes garbage.
Conclusion
For anyone running agents with provider keys, the case leaves a rule: the key lives in your vault or in someone else''s invoice. The next breach announcement is a matter of time; the inventory decides whether it arrives as a notice or as a loss.