Source review: October 22, 2026.
An AI coding tool may hold credentials that connect it to several model providers. When reviewing a security notice, the immediate question is which keys you entrusted to the affected service and how to stop their use.
The Hacker News reported on October 19 that OpenCode said unauthorized access to a legacy system may have exposed third-party provider keys saved in its hosted Console. The reported affected group was 1.4% of Console users, with external providers linked.
What is known about the reported scope?
The same report attributes to OpenCode a distinction between Console and keys stored locally by its command-line or desktop applications. Do not read “1.4%” as a percentage of all OpenCode users or all provider keys.
The company's original X disclosure could not be opened during this review. These incident details therefore remain attributed through reporting rather than presented as independently examined technical findings.
What does the $1,700 figure establish?
Dealroom reported on October 18 that Preston Zeller put his losses at $1,700. That is an individual user's reported amount, not a verified average or total loss. Billing records were not available for this article.
Keep that distinction when sharing the story. A precise number can attract attention while still leaving important questions unanswered, including the timing, scope, and final financial outcome of an individual case.
If a provider key may be exposed, start at the provider
The following recovery sequence combines provider guidance with a practical incident record. Use the provider's official website, reached directly, to manage credentials.
1. Revoke the affected credential
OpenAI's security guidance directs users with a compromised key to delete it in the API key dashboard, review unexpected usage, and contact support.
Anthropic's guidance likewise recommends immediate revocation and creating a replacement stored securely.
Removing a key from an integration is not a substitute for revoking it with the provider that issued it. Follow the provider's process even if you have already disconnected the tool.
2. List the applications that need a replacement
Before distributing a new key, identify the legitimate services that depended on the old one. Include scheduled jobs, development environments, deployment settings, and team integrations.
Assign an owner to each update. This makes it easier to restore legitimate work without accidentally putting the replacement back into an unreviewed integration.
3. Review usage and preserve a clear record
Check your provider's usage and billing views for activity you do not recognize. Save relevant timestamps, amounts, project identifiers, and support case numbers.
Record what you know and what you are still checking. Do not include full credentials in screenshots, support messages, or public posts.
4. Contact support about disputed usage
Explain when you received the security notice, which credential or project was involved, and what activity appears unexpected. Ask what evidence the provider needs.
Do not assume a reported refund in another user's case guarantees the same result for your account. Keep the support response with your incident record.
5. Check how spending controls actually work
OpenAI's current guidance describes alerts and organization or project hard limits, while warning that enforcement is not instantaneous. Review the specific controls available for each provider you use.
Write down whether a setting sends a notification, stops requests, or does something else. Test your team's response to an alert so that someone knows what to do when it arrives.
Build a small credential register
A short inventory can make the next review faster. Keep it in a protected team system and include:
- The tool or workflow using the credential.
- The provider and project it belongs to.
- The person responsible for maintaining it.
- The date of the last access review.
- The location of the approved revocation instructions.
Record a key identifier where appropriate, rather than the secret value itself. Review the register when adding an integration, changing a team member's responsibilities, or retiring a tool.
Give new integrations a defined purpose
Before connecting another AI tool, write a one-sentence reason it needs provider access. Identify the minimum workload it must run and who will review its usage.
Ask where credentials are stored and how the integration is removed. If those answers are unclear, resolve them before entrusting the tool with a production credential.
Frequently asked questions
Was every OpenCode installation affected?
The reporting reviewed for this article describes a subset of hosted Console users. It does not establish a compromise of every local installation.
Should I wait for an unexpected bill before acting?
If your provider key may be compromised, follow the provider's revocation guidance promptly. Billing review is a separate step in the response.
Is a password change enough?
Follow the recovery instructions for the specific credential involved. For a potentially exposed API key, use the provider's key revocation process rather than assuming a sign-in change addresses it.
What should a small team do first?
Identify potentially exposed credentials, revoke them at their providers, and assign owners to restore legitimate integrations. Then review usage and document the outcome.
Related: Read our AI chat sharing privacy review for a practical check of the information you share through AI tools.