Dev.to Security 🔐 Cybersecurity 👁 0 📖 6 min read

Official vs relay LLM gateways: risks and how to spot them

Official vs relay LLM gateways: risks and how to spot them An OpenAI-compatible chat.completions call looks the same whether you are talking to a first-party API, a documented multi-model router, or an unofficial relay

Official vs relay LLM gateways: risks and how to spot them

An OpenAI-compatible chat.completions call looks the same whether you are talking to a first-party API, a documented multi-model router, or an unofficial relay. The SDK will still return a string. The operator, the privacy policy, the logging and the way a free tier ends all belong to the service behind the base URL, and those are not the same.

This article uses the classifications and published fields from the 12 November 2026 snapshot on Free LLM API Tokens. I will not invent a logging policy for a site that does not publish one, and I will not treat a large tokens-per-day figure as a security control.

Three kinds of service, not two

Official provider, in that tracker's data, means a model maker or a cloud that offers the API under its own name and documentation. You create an account with that organisation and, typically, call a base URL on its domain. Groq, Google's Gemini API, Cloudflare Workers AI, Mistral, SambaNova and Cerebras are official examples in the current list.

Gateway is broader. A gateway sits in front of one or more models — sometimes its own, often someone else's — and gives you a single key and a single request format. Both official providers and gateways can be OpenAI compatible. Both can have a free allowance. They are not the same kind of dependency.

Relay warning is a separate flag. It marks unofficial resellers or unclear operators. Do not treat every gateway as a relay, and do not treat every official row as a permanent free plan. Of the 112 providers in the 12 November snapshot, 37 were classified official and 75 as gateways, and 47 carried a relay warning.

The comparison is written up at more length in the site's guides on official providers vs gateways and relay and gateway risks.

Why the distinction matters if the code is identical

With an official API you can usually find a legal entity, a status page and a written data policy. You still have to read that policy. "Official" is not a synonym for "will not train on my prompts" or "will stay free." The Gemini API entry, for example, records that free-tier prompts may be used to improve Google products. Official free credits also end: the same snapshot records that Hugging Face's free monthly inference credits had ended, and that Fireworks AI's signup credit had been removed.

With a documented gateway you must also ask where the model runs and who may store the prompt. A well-known example in the list is OpenRouter. It is recorded as a gateway (not official), OpenAI compatible, with a documented base URL of https://openrouter.ai/api/v1. The published free allowance is :free models, with a limit of 50 requests per day until credits are bought, and no card required. The notes say free-model providers may log prompts. That is a documented trade-off, not a hidden one, and it is a reason to keep private data out of :free routes even without a relay flag.

With an unofficial relay you may not get a clear answer at all. The site may present a long model list and a generous free allowance without saying where the request actually goes. A model name can be mapped to a different model than the one you expected. A free cap can disappear. A domain can change. Billing disputes and abuse reports are harder when the operator is unclear.

What a relay can see

Your prompt, system instructions and any files you attach may be visible to the relay operator, and may be logged or reused. The operator may also send that text to a third-party model host with its own logging policy. If you pasted customer data, private source code, or an API key inside the prompt, you have now shared it with at least one extra party.

A relay can also collect your API keys if you are asked to paste a key from another provider into their dashboard so they can "bring your own key." That is a different, higher risk than using a key they issued for their own endpoint: you are trusting them with a credential that can spend money or read projects on the first-party account. A tracker should never ask you for a key. If a site does, stop.

How to read the public signals

You do not need a private investigation to do a first pass. Look at:

  • Who is named as the operator, and whether a company or legal entity is published
  • Whether the docs live on that organisation's domain
  • Whether the product is described as a router in front of other APIs
  • Whether routing and logging are explained, including for free routes
  • Whether a card, a phone check or a trial end date is published
  • Whether the base URL is a typo-squatting lookalike of a well-known host

Then read the tracker's badges as a set, not as a recommendation: official or gateway, relay warning or not, OpenAI compatibility, the written allowance, and whether a card is required. No single badge means "safe." Absence of a warning is not a certification.

A large tokens-per-day number does not offset the risk

A published cap is a usage number, not a security control. In the 12 November snapshot, some of the highest daily figures belonged to relay-flagged gateways. NaraRouter and Flexlora were both recorded at 7 million tokens per day, both as gateways, both with a relay warning. APInex was recorded at 3 million tokens per day, also a relay-flagged gateway. Those rows are useful if you are comparing advertised allowances. They are a poor default for private data.

By contrast, an official no-card tier can look small next to those numbers and still be the better default for learning or for private prompts. Groq's published allowance in the same snapshot was 200,000 tokens per day and 1,000 requests per day on listed models, with no card required. "Smaller advertised cap, clearer operator" is often the right trade.

Card requirements appear in both categories. A card-backed official trial can be more constrained than a no-card official free tier with a smaller published number. Cerebras, for example, publishes 1,000,000 tokens per day during a $5, 30-day trial, with a card required. Compare the sentence in the allowance field, not only the category badge.

If the card field is "Unspecified" or "Not published", do not treat that as "no card."

What you should never send through a flagged relay

Do not send anything you would not be willing to post in a public forum. In particular:

  • API keys, passwords, cookies, or private tokens, including keys for other providers
  • Customer records, health, financial or government identifiers
  • Confidential source code, unreleased product plans, or internal documents
  • Personal data about other people
  • Content that the upstream provider would forbid

If your workflow needs those inputs, use an official provider whose policy you accept, a contract that matches your requirements, or a model you run locally.

If you still want to try a gateway

Use a throwaway prompt and a key that exists only on that site. Do not reuse a production key. Do not point a production app at a new base URL until you have read the terms and privacy policy. Prefer HTTPS base URLs copied from official docs or from a list that only repeats published endpoints. Revoke the key when you are done experimenting.

A first "hello world" request is enough to test compatibility. It is not a reason to point your main repository at that base URL.

If you later migrate from a gateway to an official API, and both are OpenAI compatible, keep the application code and change the environment: key, base URL, and model id. Test streaming, tools and JSON output, because they may differ even when a basic chat call works.

The safe default is the same in every case: treat undocumented routes as public, keep keys in environment variables, and confirm terms on the official page before you rely on a free tier.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.