Reviewed August 2026
TrustedRouter is an interesting new entrant in the AI infrastructure market. It offers the familiar convenience of a model router, one API for accessing hundreds of models, with provider choice and automatic fallback, but builds the product around a more specific proposition: users should not have to take a router's privacy claims entirely on faith.
That distinction matters. A router sits directly in the path between an application and its model providers. Depending on the application, the data crossing that path might include source code, contracts, health information, internal strategy, customer records, or personal conversations. Most services address this risk through policies, contractual commitments, and security controls. TrustedRouter is attempting to add another layer: technical evidence about the code handling a request.
The result is still a young product, and parts of the experience show it. But the underlying architecture is differentiated enough to warrant a closer look, particularly for teams where privacy, transparency, and control rank above dashboard maturity or advanced routing optimization.
The trust problem hiding inside AI routers
The appeal of an AI router is straightforward. Instead of building and maintaining separate integrations with every model provider, a developer gets one API, one key, and a consistent interface. The router can provide access to more models, shift traffic when a provider has an outage, and help an application take advantage of cheaper or more appropriate models.
The tradeoff is that the router becomes another privileged intermediary. Even if the model provider has acceptable data-handling terms, prompts and responses still pass through the router first. A conventional privacy policy can tell you what the operator says it does with that data; it cannot, by itself, prove which code handled a particular request.
TrustedRouter is built around reducing that gap. Founder Joseph Perla, previously the founder of Hangout.fm and co-founder of Turntable.fm, describes the product as “one API, all the LLMs, provably private.” That claim is more specific than the typical router privacy pitch because TrustedRouter pairs public code with attestation of the production workload.
Why attestation is the most interesting part
TrustedRouter publishes the source code, infrastructure configuration, SDKs, and deployment components involved in the service. More importantly, its production prompt gateway runs inside a confidential computing environment and publishes attestation evidence about the workload that is actually running.
The live Trust page exposes the source commit, container image reference, and measured image digest for the hosted gateway. A customer can fetch fresh attestation evidence from the API, verify its issuer and audience, bind the response to a nonce, and compare the measured digest with the published release.
In practical terms, that provides evidence that the hosted gateway receiving a request corresponds to a specific, inspectable version of the published code.
This is where TrustedRouter differs most clearly from a conventional hosted router. Publishing source code is useful, but source visibility alone does not prove that the hosted service is running that code. Attestation creates a technical link between the public implementation and the production workload.
There are important limits to that guarantee.
TrustedRouter says the gateway does not log prompt or output content. Ordinary synchronous and streaming inference is content-stateless, while billing records retain metadata such as model, provider, token counts, cost, status, and region. The gateway is also designed to fail closed: if the required attestation or gateway contract is unavailable, requests should stop instead of silently moving through an unverified path.
That design is consistent with the product's security model, although it can create an availability tradeoff during incidents.
The company is also fairly explicit about what attestation does not prove. As Perla acknowledges in “Attestation is All You Need”, attestation demonstrates that a measured workload is running the published code. It does not demonstrate that the code itself is free of vulnerabilities.
The hardware-backed attestation chain still has a trust anchor, and sophisticated physical or state-level attacks sit outside the stated threat model. More importantly for most users, TrustedRouter can provide evidence about its own portion of the request path, not the behavior of every upstream model provider. Provider retention policies and confidential-compute guarantees remain separate concerns.
TrustedRouter addresses some of that limitation with explicit routing controls. trustedrouter/zdr limits selection to zero-data-retention providers, while trustedrouter/e2e requires provider-side confidential compute and end-to-end encryption. trustedrouter/eu favors European routes, and trustedrouter/auto prioritizes healthy-provider rollover.
These controls make privacy and routing posture more explicit at the request level, rather than leaving them entirely implicit in account settings or provider selection.
What it is like to use
ModelRouter's first experience with TrustedRouter was straightforward. Signup took two clicks, and sample queries were running through the service within a few minutes.
That ease of use is important because the security model is relatively sophisticated, but the basic developer experience remains familiar.
The API is OpenAI-compatible, so an existing integration can often be moved by changing the base URL and supplying a TrustedRouter key. The company provides a migration guide for OpenRouter users, including a staged approach: swap the endpoint, verify the gateway, measure latency and availability, and then move more sensitive workloads.
Compatibility will never be perfect across every provider-specific edge case, but the basic migration path is low-friction.
The product now offers more than a bare model switchboard. Alongside direct model selection, there are named routes for automatic fallback, zero-data-retention providers, confidential workloads, and EU-focused traffic. Bring-your-own-key support lets teams preserve existing provider arrangements while using TrustedRouter's gateway and routing layer.
The public status page also separates the health of the router itself from the health of upstream providers, which is useful when diagnosing failures.
Observability is built in as well. Broadcast destinations can send metadata to PostHog or an OTLP-compatible webhook, covering fields such as model, provider, token counts, latency, cost, route type, and region. Content export is opt-in and destination-specific.
That separation fits the broader architecture: operational telemetry does not inherently require prompt collection.
Pricing is simple. TrustedRouter currently charges the provider price plus a 5% markup for prepaid text and embedding traffic, with no monthly subscription, and supports BYOK.
Whether that premium is attractive will depend largely on how much value a team places on the additional privacy and verification model compared with competing gateways.
An early product moving quickly
TrustedRouter is functional, but it still feels like a service in an early stage of maturity. The public repository's initial work appeared in May and has already grown to roughly 1,500 commits, with development accelerating markedly in August.
That pace suggests the product is evolving quickly, although rapid development also means buyers should expect the experience and feature set to continue changing.
The review found small interface details that made the product feel young: elements pressing into borders, uneven visual finishing, and pieces of generic or AI-assisted copy in the UI and API documentation.
None prevented use of the service, but the presentation is not yet as polished as more established infrastructure products.
The routing layer also has considerable room to develop. The current privacy, region, provider, and fallback controls are useful, but they are relatively simple compared with where AI routing appears to be heading.
Longer term, the opportunity is richer policy: routing based on measured quality, workload characteristics, latency budgets, cost ceilings, and organization-specific constraints. TrustedRouter already has primitives that could support that direction, but the current product should not be confused with a fully developed optimization engine.
There is also a licensing detail technical buyers should understand. TrustedRouter describes its hosted stack as open source, and the code required to inspect and verify the hosted path is public. The main quill-router repository, however, currently uses the Business Source License 1.1.
Inspection, audit, and non-production evaluation are permitted, while production use requires a commercial license, with each version scheduled to convert to Apache 2.0 after four years.
That does not undermine the attestation mechanism, but “source-available” or “publicly inspectable” is currently a more precise description of the repository than unrestricted open source.
Enterprise readiness is still developing as well. TrustedRouter publishes legal, subprocessor, DPA, BAA, and security-readiness material, but its Trust page states that a SOC 2 report has not yet been obtained.
Teams with formal procurement requirements will therefore need to evaluate the current documentation, agreements, architecture, and threat model directly. Technical attestation is useful, but it is not a substitute for every conventional compliance or governance requirement.
The company's willingness to document these boundaries is a positive sign, but buyers should still evaluate the product based on its current capabilities rather than its intended direction.
Who should consider TrustedRouter?
TrustedRouter is most compelling for teams that want the flexibility of a multi-model gateway but are uncomfortable routing sensitive traffic through another opaque intermediary.
Legal technology, healthcare applications, security products, developer tools, internal enterprise assistants, and systems processing proprietary data are obvious use cases to investigate.
It may also appeal to technically sophisticated teams that want to inspect the request path, bring their own provider keys, or choose privacy constraints per workload.
The OpenAI-compatible interface makes a limited pilot relatively easy: migrate a non-critical endpoint, verify the attestation flow, compare latency and availability, and determine whether the operational and privacy benefits justify broader adoption.
Teams that primarily want the most mature dashboard, the broadest enterprise ecosystem, or advanced automated cost-and-quality optimization may find more established alternatives stronger in those areas today.
And teams subject to strict compliance regimes should review the upstream providers, licensing, agreements, and current certifications independently. No router eliminates the need to understand the rest of the AI supply chain.
Verdict
TrustedRouter is a technically differentiated entrant in the AI routing market.
Its most interesting contribution is not putting hundreds of models behind one endpoint. Several products already do that. The more unusual idea is treating the router itself as part of the AI security perimeter and giving customers technical evidence about the workload handling their requests.
That approach addresses a real weakness in conventional hosted gateways, where users generally have limited ability to verify the software running between their application and the underlying model provider.
There are meaningful tradeoffs.
The product is young, the interface still needs polish, routing sophistication is relatively limited, and enterprise compliance maturity is still developing. Attestation also does not eliminate trust elsewhere in the inference chain, particularly at the underlying model provider.
For teams where privacy and verifiability are unusually important, those tradeoffs may be worth accepting, and TrustedRouter belongs on the evaluation list.
For teams primarily optimizing for routing intelligence, product maturity, or enterprise certifications, the decision is less obvious.
The broader idea may ultimately prove more important than the product itself. If confidential computing and production attestation become practical enough to deploy routinely, customers may eventually expect AI gateways to provide stronger evidence about how their data is handled rather than relying exclusively on contractual assurances.
TrustedRouter offers an early example of what that model can look like.
