Is your CV data safe after the OpenCode breach?

What actually happened in the OpenCode breach?

Attackers reached a legacy OpenCode Console system overnight on 16–17 October 2026 and may have taken the OpenAI, Anthropic and Google API keys users had saved inside their workspaces. OpenCode put the blast radius at 1.4% of Console users and emailed everyone affected. The open-source CLI wasn't involved; its co-founder says keys used locally never touch OpenCode's servers. Developers were posting spend alerts before the company's first statement — hundreds of dollars on a single provider, more than $1,700 in total for some people. OpenCode described a sustained campaign running roughly 48 hours, and said the investigation got genuinely awkward when the AI models it was using kept refusing to analyse the attacker's code.

The system in question was already being decommissioned, which is the detail worth sitting with. Console is the optional hosted side of OpenCode: a workspace stores one provider key so teammates can run models without ever seeing it. Convenient, and exactly the kind of quiet credential vault nobody re-audits. OpenCode framed the incident as part of a large "distillation attack" — stolen keys used to pump huge volumes of output out of commercial models — though security researchers pushed back, noting no technical evidence was published to support that framing. Anthropic and Google blocked keys they believed were exposed. OpenAI said it worked with OpenCode to restore access and refund credits burned during the attack.

As of 19 October there's still no published root cause, no dwell-time figure, no absolute user count behind that 1.4%, and no post-mortem. That gap matters more than the dollar amounts. When a tool can't yet explain how someone reached a half-retired system, you're not being paranoid for asking what else that system held. And this is where job seekers should lean in rather than scroll past: the people hit here were developers who trusted a popular open-source agent with one piece of sensitive data. You're doing the same thing every time you hand an agent the most identity-rich file you own.

What does an open-source AI agent actually store when you upload a CV?

An AI agent stores far more of your CV than the file itself. Expect at least four copies: the uploaded document, the extracted text sitting in a prompt log, a conversation transcript, and often an embedding in a vector store so the agent can "remember" you later. Add tool-call records if the agent browsed job boards on your behalf, plus whatever the model provider retains on their end. Security teams treat these logs as sensitive assets precisely because they end up being a searchable record of everything anyone asked the system. Your employment history, salary expectations and home address can live in all four places long after you've deleted the chat.

"Self-hosted" and "open source" are not synonyms for private. Running an agent on your own machine solves data residency and nothing else — you inherit responsibility for the runtime, the patching, the secret storage and every connected tool. A local agent without sandboxing has full filesystem access, which means it can read your SSH keys, browser profiles and cloud credentials alongside your CV. Prompt injection is the practical risk here: a malicious job ad or a booby-trapped README can carry instructions that make the agent quietly send data somewhere. Researchers have demonstrated exfiltration through link previews in chat apps, with no click required from the person being targeted.

Hosted community agents add the OpenCode failure mode on top. If an agent offers a shared workspace, assume your uploaded CV is visible to anyone with workspace access and recoverable from backups you can't see. Before you trust any of this, it's worth understanding what on-device processing actually changes about CV privacy — the answer is real but narrower than the marketing suggests. The honest framing: the only data that can't leak is data you never uploaded. Everything else is a question of how much retention risk a given task is worth, which is a judgement call you should make deliberately rather than by default.

Which fields on your CV should you redact before a test run?

Redact your home address, personal phone number, date of birth, national ID or PAN number, and every referee's name and contact details before you let an unfamiliar agent touch your CV. None of those fields improve the output. An AI model rewriting your bullets does not need to know you live on a particular street — swap in placeholders and the drafting quality won't move. Referees deserve special mention: pasting their phone numbers shares someone else's personal data without their consent, which is both rude and, under GDPR, arguably your problem rather than the tool's. Keep job titles, dates, employers and achievements intact, because stripping those is what actually degrades the advice you get back.

There's a second category people forget: metadata. A PDF exported from Word carries your computer's username, your organisation name and sometimes a full file path in its properties. A CV saved from a design tool can carry editing history. Check document properties and clear them before upload, or export a flat copy. Also watch the photo question — if you're applying in Israel or most of Europe, your CV shouldn't carry a headshot anyway, and a face attached to an address attached to an employment history is a neat identity package for anyone who gets hold of the log.

The practical move is to keep two versions. Your master CV, complete with every contact detail, stays offline on your own machine. A redacted working copy — placeholders in the header, no referees, no ID numbers — is what you paste into experimental agents, browser extensions and anything you've installed in the last fortnight. When a draft is ready for real applications, you rebuild the header locally. If you'd rather not maintain that by hand, you can draft the redacted version in a CV builder and keep the sensitive header as the last thing you add before sending.

How do you rotate keys and revoke an AI agent's access after a breach?

Rotate credentials in order of blast radius: provider API keys first, then OAuth grants, then passwords. If you've ever pasted an OpenAI, Anthropic or Google key into a hosted agent workspace, revoke it at the provider's console rather than deleting it inside the agent — deleting it in the tool proves nothing about copies elsewhere. Generate a replacement, set a hard spend cap on it, and check the usage dashboard for the past month before you move on. Spend caps are the single most underrated control here: the OpenCode victims who had them lost tens of dollars instead of hundreds, because the ceiling held while the alerts were still landing.

Job seekers carry a different credential set, and it's the one that gets skipped. Go to your Google and Microsoft account security pages, open third-party app access, and revoke every AI tool you no longer actively use — especially anything you granted inbox or Drive permissions to during a burst of job-search enthusiasm. Do the same on LinkedIn, and change the password on any job board where you reused one. An agent with lingering inbox access can read recruiter replies, interview invitations and offer letters, which is a richer dataset than your CV ever was.

Then deal with what the agent stored. Delete uploaded CV files from the tool's workspace, clear chat history where the tool allows it, and send a deletion request if it operates under GDPR or an equivalent regime — you're entitled to one, and reputable tools honour it. Finally, put the agent back into review-before-send mode; the control checklist that stops agents applying to jobs in your name covers the specific settings. An agent that can't act autonomously is an agent whose compromise costs you a leaked document, not forty applications sent with the wrong CV attached.

What should you check in a tool's data handling before uploading your CV?

Check five things before you upload: how long the tool retains your file, whether your data trains their models, who inside a shared workspace can see it, whether deletion is available and actually honoured, and where credentials are stored if the tool holds any. If a privacy policy can't answer those in plain language within two minutes of reading, that's your answer. Watch specifically for the phrase "anonymised or aggregated data may be used to improve our services" — a CV is hard to meaningfully anonymise, since employer, dates and job title together identify most people. Transparency beats certification badges here; plenty of breached companies had the badges.

Then look at the credential question, which is what OpenCode turned into a live case study. A tool that asks you to paste your own model provider key is handing you a liability it hasn't priced. The safer pattern is a tool that runs inference on its own account, so there's no key of yours sitting in a workspace waiting to be drained. If you do supply a key, use a dedicated one with a low spend cap, never your production key. The same instinct applies to auto-apply tools that want your job-board logins: that's a credential store you didn't ask for and can't audit.

My blunt opinion: for CV work specifically, a general-purpose agent is the wrong tool anyway. You want something that parses the file the way an applicant tracking system does and tells you what breaks, not a chatbot that rewrites your bullets into confident mush. A free ATS compatibility check on your CV gives you a score out of 100 across five categories plus a layout analysis in a couple of minutes, which is a narrower exchange of data for a far more useful answer. The broader question of whether a rogue agent can reach your CV data at all is worth reading before you install the next one.

Frequently asked questions