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

At a glance

What this is: Intezer shows that abuse of LLM inference now depends less on model sophistication and more on whether attackers can obtain free, stolen, or exposed access paths.

Why it matters: This matters because LLM endpoints, API keys, and self-hosted inference stacks now behave like governed services, and identity controls determine who can actually consume model capacity.

By the numbers:

• The corpus yielded 647 unique keys across all providers.
• Roughly 62% were Google Gemini keys.
• The revocation rate was approximately 99.5%, consistent with a corpus skewed toward older samples.

Context

LLM inference is the runtime service layer where a model accepts prompts and returns outputs, and that layer now has its own access risk. This article argues that the problem is not only model capability, but whether inference endpoints, API credentials, and hosted AI services are exposed, reused, or left without governance.

For IAM and NHI practitioners, the relevant question is who or what can call model endpoints, under what identity, and with what blast radius when credentials leak or services are left unauthenticated. The article also connects directly to NHI governance because API keys, tokens, and hosted agent sessions are the access objects being abused, not the model weights themselves.

The access patterns described here are not exceptional for cloud services, but they are becoming common for AI services because teams still treat them as experimental rather than production assets. That mismatch is the central governance gap.

Key questions

Q: What breaks when LLM inference is left open or weakly authenticated?

A: Attackers do not need to compromise the model itself if the endpoint is exposed. They can call inference directly, reuse free-tier access, or pivot through leaked keys and self-hosted proxies. The failure is a governance failure at the service boundary, where identity and authorization controls were not applied to a high-value runtime asset.

Q: Why do leaked API keys create billing and data risk in AI services?

A: Because the credential itself is often enough to invoke the service, so anyone who finds it can spend quota, generate charges, or reach data through that API. The risk is not limited to authentication bypass. It includes unauthorised consumption and exposure that follows from accepting the key as valid.

Q: What are the signs that an inference environment is being abused?

A: Look for unusual model enumeration, rapid quota exhaustion, repeated key validation failures, unexplained free-tier account creation, and traffic from unauthenticated endpoints. In self-hosted environments, exposed model lists and OpenAI-compatible APIs without a clear owner are especially strong warning signs. Those symptoms usually mean the access layer, not the model, is the point of failure.

Q: How should teams govern identity and access for AI inference platforms?

A: Teams should govern inference platforms like any other production workload with privileged access. That means separating deployment, routing, telemetry, and data-access credentials, scoping each identity tightly, logging every control-plane change, and reviewing who can alter serving behaviour. The key is to treat the runtime path as a governed service estate, not a single API endpoint.

Technical breakdown

Why LLM inference becomes an access target

LLM inference is just an authenticated or unauthenticated service endpoint that mediates access to model capability. Once attackers can call the endpoint, they do not need to compromise the model itself. The article shows that offensive use cases now include code generation, reconnaissance, and adaptive malware behaviour, which means the service layer becomes the real control point. In practice, the decisive issue is whether the endpoint can be reached, billed, or impersonated. If identity, rate limiting, and endpoint exposure are weak, model quality does not prevent abuse.

Practical implication: Treat inference endpoints as governed production services with authentication, logging, and access policy, not as passive model hosting.

Why leaked keys and free tiers are enough

API keys, disposable accounts, and free-tier access all create valid paths into inference because they satisfy provider authentication at the cheapest possible cost. The article shows attackers using leaked keys from artifacts, anonymous payment middlemen, and permanent free tiers that can be rotated when limits are hit. This is a classic credential governance problem, but the asset is the model endpoint rather than a database or cloud console. If keys are embedded in code, shipped in binaries, or created without lifecycle control, access becomes trivial to industrialise.

Practical implication: Harden secret discovery, revocation, and credential lifecycle controls around every model API key and token.

Why exposed self-hosted inference stacks are the highest-risk path

Self-hosted LLM servers often expose OpenAI-compatible APIs, built-in agent features, and plugin or model-installation functions. When authentication is disabled or left at defaults, the result is a public service that can be queried, enumerated, or abused immediately. The article’s examples show that adjacent tooling such as gateways and workflow systems can also carry live upstream keys, so compromise is often a pivot from one service into many. The governance failure is not the model choice; it is leaving a high-value service reachable without a control plane.

Practical implication: Block public exposure by default and require explicit authorization for every inference host, proxy, and agent-capable runtime.

Threat narrative

Attacker objective: The objective is to obtain low-cost, durable access to capable LLM inference that can support offensive operations without attribution or easy revocation.

1. Entry occurs when attackers gain access through leaked API keys, anonymous free-tier accounts, crypto-funded middleman services, or unauthenticated self-hosted endpoints.
2. Credential access follows when the attacker validates or rotates those credentials, or simply reuses open endpoints to call inference services at scale.
3. Impact is achieved when the attacker uses model access for reconnaissance, phishing, exploit development, malware adaptation, or other offensive workflows.

Breaches seen in the wild

• xAI API key leak 2025: An xAI developer leaked an API key on GitHub that reached 60+ private Grok models and stayed live for about two months before revocation.
• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

LLM inference governance has moved into the identity domain. The article shows that the real control problem is no longer model access in the abstract, but whether a runtime service can be called, billed, or delegated under a trustworthy identity. That puts keys, tokens, free accounts, and hosted agent sessions squarely into NHI governance, because those objects now gate access to high-capability AI services. Practitioners should treat model consumption as an identity and authorization problem, not a novelty feature problem.

Inference endpoints create a new form of credential blast radius. When one leaked key unlocks a frontier model, a workflow platform, or an AI gateway, the impact is not limited to the original secret. The surrounding service architecture determines whether abuse stops at one endpoint or fans out across connected systems. That means the relevant governance question is who can provision, reuse, and revoke inference access across the stack, not whether the model itself has stronger guardrails.

Unauthenticated AI services are becoming the modern equivalent of exposed cloud control planes. The technical pattern is familiar: open ports, default settings, leaked secrets, and weak inventory. What has changed is that the exposed service can now generate code, support reconnaissance, and adapt in real time. Teams should recognise that AI runtime exposure belongs in the same governance class as other internet-facing high-risk services, with explicit ownership and lifecycle control.

Attackers are exploiting the gap between AI experimentation and operational control. Many teams still allow ad hoc model access through developer keys, free-tier credentials, and prototype deployments that were never designed for adversarial use. That gap creates an access surface larger than the model itself, and it is widened by weak offboarding, poor secret hygiene, and unmanaged hosted agents. The practical conclusion is clear: if AI systems can act on valuable data or support offensive workflows, they need lifecycle governance before they need more model capability.

LLM access abuse is now a governance maturity test for machine identities. The same discipline that applies to service accounts, API keys, and workload credentials now has to apply to model endpoints and AI toolchains. In NHI terms, the issue is not whether the credential is human-issued or machine-issued, but whether its scope, rotation, and revocation are enforceable. Practitioners should assume model access will be targeted wherever the identity boundary is weakest.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

LLM inference abuse is now an identity governance problem. Access to model capability is increasingly mediated by secrets, free-tier accounts, and proxy services, which means the control plane is no longer the model but the credential. That is why model endpoints need the same ownership, lifecycle, and revocation discipline applied to any other machine identity.

AI access sprawl will keep widening until organisations inventory the whole inference path. The practical surface includes developer keys, hosted gateways, workflow tools, and self-hosted servers, not just the model provider itself. If one part of that chain is left outside governance, attackers will route around the managed path.

Service accounts for AI workloads should be measured against the same standard as other non-human identities. Access scope, rotation, and revocation are the controls that determine whether a model can be consumed safely. Where those controls are missing, the risk is not theoretical, because the access objects are already being traded, leaked, and automated.

For practitioners

• Govern every model API key as a production secret Inventory keys used for inference, embeddings, gateways, and agent tooling, then enforce rotation, revocation, and ownership with no shared credentials.
• Require authentication on every self-hosted inference endpoint Disable anonymous access, remove default-open configurations, and deny public exposure unless a documented business case exists for the host.
• Constrain free-tier and disposable account usage Block unsanctioned free-model services where possible and route approved workloads through managed identities with logging and quota controls.
• Hunt for leaked keys in developer artifacts Scan source repositories, binaries, logs, and uploaded samples for embedded model credentials, then revoke anything found before it is reused.
• Classify hosted AI agents as governed NHI assets Bring AI agent sessions, inference proxies, and workflow automations into the same inventory and approval process used for other high-risk non-human identities.

Key takeaways

• LLM inference abuse is being driven by access paths such as leaked keys, free tiers, anonymous gateways, and exposed self-hosted services rather than by model weakness alone.
• Intezer’s research shows that the problem is already measurable at scale, with 647 unique keys found and a 99.5% revocation rate among the samples they validated.
• The practical fix is to govern inference endpoints, credentials, and AI runtime assets as high-risk services with explicit authentication, ownership, and revocation.

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.
• Model API key: A model API key is a secret string used to authenticate requests to an AI model service. It identifies the calling application or user and authorizes access to specific model endpoints, usage limits, and billing controls. Because it can be copied and reused, it must be stored, rotated, and monitored like any other sensitive credential.
• 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.
• Inference Proxy Abuse: Inference proxy abuse is a pattern where an AI serving system is turned into a trusted network intermediary for attacker-controlled requests. It matters because a model server that fetches external content may gain access to internal services, metadata, or secrets that the attacker could not reach directly.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern service access. It is designed for practitioners who need to bring AI workloads, service credentials, and lifecycle controls into one governance model.