Skip to content
@Router-Labs

Router Labs

Router Labs

An AI software company focused on privacy.

The model gets the work. Never the identities.

routerlabs.ai  ·  solrouter.com  ·  Docs  ·  Telegram


Router Labs is the layer between the systems an institution already runs and the AI models it cannot legally hand work to. Every request is routed, recorded, and stripped before it leaves.

We do not train models and we do not sell one. We decide, per request, which model may see your work — and prove afterwards which one did. That distinction is what procurement actually cares about: a data protection officer is not evaluating a model vendor's retention promises, they are evaluating a control you operate, whose failure modes are written down and whose decisions are logged.

Infrastructure is EU-hosted.


1 · Three ways to keep a request private

No single privacy technology is both strong and capable. There are three, they trade off against each other, and which one is correct depends on the request — not on the account. So we run all three and choose per request, taking the least-exposing tier that can actually answer it.

Tier 0 — Pseudonymise, then route out · leaves the boundary

Identifiers are replaced with stable surrogates inside your network, before anything leaves it. The frontier model receives the structure of the work and none of the identities. The mapping table never crosses your perimeter, so re-identification happens only on your side, by you.

Capability Third-party processor Residual risk
Frontier Yes, de-identified Context re-identification

Tier 1 — Dedicated open-weight, in an enclave · stays inside

Open-weight models on hardware reserved for you alone. Nothing pooled, nothing shared with another tenant, no frontier vendor anywhere in the path. Where the workload runs inside a trusted execution environment, the enclave attests to the build it is running before it is given anything to run — so "we cannot read it" becomes a property you can check rather than a promise you have to accept.

Capability Third-party processor Residual risk
Strong Router Labs only Contracted processor

Tier 2 — On premises · never leaves

The model runs on your own machines, inside your own building. We supply the router, the de-identifier and the audit layer. We never supply the network path, because there isn't one.

Capability Third-party processor Residual risk
Moderate None None in transit

2 · What we are building

The orchestration layer

Every request is classified before it is routed. Three stages, all recorded.

Classify — what is in the request. Entity and data-class extraction: special categories under GDPR Art. 9, legal privilege, export-control and PHI markers. Every finding is confidence-scored individually. Low confidence fails closed, never open. Anything unresolved goes to a human rather than to a model. Customer-supplied gazetteers always beat heuristics.

Decide — which rules apply. Jurisdiction × sector × data class × subject, against § 203 StGB, GDPR, HIPAA, ITAR/EAR, DORA, MiCA, SEC 17a-4 and FCA SYSC. Several usually apply at once; all of them are collected, each obligation is reduced to a concrete control, and the most restrictive control wins the tie.

Route — where it may run. The decision produces a set of permitted tiers, not preferred ones. Capability and cost are allowed to choose only inside that set. Overrides require a human and are recorded as overrides. The full decision path is retained as the audit record.

The policy graph is versioned and signed, so the question a regulator actually asks — which rules were in force on a given day — has an answer.

The de-identifier

Tier 0 is only as good as its pseudonymisation pass, so it is worth being precise about what that pass does.

Zero dependencies, and byte-identical in a browser and on a server, so the same code runs client-side in a law firm's browser or server-side in their VPC. Detectors are ordered longest-match-first, so an IBAN is never eaten by a generic number rule. Structured identifiers are validated, not merely matched — IBANs by mod-97, cards by Luhn — which is what keeps the false-positive rate low enough to actually use. Surrogates are stable within a document, so the model still sees that two mentions are the same person. The mapping is reversible, and reversible only where the mapping table lives.

Stated limits, because a de-identifier that oversells itself is worse than none:

  • It removes identifiers, not context. "The Leverkusen client we onboarded in March" identifies a person with no identifier present. No regex fixes that — the tier model does, by never sending that class of request out at all.
  • Person and organisation detection is heuristic. Titles, known-name lists and legal-form suffixes are reliable; bare capitalised words are not. This is why customer gazetteers exist and why they take precedence.

Attestation and proof

An audit record is worth what it would survive. Three things are built to be checkable by someone who does not trust us:

  • Enclave attestation. A TEE-backed route reports its measurement and public key, so a client can confirm which build will handle a request before sending it.
  • A signed, versioned policy graph. The rules that produced a decision can be reconstructed as they stood that day, not as they stand now.
  • A per-request decision record. Which tier, which obligations, which model, and whether a human overrode any of it.

Where a counterparty must verify a run without being shown its contents, those attestation digests can be anchored on a public ledger. The digest is published; the work never is.

Compliance controls

We are not a certification body and we do not certify anyone. We supply the technical controls, records and contracts an auditor asks for — the audit stays yours.

SOC 2 Type II Role-based access, a record of every request and which model answered it, retention you set
ISO/IEC 27001 Supplier control and access management, with written evidence to drop into your ISMS
HIPAA Identifiers removed before the request leaves your network, or the model runs on hardware you control
GDPR Art. 28 Pseudonymisation, EU hosting, deletion on request — measures, not intentions
§ 203 StGB The Abs. 4 undertaking, plus pseudonymisation so plaintext never reaches us
EU AI Act Art. 4 & 50 Dated per-seat training records, and disclosure wording for client-facing use

3 · Solrouter — architecture

Solrouter is the self-serve platform the same technology is built on: encrypted, multi-model AI, with no email and no account. It is not an agent and it does not act on your behalf — it is an inference path that the operator cannot read.

  client                    relay                     enclave
┌──────────┐   ciphertext  ┌──────────┐   sealed    ┌─────────────────┐
│ web app  │ ────────────▶ │ backend  │ ──────────▶ │  Intel TDX      │
│ SDK      │               │ routes,  │             │  open-weight    │
│ MCP      │ ◀──────────── │ meters,  │ ◀────────── │  inference      │
└──────────┘   ciphertext  │ never    │   sealed    └─────────────────┘
                           │ decrypts │
                           └──────────┘

Encryption is client-side. Prompts are encrypted on the device before they are sent. The backend is a blind relay — it authenticates, meters and routes, and never holds the plaintext.

Inference runs in an Intel TDX enclave, hardware-isolated from the machine's operator, against open-weight models only. Privacy mode has no third-party model API in the path at all — no OpenAI, no Anthropic, no Google — because handing a decrypted prompt to a proprietary provider would make the client-side encryption and the enclave worth nothing. Today that is gpt-oss-20b (Apache-2.0, default) and qwen3-8b, running on the Nosana GPU network. The prompt leaves the enclave only as a re-encrypted response.

Authentication is a wallet signature (SIWS). No email, no password, no account record to breach. Usage is metered per call.

Surfaces

Web app The chat client
@solrouter/sdk TypeScript client, encrypted by default
@solrouter/mcp-server The same tools for any MCP client
Agent Privacy API A separate HTTP surface for third-party agents, published as an OpenAPI 3.1 spec and an A2A agent card

Full product reference lives at docs.solrouter.com — this page is the overview, not the documentation.


Open source

router-sdk @solrouter/sdk — the encrypted-by-default TypeScript client
solrouter-docs Documentation source
tempRouter

Working with us

Engagements open with a fixed-scope assessment of the AI tools already in use, because most institutions find their exposure is live and undocumented before we arrive.

Request access →


The obligations named here are orientation, not legal advice.

Popular repositories Loading

  1. solrouter-docs solrouter-docs Public

    Public documentation for Solrouter — verifiable private AI on Solana

    MDX 1 1

  2. router-sdk router-sdk Public

    TypeScript

  3. .github .github Public

    Router Labs organization profile and community health files

  4. tempRouter tempRouter Public

    TypeScript 1

Repositories

Showing 4 of 4 repositories

People

This organization has no public members. You must be a member to see who’s a part of this organization.

Top languages

Loading…

Most used topics

Loading…