LLM inference abuse is now an access problem, not a model problem

At a glance

What this is: This analysis maps five routes attackers use to reach LLM inference without paying for it, from underground access and anonymous intermediaries to leaked keys and exposed self-hosted servers.

Why it matters: It matters because AI inference is becoming part of the attack chain, and identity, secrets, and service exposure controls now determine whether defenders can contain misuse across AI, NHI, and broader IAM programmes.

By the numbers:

• The corpus yielded 647 unique keys across all providers.
• Roughly 62% were Google Gemini keys.
• About 65% of the 659 unique samples are confirmed Android by VirusTotal's type classification.
• 99.5%.

👉 Read INTEZER's analysis of how attackers are gaining access to LLM inference

Context

LLM inference now behaves like any other internet-facing service with a credential and exposure problem. The article shows that attackers do not need to defeat the model itself if they can buy access, borrow access, steal keys, or find an endpoint left open. For identity and secrets teams, the important issue is not just who can prompt the model, but who can authenticate to the infrastructure behind it.

That changes the governance boundary for LLM workloads. API keys, free-tier accounts, and self-hosted inference servers are effectively non-human identities or identity-adjacent access paths, and they need lifecycle controls, monitoring, and offboarding discipline. The cases described in the source are not exotic outliers; they reflect familiar failures in credential management, exposure control, and service hardening.

At the same time, the article shows how AI capability is being folded into offensive workflows. That makes LLM access a security control plane issue, not only an application feature. The starting position in this article is typical of modern AI operations: capability moves faster than governance, while attackers exploit the resulting access gaps.

Key questions

Q: What breaks when organisations do not govern LLM inference access like a credentialed service?

A: Attackers can substitute easier access paths for legitimate ones, using free tiers, leaked keys, anonymous payment intermediaries, or exposed self-hosted servers. The result is not just model misuse. It is uncontrolled capability, weak attribution, and a larger abuse surface across downstream systems that consume the model output.

Q: Why do leaked API keys matter so much in AI workflows?

A: Because they turn distributed software into a reusable non-human identity. A single embedded key can be copied, replayed, and rotated across many artefacts, which makes access persistence the real risk. In practice, the key often survives longer than the team that embedded it, especially in mobile apps and build outputs.

Q: How should security teams monitor for misuse of free-tier or keyless LLM services?

A: Track rate spikes, repeated account creation, disposable identity signals, unusual source geographies, and prompt patterns that resemble recon or automation. Where services are keyless, identity controls move out of the request itself and into network, behaviour, and workload telemetry, so detection has to be broader than simple auth logs.

Q: Who is accountable when a self-hosted model server is left open to the internet?

A: The operator is accountable, because the failure is usually basic service governance rather than a model flaw. Ownership should sit with the team running the service, with clear responsibility for authentication, patching, exposure control, and credential hygiene across any connected tools or upstream provider accounts.

Technical breakdown

How attackers bypass paid LLM access controls

The article describes four main ways to reach LLM inference without a normal commercial account trail. Attackers can buy offensive models from underground sellers, use crypto-funded intermediaries that hide the end user, register for free-tier accounts with disposable identities, or exploit exposed self-hosted inference servers. The common pattern is not model compromise. It is access substitution, where a legitimate authentication path is replaced by an easier, cheaper, or anonymous one. That makes inference governance an identity and abuse-detection problem as much as a model-security problem.

Practical implication: treat every inference path as a controlled access surface, not a harmless API endpoint.

Why leaked API keys remain the most durable route

Hardcoded keys inside apps, scripts, and build artefacts remain attractive because they turn distributed software into a credential reservoir. Once exposed, a key can be validated, rotated, or burned, but it may still provide enough access for model-listing, prompt submission, or downstream abuse. The article's VirusTotal hunt shows how credentials persist across Android packages, binaries, archives, and developer code. That is a classic NHI pattern: machine-issued secrets accumulate outside their intended lifecycle and survive in places traditional reviews do not inspect.

Practical implication: inventory and rotate model API keys wherever software artefacts, logs, or mobile builds can expose them.

What exposed self-hosted LLM servers change in the threat model

Self-hosted LLM servers collapse the distance between model access and host compromise. If authentication is disabled, or if an exposed service includes model installation, proxying, or agent support, the attacker may gain not just inference access but the ability to pivot into adjacent tools, upstream keys, and connected workflows. The article's examples show the familiar cloud and application-security lesson: the model is only one component of the attack surface. The more the service integrates with local files, MCP-like tool access, or upstream billing accounts, the more one open port can become a control failure.

Practical implication: place inference servers behind explicit authentication, network segmentation, and service-level monitoring from day one.

Threat narrative

Attacker objective: The attacker wants reliable, low-friction access to frontier or proximate LLM capability for recon, exploitation, and credential-driven abuse without leaving a normal payment or identity trail.

1. Entry occurs when attackers obtain LLM access through underground subscriptions, anonymous payment intermediaries, free-tier accounts, leaked API keys, or unauthenticated self-hosted servers.
2. Escalation follows when the accessed model or server is used for reconnaissance, exploit generation, credential chaining, phishing content, or runtime adaptation inside malware.
3. Impact occurs when the attacker turns that inference access into scalable offensive capability, credential theft, or abuse of victim-hosted compute and connected systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Inference access has become an identity governance problem. The article shows that attackers do not need to crack the model if they can obtain, borrow, or impersonate the access path. That makes API keys, free-tier accounts, and upstream billing accounts part of the identity fabric of AI operations. For IAM and NHI teams, the key insight is that model access now needs lifecycle control, revocation, and attribution, just like any other machine credential.

LLMjacking is a named access pattern that security teams should track explicitly. It combines credential abuse, anonymous funding, and exposed services into one repeatable route to capability. This is not just shadow AI usage, because the abuse can involve genuine machine identities, stolen secrets, and unmanaged inference endpoints. The governance failure is the absence of a trustworthy access boundary around the model layer, which should be treated as an NHI control domain.

Free-tier and keyless models create a blind spot for abuse detection. When access requires only disposable identity data or no credential at all, traditional account-based controls lose much of their value. That does not make the risk acceptable; it means monitoring must shift to rate patterns, endpoint exposure, and anomalous prompt behaviour. Practitioners should map these services into their AI asset inventory and monitor them as part of the broader security perimeter.

Exposed inference servers behave like any other ungoverned internet service. The article's core lesson is operational, not novel: unauthenticated services get found quickly and abused quickly. In the AI context, the blast radius includes model access, attached credentials, and downstream workflows, which is why identity, secrets, and host hardening must be managed together. The practitioner takeaway is to govern inference as production infrastructure, not as an experimental convenience.

The market will keep rewarding access-layer controls over model-only claims. As offensive use of LLMs becomes routine, organisations will need discovery, policy enforcement, and credential lifecycle controls around the inference stack itself. That will favour programmes that can join IAM, NHI, and AI governance into one operating model. Security teams should prepare for more tool sprawl unless they build a single control view across models, keys, and endpoints.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• For a broader NHI view of compromised credentials and access abuse, see AI LLM hijack breach for a related attack pattern across stolen keys and AI model access.

What this signals

LLM access control is converging with NHI governance. As model use shifts from experimentation to production abuse, teams need one view of API keys, service accounts, upstream billing, and host exposure. The practical change is that AI workloads should enter the same control inventory as other non-human identities, with ownership, revocation, and auditability attached to each access path.

AI governance teams should expect more credential-driven abuse than model manipulation. The most actionable defensive work is still basic security hygiene: inventory, segmentation, rotation, and detection of abnormal access patterns. That aligns closely with the themes in the The 52 NHI breaches Report, where persistence and access sprawl repeatedly outlive the original misuse event.

Access-layer controls will matter more than model-layer policy alone. The organisations that will scale safely are the ones that can connect AI usage, secret handling, and service exposure into one operating picture. For teams using the MITRE ATT&CK Enterprise Matrix as a reference, the relevant question is how quickly credential access turns into lateral use of connected systems.

For practitioners

• Inventory every LLM access path Map paid APIs, free-tier accounts, anonymous endpoints, intermediary payment services, and self-hosted inference servers into a single inventory so you can see where access is authenticated, delegated, or open. Include upstream billing accounts and service tokens as governed assets.
• Rotate and revoke exposed model keys Search application code, mobile builds, container images, logs, and repository history for API keys used to reach model providers. Revoke dead keys quickly, rotate live keys on a schedule, and tie ownership to a named service account or team.
• Treat inference hosts as internet-facing production systems Place self-hosted model servers behind authentication, segmentation, patching, and runtime monitoring. Disable public exposure unless it is explicitly required, and alert on unauthenticated model-list requests, unusual volume, or unexpected upstream provider usage.
• Add abuse signals to AI governance monitoring Watch for rapid account churn, repeated free-tier registration, disposable email patterns, prompt bursts, and model access from hosts that should not be running AI services. These signals help distinguish legitimate testing from adversarial access scaling.

Key takeaways

• LLM abuse is fundamentally an access-governance problem, because attackers reach inference through stolen secrets, anonymous intermediaries, free tiers, and open servers.
• The strongest evidence in the article is the scale of exposed and recoverable credentials, which shows that AI workflows still inherit classic secret-management failures.
• Practitioners should govern inference endpoints, API keys, and hosted AI services as part of the same identity and exposure control plane.

Key terms

• LLM inference access: The runtime path used to send prompts to a large language model and receive outputs. In security terms, this is an access surface with identities, quotas, billing, logs, and abuse controls, not just an application endpoint.
• LLMjacking: Abuse of cloud AI services through stolen machine credentials rather than human user accounts. The attacker uses valid non-human identities such as API keys or tokens to enumerate model access, invoke endpoints, and create cost, data, or policy exposure under the victim's tenancy.
• Free-Tier Abuse: Free-tier abuse is the repeated exploitation of trial or no-cost access intended for legitimate evaluation. In AI products, it often appears as rapid sign-up cycling, disposable identities, and one-and-done usage patterns that consume compute before the provider can intervene.
• API Key Rotation: API key rotation is the process of replacing a secret with a new value before or after risk emerges. In NHI governance, it is a lifecycle control that reduces the time a leaked credential remains usable and helps limit the blast radius of exposure.

What's in the full report

INTEZER's full analysis covers the operational detail this post intentionally leaves for the source:

• Provider-by-provider rate limits and access paths for free-tier and keyless inference services, useful if you need implementation detail.
• The YARA and VirusTotal hunting workflow used to uncover leaked model keys in real artefacts, which matters for detection and response teams.
• The host-level findings on exposed Ollama, LocalAI, Langflow, n8n, vLLM, and ComfyUI deployments, which help you compare real-world exposure patterns.
• IOC and sample context for the malicious binaries and APKs that carried AI API keys, useful for triage and validation.

👉 INTEZER's full post covers provider limits, exposed-server findings, and key-hunting details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle fundamentals. It is designed for practitioners who need to apply those controls across AI, cloud, and broader security programmes.