AI Security
LLMjacking and Stolen AI API Access: How to Detect and Contain It
LLMjacking explained: learn how stolen AI API keys and cloud credentials are abused, what warning signs to review, and how to contain compromised access safely.
LLMjacking** is the unauthorized use of cloud-hosted AI models or compute after an attacker gains access to an AI account, API credential or cloud environment. The practical concern is not the label itself; it is that a stolen key or account can let someone test access, route requests through a service, or deploy AI infrastructure that the legitimate owner did not approve. For defenders, the first priorities are to confirm what was exposed, contain the credential, and review activity without assuming that every unusual request proves LLMjacking. The evidence is still developing and should be read carefully. Sysdig documented one investigation in 2024 involving stolen cloud credentials and multiple cloud-hosted LLM services. Google Threat Intelligence Group (GTIG) described additional credential, account and cloud-infrastructure abuse in a 2026 report. Those reports show mechanisms and observed examples, not a measured prevalence rate. This guide separates documented facts from defensive interpretation so teams can act without overstating what the evidence proves. Readers can use this article to understand how stolen AI API access is tested and monetized, which signals deserve attention, and what a safe containment sequence looks like. For the broader control context, see CYBERoinfo’s [cloud security fundamentals](https://cyberoinfo.com/cybersecurity/cloud-security) and keep the focus on access governance, logging and recovery. > **Key Takeaways > - LLMjacking means unauthorized use of AI services or cloud compute through stolen credentials, accounts or cloud access. > - Stolen access may be checked against several providers before it is used; a successful check is a warning signal, not proof of a completed incident. > - Treat exposed AI keys, cloud credentials, CI/CD tokens and developer secrets as containment priorities: replace or rotate them, deploy replacements, revoke the old credentials, and review logs. > - Least privilege, phishing-resistant MFA, short-lived credentials, audit logging and anomaly detection reduce the opportunity for unauthorized AI workloads. > - CERT-In, CISA and Google Cloud guidance support practical defensive steps, but the cited reports do not establish a universal rate or market-size estimate for LLMjacking.
What Is LLMjacking and Why Does Stolen AI API Access Matter?
LLMjacking is an emerging label for unauthorized use of cloud-hosted large language models or related compute. The access can come from a stolen API key, a compromised developer account, an exposed cloud token or a hijacked cloud environment. Once access works, the unauthorized user may submit model requests or use cloud resources for high-performance compute. The defining issue is unauthorized consumption of someone else’s AI service or infrastructure.
The risk has two sides. A provider account may incur unexpected usage or lose control over model access, while a cloud environment may be changed to run infrastructure that the owner did not create. A key can also reveal more than a single model endpoint, depending on its permissions and the service configuration. That is why stolen AI API access should be handled as a credential-security incident rather than only as a billing discrepancy.
CISA’s cloud-use-case guidance explains that cloud management interfaces are commonly exposed as internet-accessible APIs and that API-key-like tokens can grant access without equivalent identity verification. In practical terms, a token can be easy for an attacker to use remotely even when the organization’s normal sign-in process has stronger checks. Teams should therefore map where each credential works, what it can do and how quickly it can be disabled.
The label does not tell you how an incident began. A leaked key may come from an application, a repository, a CI/CD workflow, a developer tool or a broader cloud compromise. Avoid treating the presence of an AI endpoint in logs as proof of LLMjacking; establish the identity, source, permission scope, time window and approved business purpose first. CYBERoinfo’s [API security guide](https://cyberoinfo.com/cybersecurity/api-security) can sit alongside that investigation as a broader control reference.
How Does LLMjacking Use Stolen AI API Keys and Cloud Credentials?
The short answer is that attackers first validate access, then choose the account or environment that offers useful capability. In its 6 May 2024 investigation, Sysdig said its Threat Research Team observed stolen cloud credentials being used to target ten cloud-hosted LLM services. The researchers reported credential checking against services including Anthropic, AWS Bedrock, Azure, OpenAI, OpenRouter and Google Vertex AI, as well as evidence of an LLM reverse proxy.
Sysdig said the credentials came from a system running vulnerable Laravel and estimated that the activity could cost the victim more than $46,000 per day if it went undiscovered. That figure belongs to the documented investigation and its assumptions; it is not a general loss estimate for LLMjacking. The useful defensive lesson is that a stolen credential may be tested across several services, so reviewing only one AI provider can leave part of the exposure unseen.
GTIG’s 8 September 2026 report described a broader set of access paths observed through Mandiant incident-response engagements, underground-forum tracking and platform defenses. It said adversaries were stealing developer credentials, buying compromised AI-platform accounts and hijacking enterprise cloud infrastructure for unauthorized high-performance compute. GTIG also reported more buyers and sellers of AI-related accounts in the 2026 underground forums it tracked, while noting that average marketplace prices per account more than doubled in 2026; it did not publish absolute counts or prices.
These observations support a cautious workflow: inventory AI providers, identify every credential and account that can reach them, and compare successful authentication with approved workloads. Do not reproduce live credentials or probe an unfamiliar service as an experiment. If you need to understand the wider supply-chain route, CYBERoinfo’s [software supply-chain security coverage](https://cyberoinfo.com/cybersecurity/software-supply-chain) provides a related defensive lens.
What Warning Signs Can Point to LLMjacking?
The strongest warning sign is a mismatch between authorized use and recorded activity. Review new or unusual model requests, unfamiliar regions or networks, unexpected project changes, new service accounts, unexplained compute growth and AI-related charges that do not match an approved workload. None of these signals proves LLMjacking alone, but together they can justify immediate credential review and containment.
Look for access validation across multiple providers or endpoints, especially when a credential is associated with an application that should not call AI services. Sysdig’s investigation found credential-checking activity and an LLM reverse proxy, so a pattern of rapid service discovery or routing through an unfamiliar intermediary deserves attention. Keep this as a detection hypothesis, not an attacker playbook: analysts should preserve relevant logs and avoid interacting with suspicious infrastructure.
Developer and cloud configuration files are another important review point. GTIG reported that ACRSTEALER controllers were observed in May 2026 targeting AI-coding-assistant configuration files, including `secrets.json` for Cline and `config.yaml` for Continue AI, which can contain plaintext API keys and model-routing endpoints. The presence of one of these files does not establish theft, but plaintext secrets should be treated as exposed until the team can establish otherwise.
Also review identity and infrastructure changes around the same time. GTIG described an April 2026 Mandiant case in which an exposed GitHub personal access token was used to enter a cloud environment, deploy unauthorized AI infrastructure, create a privileged service account and scale high-performance compute. That is a documented example, not proof that every stolen key follows the same path. Useful detection joins credential events, IAM changes, deployment records, model usage and billing rather than relying on one alert.
How Should You Respond to Stolen AI API Access?
Start by containing the credential and preserving enough evidence to understand the scope. Identify the affected key, account, token or service account; record where it was found; note the relevant time window; and restrict or disable access according to the provider’s emergency process. Avoid deleting logs or infrastructure before responders have captured the information needed to distinguish unauthorized activity from a legitimate job.
For a compromised Google Cloud credential, Google Cloud guidance says to create a new credential, deploy it wherever it is needed, and then revoke the old credential. The same guidance notes that short-lived service-account tokens can remain valid until expiry, so response may also require disabling the service account or applying an IAM deny policy. The exact action depends on the credential type and the service, but the principle is consistent: replacement is not complete until old access is no longer usable.
Rotate related secrets, not only the key that first triggered the alert. Check cloud credentials, CI/CD tokens, repository tokens, developer-tool configuration, model-routing endpoints and service-account permissions. CERT-In’s 2 April 2026 notice advises organizations to rotate API keys, cloud credentials, CI/CD tokens and other secrets after relevant exposure, audit workflows, use MFA, pin dependencies and limit long-lived credentials. Its supply-chain notice is relevant defensive guidance; it does not establish that every listed compromise was LLMjacking.
After containment, compare provider logs, cloud audit logs, IAM events, deployment history and billing or usage records. Determine which requests succeeded, which resources changed, whether a privileged identity was created and whether other secrets may have been reachable. Close with a documented recovery decision: credentials replaced, permissions reduced, affected workloads reviewed, monitoring enabled and owners informed. Keep the response supportive and factual; an unexpected bill is a signal to investigate, not a reason to blame the person who stored a secret.
Which Controls Reduce LLMjacking Risk?
The most effective controls reduce both the chance of credential theft and the value of any credential that is stolen. Use least privilege for AI services, separate development and production access, avoid long-lived secrets where practical, and keep model access behind a managed identity or credential-management system. CISA recommends strong, preferably phishing-resistant MFA, extensive logging and anomaly detection, along with cloud-native credential management such as one-time passwords and regular key schedules.
Make secret placement part of the software-development process. Scan repositories and build artifacts for keys, keep sensitive values out of plaintext configuration when possible, pin dependencies and review changes to CI/CD workflows. GTIG’s observation about `secrets.json` and `config.yaml` shows why AI-coding-assistant configuration deserves the same care as other developer secrets. The goal is not to prohibit useful tools; it is to prevent an ordinary configuration file from becoming a durable access path.
Set up monitoring that connects identity, usage and cost. Alert on new service accounts, unexpected permission changes, unusual model volume, new regions, unfamiliar user agents, sudden compute scaling and AI usage that falls outside the owner’s normal pattern. Since a valid token may bypass an interactive login, monitoring should focus on what the credential does after authentication as well as how it was obtained.
Practice the recovery sequence before an incident. Teams should know who can revoke a key, who can disable a service account, where audit logs are retained, how to replace secrets in every deployment and how to review provider-level usage. CYBERoinfo’s [phishing-resistant MFA guidance](https://cyberoinfo.com/cybersecurity/phishing-resistant-mfa) is relevant to the identity layer, but MFA should complement—not replace—short-lived credentials, least privilege and service-level monitoring.
What Should Indian Organizations Know About LLMjacking?
Indian organizations can apply the same core controls while using CERT-In’s guidance as a useful local reference point. The 2 April 2026 CERT-In current-activity notice recommends rotating exposed API keys, cloud credentials, CI/CD tokens and other secrets; auditing workflows; enabling MFA; pinning dependencies; and limiting long-lived credentials. These measures address credential and software-supply-chain exposure that can contribute to unauthorized AI access.
The notice should be interpreted precisely. It documented software-supply-chain compromises involving, among other components, LiteLLM, and described credential harvesting and exfiltration. It did not establish that all listed supply-chain incidents were LLMjacking, and it did not identify an India-specific LLMjacking victim in the evidence used for this article. Avoid turning general guidance into a claim about a particular organization or incident.
For operations teams, the practical translation is straightforward: maintain an inventory of AI providers and cloud projects, assign owners to each credential, record rotation and expiry, and make emergency revocation a tested procedure. Include developer tools, repositories and CI/CD systems in the same review because AI-related secrets can be stored outside the main AI platform.
Keep incident communications clear about certainty. State what was observed, what remains unconfirmed and what has been contained. That discipline helps legal, security, finance and engineering teams make sound decisions without publishing unsupported loss figures or implying that an episodic signal is a prevalence estimate. For adjacent national context, CYBERoinfo’s [India cybersecurity overview](https://cyberoinfo.com/cybersecurity/india-cybersecurity) can support broader planning.
Frequently Asked Questions
### Is LLMjacking the same as an AI data breach?
No. LLMjacking describes unauthorized use of AI services or cloud compute through stolen or compromised access. A data breach may involve unauthorized access to or disclosure of information. The two can occur together, but one does not prove the other. Investigators should establish whether data was accessed, copied or exposed rather than inferring it from unusual AI usage alone.
### Does an unexpected AI bill prove LLMjacking?
No. It is a useful warning signal, but billing anomalies can have legitimate causes such as a new workload, a configuration error or an approved experiment. Compare usage with deployment records, identity events, provider logs and the owner’s change history. If the activity is not explained, contain the relevant credentials while preserving evidence.
### What should I do first if an AI API key is leaked?
Treat the key as compromised. Identify where it is used, create and deploy a replacement if the provider’s process supports it, revoke the old key, and review related credentials, logs and permissions. If the key belongs to a service account or cloud environment, check whether disabling the account or applying a deny policy is also necessary. Google Cloud’s compromised-credential guidance describes this replace, deploy and revoke sequence for its credential context.
### Can MFA stop LLMjacking by itself?
No. MFA helps protect interactive identity access, especially when phishing-resistant methods are used, but an attacker who obtains a usable API-key-like token may not face the same interactive verification. Combine MFA with least privilege, short-lived credentials, managed secret storage, logging, anomaly detection and tested revocation.
Limitations
- Evidence and guidance can change; verify current advisories and organisational applicability before acting.
Evidence sources
- sysdig.com — Sysdig, LLMjacking: Stolen Cloud Credentials Used in New AI Attack (6 May 2024)
- cloud.google.com — Google Threat Intelligence Group, GTIG AI Threat Tracker: From Prompting to Autonomy (8 September 2026)
- cert-in.org.in — CERT-In, Multiple Software Supply Chain Attacks Targeting Open-Source Packages and Developer Tools (2 April 2026)
- cisa.gov — CISA, TIC 3.0 Cloud Use Case (December 2023)
- docs.cloud.google.com — Google Cloud, Respond to compromised Google Cloud credentials
- trends.google.com — Google Trends, LLMjacking, worldwide Web Search, past 12 months (accessed 12 October 2026)