Security researchers use the term LLMjacking for the theft of access to hosted language models, which Sysdig first documented in 2024 and compared to cryptojacking, the older practice of stealing computing power to mine coins [1] [2]. Reporting from 2026 describes stolen AI keys being scraped, tested, resold and used as infrastructure, and an Okta analysis of stealer logs found AI service tokens and keys among the stolen data [3] [4] [5].
Background
In cryptojacking, an attacker runs mining software on someone else's hardware or cloud account, and the victim pays for electricity or compute. Sysdig's 2024 report describes the same economics for language models: the attacker uses the victim's credentials to run inference on a hosted model, and the victim receives the invoice [2]. A key for a hosted model is a bearer credential, so whoever holds the string can use the account without any further login.
This item is the general trend piece. A narrower report on stealers that take tokens and prompt histories from coding agents is covered in Gen Digital finds information stealers collecting tokens and prompt histories from AI coding agents, and a supply-chain case in Hijacked npm and PyPI packages that steal developer keys.
Findings
Sysdig's first report, from May 2024, described attackers who obtained credentials from a system running a vulnerable version of the Laravel framework (CVE-2021-3129), then targeted hosted models, notably Anthropic's Claude on AWS Bedrock. The attackers probed ten AI services to learn which credentials worked, among them Anthropic, OpenAI, Azure, Google Vertex AI, Mistral and OpenRouter. Sysdig estimated that use of Claude 2.x models at maximum quota across regions could cost a victim more than 46,000 dollars a day [1].
In September 2024 Sysdig reported a tenfold increase in model requests during July of that year, and a cost estimate above 100,000 dollars a day for cutting-edge models such as Claude 3 Opus. It also observed attackers enabling models the victim had not enabled and deleting the model invocation logging configuration, which hides usage from the account owner [2].
Pillar Security reported on 28 January 2026 an operation it called Bizarre Bazaar. Its honeypots recorded 35,000 attack sessions, an average of 972 a day, against exposed model endpoints such as unauthenticated Ollama servers and OpenAI-compatible APIs, and against MCP servers without access control. Pillar describes a three-part supply chain of scanning, validation and resale, with access to more than 30 model providers sold through a storefront at a discount of forty to sixty per cent, and a typical delay of two to eight hours between a public scan and an exploitation attempt [3]. Pillar's operation concerns exposed endpoints rather than keys stolen from a person's Mac; it is included because it shows the resale market.
The Cloud Security Alliance's AI Safety Initiative wrote on 18 June 2026 that LLMjacking has moved from cost-shifting to infrastructure for offensive tooling. It cites a Sysdig-documented tool that uses hijacked inference capacity as its reasoning engine, and a May 2026 incident in which a model-driven intrusion reached database exfiltration across four pivot points in under two minutes [4].
The route from a developer's computer is documented by Okta. It analysed a 7 GB stealer dump published on Telegram on 2 August 2026 that came from 5,871 infected machines in 162 countries. The dump held 44,791 unique JSON web tokens, of which 555 were likely tied to AI services, and 24 valid API keys for Google Gemini, OpenAI, Groq and OpenRouter. Affected services also included Anthropic, Cursor and Poe. The article names Lumma Stealer and Vidar as the tools involved, and Okta's Jeremy Kirk is quoted as saying that session tokens and API keys can be replayed to bypass credential-based authentication [5].
A Techweez article of 28 September 2026 attributes the trend to Google's Mandiant team and lists the usual origins of a credential: a personal access token committed to GitHub, a leaked API key, or a session token lifted by an information stealer. It says victims often learn of the abuse only when the invoice arrives [6].
Implications for Mac users
The reports describe several separate routes: keys leaked in public code, credentials taken from servers with known flaws, exposed model endpoints, and secrets lifted from a personal computer by a stealer. Only the last involves a Mac directly. A developer who keeps a key in a plain configuration file, a shell profile or a synced project folder gives a stealer a predictable target [5] [7].
The theft is usually not the visible event. The attacker uses the key from their own machines, and the owner sees a bill. Sysdig's cryptojacking comparison holds in that respect: the cost falls on the account holder, not on the attacker [2].
Recommendations
- Keep keys out of source code and out of files that are committed or synced. Anthropic advises injecting them as environment variables or, better, using a secrets manager rather than local dotenv files, and adding .env files to .gitignore [7].
- Add secret scanning to the build pipeline. Anthropic suggests a tool such as Gitleaks, and says it takes part in GitHub's secret scanning programme, which leads to exposed Claude keys in public repositories being deactivated automatically [7].
- Use a separate key for each environment and project, so that one leak has a limited reach [7]. Prefer narrowly scoped and short-lived tokens where the provider offers them [5].
- Set spend limits and billing alerts, and review usage logs. Both Anthropic and the Cloud Security Alliance recommend this as the practical signal of a stolen key [4] [7].
- Rotate keys on a schedule (Anthropic suggests every 90 days) and at once after any suspected exposure, including after an infection of a computer, not only after a password change [7].
- Never expose a self-hosted model or MCP server to the internet without authentication [3].
Relevance to FireAI
FireAI cannot stop the use of a key that has already been stolen, because the attacker uses it from other machines and the traffic never passes through the user's Mac. It also does not find keys in files, scan repositories, rotate credentials or check a provider account. What it can do concerns the theft from the Mac itself. In Alert mode a new app with no rule that tries to connect triggers a prompt, Paranoid mode blocks unsigned apps, and the threat lists can block known bad destinations. The World map shows which app talked to which server and warns in red when the Mac suddenly sends a lot of data to one country. A stealer that sends data through a connection an already-approved app is allowed to make would not be asked about.
Limitations
The sources differ in kind. Sysdig, Pillar and Okta report their own observations; the Cloud Security Alliance note is a secondary synthesis, and the Techweez article, which attributes the trend to Mandiant, gives no figures and was not checked against a Mandiant publication. The dollar figures from Sysdig are estimates of possible cost at maximum usage, not measured losses. The Okta figures describe one dump, and the 24 valid keys were those found valid in it, not a measure of how many keys are stolen overall.
The headline contrast is a simplification. Pillar states that the same operation also sought compute for cryptocurrency mining, so the two activities coexist rather than one replacing the other [3]. None of the sources reports a count of stolen Claude keys, and the sources fetched do not say what share of thefts originate on personal Macs.
Try FireAI, by HisnLabs free for 17 days.