PENTESTY · EDITORIAL ANALYSIS · · 4 min read
OpenCode Console: proving provider API key revocation
Removing a credential from a tool and ending its validity at the issuer are different decisions. Structure replacement around accountable owners and evidence.
By Pentesty
The scope of the October statement
The October 19 Cyber Security Brazil report prompted this analysis. In its October 17, 2026 statement, OpenCode reported a breach the previous night affecting 1.4% of Console users, within a subset with external providers connected. That publication described the incident as ongoing. It does not establish its current status.
Dax Raad distinguished Console from the OpenCode application. In the same public conversation, Lydia Hallie reported revoking Claude keys believed to be affected. Those statements do not demonstrate that every credential was copied or used.
Make revocation an observable decision
Anthropic’s guidance recommends immediately revoking a suspected compromised key in the provider’s own Console. For other services, consult the applicable guidance and coordinate containment and continuity with accountable owners, without assuming a universal replacement sequence.
In Pentesty’s analysis, deleting the intermediary’s entry does not establish that the issuer stopped accepting that credential. Record the provider action, its timing and who authorized it. The replacement key needs controlled distribution; copying it into tickets or messages would create another exposure during response.
Check which route the budget actually controls
Console budgets block new requests once the limit is reached; requests already started may finish. In our analysis, that gateway control does not demonstrate that a request sent directly to the provider with a still-valid credential would be blocked.
Compare intermediary records with usage at the issuer, accounting for periods, time zones and update delays. A discrepancy calls for investigation without proving fraud or attribution to the incident by itself. Our AI governance and observability article connects purpose, identity and outcome. Also record which limits are alerts and which actually reject operations.
Close with containment and continuity evidence
Include scheduled applications, test environments and recovery procedures in acceptance. An old job or restored configuration can point back to the previous credential. Each dependency needs an owner and confirmation, without retaining the suspect key as an emergency alternative.
Our review of Docker Hub tokens and ownership provides identity context. Here, the additional deliverable is a matrix separating validity at the issuer, configuration at the intermediary and application operation, with gaps and a review deadline.
Frequently asked questions
Does the statement cover every OpenCode user?
The company limited its notice to a Console subset with external providers. Check which service your team used and the notifications received, without confusing hosted Console with the application.
Does deleting the integration establish that the key is invalid?
No. Record revocation at the issuer and verify the result within an authorized procedure. Removal at the intermediary establishes only the change made in that system.
Does an intermediary budget limit every use of the key?
It covers requests subject to that control. Assess direct provider access and the limits available in the issuing account separately.
What should accompany completion of replacement?
An updated dependency record, revocation evidence and validation of permitted workflows with the replacement. Preserve unanswered questions and their accountable owners.
Sources and references
- Cyber Security Brazil: editorial news reference
- OpenCode: October 17, 2026 public statement
- Dax Raad: October 17 distinction between Console and the application
- Lydia Hallie: revocation of Claude keys believed affected
- OpenCode Console: providers and credential storage
- OpenCode Console: budget scope and behavior
- Anthropic: API key practices and revocation
Original Pentesty analysis, published October 20, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.