Skip to main content

The LLMjacking Budget Conversation: Three Questions Your CFO Will Ask

3 November 2026 · Strategic synthesis from recent signals

When Mandiant reported LLM theft generating over US$100,000 in daily fraudulent charges this week, they documented something your CFO will care about: cloud credentials that steal budget, not data.

This isn't hypothetical risk management theatre. Multiple 2026 incidents reached seven-figure cumulative charges before detection. In one case, attackers enabled model services that organizations hadn't turned on themselves, then rotated short-lived service accounts to bypass rate limits.

Here's the conversation coming to your organization — and the evidence you need to prepare for it.

The Signal: What Happened​

Mandiant's November 2 disclosure (via The Register, primary source) documented "LLMjacking" incidents where compromised enterprise cloud credentials were used to rack up massive model inference charges.

Confirmed facts:

  • Daily fraudulent charges exceeding US$100,000 observed in multiple incidents
  • Cumulative charges reached US$1 million at some organizations before access was revoked
  • Attackers enabled LLM services on cloud accounts that didn't previously use them
  • Service-account rotation used to evade rate limits and spending controls
  • Victims faced this exposure even without enabling model services themselves

What's uncertain:

  • How prevalent these incidents are (Mandiant observations, not industry census)
  • How much fraudulent billing victims ultimately paid (some disputed charges, outcomes vary)
  • Whether every spending control type was bypassed (service-account rotation defeats some, not all)

This is vendor-reported intelligence, not independent research. Google Cloud Mandiant has detection incentive. But the documented mechanics are specific enough to prepare for.

Why Your CFO Will Care: Three Failure Modes​

1. Budget Exposure You Didn't Budget For​

The problem: Your cloud governance model assumes workloads you deployed. LLMjacking works because permissions often allow enabling services, not just using them.

Traditional cloud cost overruns come from your own workloads running longer or scaling larger than expected. You forecast them. You set alerts. You have budget approval chains.

LLMjacking charges come from someone else's workload on your bill. A compromised credential with service-enablement permissions becomes a blank check for model inference costs.

Why controls didn't catch it earlier:

  • Service enablement is often separated from usage monitoring
  • Rate limits and quotas apply per project, not per attacker — rotating projects bypasses them
  • Spending alerts trigger after the charges accrue, not before
  • Many organizations monitor usage of deployed services, not newly enabled ones

The CFO question: "If a credential is compromised tomorrow, what's the maximum fraudulent spend before we detect and revoke it?"

Answer you need: Not "we have monitoring." You need dollar exposure ceiling and time-to-detection SLA. If the answer is "unlimited and we don't know," say so. Then explain the mitigation plan.

2. Existing Controls Were Designed for Different Threats​

The problem: Your cloud security controls likely focus on data theft and lateral movement. Budget theft needs different detection patterns.

Most enterprise cloud security programs matured through data breach response. The threat model: exfiltrate sensitive data, move laterally to high-value systems, establish persistence.

LLMjacking doesn't fit that model. Attackers don't want your data. They want your compute quota to run their own inference workloads — often for resale or cryptocurrency mining analogs.

Detection gap:

  • DLP (Data Loss Prevention) won't see it — no data leaving
  • Anomalous authentication might catch initial access, but authorized use of enabled services looks normal
  • Network egress monitoring sees API calls to legitimate cloud services
  • Traditional SIEM rules flag suspicious admin actions, not billing anomalies

The CFO question: "We already spend $X million on cloud security. Why didn't those controls prevent this?"

Answer you need: Honest assessment of control coverage. If your security stack monitors for data theft but not budget theft, say so. Then: "Here's what we're adding: billing anomaly detection, service-enablement restrictions, spending velocity alerts."

3. The Governance Gap: Who Can Enable What​

The problem: Service-enablement permissions are often too broad. Cloud identities that need to provision infrastructure often inherit permissions to enable any service.

In Mandiant's incidents, attackers enabled LLM services on accounts that hadn't previously used them. That requires serviceusage.services.enable (GCP) or equivalent permissions — often granted to roles like "Project Editor" or "Owner" that many operational identities hold.

Your DevOps automation, CI/CD pipelines, and platform teams likely have these permissions for legitimate reasons. That's a lot of attack surface.

Blast radius:

  • One compromised automation credential can enable services across multiple projects
  • Short-lived service accounts (legitimate pattern for CI/CD) become rotation vehicles for attackers
  • Quota enforcement often assumes good-faith use by authorized identities, not adversarial workloads

The CFO question: "How many credentials have permission to enable million-dollar services we don't use?"

Answer you need: Audit results. List roles with service-enablement permissions. For each: Why they need it, how they're monitored, and what the spending ceiling is if compromised.

What to Do Monday: Decision Support for AI Leaders​

Immediate Actions (This Week)​

1. Audit service-enablement permissions

  • Identify every role/service account with permissions to enable cloud services
  • For each: Document business justification, last use, monitored by what control
  • Restrict service-enablement to dedicated roles where possible
  • For roles that need it: Add spending alerts and velocity monitoring

2. Set up billing anomaly detection

  • Alert on newly enabled services in projects that haven't used them
  • Monitor spending velocity: flag charges that exceed 3x historical daily average
  • Separate alerts for model inference vs. other compute (different cost profiles)

3. Verify quota and spending controls apply to enabled services, not just deployed ones

  • Test: Can a credential with service-enablement permission bypass your quotas by enabling services in new projects?
  • If yes: Implement project-creation restrictions or spending caps at organization level

Strategic Changes (This Quarter)​

4. Revise cloud IAM strategy for AI services

  • Treat model inference permissions like financial transaction permissions: audit, approve, monitor
  • Separate "can deploy models we already use" from "can enable new model services"
  • Require approval workflow for enabling high-cost services

5. Add budget theft to your threat model

  • Update cloud security playbooks: compromised credential → check billing, not just data access
  • Include spending anomaly in SOC detection rules
  • Test incident response: How fast can you revoke credentials and dispute charges?

6. Establish cost guardrails before enabling model services

  • For each cloud project using models: Set hard spending cap (not just alert threshold)
  • Monitor service-account lifecycle: flag creation/deletion patterns consistent with rotation
  • Require MFA or additional approval for service-enablement permissions

What Remains Uncertain​

This is Mandiant intelligence, not industry consensus. We don't know:

  • How common LLMjacking is across cloud providers (Google Cloud reported, others silent)
  • Whether automated detection caught any incidents before seven-figure losses
  • If quota/spending controls worked in cases Mandiant didn't observe
  • What percentage of fraudulent charges victims successfully disputed

Don't assume worst case, but don't ignore it.

Mandiant has incentive to highlight threats their tools detect. That doesn't mean the threat is fake — the mechanics are specific, the blast radius is real, and the control gap is documented.

Prudent response: Audit your exposure, test your controls, fix obvious gaps. Don't launch a six-month governance project. Do answer the CFO's three questions with evidence.

The Strategic Implication​

Cloud security is no longer just about protecting data. It's about protecting budget.

LLMjacking isn't a new class of attack. It's credential theft applied to high-cost compute resources. But the speed at which costs accrue (US$100K/day) and the difficulty of detection (legitimate API calls to legitimate services) make it different enough to matter.

For boards and C-suite: This is a concrete, documented exposure with seven-figure loss examples. It's not "maybe someday AI risk." It's "did we lose money yesterday and not know it yet?"

For AI governance programs: This validates the "assume breach" mindset. Governance isn't just ethics and bias. It's "can a compromised credential bankrupt a project before anyone notices?"

For enterprise AI adoption: Secure AI deployment isn't optional overhead. It's the control that prevents your AI experimentation budget from becoming someone else's revenue stream.

Sources & Evidence​

This analysis synthesizes evidence available as of November 3, 2026. Cloud security landscape evolves; verify current state before making commitments.

Questions or feedback? Comment on GitHub Issue #55 or email dwaynehelena@gmail.com.