TrustedRouter

When a procurement process requires a current SOC 2 Type II report or specific ISO certifications.

• The vendor references SOC 2 readiness; a completed SOC 2 report was not located in the public sources reviewed for this research.

When the procurement requirement is for end-to-end confidentiality guarantees that explicitly cover both the gateway and downstream providers for all traffic.

• The gateway attestation covers the gateway workload; downstream provider retention and confidentiality behaviors need to be evaluated and selected per route/policy.
• User-provided models are routed outside the attested boundary and are not covered by zero-retention claims.

When a purely self-hosted architecture is required.

• Self-hosted gateways (for example, LiteLLM or other open-source options) are more appropriate when full infrastructure control is a hard requirement.

When default, rich payload logging is required for debugging and analytics.

• TrustedRouter's design posture of minimizing prompt/output logging reduces out-of-the-box payload-level observability compared with gateways designed for extensive logging and analytics.

Current limitations acknowledged by the vendor

• User-provided model endpoints are not attested and thus are outside the scope of the gateway attestation and zero-retention assertions.
• TLS termination requirement: TLS must terminate inside the measured workload to preserve the vendor's attestation model; this can complicate conventional CDN/WAF termination patterns.

Features on the roadmap (not yet available)

• No explicit dated roadmap items were located in the public sources reviewed during this research.

Scale limitations

• No independent load testing or third-party scale testing results were located in the sources reviewed for this research.

Security or compliance gaps

• SOC 2 report was not publicly available at the time of this research; public ISO certification records were not located.

Technical debt or architectural limitations mentioned in public sources

• The attestation model places constraints on network architecture and certain enterprise deployment patterns.

API limitations or integration constraints

• The trust model requirement that TLS terminate within the measured workload can complicate enterprise networking patterns that rely on external TLS termination.

Distinguishing technical attributes supported by public documentation

• Published attestation artifacts and published image digests/commits intended to enable independent verification of the gateway workload.
• Explicit route-level privacy labels and routing aliases for distinct operational postures (for example, zero data retention routes and EU-focused routing).
• A documented requirement that TLS terminate inside the measured workload to preserve the intended evidence model; this is a strong security posture but is constraining for certain network architectures.

Limitations of unique selling point claims

• Limited independent customer feedback was identified in public review platforms during this research; unique selling point characterization is therefore primarily based on product architecture evidence and vendor disclosures rather than broad third-party validation.

• Claims include very large token volumes routed in the first month and substantial volumes of documents, pages, and case insights processed.
• A customer-attributed quote emphasizes the importance of not relying on unaudited promises about data access. The case study notes that reported counts came from the customer's production database and that token volumes were cross-checked against metadata-only usage records.
• Critical evaluation: This material is vendor-hosted and should be treated as a vendor-provided case study unless independently corroborated.

Claimed results (as reported by the vendor): a large number of documents processed across multiple active matters, hundreds of thousands of pages analyzed, a substantial number of case insights generated, and high token usage in initial production.

Implementation notes (vendor-provided): base URL migration with API calls formatted for a specific third-party LLM provider, use of a mixed-model strategy to balance cost and performance, and selection of privacy-focused routing for sensitive tasks.

Critical evaluation: The case study relies on vendor-reported metrics and includes a measurement note indicating internal cross-checks. These elements increase plausibility but do not replace independent third-party verification.

• Software developers building agentic applications that require access to multiple models
• Teams with sensitive data constraints (legal, healthcare, regulated workflows) that prefer a hosted routing layer over a fully self-hosted proxy