The Hidden Cost of Free AI Inference: Model Files as Malware, Prompts as Training Data

Everyone is rushing to open-source models. The token bill on OpenRouter’s free tier is $0. The security bill is not.

The good news first: open weights are a genuine gift. The ability to run a competitive model on your own hardware, without a vendor contract, is a strategic asset every engineering-led business should be building capability around. This post is not an argument against open models.

It is an argument that “free” quietly moves the cost from your P&L to your attack surface and your data - and that two specific failure modes are already showing up in production.

Risk 1: The model file is executable code

Loading a model is not loading data.

The default serialisation formats for PyTorch and much of the open-weights ecosystem - .pt, .bin, anything backed by Python’s serialisation module - run arbitrary Python code when they are deserialised. “Downloading a model” and “running a stranger’s code as the user who ran from_pretrained(...)” are, in those formats, the same operation.

This is not new. It has just stopped being theoretical.

February 2025 - ReversingLabs found models hosted on Hugging Face that used a “broken serialisation” trick to spawn reverse shells on load. The malicious payloads were crafted specifically to bypass Hugging Face’s own scanner. The models loaded, the shell opened, the scanner said clean.

April 2026 - CVE-2026-25874: an unauthenticated remote code execution in Hugging Face’s LeRobot library via deserialisation of an untrusted checkpoint. Any process that loaded a checkpoint could be compromised without authentication.

May 2026 - a repository called Open-OSS/privacy-filter hit #1 trending on the platform in 18 hours. Roughly 244,000 downloads before it was pulled. It was a backdoor - RCE on load. A quarter-million machines, one poisoned file, one social-engineering angle (“privacy filter” is exactly the kind of thing an engineer running an ML pipeline searches for and installs without thinking).

What actually protects you

• Prefer safetensors. The .safetensors format was designed exactly to remove executable code from the model-loading path. Numeric weights only, no serialised Python. Every model your team loads should be a safetensors file unless there is a specific and documented reason it cannot be.
• Load models in an isolated environment. A locked-down container, a separate service account, no access to production secrets. Assume every model file is untrusted code until proven otherwise.
• Pin and hash-verify. Load models by commit hash, not by tag. Verify the SHA against a source you trust. Never pip install and load in the same step.
• Scan before load - but do not rely on the scanner alone. The February 2025 findings prove the scanner can be bypassed. Scan is a filter, not a proof.
• Treat model provenance the same as software supply chain. You would not run an unpinned curl | bash from a random GitHub account. Loading a random legacy-format model is the same operation with a nicer UI.

Risk 2: Free inference is paid in prompts

On zero-cost inference endpoints - free tiers on hosted LLM services, most “community” model routers, most free API keys - the terms of service are explicit about the trade. The provider may use your inputs and outputs to train their own models.

Your source code. Customer PII. Sales pipeline notes. Product strategy documents. Whatever you piped through the free endpoint becomes part of someone else’s training corpus.

The retention is set by the downstream provider, not by the router in the middle. The router does not know what happens to the data after it hands it off. Some downstream providers store prompts for 30 days for abuse review; some store them indefinitely to improve the model.

You are not the customer. You are the corpus.

On a router, the problem compounds - you often do not know which downstream provider is actually serving the free model on any given request. No provenance, no audit trail, no service-level agreement, no data processing agreement, no way to attribute a leak back to a specific party. The router shuffles requests across whoever has capacity, and “whoever has capacity” is a moving target.

What to actually do about it

• Assume any prompt sent to a free endpoint is public. If you would not paste it into a public gist, do not send it to a free tier.
• Read the data-usage clause on every provider you use. Even paid endpoints from major providers vary; the default on “free” is almost always training-eligible.
• Route sensitive traffic through paid endpoints with a signed data processing agreement. The paid tier of the same provider is usually explicitly not training-eligible. That is what you are paying for.
• Self-host the model for genuinely sensitive workloads. Open weights make this actually possible. A quantised model on a single GPU is enough for a large class of internal use cases.
• Isolate customer data from experimentation. Whichever endpoint your engineers are prototyping against on a Friday afternoon should not be able to touch production PII. This is an IAM problem, not a policy problem.

The uncomfortable framing

None of this is about the model being Chinese, or open, or new.

The dangerous property is “free”. Free serialisation formats that also happen to be executable. Free inference endpoints that also happen to be training corpuses. Free routers that also happen to have zero downstream visibility.

The cost has not gone away. It has moved - from your line-item cloud spend to your attack surface, from your token bill to your data governance, from a predictable operational expense to a class of incident you will only see after the fact.

The founder-level question is not “should we use open-source models”. It is: which layer of the stack are we willing to have zero visibility into, in exchange for a lower P&L number this quarter?

Answer that once, deliberately, and the specific tools drop out. Answer it by accident, and you will find out from your incident-response Slack channel which choice you made.

---

Related reading from prior sprints:

• The Self-Correcting Content Pipeline: What 14 Days of Performance-Weighted Auto-Generation Actually Look Like - the strategy piece on why founders should build systems, not just buy tools.

For the operational implementation of these controls in an Australian small business context - model isolation, container hardening, IAM boundaries - the team at Cloud Geeks Insights covers the DevOps and cloud-security layer in depth.

Part of the Ganda Tech Services family. Ash Ganda writes about founder-level technology strategy for Australian small and medium businesses.