As of 19 Oct, OpenCode says provider keys of 1.4% of Console users may be exposed; no count is stated

1.4% is the only size OpenCode has given, and it has no base

OpenCode's account of its Console breach contains one number. In a post on X published at 17:56 UTC on Saturday 17 October 2026 (18:56 BST) and edited 11 minutes 47 seconds later (derived), the company says the breach "impacted 1.4% of OpenCode Console users". That is one in 71 (derived) but of an unstated base: no count of users, workspaces or keys appears in any OpenCode page, post or notice read for this briefing, and nobody outside the company can turn the percentage into a number of people. Do not multiply it by the "over 16M developers every month" on OpenCode's front page: that is a different population, and the Console is, in the company's words, an optional service.

What the record does not establish is most of what a defender needs. It does not say when the unauthorised access began or ended, how the intruder got in, whether the stored keys were encrypted, whether any key was used, or whether any UK organisation is among the 1.4%. It does not say what the company means by "a large scale distillation attack", the phrase it uses for the cause. It names Anthropic, OpenAI and Google as the providers it is working with, and nobody else. On the instruction, the company's own notice and the provider pages read all agree: revoke the keys at the provider. The notice, as users have posted it, tells them to "revoke and replace those keys through the relevant provider's dashboard". Deleting the stored copy in Console is a different action, and the diagram under the heading "Revoke at the provider" shows why the difference is the whole point.

Everything here is stated as of Monday 19 October 2026. This briefing was researched and written between 08:34 and 09:02 BST that day, and the incident is, by the company's own words on 17 October, ongoing. Claims that could change by this afternoon (a security notice on OpenCode's site, a count, a regulator notice, a compensation policy) are marked with the time they were last checked.

What OpenCode states, and what it does not

The company's public statement is one post on X, in two versions, plus an email that users have copied onto public pages. The post is the primary record of what OpenCode itself said. The email text comes from two users who quoted the same sentence in separate places, so it is likely but not authenticated. A third source, the status page the company runs for the Console and hosted inference, carries no security entry as of 08:35 BST on 19 October, and none when re-read at 09:02 BST. The company's X account has posted nothing further about the incident since 18:08 UTC on 17 October, and its front page and changelog carry no notice, at the same re-read.

What OpenCode says about the Console breach in its X post (17 October 2026, version edited at 18:08 UTC), in the email as two users quoted it, and on its pages, against what none of these state. Read on 19 October 2026.

The question	Stated	Not stated
How many?	"Impacted 1.4% of OpenCode Console users". "A subset of users who had external providers linked".	The base. A count of users, workspaces, keys or providers. Whether the 1.4% is of all Console users or only active ones, and on what date.
When?	"Last night", in a post made on the afternoon of 17 October. Emails "this morning". "The incident is ongoing so we cannot share more details at this point" (17 October, 18:08 UTC).	Any clock time or time zone. When access began or ended. Whether it has ended as of 19 October.
Where?	"We identified unauthorized access to a legacy system that we were in the process of decommissioning" (the email, as users posted it).	What the system was, whether it is the Console users sign in to now, what else it held, and why a system being retired still held live provider keys.
How?	"A large scale distillation attack" (the company's phrase for the cause).	The route in. What the phrase means here. Any evidence for it or any attribution. The post does not define the term.
What was exposed?	Third-party provider keys "may have been exposed" (the email, as quoted). Keys of providers such as OpenAI and Anthropic.	Whether keys were encrypted or readable. Any other data: names, emails, billing, usage logs, prompts. OpenCode-issued keys. The cloud credentials the docs let Console store.
Was any key used?	Nothing on any OpenCode page read.	Any count of keys misused, any amount, any provider confirmation. User reports exist and are unverified (see the section on user reports).
What has been done?	"Working with Anthropic, OpenAI, and Google to remediate" (the post).	Any security notice on opencode.ai or its status page. Changes to key storage. A regulator notification. A compensation policy.

The wording of the first version of the post is partly lost. The service that quotes it returned the first version cut off at 270 characters, ending "working with". What it said after that is unknown. What is known is that the first version runs from "via email" straight into "The incident is ongoing", and the sentence "If you did not get an email you were not impacted" is not in it. That sentence, and the names of the three providers, arrived in the edit 11 minutes 47 seconds later (derived from the two timestamps).

The OpenCode name also does work it should not. The company's front page says its open source agent is "used and trusted by over 16M developers every month" and that it is "built for privacy first", and that it "does not store any of your code or context data". The privacy statements concern code and prompts, not credentials. The Console is a separate hosted service, and its docs say it "stores the credential and serves each provider through its gateway". A reader who runs the open source agent locally with their own keys is not described by the company's post. A reader who ever pasted a provider key into the Console is.

17 to 19 October, in the order the timestamps put it

The first public trace of a problem is not the company's statement. A user opened a public issue on the project's GitHub page at 17:15:25 UTC saying they could not sign in to the Console, and the first reply from another user, at 17:18:45, reports an "api key expired" message in OpenCode. The company's post followed at 17:56:19. That is 40 minutes 54 seconds (derived) between the first public issue and the first post. The Hacker News item titled "Potential provider key breach", pointing at a Reddit thread, was submitted at 17:19:19, 37 minutes 0 seconds (derived) before the post.

What was recorded, with the clock time in UTC and BST, from the company's post, GitHub's and Hacker News's public interfaces and the status page's own JSON feed. Read on 19 October 2026. Who recorded each item is in the last column.

When (UTC, BST)	What was recorded	By whom
Fri 16 Oct, night. No clock time	The intrusion, in the company's account ("last night" in a post of 17 October). The Hacker News Console report places it on the night of 16 October.	Company; The Hacker News (secondary)
Sat 17 Oct, morning. No clock time	Emails sent to affected users ("this morning"). The subject line, as The Hacker News reports it: "Action Required: Potential provider key breach".	Company; The Hacker News (secondary)
Sat 17 Oct 16:16 UTC, 17:16 BST	A project member opens a code change "Companion to the Console expired-key response change". It does not mention a breach. Whether it relates to the incident is not stated.	GitHub, a code change
17:15 UTC, 18:15 BST	First public issue: cannot sign in to the Console. A reply at 17:18 reports an "api key expired" message.	User reports, GitHub
17:19 UTC, 18:19 BST	A Hacker News item titled "OpenCode: Potential provider key breach" links a Reddit thread.	Hacker News
17:56:19 UTC, 18:56:19 BST	OpenCode's post, first version: 1.4% of Console users, emailed "this morning", incident ongoing.	Company
18:01 UTC, 19:01 BST	A Hacker News item, "OpenCode Hacked: User credentials leaked" (948 points when read), links the post. At 18:02 a comment carries the email text.	Hacker News, a user
18:08:06 UTC, 19:08:06 BST	The post is edited: adds "If you did not get an email you were not impacted" and names Anthropic, OpenAI and Google.	Company
Sun 18 Oct 12:04 UTC, 13:04 BST	A personal X post, from an account whose profile says it builds OpenCode, says people have been "non stop" trying to attack the systems for 48 hours. It does not say who or what counts as an attack.	A team member, personal account
Sun 18 Oct 15:47 UTC, 16:47 BST	A user opens an issue asking for a compensation policy and a security entry on the status page.	User report, GitHub
Mon 19 Oct 06:11 UTC, 07:11 BST	A user posts to Hacker News text described as a follow-up email: OpenAI keys revoked, refunds issued. Unauthenticated.	A user, Hacker News
Mon 19 Oct 07:35 UTC, 08:35 BST	The status page's JSON feed lists no security incident. Its Console incidents on 17 October last 4 and 5 minutes (latency) and its request-log incidents 4 and 35 minutes; none names a cause.	Company status page

Two cautions about the table. The first public issue is the first one found, not the first that occurred. And a user seeing an expired key says what the user saw, not why. OpenCode's post and notice, as read, speak only of third-party provider keys. They do not say that OpenCode's own keys were expired or revoked. Several users say theirs were, and the section on user reports sets those out as what they are.

Revoke at the provider: deleting in Console removes your copy only

OpenCode's docs describe the Console as a store and a relay. The Providers page says "Console stores the credential and serves each provider through its gateway, so members use the models without ever seeing the provider key". Its API page adds that "the provider secret never leaves the workspace". Both are statements of design, and the incident is the test of them. The same page says that to take a provider out of a workspace the owner opens the provider's menu and chooses Remove, which "deletes the provider and its models". Nothing on any OpenCode page read says that this tells the provider to end the key.

The step that matters is the provider's. A provider key is a bearer credential: Google's page on API keys says that "if someone steals an authorization key, they can use it to authenticate as that service account". So a stolen copy keeps working until the provider ends the key, and nothing done in someone else's gateway changes that. This is an inference from how bearer credentials work. The Hacker News report, as relayed to the author, makes the same point. It also explains why the advice in OpenCode's own notice, as users quoted it, is to "revoke and replace" through "the relevant provider's dashboard".

The same logic applies to the Console's budgets. The Budgets page says they "cap how much a workspace spends each month" and "are checked when a request starts". A budget therefore counts requests that pass through Console. A key used directly at the provider does not pass through it, so a Console budget cannot be what stops that use (inference from the docs). The limit that can stop it is the provider's, and the next table sets out what each provider's own page says to do.

What each provider's own pages say about a key you suspect is compromised, as read on 19 October 2026, and what the pages do not say. The vendors bill for the usage a stolen key creates and sell the limits and dashboards these pages recommend.

Provider page	The page says	Not on the page
Anthropic, Help Center, "What should I do if I suspect my API key has been compromised?" and "API Key Best Practices" (both dated 16 March 2026)	Revoke the key immediately: in the Console, open the API keys page and choose "Delete API Key". Create a new key and keep it in a secrets management system. Set usage and spend limits. Uploading a key to a third-party tool gives its developer "access to your Claude Console account".	How long a revoke takes to bite. What a vendor-side breach looks like. A way to see whether the old key was used. (Both pages were fetched with a plain request and read in full.)
OpenAI, Production best practices and Spend limits guides (developers.openai.com)	Set an expiry date and rotate: create a replacement, update the applications, and "revoke the old key once you've verified that the replacement works". Spend alerts "do not enforce a cap"; a hard limit returns an error once reached, and enforcement "is not instantaneous".	What to do when a copy of the key may already be elsewhere. The Help Center article "Best practices for API key safety" answered with a block and was not read.
Google Cloud, "Best practices for managing API keys" (last updated 13 October 2026)	Keys are bearer credentials. Isolate keys: one per team member per application. Rotate: create new, update, delete old. A deleted key can be restored within 30 days. Add key restrictions and monitor usage.	Anything on the Gemini API's own key page, which redirected to a sign-in. Any statement about this incident.

None of the three pages says anything about this incident, and no provider statement about it was found. OpenCode says it is working with all three. The same reading gives the order of work in the checklist at the end: end the key at the source, then prove it is dead, then look back at what it did.

Labels doing the work of controls

A comforting word in this story is doing the job of a control, and the table sets each against what it does and does not do. The labels come from OpenCode's pages, its posts and the reports of its users.

Labels in the OpenCode record, what the source says each means, and what it does not do. Read on 19 October 2026.

The label	What it does	What it does not do
"Remove" a provider in the Console	Deletes the provider connection and its models from the workspace (docs).	Nothing on the page says it tells OpenAI, Anthropic or Google to end the key.
A Console "budget"	Blocks new requests through Console when a workspace or member reaches a dollar limit (docs).	Cap use of a key outside Console. The provider's limit does that.
"Not impacted" if no email	The company's statement that an email was sent to the 1.4% (post of 17 October).	Cover users who say their OpenCode keys or workspaces stopped working without an email (unverified, see the section on user reports).
"Built for privacy first"	The front page says OpenCode does not store code or context data.	Say anything about credentials. The Console stores them (docs).
"SOC 2 Type 2: Compliant"	The company's trust centre lists SOC 2 Type 1 and Type 2 as compliant, and a breach notification policy.	Say which systems or period the reports cover. They sit behind a non-disclosure agreement. Whether the legacy system was in scope is not stated.
"Legacy system we were decommissioning"	Names a system the company says it was retiring.	Explain why it held live keys, or whether it is the Console users sign in to now.
"Distillation attack"	The company's description of the cause.	Describe an entry route. It is not defined in the post, and users on Hacker News dispute it.
Cyber Essentials	Sets basic controls for user accounts and cloud services (v3.3, April 2026).	Mention API keys or service accounts. A certificate does not show who holds your provider keys.

The trust centre deserves one more sentence. Its page lists four subprocessors and three policies and offers a penetration test report and a SOC 2 report, but only under a non-disclosure agreement, with no period or scope on the page. A reader can ask for them. A reader cannot tell from the page whether a system the company was decommissioning was inside either.

What users report, and what is unverified

Everything in this section is a user's own account on a public page. None is a company statement, and none has been confirmed. Nine public GitHub issues read for this briefing, opened between 17:15 UTC on 17 October and 15:47 UTC on 18 October (22 hours 32 minutes apart, derived), report a failure of a key or a workspace. Most were answered with a pointer to a support email address, and several were then closed on the ground that account support is handled by email, not on GitHub.

Claims by users about the incident, where each was read, and what is verified. User accounts, not facts. Read on 19 October 2026.

The claim	Where it was read	Status
OpenCode-issued keys, including ones set to never expire, showed as expired for people who linked no provider.	Several GitHub issues; one user links a screenshot of the Console key list with "Expires: Never" beside "Status: Expired".	Unverified. The screenshot was not opened. Not addressed in any company statement read.
A key created automatically during an upgrade expired about 47 hours later.	A GitHub issue; the user's own stamps give 47 h 13 min (derived).	Unverified. It would point to expiry by design, the opposite of the claim above.
All workspaces restricted since 17 October, no breach email, no provider keys stored.	A GitHub issue and one later comment.	Unverified. If true it sits outside the company's "no email, not impacted" line.
Losses in the hundreds of dollars and, in one case, about 1,700 dollars.	A GitHub issue; a Hacker News comment gives 300 to 1,700 dollars.	Unverified. No provider or OpenCode has confirmed an amount.
OpenCode and OpenAI revoked the keys and issued refunds; accounts banned in the process should be reinstated.	Text a user posted to Hacker News at 06:11 UTC on 19 October as a follow-up email.	Unauthenticated. Not on any OpenCode page read. If it is genuine it is an email, not a published policy.
Some users have already paid for usage they did not run, and the Hacker News article cites a Dealroom report.	As relayed to the author from the Hacker News article, which could not be opened. The Dealroom report was not found.	Not read. Not relied on.
The breach was a distillation campaign.	The company's post; Hacker News commenters dispute it.	The company's characterisation. No evidence in the record.

One detail ties the reports to the checklist. A user who says no provider key was ever stored lost service anyway. If that is true, the company's line that only the 1.4% need act is not a safe basis for a security decision, and any organisation with a high-value key in a Console workspace should treat "I received no email" as the beginning of the question, not the answer.

Not the first stored key, and not the first vendor

Keys held for you by a vendor are a recurring target, and the week of this incident has two others on the record. Huntress reported on 16 October that a Microsoft 365 credential held by ConnectWise's Cloud Backup (formerly SkyKick) had been compromised and used to sign in to customer tenants. ConnectWise's own advisory, updated at 01:15 UTC on 19 October, says disabling the affected connections "does not reverse changes previously made inside a tenant", and adds: "A vendor action and a customer-tenant setting are different controls". This site covered that incident. It is the same shape as this one: the vendor can end its credential, and only the customer can end what the customer holds.

Symantec's report of 15 October on the Aoki infostealer says stolen API keys and tokens "can allow attackers to carry out activity under a legitimate user's identity and API quota", and that "a stolen AI key can be cashed in directly, either through resale or by running up usage". That is Symantec's assessment of a different route, malware on the developer's machine. This site covered it too. Sysdig's report of May 2024 on "LLMjacking" shows the other half: attackers checked stolen credentials against ten AI services before using them, and its worst-case estimate for one model on one cloud service was over 46,000 dollars a day. That is an estimate for one scenario, not a loss reported by anyone.

GitHub's documentation gives the rule these cases keep restating. When secret scanning finds a key, GitHub says to "rotate the affected credential immediately", and that removing it from history is "often unnecessary if you've already revoked the credential". For partner providers GitHub tells the provider "so they can take action, such as revoking the credential". The end of a key is the issuer's act, not the holder's deletion. This site has covered how many working credentials sit in public GitHub code. GitHub's scanning looks at repositories. It cannot see a key held in a vendor's database, which is where this incident happened.

The UK position, as the pages read say it

None of the UK pages below mentions API keys, and none says that a provider key is or is not personal data. This section says what each requires and what it does not. It is not legal advice. The ICO's relevant guidance says on its face that it is under review after the Data (Use and Access) Act 2025, and the legislation page now names "the Commission" in Article 33 in place of the Information Commissioner, from 30 September 2026, per its own amendment notes.

UK sources read in full on 19 October 2026: what each says and what it does not. Not legal advice.

Source	What it says	What it does not say
UK GDPR Articles 4, 32, 33 and 34 (legislation.gov.uk)	Personal data is information relating to an identified or identifiable person, including "an online identifier". Article 32 lists "the pseudonymisation and encryption of personal data" among appropriate security measures. A controller notifies the regulator "without undue delay and, where feasible, not later than 72 hours after having become aware", unless unlikely to cause risk. A processor "shall notify the controller without undue delay". Information may be given in phases. High risk to individuals means telling them.	Whether a provider key relates to a person. Whether the stored keys were encrypted. Whether OpenCode is a controller or processor for a given Console customer. When "aware" begins for a customer.
ICO, "UK GDPR data breach reporting" (last updated 28 May 2025) and "Personal data breaches: a guide"	Report within 72 hours of becoming aware, "report early" and "update later". The ICO accepts partial information in the first 72 hours. Processors must tell controllers. Consider telling the NCSC if the breach was caused by a malicious actor.	Anything on API keys. When awareness starts for a vendor-held credential. Both pages note they are under review.
ICO, "What is personal data?"	Repeats the Article 4 definition and says it is under review.	A word on credentials, accounts or tokens.
NCSC, "Protect your code repository" (published 20 February 2019)	Separate secret credentials from source code, consider key rotation, and revoke access "swiftly when no longer required, or in the event of compromise".	Anything on AI provider keys or hosted gateways. It is about code repositories.
NCSC, supply chain security principles (reviewed 22 October 2025)	Know "the value of your information or assets which suppliers hold" and what access suppliers have. Set incident reporting "timescales, who to report to" in the contract. Written for large organisations, the public sector and professionals.	Anything specific to AI gateways. It does not say how a small team should do this.
Cyber Essentials, Requirements for IT Infrastructure v3.3 (April 2026)	A cloud service is in scope when accessed "via an account". Accounts must be controlled, removed when not needed, and passwords changed "promptly if you know or suspect" compromise.	Any wording on API keys, service accounts or tokens beyond physical MFA tokens, found by search. A certificate says nothing about who holds your provider keys.
OpenCode privacy policy (effective 6 March 2026) and terms (effective 15 August 2026)	Names 13 US state privacy laws. Says it uses "appropriate" security measures. The terms choose Delaware law and binding arbitration, and cap liability, "to the fullest extent allowed by applicable law", at the greater of 100 dollars or what the user paid or owed in 12 months.	UK GDPR or the UK. How credentials are stored. Any breach notification commitment to customers.

A derived clock shows what the 72 hours means in practice, on two assumptions that the record does not establish: that a controller became aware on receiving the email at 09:00 BST on Saturday 17 October, and that the incident is a notifiable personal data breach for it. Seventy-two hours from then ends at 09:00 BST on Tuesday 20 October, which at 08:50 BST on Monday 19 October leaves about 24 hours (derived). The ICO's guide points to European guidelines for when a controller becomes aware, and those were not read here.

Whether a provider key is personal data is a separate question that the pages do not decide. A key can be a route to what sits behind it. Symantec says a stolen token "can also expose connected repositories, cloud services" and Google says a stolen key lets someone "access the same resources" as the account. Prompts, files or stored responses at a provider could include personal data, and OpenCode's privacy policy lists names, email addresses and payment data among what it collects. What the legacy system held beyond keys is not stated, which is the first question for the data protection officer to put to OpenCode.

What to do, in order

The order below follows the reasoning above: end the key at the source, prove it, look back, limit, shrink, and then deal with the supplier. Each step assumes the previous one is done.

Two limits on this advice. It rests on provider pages read on 19 October 2026 and on a company statement that is two days old and still described as ongoing. It does not assume anyone's keys were used: nothing public says any were, and the loss figures are user reports. It also does not say OpenCode's product is unsafe to use. The company's open source agent, which per its docs keeps keys on the user's machine, is not what its post describes.

The question that exposes the gap

OpenCode's notice, as users quoted it, ends by telling people to "review recent usage for unexpected activity". That sentence is only as useful as the date it is reviewed back to, and the company has not said when access began. The notice asks each affected user to find evidence of misuse from a provider dashboard, over a window nobody has defined: a request to prove a negative on a clock the company has not set.

If a key you saved in someone else's gateway was copied on the night of 16 October, who in your organisation can show, today and with evidence, that it has been revoked at the provider, and what it did before that?

Key facts