Between 16 and 21 October 2026, attackers went after AI provider keys three different ways: a hosted key vault, a cloud billing account and the release pipeline of a widely used open-source LLM gateway. None of them needed a model jailbreak, because a provider key is a bearer credential that turns straight into compute, money and access.
AG Tech Consulting's advice for clients this week: treat every place that stores or relays AI provider keys (hosted consoles, LiteLLM-style proxies, CI runners, developer laptops running coding agents) as a tier-0 secret store. This week, find every copy of every OpenAI, Anthropic, Google, Azure and Bedrock key, rotate any key that sat in OpenCode Console or on a host that ran litellm 1.107.0, give each tool its own key with a provider-side spend cap, and put alerts on billing-account IAM changes in Google Cloud.
What happened in five days
Three incidents landed in the same week. On the night of 16 October, an intruder reached a legacy system behind OpenCode Console and may have exposed the provider keys users had saved there.
On 20 October, Wiz's Customer Incident Response Team described intrusions in which attackers phished Google Cloud admins, took over billing accounts and ran Gemini workloads at the victims' expense.
On 21 October, litellm 1.107.0 shipped to PyPI and Docker with a credential stealer, built and signed by LiteLLM's own release pipeline. A day later, HiddenLayer published research on what an attacker who controls an LLM gateway can do to the coding agents behind it.
OpenCode Console: the hosted key vault
OpenCode is an open-source AI coding agent. Console is its optional hosted service: a workspace saves its own OpenAI, Anthropic or Google key, and Console calls the provider so team members can use the models without seeing the key.
OpenCode says the intruder reached a legacy system it was decommissioning. Affected users, 1.4% of Console users and all with an external provider linked, got an email on 17 October titled "Action Required: Potential provider key breach". BleepingComputer reports the email gives 00:30 UTC on 17 October as the earliest possible exposure.
OpenCode linked the breach to "a large-scale distillation attack" without explaining how. Co-founder Dax Raad stressed that the CLI and desktop apps keep keys locally: "those keys never come to us."
Users reported unauthorized charges from a few hundred dollars up to about $1,700, and some Google Cloud projects were suspended for "abusive activity consistent with hijacked resources". Anthropic and Google blocked keys they believed were exposed; OpenAI worked with OpenCode to restore access and refund API customers.
The lesson is structural. Deleting a key from Console does not revoke it, and a Console budget cannot cap its use, because Console only sees traffic that passes through its own gateway. Only the provider can kill a bearer key.
Wiz: LLMjacking through the billing account
Wiz CIRT's write-up (Shira Ayal, Andre Maccarone) covers Google Cloud intrusions whose only goal was to make the victim pay for mass LLM inference.
Initial access was a sponsored Google Search ad for "google cloud" or "gcp". The click passed through a Google Sites redirect to a fake sign-in page that captured the password and MFA code, then bounced the user to the real prompt. The kit logged in immediately, and the actor re-authenticated minutes later from a second IP.
Inside, the attacker enabled the Gemini API in existing low-usage projects, created service accounts with Gemini API keys and granted roles/ml.admin and roles/mcp.toolUser.
Then came the guardrails. The attacker deleted the iam.allowedPolicyMemberDomains organization policy, added attacker-controlled Gmail accounts to the billing account, and granted roles/billing.admin and roles/recommender.billingAccountCudAdmin.
The decisive step was linking attacker-owned projects to the victim's billing account. Prompts and outputs ran in foreign tenants, so the victims' logs showed nothing about the workloads. Later activity came from IPs in each victim's headquarters country, and existing billing admins were demoted to read-only viewers.
Within 24 to 48 hours, victims faced unauthorized Gemini charges of tens to hundreds of thousands of dollars.
LiteLLM 1.107.0: the gateway itself was poisoned
LiteLLM, maintained by BerriAI, puts more than 100 LLM providers behind one OpenAI-compatible API. It runs on laptops, in CI and as production gateways holding provider keys. This was its second PyPI compromise of 2026, after 1.82.7 and 1.82.8 in March.
All seven 1.107.0 wheels were live on PyPI from 11:39 to 13:23 UTC on 21 October. The v1.107.0, latest, main-latest and main-stable images on GHCR and Docker Hub pointed to infected images from 11:46 until as late as 14:20 UTC. LiteLLM says its private enterprise registry was not affected and advises pinning 1.106.2.
How the release was hijacked
By LiteLLM's account, its internal LiteLLM deployment was exposed to the internet and held an unexpected user account. The deployment's logs contained GitHub CLI OAuth tokens for three developers. LiteLLM says Claude Code can embed a user's GitHub CLI token in a response body in some situations, and the deployment logged response bodies.
One token belonged to a GitHub organization owner. Branch protection rejected an unauthorized change to the private release workflow at 10:08:29 UTC; five seconds later the owner token overrode it and pointed the release at a lookalike repository, Berri-AI/litellm. A second developer's credential satisfied the production approval gate, and a third deleted the workflow run records.
StepSecurity's analysis explains why March's hardening (private release repo, PyPI Trusted Publishing, immutable tags, signed images) did not help. The attacker did not bypass the pipeline; it changed the trusted workflow, so the artifacts carried valid signatures and SLSA provenance, which named the hyphenated repository.
What the payload takes
Each wheel added cook.pth, cook.py and sitecustomize.py to site-packages via one injected data = "cook" line under [tool.maturin]. Python runs them on every interpreter start, including pip itself, without anyone importing litellm. The git tag is clean, so source review would not catch it.
The stealer, "privcollect", runs 16 modules: browser passwords and cookies, SSH, GPG and TLS keys, AWS, Azure and GCP credentials, instance-metadata role tokens, Kubernetes, CI and Vault secrets, every readable /proc/*/environ, and the configs of more than 20 AI coding tools, from Claude Code, Cursor and Copilot to Gemini CLI, Codex and opencode.
On proxy hosts with DATABASE_URL set, it dumps LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable: the upstream provider keys. The bundle is encrypted with AES-256-CBC and RSA-4096 and posted to http://www.litellm.dev/healthcheck, a domain registered on 13 October.
sitecustomize.py forks a detached daemon that polls a GitHub dead drop hourly and runs whatever /codepy it is pointed to. The dead drop was empty at release and the account is now deleted, but infected hosts keep polling, so anyone who re-registers that username could get code execution.
What a compromised gateway can do to coding agents
HiddenLayer's "Man-in-the-Model" research (22 October) starts where LiteLLM ends. Gateways such as LiteLLM, OpenRouter and Vercel AI Gateway, and inference servers such as vLLM, llama.cpp and Ollama, relay prompts, tool definitions, tool calls and outputs.
An attacker who controls that layer, for example through its package, plugins or container image, can first watch. The gap between a tool call and its result reveals whether the agent paused for human approval. Across more than 35,000 file reads in HiddenLayer's dataset, only 1.0% fell in its timing heuristic's ambiguous range, so the proxy can map which actions are auto-approved.
Then it can act: insert tool calls the model never requested and hide the injected output from the user. Added code blends into long agent-generated commands, while reviewers scan for familiar signs like rm, sudo or curl piped into a shell.
Future security risks to plan for
1. Gateways as the new identity provider. Proxies now hold every provider key, the logs of every session and sometimes developer tokens. Compromise one and you inherit all of them, plus a position to steer agents.
2. Logs as a credential leak. LiteLLM's breach chain ran through response bodies that contained GitHub tokens. Prompt and response logging, now standard for AI observability, will keep capturing secrets that agents echo.
3. Billing as the payload. LLMjacking needs no data theft. Expect more attacks whose only goal is to attach someone else's payment method to inference, with prompts hidden in tenants you cannot see.
4. Signed does not mean safe. Provenance proved which workflow built LiteLLM 1.107.0, not that the workflow was legitimate. Owner tokens that can override branch protection make signing a formality.
5. Bearer keys outliving the incident. Keys copied once keep working until the provider revokes them, and orphaned dead drops keep infected hosts listening.
A 10-point checklist for CTOs
Inventory every AI provider key: where it is stored (consoles, proxy databases, .env files, CI secrets, coding-tool configs) and which team owns it. Rotate keys that were saved in OpenCode Console or reachable from any host or container that ran litellm 1.107.0; revoke at the provider, not in the tool. Give each tool and environment its own key, with a provider-side spend limit and alert; review provider usage back to at least 16 October. Search lockfiles, Dockerfiles and Helm values for litellm 1.107.0, open-ended litellm>= constraints and floating latest/main-stable tags; pin by digest. On any affected host, do not run pip first: delete cook.pth, cook.py and sitecustomize.py from the shell, kill the process holding /tmp/remote_code_loader.lock, rebuild, and block litellm.dev. Keep self-hosted gateways off the public internet, and turn off or redact response-body logging; scan existing logs for GitHub, cloud and provider tokens. Restrict egress from gateway hosts and CI runners to known destinations so a stealer cannot post its bundle. In Google Cloud, alert on changes to iam.allowedPolicyMemberDomains, billing-account IAM, Gemini API enablement and new service-account keys in old projects; review IAM for consumer domains. Use phishing-resistant MFA (passkeys or security keys) for cloud admins, and block sponsored-ad sign-in paths through managed bookmarks. Reduce GitHub organization owners, require short-lived tokens, and alert on branch-protection overrides and deleted workflow runs.
The bottom line
AI keys now sit in the same places attackers already know how to reach: SaaS consoles, admin logins, CI pipelines and logs. This week showed all three routes in use at once.
Treat the gateway and the billing account as tier-0 systems, and assume any key that touched a compromised host is being spent by someone else.
Sources
https://thehackernews.com/2026/10/opencode-console-breach-may-have.html https://www.bleepingcomputer.com/news/security/opencode-hack-exposes-api-keys-amid-ai-distillation-attacks/ https://techcrunch.com/2026/10/19/hackers-hit-ai-coding-tool-opencode-running-up-charges-on-users-ai-accounts/ https://www.wiz.io/blog/from-phishing-to-llmjacking https://docs.litellm.ai/blog/security-incident-oct-21-2026 https://www.stepsecurity.io/blog/litellm-1-107-0-compromised-pypi-backdoored-wheels-credential-stealer https://research.jfrog.com/post/litellm-hijacked-again/ https://socket.dev/blog/litellm-compromise https://www.hiddenlayer.com/research/blog-llm-gateway-coding-agent-security https://theinjection.dev/week/2026-w43/
Also on our website: https://agtechconsulting.ai/insights/your-ai-gateway-holds-every-key-attackers-came-for-it.html
Want help finding every AI key in your estate and locking down the gateways and billing accounts that hold them? Email avinash@agtechconsulting.ai, visit agtechconsulting.ai, or book a 30-minute call: https://calendly.com/avinash-dubey-30-min-catchup/meeting-with-ag-tech
Mentioning: LiteLLM AI Gateway Krrish D. Ishaan Jaffer Wiz StepSecurity JFrog Socket HiddenLayer OpenCode Google Cloud Anthropic OpenAI GitHub Python Software Foundation OWASP GenAI Security Project Cloud Security Alliance
Originally published on LinkedIn in the Your CTO Advisor newsletter: read and comment on LinkedIn →
