Who Sees Your Prompts on the Way to the Model?
Somewhere between your application and the AI model answering it, there may be a company you never evaluated. Model aggregators, with OpenRouter as the biggest, now sit in the path of a massive share of the world's AI traffic, and every request that goes through one crosses two administrative boundaries instead of one. We call that second boundary the second hop, and almost nobody audits it. The verdict up front: aggregators are legitimate infrastructure with better privacy defaults than their critics claim, and they're still the wrong permanent home for sensitive workloads, because the real exposure lives in what they route to, not in what they store.
What does a model router actually do?
It gives you one API and one bill in exchange for standing in the middle of every request.
An aggregator puts hundreds of models behind a single endpoint. Swapping models becomes a one-line change, and every new release lands there within days, which is exactly why developers love it. It's also where much of the market goes to try the open-weight wave: the usage rankings on these platforms have become the industry's scoreboard, and Chinese open-weight models like Moonshot's Kimi family have gone from a rounding error to nearly half the traffic in about a year. So if your teams are experimenting with Kimi or DeepSeek right now, there's a good chance those requests transit an aggregator, and a better chance nobody in your company decided that on purpose. The convenience is real. So is the middleman.
What is the second hop?
It's the administrative boundary your data crosses that never showed up in a vendor review.
Trace one request. Your application sends a prompt to the router. The router forwards it to whichever downstream company is hosting the model you asked for. Two separate parties handle the prompt, each under its own terms, which means your effective privacy policy is the union of both policies, and most companies have read neither. We've written before about the prompt trail, the record your AI usage leaves at every provider that touches it. The second hop lengthens that trail by one party on every single request. And unlike your model vendor, the party in the middle rarely went through procurement. It arrived through a developer's convenience decision, usually a perfectly sensible one, made long before anyone asked what data would eventually flow through it.
Aren't the router's defaults private enough?
They're better than most critics assume, and they're beside the point.
Credit where it's due: the biggest aggregator doesn't store prompt or completion content by default and keeps only request metadata. It also offers filters that restrict routing to zero-retention providers or exclude ones that train on inputs. Configured deliberately, it's a defensible piece of infrastructure. The exposure hides in four places the defaults don't cover. First, the same model name is served by many different hosts, and the router picks one per request based on price and speed, so the company handling your data can change between Tuesday and Wednesday without anything changing on your end. Each host has its own retention policy and its own jurisdiction. Second, the opt-ins: discounted usage in exchange for prompt logging, and free endpoints that may train on inputs or even publish prompts. One developer flipping one toggle changes your company's data posture. Third, configuration lives in a dashboard owned by whoever opened the account, which is rarely the person accountable for data governance. Fourth, concentration: a single third party in the path of everything your company asks every model is a rich target and a single point of trust, however well it behaves today.
When does an aggregator stop being defensible?
The moment prompts start carrying data you'd have to report losing.
This is a consequence-line call, the same sort we apply to model choice. For experimentation, evals, prototypes, and anything built on public or synthetic data, an aggregator is arguably the best tool available, and pretending otherwise would be theater. Customer records, contracts, source code, financials, health data, and internal strategy are a different matter. The middle party can run a tight ship and it still won't save you in a compliance review, because you can't attest to a data path you didn't choose. When an auditor or a customer asks where their data went, "to one of several hosting companies, selected per request by a routing algorithm we don't control" is an answer that ends deals. The question for your team is simpler than trust: can you document the path?
Should you build your own router instead?
For anything past the consequence line, yes, and it's a smaller build than it sounds.
A thin routing layer you own keeps the convenience that made aggregators popular, one interface and swappable models, while replacing the data path entirely. Your infrastructure calls each provider directly, under contracts you signed and keys you hold, with data terms you verified once, at setup, instead of per request. This is the bottom rung of the control ladder and the working half of swap-ready architecture: model choice becomes a config change, and there's no third party standing in the traffic. The trade is honest. You maintain a handful of provider integrations, and you give up day-one access to every new model that drops. What you get back is an attestable path and routing rules that follow your consequence line rather than a price-and-speed algorithm. We build these for clients in weeks, not quarters. The move is small. Knowing it exists is most of the battle.
What should you do this month?
Four steps, in order. First, inventory: find every workload with an aggregator in its path, which takes one afternoon of checking API base URLs. Second, lock the account you already have: zero-retention routing on, training-permitted and free endpoints off, logging discounts declined, dashboard access limited to people accountable for data. Third, classify each workload against the consequence line, because most of what you find will be fine where it is. Fourth, stand up a thin router of your own and move everything past the line behind it, leaving the aggregator to do what it's genuinely great at: cheap, fast experimentation on data that was never sensitive to begin with.
If you want the second hop out of your sensitive workflows and a routing layer you actually own,
learn about our AI Blueprint or reach us at contact@theyor.com