Eigenes On-Prem-Modell einbinden
Ein Enterprise-Deployment kann Ihren eigenen, im Netz gehosteten Inferenz-Endpunkt als zweiten Bewerter einbinden. Das Modell auf dem Gerät bleibt primär, der Endpunkt wird über gepinntes TLS erreicht, und fällt er aus, fällt die Entscheidung auf das lokale Modell zurück. Diese Seite ist die Konfigurationsreferenz für Betreiber.
Worum es geht
Ihr Endpunkt läuft neben dem Modell auf dem Gerät, nie an seiner Stelle:
- Immer dual: Das Modell auf dem Gerät bleibt vorhanden und primär; Ihr Endpunkt ist ein zweiter Bewerter unter einer Richtlinie lokal-primär, On-Prem-Zweitmodell.
- Nur Enterprise, und gleichermassen in Cloud-Modus und Private-Modus verfügbar: Ein Cloud-Gerät kann seinen zweiten Bewerter genauso auf einen On-Prem-Endpunkt richten wie ein Private-Deployment.
- Ihre Umgebung behält alles: Weil Sie das Modell hosten, verlassen dessen Gewichte und der bewertete Inhalt Ihr Netz nie.
Was Sie bereitstellen
Der Endpunkt und sein Vertrauensanker sind Teil Ihres Deployment-Profils. Die URL, der Zertifikat-Pin und die Auth-Referenzen reisen im signierten Claim; das Geheimmaterial selbst bleibt auf dem Daemon-Host.
| Feld | Zweck |
|---|---|
| Endpunkt-URL | HTTPS-URL Ihres Inferenz-Servers in Ihrem Netz. Muss https:// sein. |
| TLS-Pin (SHA-256) | SHA-256 des Server-Leaf-Zertifikats des Endpunkts, 64 Hex-Zeichen. Pflicht: Es ist der einzige Vertrauensanker, eine PKI- oder CA-Kette ist nicht nötig. |
| Bearer-Token (optional) | Wird bei jeder Anfrage als Authorization: Bearer-Header gesendet. |
| Client-Zertifikat (optional) | Aktiviert Mutual TLS, eine zweite, beidseitige Schicht. |
Die Datei onprem.secret
Das Geheimmaterial liegt in einer nur für den Eigentümer lesbaren Datei onprem.secret im Daten-Verzeichnis des Daemon, at-rest verschlüsselt und nur für die Anfrage im Speicher entschlüsselt. Es wird beim Check-in aufgefrischt, sodass eine Rotation beim nächsten Check-in ohne Daemon-Neustart greift. Sie trägt zwei Felder:
| Feld | Zweck |
|---|---|
bearer | Der Bearer-Token-Wert im Authorization-Header. |
clientCertPem | PEM-Bündel mit Client-Zertifikat und Schlüssel für Mutual TLS. Weglassen, um ohne mTLS zu fahren. |
Was Ihr Endpunkt empfängt
Jede Bewertung ist ein einzelnes HTTPS-POST. Die Nutzlast ist dieselbe minimale Projektion, die der Cloud-Modus sendet: der Dateipfad und ein redigiertes, nur-hinzugefügtes Unified-Diff, nie die ganze Datei.
{
"path": ".../CLAUDE.md",
"unified": "@@ ... @@\n+hinzugefügte Zeile, redigiert"
}Was Ihr Endpunkt zurückgeben muss
Antworten Sie mit HTTP 200 und einem JSON-Objekt, das den abgestuften Gefahrenwert auf einer Skala von 0 bis 1 trägt. Zwei optionale Felder werden gelesen, falls vorhanden:
| Feld | Typ | Bedeutung |
|---|---|---|
danger | number | Der abgestufte Gefahrenwert im Bereich 0 bis 1. Pflicht. |
reasoning | string | Eine kurze Begründung. Optional. |
category | string | Die Angriffskategorie. Optional. |
{ "danger": 0.02, "reasoning": "...", "category": "benign" }Transport und Sicherheit
- Nur HTTPS, TLS 1.2 oder neuer; der Daemon öffnet keinen eingehenden Port.
- Das Server-Zertifikat wird bei jeder Verbindung gegen Ihren Pin geprüft; ein Zertifikat, das nicht zum Pin passt, wird abgewiesen, bevor eine Anfrage gesendet wird.
- Die PKI-Kette wird nicht herangezogen: Allein der Pin autorisiert den Endpunkt.
- Optionales Mutual TLS: Ist ein Client-Zertifikat konfiguriert, präsentiert der Daemon es.
- Jede Anfrage trägt ein begrenztes Zeitlimit (20 Sekunden).
Fail-closed-Verhalten
Weiterlesen
Was zur Bewertung das Gerät verlässt, redigiert und nur-hinzugefügt: Was der Cloud-Modus sendet. Die Egress-Fläche des Daemon: Netz- und Firewall-Anforderungen.
Ihr Modell, Ihr Netz, Ihr Inhalt.
Das Modell auf dem Gerät bleibt primär, und die Anordnung ist immer dual und fail-closed. Eine Enterprise-Fähigkeit.
Sign me up