Bring your own on-prem model
An Enterprise deployment can attach your own network-hosted inference endpoint as a second evaluator. The on-device model stays primary, the endpoint is reached over pinned TLS, and if it fails the decision falls back to the local model. This page is the operator's configuration reference.
What it is
Your endpoint runs alongside the on-device model, never instead of it:
- Always dual: the on-device model stays present and primary; your endpoint is a second evaluator under a local-primary, on-prem second-model policy.
- Enterprise only, and available in Cloud mode and Private mode alike: a Cloud device can point its second evaluator at an on-prem endpoint just as a Private deployment can.
- Your environment keeps everything: because you host the model, its weights and the evaluated content never leave your network.
What you provide
The endpoint and its trust anchor are part of your deployment profile. The URL, the certificate pin and the auth references travel in the signed claim; the secret material itself stays on the daemon host.
| Field | Purpose |
|---|---|
| Endpoint URL | HTTPS URL of your inference server on your network. Must be https://. |
| TLS pin (SHA-256) | SHA-256 of the endpoint's server leaf certificate, 64 hex characters. Mandatory: it is the only trust anchor, so no PKI or CA chain is needed. |
| Bearer token (optional) | Sent as an Authorization: Bearer header on every request. |
| Client certificate (optional) | Enables mutual TLS, a second bidirectional layer. |
The onprem.secret file
The secret material lives in an owner-readable onprem.secret file in the daemon data directory, held encrypted at rest and decoded only in memory for the request. It is refreshed at check-in, so rotating a credential applies at the next check-in without a daemon restart. It carries two fields:
| Field | Purpose |
|---|---|
bearer | The bearer token value placed in the Authorization header. |
clientCertPem | PEM bundle holding the client certificate and key for mutual TLS. Omit it to run without mTLS. |
What your endpoint receives
Each evaluation is a single HTTPS POST. The payload is the same minimal projection Cloud mode sends: the file path and a redacted, added-only unified diff, never the full file.
{
"path": ".../CLAUDE.md",
"unified": "@@ ... @@\n+added line, redacted"
}What your endpoint must return
Answer HTTP 200 with a JSON object carrying the graded danger value on a 0 to 1 scale. Two optional fields are read if present:
| Field | Type | Meaning |
|---|---|---|
danger | number | The graded danger value in the range 0 to 1. Required. |
reasoning | string | A short reason string. Optional. |
category | string | The attack category. Optional. |
{ "danger": 0.02, "reasoning": "...", "category": "benign" }Transport and security
- HTTPS only, TLS 1.2 or newer; the daemon opens no inbound port.
- The server certificate is checked against your pin on every connection; a certificate that does not match the pin is rejected before any request is sent.
- The PKI chain is not consulted: the pin alone authorizes the endpoint.
- Optional mutual TLS: when a client certificate is configured, the daemon presents it.
- Each request carries a bounded timeout (20 seconds).
Fail-closed behavior
Read next
What leaves the device for evaluation, redacted and added-only: what Cloud mode sends. The daemon egress surface: network and firewall requirements.
Your model, your network, your content.
The on-device model stays primary and the arrangement is always dual and fail-closed. An Enterprise capability.
Sign me up