Wie das Gateway zusammenpasst
Anwendung oder Agent
Unterstützte OpenAI- und Anthropic-Anfrageformate
NautGate
Protokolladapter
Routingregeln und Modellauswahl
Anbieterverbindungen
Modellanbieter
Konfigurierter Cloud-Anbieter oder lokales Modell
Entscheidungsregister und Anforderungsaufzeichnungen
Angefragte, ausgewählte und vom Anbieter gemeldete Modelle. Die Inhaltserfassung folgt der Aufzeichnungsrichtlinie.
Dashboard
Überprüfen Sie Aktivitäten, Routen und Kosten
Nachweisbelege
Kanonische Empfangs-Hashes → Merkle Root → Checkpoint
Signaturerweiterung
Übermittelt den Prüfpunkt an den Signaturdienst
Signierdienst + TSB
Fordert einen autorisierten Signaturvorgang über die REST-API an
HSM
Der private Signaturschlüssel bleibt im Inneren
Exportierte Nachweise → unabhängiger Prüfer
Überprüft Hashes, Inklusion und Signatur mithilfe eines separat vertrauenswürdigen öffentlichen Schlüssels. Kein HSM-Zugriff erforderlich.
NautGate sitzt zwischen einer verbundenen Anwendung und ihren Modellanbietern. Seine Protokolladapter akzeptieren unterstützte OpenAI Chat Completions-, OpenAI Responses- und Anthropic Messages-Anfragen. Diese Einstiegspunkte versorgen eine gemeinsame Routing- und Nachweispipeline und nicht separate Protokolle für jedes Clientformat.
Die Routing-Schicht wandelt das angeforderte Modell, die konfigurierten Präferenzen und Routing-Regeln in eine Anbieter- und Modellauswahl um. Es berücksichtigt den Routenzustand und die konfigurierten Einschränkungen, bevor die Anfrage weitergeleitet wird. Explizite Modellauswahl und automatisches Routing verwenden dasselbe Gateway, treffen jedoch nicht dieselbe Auswahlentscheidung.
Die Anbieterverbindung sendet die Anfrage stromaufwärts und gibt die Antwort zurück, einschliesslich gestreamter Antworten, sofern unterstützt. NautGate unterscheidet das von der Anwendung angeforderte Modell, das vom Router ausgewählte Modell und das vom Anbieter gemeldete Modell. Wenn Sie diese getrennt halten, wird eine Ersetzung sichtbar, anstatt sie hinter einem Modellnamen zu verbergen.
Das Entscheidungsbuch und die Anforderungsdatensätze unterstützen die Untersuchung im Dashboard. Der Nachweispfad erstellt Belege und Kontrollpunkte aus erfassten Datensätzen. Durch optionale Signatur werden ein separater Dienst und eine HSM-Verbindung hinzugefügt. Das HSM wählt weder das Modell aus noch generiert es seine Antwort.
Wo die Grenzen liegen
Die Anwendung muss ihre Anfragen tatsächlich über NautGate senden, damit diese Sichtbarkeit besteht. Wenn ein kompatibler Client auf das Gateway gerichtet wird, wird dieser Workflow verbunden. Anrufe, die direkt an einen Anbieter gesendet werden, bleiben ausserhalb seiner Aufzeichnung.
Anbieteranmeldeinformationen, Routenberechtigungen und Aufzeichnungsrichtlinien sind Konfigurationsentscheidungen. Eine lokale Modellroute hält die Modellausführung nur dann lokal, wenn ihre Konfigurations- und Fallbackregeln diese Grenze erzwingen. Auch die Prompt- und Response-Aufbewahrung erfordert eine explizite Richtlinie, unabhängig davon, wo das Modell ausgeführt wird.
Der Signaturdienst ist eine weitere Vertrauensgrenze. Beschränken Sie, wer eine Signatur anfordern kann und welchen Schlüssel er verwenden darf. Ein geschützter Schlüssel trägt dazu bei, die Integrität der erfassten Nachweise zu bewahren, kann jedoch fehlende oder falsche Datensätze am Gateway nicht reparieren.
Eine kanonische Beleg
Die Prüfung beginnt mit einem vereinbarten Format für den Beleg. Prüfer und Unterzeichner müssen dieselben Bytes hashen. Eine beliebig neu formatierte Fassung des Datensatzes reicht dafür nicht.
Empfangs-Hashes werden in einem Merkle-Baum zusammengefasst. Seine Wurzel fasst den Stapel zusammen, während ein Einschlussnachweis eine offengelegte Beleg mit dieser Wurzel verbindet.
Was Securosys hinzufügt
Securosys stellt das Hardware-Sicherheitsmodul bereit, das von dieser Signaturintegration verwendet wird. Ein HSM ist dedizierte Hardware, die kryptografische Schlüssel schützt und Vorgänge wie das Signieren ausführt. In diesem Setup verbleibt der private Signaturschlüssel im HSM; NautGate erhält eine Signatur, nicht den Schlüssel.
TSB steht für Transaction Security Broker. Es stellt dem Signaturdienst eine REST-API zur Verfügung, über die er eine Operation für einen HSM-Schlüssel anfordern kann. NautGate bereitet einen Prüfpunkt vor, seine Signaturerweiterung übergibt ihn an den Signaturdienst und dieser Dienst ruft TSB auf. Die zurückgegebene Signatur begleitet den Kontrollpunkt zur späteren Überprüfung.
Dadurch wird der geschützte Signaturschlüssel von den gewöhnlichen Anwendungsdateien des Gateways getrennt. Die Nutzung erfordert ein konfiguriertes HSM oder HSM-Dienst, TSB-Zugriff und die Berechtigung zur Verwendung des gewählten Schlüssels. Die Integration ist optional und diese Dienste werden durch die Installation von NautGate nicht automatisch bereitgestellt.
Unterzeichnung des Kontrollpunkts
Die Signaturerweiterung übergibt den Prüfpunkt an den Signaturdienst, der Securosys TSB aufruft. Die dargestellte Integration verwendet POST /v1/synchronousSign mit SHA256_WITH_RSA. Der private Schlüssel verbleibt im HSM.
Das Signieren ist optional. Routing, Protokollierung und das Dashboard funktionieren auch ohne; Ein signierter Prüfpunkt fügt dem Nachweispfad eine unabhängig überprüfbare Referenz hinzu.
- 01Hash des Belegs
- 02Merkle-Wurzel
- 03HSM-Signatur
Ein unabhängiger Prüfer
Ein Verifizierer berechnet den offengelegten Empfangs-Hash neu, prüft seine Aufnahme in den Prüfpunkt und verifiziert die Signatur mit einem separat vertrauenswürdigen öffentlichen Schlüssel. Diese Prüfung kann offline ausgeführt werden.
Das Vertrauen in den öffentlichen Schlüssel ist wichtig. Das Akzeptieren eines mit einer Beleg gebündelten Schlüssels würde es einem Angreifer ermöglichen, die Daten und den Schlüssel miteinander zu ersetzen. Eine gültige Signatur stellt die Datensatzintegrität in Bezug auf diesen Schlüssel her, nicht die Wahrheit der Eingabe, die vollständige Erfassung oder einen vertrauenswürdigen Zeitstempel.