Access to cheap and abundant inference is incredibly powerful for cyber operations. Adversaries across the world know this as it removes two limits that matter a lot to them: cost and attribution. We call this Living off Someone Else's Inference and have built a tool called infreerence to showcase how it works.
This article is part of Sentry's AI Security work. The objective is to help lay out why protecting inference infrastructure is so important, showcase how vulnerable the AI/LLM ecosystem on the internet is, how adversaries automate and harvest free inference at scale, and give you the tools to help protect your organization. Lastly, it showcases infreerence, the reconnaissance engine that we built to help red and blue teamers. You can use the tool to find exposures on your own organization.
This research was done by Armend Gashi and Redon Gashi and presented at DEF CON 34 Creator Stage for Recon Village, the Red Team Village, and Adversary Village.
What "free inference" means? #
Inference is becoming an important commodity used for all kinds of cyber-related work. It's resource-intensive and requires lots of GPU and other compute power. Adversaries need compute time and must pay up for it one way or another, which translates into either a metered API bill, cloud, or they must pay for the hardware and the electricity of self-hosted models. Access to bountiful compute is becoming more and more important to both adversaries and defenders, and therefore finding cheap or free reliable inference is a strategic step in contemporary killchains.
Is there such a thing as truly free inference? We think so!
Here is the definition for the purposes of this blog:
Free inference occurs when a different party pays inference costs and you keep the output. The name of our tool is a portmanteau: in-free-rence. Ha!
We researched two conditions that produce free inference:
- Exposed and vulnerable self-hosted inference servers. In the last two years, developers installed model servers on their laptops and devices. Many of these servers then appeared on public IP addresses. Examples are Ollama, llama.cpp server, LiteLLM proxies, vLLM, LocalAI, and an Open WebUI installations. However, in many cases these inference servers are left unprotected and internet facing. Any person who finds these servers can send prompts to them and jack them.
- Leaked provider credentials. The second condition is leaked credentials. We find valid
OPENAI,ANTHROPIC, or Moonshot/Kimi keys committed in.envfiles, configuration files, or a public repositories. In many cases, the capacity is frontier-grade inference.
This supports some of the same conclusions as our report on the PCC path traversal and security testing we've done over the last two and a half years: the important AI security failures are usually not failures of the model itself, rather that they are failures of the pipeline and the environment around the model.
Why free inference is a high-value target? #
Free inference has incredible value. Whether you believe LLMs are slot machines or powerful augmentors, it's hard to imagine a contemporary killchain without AI being used to increase its scale, speed, sophistication, or scope. In fact, we believe reliable inference is a persistence multiplier for cyber operations, but that's another blog post. Stay TUNED!!
In this part of our research, we focus on two specific value-adds for adversaries.
1. Attribution
When you send inference through a victim's key, or through an anonymous exposed server, you take the victim's identity and potentially hide your own. The provider's request logs, the abuse-detection rules, the rate-limit counters, the payment record, and the subsequent ban all apply to the account holder. If you have access to hundreds of compromised models, then you're able to rotate inference and always have a steady, uninterrupted supply of hard-to-attribute compute.
This changes the risk of every model-assisted task that would otherwise incriminate adversaries. Such tasks include the composition of phishing messages, iterative development of malware, and many other applications. If an attacker does this work on a funded account, the attacker creates a complete evidentiary record. The provider's safety tooling also flags the account and usually stops the service.
You do not have to take our word that attackers optimize for this. Sysdig analyzed such operations, especially utilizing the OAI reverse proxy, which is the software that supports the stolen-key economy. Free inference supplies free compute and free anonymity, and the anonymity is often a plus for adversaries.
2. Cost
Inference is expensive at volume, and offensive automation consumes volume. Examples include FUD malware generation, vulnerability research, exploit development, etc. The token bill for this work is a real limiting factor. If a different party pays the bill, the limit disappears! The activity became sufficiently large that in early 2025 Microsoft started taking action against a group that it tracks as Storm-2139. That group operated a business across Azure OpenAI and all the other major providers.
A wombo combo
Low cost and anonymity together already make a strong product for resale. The change in 2026 is that attackers now build with free inference. In June 2026 Sysdig documented a new case. An attacker used misconfigured Ollama servers as the reasoning core of an autonomous offensive pipeline. The pipeline scanned, exploited, and compromised targets with no human operator. This is the direction of the trend, and we're sure there are more examples in the wild.
The exposure is large! #
We ran infreerence in the wild to test the waters and found 5k vulnerable inference endpoints with access to 20k+ models of various model families.
infreerence #
infreerence is a reconnaissance engine for internet-exposed AI infrastructure. It performs the complete discovery workflow that an attacker uses to find free inference, but it does this as a measurement tool for defenders. You point it at your own IP ranges and your own repositories, and you see what an attacker sees. It answers the two important questions in order:
-
Is there exposed inference at this location?
-
Does that inference work?
The tool covers both conditions in one:
- Exposed services : the
inferencefinding. - Leaked credentials : the
keysfinding.
Both findings share the same history, the same inventory, and the same verdicts. If a target supplies free inference, infreerence records it and lets you know!
How the tool finds things?
The design is familiar if you have written Nuclei templates. A template is a portable YAML description of one item that is worth a search. It connects a search query to a source, and it adds an optional probe that runs against each result:
id: ollama-running
info:
name: Exposed Ollama LLM Inference Server
description: Detects internet-exposed Ollama servers ("Ollama is running").
tag: inference
family: ollama # the provider (vendor) this targets
queries:
- source: shodan
query: '"Ollama is running"'
verify: ollama # post-discovery probe
A provider collects the templates for one vendor, such as Ollama, LiteLLM, or vLLM. A source is the search engine which we usually power with Shodan but will introduce compatibility for Censys, Google, and GitHub. A cool thing is that a new source does will not require changes to the templates. Lastly, A verifier is the component that gives the tool its value. After a source returns results, infreerence probes each host and decides whether the host is genuine or some sort of honeypot.
The supplied templates already cover Ollama, llama.cpp, LiteLLM, OpenRouter, vLLM, LocalAI, and Open WebUI. Each template has a verify hook. Feel free to add more!
Verifying inference
We built infreerence so that inference verifiers run the full chain: authentication, then model enumeration, then a live chat probe, then a honeypot score.
The score step is necessary on the internet, because many exposed inference proxies are honeypots. An inference honeypot emulates the API and answers any prompt, in order to waste the time of a scanner and to corrupt its results. infreerence gives every open host a score of likely_real, suspicious, or likely_honeypot. The score uses signals that are difficult to falsify:
- A genuine server refuses an unknown model . A honeypot answers as that model.
- A genuine chat response contains token-usage counts (
eval_count,completion_tokens). Many honeypots omit these counts. - A product fingerprint endpoint answers in the same way as the genuine product.
- The tool compares the response against a catalog of known honeypot replies and flags a match.
Not perfect but it does the job.
Each finding shows a 🍯 badge and a honeypot summary. The tool also keeps a honeypot memory: after it flags a honeypot, it does not probe that host again. If you have run a large inference sweep manually, you know that this step consumes most of your time. Because the tool does this work, it gives you a list of working inference endpoints.
Leaked keys, attributed by acceptance
Infreerence checks does this credential still authenticate, and which provider issued it? The important design decision is that the provider comes from validation. infreerence detects the OpenAI shapes (sk-, sk-proj-, sk-svcacct-, sk-admin-), the Anthropic shape ( sk-ant-), and the Moonshot/Kimi shape ( sk-). It then asks each provider whether the key works using a minimal token number request.
We had to build a verifier for multiple reasons. For example, Moonshot issues keys in the exact classic OpenAI format. Therefore the tool offers a same-shaped key to both providers, and attributes the key to the provider that accepts it.
scanning owner/name for provider API keys …
openai WORKS sk-proj-…4f2a .env:3
moonshot WORKS sk-QHhFG…fsJr .env:7
anthropic dead sk-ant-a…9xQz src/config.py:12 (+1 more)
3 key(s) found · 2 working
The verdicts are WORKS, dead, and unconfirmed. A rate-limited 429 response counts as a working key, because the credential was valid enough to receive a throttle. This portion of the tool can be a little janky but it works out.
From a finding to a running agent
Here's the cool part.
infreerence converts a confirmed endpoint into configuration text that you can paste into real tools. The infreerence integrations command produces this configuration for generic OpenAI clients, curl, opencode, Codex, Gemini CLI, and Claude Code. Ollama, llama.cpp, LiteLLM, LocalAI, and vLLM all expose an OpenAI-compatible /v1 interface, so many endpoints connect directly. For the other endpoints, the tool writes a LiteLLM bridge that is ready to run.
To connect Claude Code to a discovered gateway, you need this much configuration:
unset ANTHROPIC_API_KEY # never send your real key to the target
export ANTHROPIC_BASE_URL="http://<HOST>:4000" # the discovered endpoint
export ANTHROPIC_AUTH_TOKEN="not-needed"
export ANTHROPIC_MODEL="claude-opus-4.5" # a model the host actually serves
export ANTHROPIC_SMALL_FAST_MODEL="claude-haiku-4.5"
claude
How to work with the results
The tool keeps all results in one place. infreerence scan <provider> searches and verifies, and it shows a live progress bar. scans and show display the history. loot is the inventory across all scans of everything that works. It shows live endpoints and valid keys together, and it colors the models for viewing pleasure!
Green shows a working model, red shows a failed model, amber shows a slow model, and plain text shows an untested model. serve starts a web interface and an API with a template editor, a scan launcher, and a streaming chat against a discovered model.
To do: Better honeypot detection: SLMs that impersonate an LLM
Honeypots are becoming more capable with the adoption of SLMs. Such a honeypot answers arbitrary prompts fluently, reports plausible usage numbers, never repeats a fixed string, and passes every known-reply check. It looks genuine because, in a limited sense, it does respond.
The detection method must therefore change. You cannot run a 200-prompt benchmark against every open host on the internet otherwise we're doing damage. We want a small probe set with high information content, ideally one or two requests. A truly capable model must pass this probe set, and a 3B substitute must reliably fail it. It's something we're thinking about but don't have a valid solution.
System-level signals also help and they are difficult to falsify. A server that runs a small model cannot reproduce the throughput and the time-to-first-token profile of the frontier model that it impersonates. Our work on the PCC inference telemetry showed that per-token timing and draft-token counts may reveal speculative-decoding behavior, and therefore indicate the size and capability model. Interesting to explore, for now it's just hypothesizing.
Use the tool only on your own systems #
By default this tool sends real HTTP requests to live hosts. Verification of an inference endpoint requires a real chat completion, and that completion consumes another party's tokens, albeit minimal. Run the tool against your own infrastructure, or against an environment that you have explicit authorization to test. Do not run it anywhere else.
Why this is urgent #
Every organization is moving inference capacity into production with sometimes it being hard to protect. Exposed inference servers and leaked provider keys are the natural result of that speed. Find where your inference is exposed, find where your keys have leaked, and close both before another party finds the margin. Use infreerence to take the inventory.
infreerence is open source (MIT). The code, the wiki, and the full command reference are on GitHub.
This is part of Sentry's AI Security research, run through SARC*, the Sentry Applied Research Center. Find more at* blog.sentry.security*.*