Outgate sitzt zwischen Ihrer App oder Ihrem Agenten und den Modell-Providern, die Sie nutzen.

Statt OpenAI oder Anthropic direkt aufzurufen, schicken Sie Anfragen durch das Gateway. Dort können Sie Guardrails anwenden, Routing steuern und alles an einem Ort beobachten.

Der Einstieg läuft in drei Schritten: einen Provider verbinden, einen Endpoint zum Zugriff anlegen und die erste Anfrage senden.

Provider verbinden

Sagen Sie Outgate, wo Ihr Modell läuft und wie Anfragen authentifiziert werden sollen.

Ein Provider ist eine Verbindung zu einer Upstream-API wie OpenAI, Anthropic oder einem kompatiblen Dienst. Beim Anlegen definieren Sie die Upstream-URL und wie Anfragen authentifiziert werden sollen.

Die meisten Teams starten mit Auth-Forwarding. In diesem Modus nutzt Ihr Client weiter seine eigenen Credentials, und Outgate reicht sie an den Upstream-Provider weiter. Das ist der schnellste Einstieg, weil Sie keine Keys migrieren oder zentral speichern müssen.

Wenn Sie es bevorzugen, können Sie Credentials in Outgate hinterlegen und das Gateway die Authentifizierung für Sie übernehmen lassen.

Beim Einrichten des Providers können Sie auch eine Guardrail-Policy attachen. Die Standard-Policy funktioniert sofort und erkennt sensible Werte in Anfragen, bevor sie das Modell erreichen. Sie können sie später durch eine eigene Policy ersetzen, wenn Sie strengere Regeln brauchen.

Einen teilbaren Endpoint anlegen

Legen Sie einen Share an, um eine Gateway-URL und einen Key für Ihren Client zu erhalten.

Um den Provider tatsächlich zu nutzen, legen Sie einen Share an. Ein Share ist der konkrete Weg, Traffic durch das Gateway zu schicken. Er erzeugt eine Gateway-URL und einen Key, den Ihr Client verwenden kann. Sie können sich das als benannten Zugangspunkt zu Ihrem Provider vorstellen.

Anfragen über einen Share lassen sich auf zwei Arten authentifizieren. Standardmäßig ist der Key direkt in der URL enthalten — gut für schnelle Setups und lokale Entwicklung. Alternativ können Sie Credentials per Umgebungsvariable übergeben, was oft natürlicher ist, wenn Tools einen API-Key vor dem Start erwarten.

Sobald der Share angelegt ist, haben Sie alles, was Sie brauchen, um Traffic durch Outgate zu routen.

Die erste Anfrage senden

Mit der CLI lässt sich das Setup schnell validieren.

Sie können jetzt manuell Anfragen senden — der schnellste Weg zur Setup-Validierung ist allerdings die CLI.

curl -fsSL https://outgate.ai/download/install.sh | sh
og login
og status

Der Login-Flow öffnet standardmäßig einen Browser. Wenn Sie über SSH oder in einem Container arbeiten, können Sie einen Flow ohne Browser nutzen oder ein Token-File mitgeben.

Nach dem Login kann die CLI bestehende Tools kapseln und durch Ihr Gateway routen — ohne Code-Änderungen.

Ihren Agenten durch das Gateway laufen lassen

Starten Sie Claude Code oder Codex direkt durch Outgate.

og claude

# oder
og codex

Wenn mehrere Provider konfiguriert sind, können Sie einen explizit auswählen. Sonst trifft die CLI eine sinnvolle Standardwahl auf Basis dessen, was verfügbar ist.

Im Hintergrund löst die CLI Konfiguration aus mehreren Quellen auf. Flags haben Vorrang, danach kommt die Projekt-Konfiguration in .og.yaml, dann Umgebungsvariablen und zuletzt globale Defaults. So setzen Sie Werte einmal pro Projekt und müssen sie nicht in jedem Befehl wiederholen.

Eine einfache .og.yaml im Repository pinnt zum Beispiel einen Provider oder Share, sodass Ihr Team automatisch dasselbe Setup nutzt.

Optional: Guardrails vor der Produktion testen

Erkennung ausführen, ohne echte Anfragen ans Modell zu senden.

Wenn Sie eine Guardrail-Policy attached haben, können Sie sie vor Live-Traffic testen. Die CLI bietet einen Scan-Modus, der nur die Erkennung ausführt.

Im Scan-Modus werden Ihre Dateien verarbeitet, sensible Werte identifiziert und als Fingerabdrücke gespeichert, sodass sie später wiedererkannt werden — ohne die Originaldaten preiszugeben.

Das ist nützlich, wenn Sie Policies validieren wollen, bevor sie produktiven Traffic sehen.

Was Sie jetzt haben

Einen vollständigen Request-Pfad durch Outgate.

An diesem Punkt steht ein vollständiger Pfad durch Outgate: Ihr Tool oder Ihre App sendet eine Anfrage → das Gateway wendet Guardrails an → die Anfrage erreicht Ihren Provider → die Antwort kommt auf demselben Pfad zurück.

Sie mussten Ihren Client nicht ändern und haben jetzt einen zentralen Ort, um zu steuern und zu beobachten, wie Anfragen behandelt werden.

Wie es weitergeht

Routing, strengere Guardrails und Observability ergänzen, wenn Sie so weit sind.

Von hier aus erweitern die meisten Teams die Steuerung: Routing zwischen Providern, strengere Guardrail-Policies oder Monitoring von Traffic und Latenz.

Der Kernablauf bleibt gleich: Alles läuft durch das Gateway.