Attackers are compromising cloud admins not to steal data but to make the victim pay for large-scale LLM use. In a write-up published October 20, 2026, the Wiz Customer Incident Response Team (CIRT) describes campaigns against Google Cloud Platform (GCP) in which attackers phished privileged users, linked their own GCP projects to the victim's billing account, and ran Gemini API workloads that produced "tens to hundreds of thousands of dollars" in charges within 24 to 48 hours. Because the AI work ran in the attackers' projects, the victims could not see a single prompt. This is LLMjacking, and it matters to anyone whose coding agents run on a cloud or model account.
| Question | Short answer |
|---|---|
| Am I affected? | If you run GCP with admins who can change billing, org policy or IAM. Wiz investigated several intrusions with this pattern |
| What is the entry point? | Phishing via sponsored Google Search ads for "google cloud" and "gcp", with MFA codes captured and replayed |
| What did the attackers want? | Non-destructive financial abuse: mass Gemini API usage billed to the victim |
| Can I see the prompts? | No. The workloads ran in attacker-controlled projects linked to your billing account |
| Is there a patch? | No. This is account takeover; the fixes are policy, privilege and monitoring |
| Does data leave my machine? | Not from a local agent. The exposure is in the cloud account |
What Wiz observed, step by step
The details below come from Wiz's own report. Wiz states it investigated "multiple intrusions" and focuses this post on GCP; it does not say how many victims, how many actors, or give a single total loss figure.
1. Initial access: a sponsored ad and a replaying phishing kit
The actor bought Google Search ads for common administrative terms such as "google cloud" and "gcp". A click went through a Google Sites redirect to a fake Google sign-in page. Users with valid access to the Google Cloud console entered credentials and MFA codes, which the page captured before sending the user back to the real Google prompt. The second prompt looked like a glitch. Meanwhile the phishing kit used the harvested credentials at once for the first malicious login, from 212.73.134[.]136. A few minutes later the actor re-authenticated from a second IP, which they used for the rest of the activity.
Google flagged the login as suspicious and emailed the user, but Wiz's point is that user awareness is not enough: ingest Google Workspace user log events and alert on suspicious-login flags and unusual re-authentication. Wiz says that after reports of the activity, Google Ads removed the malicious campaign.
2. Persistence: reuse old projects, mint keys
Rather than build new infrastructure, the actor targeted existing, low-usage projects. They enabled the Gemini API, created service accounts with Gemini API keys, and added those accounts to high-privilege roles such as roles/ml.admin and roles/mcp.toolUser. Quiet, old projects draw little attention, and cost spikes there are easier to miss.
3. Removing the guardrail
The actor then deleted an organization-level safety policy, iam.allowedPolicyMemberDomains. That policy restricts IAM membership to verified company domains. With it gone, external personal accounts could be granted access and high-privilege permissions.
4. Billing takeover
With the restriction lifted, the compromised user added actor-controlled Gmail accounts to the organization's billing account and assigned administrative roles, including roles/billing.admin on billing accounts and roles/recommender.billingAccountCudAdmin on projects. Wiz notes that roles/billing.admin gives full control, including the ability to manage permissions, attach external projects and change payment settings.
5. Linking foreign projects
The actor linked external GCP projects to the victim's billing account. That created cross-tenant access: every API request made in the attackers' projects was charged to the victim, while prompt payloads stayed invisible to the victim's monitoring. Wiz stresses that while the victim carried financial responsibility, its logs showed nothing about the nature or content of the AI workloads.
6. Defence evasion and lockout
After the first login, the actors' activity came from IP addresses geolocated in each victim's headquarters country, even when the compromised user was elsewhere, to avoid location-based alerts. They also demoted existing internal billing administrators to read-only viewers, which removed the legitimate admins' ability to revoke permissions or detach the rogue projects from the console.
How this relates to earlier LLMjacking
Sysdig's Threat Research Team coined LLMjacking in 2024, describing attackers who used stolen cloud credentials to reach hosted models, resell access, and leave the account owner paying; coverage of that report estimated victim costs could exceed $46,000 per day and noted attackers could exhaust quotas and lock the legitimate organization out. In that older pattern the attacker used the victim's own model endpoints through stolen keys. What Wiz describes is different in one important way: the attacker does not need to touch the victim's models at all. Owning the billing account is enough, and it hides the workload better.
We covered the criminal market behind stolen model keys in AI API key theft: inside the criminal reseller supply chain. The Wiz CIRT also published an analysis of an AI-driven cloud attack the day before, which we wrote up separately; these two pieces are about different intrusions, one where the attacker used AI as a tool and one where the attacker wanted AI usage as the product.
What this means if you run AI coding agents
Most coding-agent users do not administer a GCP organization, but the same weaknesses show up in smaller form: a model API key in a project folder, a cloud account shared across a team, a billing account with one over-privileged admin. Use the Wiz hunting guidance as a checklist, and apply the same thinking to agent credentials.
If you administer GCP:
- Review IAM for external members. Look for users on non-corporate domains, especially
@gmail.com, on projects and billing accounts. - Audit organization policy changes. Watch for edits or deletion of
iam.allowedPolicyMemberDomains, and for IAM changes on billing administrators. - Watch for quiet-project activity. Alert on Gemini API enablement, new service accounts and new service account API keys in projects that have been idle.
- Check who can link billing. Billing admin is a sensitive role. Keep it to few named accounts and review membership regularly.
- Set budgets and alerts. Wiz recommends monitoring abnormal API cost surges and enforcing spend-cap budgets. A budget alert is often the first sign the victim sees.
- Ingest Workspace login logs. Alert on suspicious-login flags and re-authentication right after a sign-in.
- Go beyond password plus code. The kit replayed a captured MFA code in real time. Phishing-resistant authentication such as passkeys or security keys defeats that replay; this is our recommendation, not a statement from Wiz.
- Reach the console from a bookmark, not from a search ad.
Wiz's indicators include phishing domains with misspelled Google-like names (for example gboogl[.]com, groosl[.]com, gsool[.]space) and the IP above; the full list is in the Wiz report. Treat any hit in DNS or proxy logs as a sign a user visited the kit.
If you run coding agents with model keys:
- Give each agent or project its own API key with a spend cap, so abuse of one key is bounded and revocable.
- Keep keys out of files an agent can read or print. Our post on credential harvesting by agents shows how quickly an agent with file access collects whatever lies around.
- Rotate keys on any suspicion, and check usage dashboards for models and times you did not use.
What Beam can and cannot do here
Beam cannot see this attack. It is an account takeover in the cloud console, outside what a local agent monitor observes. What Beam does cover is the local side of key hygiene: its agent hooks can flag credential exposure when Claude Code or Codex reads or runs something that surfaces a secret, and redact known credential formats before anything is stored. Hook-based deny works for Claude Code and Codex PreToolUse; it is not a kernel sandbox, and detection is heuristic. Everything stays on your device (how that works). For a practical baseline, see stopping Claude Code dangerous commands and the vibe coding security checklist.
Why the billing layer is the blind spot
Most cloud monitoring is built around resources: a virtual machine that starts mining, a bucket that becomes public, a key used from a new country. A linked billing account sits one level above that. The attacker never needs to create anything in the victim's projects that looks unusual to a resource-level detector, because the expensive resource lives in someone else's tenant. The only signal inside the victim's environment is the invoice and the IAM and billing audit trail, which is why Wiz's hunting list centres on membership changes, policy changes and cost anomalies rather than on workload telemetry.
The demotion step compounds this. Once existing billing administrators are reduced to viewers, a responder who notices the surge may not have the permission to stop it. If you suspect this pattern, the practical order is: contact whoever still holds organization-level or billing-admin rights, remove external members, detach unknown projects from the billing account, restore the domain restriction policy, revoke the new service account keys, and then review the audit logs to establish which accounts were used. Finally, treat the cost number as a warning about speed, not a one-off. Charges of that size within one to two days mean a monthly invoice review is far too slow. A daily budget alert with an automatic notification to more than one person is cheap insurance.
What is and isn't established
Wiz is the only source for these intrusions in our research, and the report does not name victims, give a count of intrusions, or attribute the activity to a named group. The cost range ("tens to hundreds of thousands of dollars") is Wiz's description of the cases it investigated, not an aggregate. The GCP-specific roles, the policy name and the indicators are as Wiz reports them. Wiz says similar patterns exist outside GCP ("multiple intrusions demonstrating this pattern") but details only GCP, so do not assume the same steps on other clouds.
Frequently asked questions
What is LLMjacking?
LLMjacking is the abuse of someone else's cloud account or API keys to run large language model workloads at the victim's expense. Sysdig named the pattern in 2024; Wiz CIRT now describes a variant that hijacks the billing account itself.
How did the attackers get in?
According to Wiz, they bought Google Search ads for terms such as "google cloud" and "gcp" that led through a Google Sites redirect to a fake Google login page, which captured credentials and MFA codes and replayed them immediately.
Why couldn't victims see what the AI usage was?
The attackers linked their own external GCP projects to the victim's billing account. Prompts and outputs were processed in those foreign projects, so the victim's audit logs show the charges but not the workload.
What should I look for in my own environment?
Wiz recommends checking for IAM members on external domains such as @gmail.com, changes to the iam.allowedPolicyMemberDomains policy, billing admin changes, unexpected Gemini API enablement, new service account keys in old projects, and cost surges.
Does this affect people running coding agents?
Indirectly. Coding agents run on model API keys and cloud accounts, and a hijacked billing account or stolen key means someone else's usage on your bill. Keep agent keys scoped, budgeted and out of agent-readable files.
Can Beam detect this attack?
No. This is a cloud account takeover. Beam can flag credential exposure in what a coding agent reads or runs on your machine, which reduces one way keys leak, but it does not watch Google Cloud audit logs.
Related reading
- AI API key theft: inside the criminal reseller supply chain
- Anatomy of an AI-driven cloud attack
- Agents and credential harvesting
- Sources: Wiz CIRT report and The Hacker News on the original LLMjacking research
Details are as published by Wiz on October 20, 2026 and may be updated. Check the source for later changes.