The LLM Token Black Market: What Every AI Builder Needs to Know About API Key Theft

I run Tuqlas, an AI chatbot platform that makes LLM API calls on every single user interaction. Every message a customer sends hits OpenAI or Anthropic endpoints through my managed keys. So when I read Matt Lenhard's deep dive into the underground LLM token relay market this week, I did not see an interesting security story. I saw a direct threat to my infrastructure and my wallet.

The research, published on July 26, 2026, reveals a structured marketplace where resellers pool stolen, abused, or fraudulently obtained API keys and sell discounted LLM tokens to buyers who want cheap inference. This is not a theoretical attack. It is an operating business with forums, pricing tiers, and customer support.

How the relay market works

The architecture is surprisingly elegant and built entirely on legitimate open-source software. Resellers use tools like one-api and new-api, which are open-source API proxy and management platforms originally designed for legitimate multi-provider routing. These tools let you load-balance across multiple API keys, track usage, and present a unified endpoint to consumers. In the relay market, operators load these proxies with dozens or hundreds of stolen keys and sell access to the unified endpoint at a discount.

The supply chain for keys works through several methods. Some operators abuse free-tier trials at scale, spinning up hundreds of accounts to accumulate small quotas that add up to meaningful capacity. Others proxy through unprotected support bots and customer service chatbots that expose their underlying LLM endpoints without authentication. The more brazen operators use stolen credit cards to provision paid API accounts, running them until the chargebacks hit. And some simply buy credentials from initial access brokers who have compromised developer machines or CI/CD pipelines.

Buyers fall into three categories: people who want cheap tokens for personal projects, developers trying to bypass geo-restrictions on providers not available in their region, and teams running large-scale data generation for model distillation. That last category is particularly concerning because it means stolen tokens are directly funding the creation of competing AI models.

Why this matters if you build AI applications

If you are shipping any product that makes LLM API calls, you are a potential supply node in this market whether you know it or not. The relay operators are not just stealing keys from individual developers who accidentally pushed credentials to GitHub. They are targeting any unprotected LLM endpoint they can find. That means your internal chatbot, your customer support widget, your RAG pipeline endpoint, or any proxy you have exposed to make your frontend work could be monetized by these resellers if left unprotected.

With Tuqlas, I pass through potentially thousands of API calls per day to LLM providers. If someone compromised one of my API keys or found a way to proxy through my endpoints, they could burn through my spending limits in hours. I have seen it happen to other SaaS builders who wake up to a five-figure bill because their key was in a relay pool for a weekend.

Detection patterns for your SOC

As a Splunk architect who spends most of my day building detection rules, my immediate reaction was to ask: how would I spot this in telemetry? Here are the patterns that indicate your API keys or endpoints are being abused by a relay market:

• Sudden spikes in token consumption outside business hours, especially sustained high-volume usage between 0200 and 0800 in your primary timezone. Relay markets serve global customers, so your keys get used around the clock.
• Geographic diversity in API call origins. If your application only serves users in Southeast Asia but you see API calls originating from Chinese, Eastern European, or South American IPs, your endpoint is being proxied.
• Model usage patterns that do not match your application. If your product only uses GPT-4o but your billing shows Claude 3.5 Sonnet charges, someone is routing other models through your account.
• Abnormally high request concurrency. Relay operators load-balance across many customers simultaneously. If your single-application key suddenly shows 50 concurrent requests when your app typically peaks at 5, that is relay traffic.
• Prompt pattern diversity that exceeds your application's scope. Your chatbot handles customer service queries. If suddenly your API logs show coding tasks, translation jobs, and creative writing, your key is in a relay pool.

Splunk queries for API key abuse detection

I spent part of this weekend writing detection rules specifically for this threat. If you log your LLM API calls (and you absolutely should), these SPL queries will surface relay market indicators.

index=api_logs sourcetype=llm_proxy
| bin _time span=1h
| stats sum(token_count) AS hourly_tokens, dc(src_ip) AS unique_sources, dc(model) AS models_used by _time, api_key
| eventstats avg(hourly_tokens) AS avg_tokens, stdev(hourly_tokens) AS stdev_tokens by api_key
| eval zscore = (hourly_tokens - avg_tokens) / stdev_tokens
| where zscore > 3 OR unique_sources > 10 OR models_used > 2
| sort - zscore
| table _time, api_key, hourly_tokens, unique_sources, models_used, zscore
| rename zscore AS "Anomaly Score"

That query catches three key indicators simultaneously: abnormal token volume (z-score above 3), too many source IPs hitting the same key, and unexpected model diversity. Any one of these in isolation might be explainable. All three together is a strong signal your key is in a relay pool.

index=api_logs sourcetype=llm_proxy
| eval hour=strftime(_time, "%H")
| eval is_offhours=if(hour >= 2 AND hour <= 7, 1, 0)
| stats sum(token_count) AS tokens, count AS requests by api_key, is_offhours
| xyseries api_key is_offhours tokens
| rename 0 AS business_hours_tokens, 1 AS offhours_tokens
| eval offhours_ratio = round(offhours_tokens / (business_hours_tokens + 1), 2)
| where offhours_ratio > 0.5
| sort - offhours_ratio
| table api_key, business_hours_tokens, offhours_tokens, offhours_ratio

This second query identifies keys with disproportionate off-hours usage. If a key is serving your application, usage should roughly follow your user base's active hours. A ratio above 0.5 means the key is getting more than half its traffic during hours when your real users are asleep. That is relay traffic serving other timezones.

Hardening your LLM infrastructure

Detection is only half the equation. Here is what I have implemented for Tuqlas and what I recommend for any AI application that manages its own API keys:

• Per-key spending caps with aggressive limits. Every API key should have a hard daily and monthly spending cap set at the provider level. If your app uses $50/day, set the cap at $75. The relay market only works when keys have headroom to exploit.
• Key rotation on a 30-day cycle minimum. Shorter for production keys handling high-value traffic. If a key leaks, the window of exploitation is bounded by your rotation schedule.
• IP allowlisting at the provider level where supported. OpenAI and Anthropic both support restricting keys to specific IP ranges. If your backend runs on known infrastructure, lock the key to those IPs.
• Request fingerprinting. Log and analyze the structure of prompts hitting your endpoints. Build a baseline profile of what legitimate requests look like (average prompt length, system message patterns, common prefixes) and alert on deviation.
• Rate limiting per source, not just per key. Even if the total request volume looks normal, relay traffic comes from many concurrent sources. Implement per-IP or per-session rate limits on any exposed endpoint.
• Audit exposed endpoints ruthlessly. Any HTTP endpoint that ultimately calls an LLM with your key is an attack surface. Internal tools, staging environments, debug endpoints, webhook receivers that trigger AI workflows. Inventory them all and authenticate every single one.

The broader security implications

What strikes me about this research is how it connects to the broader pattern of AI security incidents this week. We had the OpenAI/Hugging Face model poisoning disclosure, the continued fallout from autonomous AI agents being used in offensive operations, and now a fully operational black market for stolen AI capacity. These are not isolated events. They are the emerging attack surface of an industry that moved to production faster than it moved to security.

The relay market also highlights a fundamental economic problem: LLM inference is expensive enough to steal but difficult to track at the transaction level. Unlike traditional computing resources where you can monitor CPU cycles and network bandwidth with mature tooling, LLM token usage is a new category of resource consumption that most organizations are not monitoring with the same rigor they apply to compute and storage.

Any unprotected LLM endpoint can be monetized by the relay market ecosystem. If your endpoint accepts a prompt and returns a completion without strict authentication and rate limiting, someone is already looking at how to sell access to it.

What LLM vendors need to do

This is not solely a user-side problem. LLM providers need to step up their key hygiene tooling. Right now, most providers give you a key and a usage dashboard. What they should provide is anomaly detection on key usage patterns, automated alerts when keys show relay-like behavior, and the ability to set granular per-key policies beyond simple rate limits. Some providers are better than others here, but none of them have solved it at the platform level.

I would also love to see providers implement key fingerprinting where the provider can detect that a single key is being fronted by a proxy serving multiple distinct users. The traffic patterns are distinguishable if you look at prompt diversity, session continuity, and request timing. Providers have the data to build this. They just have not prioritized it because, frankly, stolen key usage still shows up as revenue on their books until the chargebacks arrive.

Protect your keys like production credentials

The era of treating LLM API keys as low-sensitivity configuration is over. These keys represent direct financial exposure that scales linearly with the attacker's ambition. A compromised database credential at least requires the attacker to find something valuable to exfiltrate. A compromised LLM key prints money immediately by selling access through a relay market.

Treat your LLM keys with the same rigor you apply to payment processing credentials. Vault them. Rotate them. Monitor them. Alert on them. And most importantly, assume that right now, someone is scanning the internet for any endpoint that will accept a prompt and return a completion using your budget.

If you are building detection capabilities for LLM token abuse or trying to harden your AI application infrastructure, I have been deep in this problem all week. Reach out and let us share notes on what works.

Get in touch to discuss AI security and monitoring strategies