Open Connector für AI-Agenten selbst hosten

Was Open Connector für einen AI-Agenten leistet

Beim Self-Hosting von Open Connector befindet sich zwischen Ihren AI-Agenten und jeder von ihnen aufgerufenen Software-as-a-Service-(SaaS-)API ein zentrales Authentifizierungs-Gateway. Der Agent verwaltet dadurch niemals ein Provider-Token. Open Connector ist ein Open-Source-Gateway von OOMOL Lab und steht unter der Apache-2.0-Lizenz. Es läuft als einzelner Container, speichert seinen Zustand in einer einzelnen SQLite-Datei und stellt Provider-Aktionen über HTTP sowie über MCP (model context protocol) bereit.

Das Problem beginnt bei der zweiten Integration. Jeder Provider verwendet einen eigenen OAuth-(open authorization-)Ablauf, eine eigene Gültigkeitsdauer für Refresh-Tokens und eigene Bezeichnungen für Scopes. Fünf Provider manuell in einen Agenten zu integrieren, bedeutet fünf Redirect-Handler, fünf Credential-Speicher und fünf Refresh-Schleifen, die vor Ablauf eines Tokens ausgeführt werden müssen. Fast niemand implementiert diesen Code. Stattdessen erstellt man pro Dienst ein langlebiges persönliches Zugriffstoken und fügt es in die Agent-Konfiguration, eine Umgebungsdatei oder sogar direkt in den Prompt ein. Jedes vom Agenten ausgeführte Tool kann dieses Token anschließend lesen. Außerdem landet es im Transkript. Genau dieses Problem beschreibt wie Sie Geheimnisse aus AI-Agenten heraushalten.

Ein Authentifizierungs-Gateway teilt die Zugangsdaten in zwei Teile. Das Gateway speichert die Provider-Zugangsdaten und führt den OAuth-Ablauf aus. Der Agent erhält ein Laufzeittoken, das nur gegenüber dem Gateway gültig ist. Wenn der Agent eine Aktion aufruft, lädt das Gateway die gespeicherten Zugangsdaten, fügt sie serverseitig in die ausgehende Anfrage ein und gibt nur den Antwortinhalt zurück. Der Agent erhält das Provider-Zugriffstoken niemals. Wenn das Agenten-Transkript offengelegt wird, müssen Sie daher nur ein widerrufbares Laufzeittoken ersetzen und nicht Ihr GitHub-Konto schützen.

Der Katalog nennt mehr als 1,000 Provider und 10,000 vorgefertigte Aktionen. Das ist eine eigene Angabe des Projekts und lässt sich nicht von außen überprüfen. Überprüfen lässt sich jedoch die Struktur: ein HTTP-Endpunkt pro Aktion, eine gespeicherte Verbindung pro Provider und ein Token pro Agent. Falls die Agentenseite für Sie noch neu ist und sich Begriffe wie Tool-Aufruf oder MCP-Server noch nicht gefestigt haben, baut der schrittweise Pfad in wie Sie AI-Agenten von Grund auf lernen die Schleife, die Tools und die Sicherheitspraktiken auf, die ein solches Gateway voraussetzt.

Warum Sie Open Connector selbst betreiben sollten, statt einen gehosteten Connector-Dienst zu verwenden

Ein gehosteter Connector-Dienst erledigt dieselbe Aufgabe und speichert die Refresh-Tokens für jeden Anbieter, den Sie damit verbinden. Ein Refresh-Token für Google oder GitHub ist ein langlebiger kryptografischer Schlüssel zu Ihren E-Mails und Repositories. Er bleibt in der Regel auch nach einer Passwortänderung gültig. Wird der Dienst kompromittiert, ist auch Ihr Zugriff gefährdet. Beim Self-Hosting liegen diese Datensätze stattdessen in SQLite auf einem von Ihnen gemieteten und administrierten Rechner. Sie sind mit einem Schlüssel geschützt, der Ihren Rechner nie verlässt.

Machen Sie sich die Kosten klar, bevor Sie beginnen. Diese VPS-Instanz wird zum wertvollsten Server, den Sie betreiben. Sie enthält in einer Datei gültige Zugangsdaten für ein Dutzend Dienste. Behandeln Sie sie daher wie einen Host für einen Passwortmanager: Eine Firewall darf nur Port 443 veröffentlichen, gemeinsame Logins sind zu vermeiden, und Sie müssen mindestens einmal eine Sicherung erfolgreich wiederhergestellt haben. Richten Sie außerdem einen Alarm ein, wenn der Server nicht mehr antwortet. Wenn Sie Ihren Passwort-Tresor nicht auf diesem Rechner ablegen würden, sollten Sie dort auch den Connector nicht betreiben.

Pinnen Sie eine Version, bevor Sie etwas installieren

Open Connector ist noch jung. Das Repository wurde erstmals am 29. Juni 2026 veröffentlicht. Am 1. August 2026 ist v1.3.3 das neueste getaggte Release. Es wurde am 30. Juli 2026 veröffentlicht und trägt ebenfalls das latest-Tag. Die Registry veröffentlicht außerdem ein tip-Tag. Dieses wird aus dem neuesten Commit auf main erstellt.

Bei einem so neuen Projekt ändern sich bewegliche Tags häufig. Ein docker compose pull, das zwei Releases überspringt, kann einen Endpoint ändern, von dem Ihr Agent abhängt. Dann verbringen Sie den Abend damit, das Problem fälschlicherweise beim Agenten zu suchen. Pinnen Sie das Image auf ein Release-Tag. Führen Sie Upgrades erst durch, wenn Sie dies bewusst entscheiden und die Release Notes gelesen haben.

Open Connector hinter TLS auf Ihrem eigenen VPS bereitstellen

Vor dem Start des Containers benötigen Sie:

• Docker mit dem Compose-Plugin auf Ubuntu 24.04 oder einer vergleichbaren Version
• einen Hostnamen, dessen A-Record auf diesen VPS zeigt, zum Beispiel connect.example.com
• einen Reverse Proxy, der TLS (Transport Layer Security) für diesen Hostnamen bereits terminiert
• zwei zufällige Secrets, die weiter unten erzeugt werden

Traefik-Reverse-Proxy für mehrere Docker-Compose-Anwendungen behandelt die Proxy-Konfiguration. Die vollständige Zertifikatskonfiguration für eine einzelne Anwendung finden Sie im Leitfaden n8n auf einem VPS mit Docker und HTTPS.

Erzeugen Sie zuerst die Secrets. Der Verschlüsselungsschlüssel schützt die gespeicherten Zugangsdaten. Das Admin-Token schützt die Webkonsole und die gesamte /api-Oberfläche. Für beide Werte gibt es keinen Standardwert. Die Laufzeit startet jedoch problemlos, wenn sie fehlen.

mkdir -p ~/open-connector && cd ~/open-connector
umask 077
printf 'OOMOL_CONNECT_ENCRYPTION_KEY=%s\n' "$(openssl rand -base64 32)" > .env
printf 'OOMOL_CONNECT_ADMIN_TOKEN=%s\n' "$(openssl rand -base64 32)" >> .env
chmod 600 .env

Speichern Sie beide Werte jetzt in Ihrem Passwortmanager, bevor Sie die Anwendung zum ersten Mal starten. Für den Verschlüsselungsschlüssel gibt es keinen Wiederherstellungsweg. Der Grund dafür steht weiter unten in der Liste der Fehlerursachen.

Erstellen Sie nun compose.yaml. Es unterscheidet sich an zwei Stellen vom Upstream-Beispiel. Beide Änderungen sind wichtig.

services:
  connector:
    image: ghcr.io/oomol-lab/open-connector:v1.3.3
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - connector-data:/app/data
    environment:
      OOMOL_CONNECT_DATA_DIR: /app/data
      OOMOL_CONNECT_ORIGIN: "https://connect.example.com"
      OOMOL_CONNECT_ENCRYPTION_KEY: "${OOMOL_CONNECT_ENCRYPTION_KEY:?set this in .env}"
      OOMOL_CONNECT_ADMIN_TOKEN: "${OOMOL_CONNECT_ADMIN_TOKEN:?set this in .env}"

volumes:
  connector-data:

Die erste Änderung ist der festgelegte Tag anstelle von latest. Die zweite Änderung betrifft den Port. Die Upstream-Datei veröffentlicht 3000:3000. Dadurch wird der Port an jede Netzwerkschnittstelle des Hosts gebunden. Docker schreibt veröffentlichte Ports in die NAT-Tabelle (Network Address Translation), bevor das Paket die ufw-Filterkette erreicht. Daher schließt ufw deny 3000 diesen Port nicht. Diese Falle wird unter warum Docker-Ports ufw umgehen beschrieben. Mit 127.0.0.1:3000:3000 wird der Port nur an der Loopback-Schnittstelle veröffentlicht. Ihr Reverse Proxy verbindet sich dann vom selben Host aus.

:? kennzeichnet jede Variable als erforderlich. Dadurch verweigert der Stack den Start, wenn .env fehlt, statt mit unverschlüsselten Zugangsdaten zu starten. Die Werte in .env statt in der Compose-Datei zu speichern, entspricht dem Muster aus Docker-Compose-Env-Dateien und Secrets.

docker compose up -d
docker compose logs -n 30 connector
curl -s http://127.0.0.1:3000/health
sudo ss -tlnp | grep 3000

/health prüft { "ok": true }, sobald die Laufzeitumgebung gestartet ist. ss muss 127.0.0.1:3000 ausgeben. Eine Zeile mit 0.0.0.0:3000 bedeutet, dass weiterhin das Upstream-Port-Mapping verwendet wird und das Gateway direkt aus dem gesamten Internet erreichbar ist. Eine abgelehnte Verbindung beim Health Check bedeutet, dass der Container noch nicht lauscht. Lesen Sie daher die Logs, bevor Sie den Proxy ändern.

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.connector.rule=Host(`connect.example.com`)"
      - "traefik.http.routers.connector.entrypoints=websecure"
      - "traefik.http.routers.connector.tls.certresolver=le"
      - "traefik.http.services.connector.loadbalancer.server.port=3000"

Warum OAuth einen echten Hostnamen voraussetzt

OOMOL_CONNECT_ORIGIN ist die Einstellung, die häufig übersprungen wird. Dadurch schlägt OAuth auf eine Weise fehl, die wie ein Fehler des Providers aussieht. Die Laufzeit erstellt daraus die Redirect-URI im Format <origin>/oauth/callback. Wenn der Wert nicht gesetzt ist, wird als Origin standardmäßig http://localhost:3000 verwendet. Die Laufzeit sendet dem Provider dann die Redirect-URI http://localhost:3000/oauth/callback, während in Ihrer OAuth-Anwendung https://connect.example.com/oauth/callback registriert ist. Die beiden Zeichenfolgen unterscheiden sich. GitHub antwortet daher:

The redirect_uri MUST match the registered callback URL for this application.

Ein OAuth-Provider leitet den Browser an diese URI zurück. Deshalb muss es sich um eine Adresse handeln, die aus dem Internet erreichbar ist. Provider lehnen reines http:// für alle Ziele außer localhost ab. Genau deshalb benötigt diese Bereitstellung einen Hostnamen und ein Zertifikat. Setzen Sie den Origin vor dem ersten Start, da der Wert beim Start eingelesen wird. Führen Sie nach dem Bearbeiten von .env oder compose.yaml erneut docker compose up -d aus, um die Änderung anzuwenden.

Verbinden Sie Ihren ersten Provider über OAuth

Erstellen Sie zuerst die OAuth-Anwendung beim Provider. Bei GitHub lautet der Pfad Settings, dann Developer settings, dann OAuth Apps und anschließend New OAuth App. Setzen Sie die Autorisierungs-Callback-URL auf https://connect.example.com/oauth/callback. Bewahren Sie die Client-ID und das Client-Secret auf.

Jeder Aufruf von /api überträgt das Admin-Token. Exportieren Sie es daher einmal für die Shell-Sitzung.

export ADMIN_TOKEN='paste-the-admin-token'
curl -s https://connect.example.com/api/oauth/configs \
  -H "authorization: Bearer $ADMIN_TOKEN"

Die Auflistung zeigt die Redirect-URI, die die Laufzeitumgebung für jeden Provider erwartet. Damit können Sie am schnellsten prüfen, ob Ihr Origin übernommen wurde. Wenn dort weiterhin localhost steht, läuft der Container mit dem alten Wert. Der OAuth-Ablauf schlägt dann beim letzten Schritt fehl.

Speichern Sie die Client-Anmeldedaten und starten Sie anschließend eine Autorisierung.

curl -s -X PUT https://connect.example.com/api/oauth/configs/github \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"clientId":"...","clientSecret":"..."}'

curl -s -X POST https://connect.example.com/api/oauth/authorizations \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"service":"github"}'

Der zweite Aufruf liefert eine authorizationUrl zurück. Öffnen Sie sie in einem Browser und bestätigen Sie die Scopes. Der Provider leitet den Browser anschließend an /oauth/callback zurück. Dort tauscht die Laufzeitumgebung den Code aus und speichert die Anmeldedaten. Die Webkonsole an Ihrem Origin führt mit einem Formular durch dieselben Schritte und verwendet dabei dasselbe Admin-Token. Provider, die einen einfachen API-Schlüssel verwenden, überspringen diesen gesamten Ablauf: PUT /api/connections/<service> mit {"authType":"api_key","values":{"apiKey":"..."}} speichert den Schlüssel direkt.

Geben Sie jedem Agenten ein Laufzeit-Token, niemals das Zugangstoken

Der Agent authentifiziert sich beim Gateway mit einem Laufzeit-Token, das die Admin-API ausstellt.

curl -s -X POST https://connect.example.com/api/runtime-tokens \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"name":"research-agent"}'

Die Antwort enthält ein Token, das mit oct_ beginnt. Stellen Sie für jeden Agenten genau ein Token aus und benennen Sie es nach diesem Agenten. Wenn Sie ein Token nicht zuordnen können, müssen Sie andernfalls alle Tokens widerrufen. Der Agent ruft Aktionen anschließend über gewöhnliches HTTP auf.

curl -s -X POST https://connect.example.com/v1/actions/github.get_current_user \
  -H "authorization: Bearer oct_..." \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Eine erfolgreiche Antwort ist ein Envelope, dessen Feld success den Wert true enthält. Die Provider-Nutzdaten stehen unter data. Das GitHub-Token kommt in dieser Antwort an keiner Stelle vor. Für einen MCP-Client verweisen Sie ihn mit demselben Bearer-Header auf https://connect.example.com/mcp. Das Gateway stellt dann Discovery-Tools wie search_actions und execute_action bereit, statt ein eigenes Tool für jede API anzubieten. Dadurch bleibt die Tool-Liste des Agenten klein. MCP-Server auf einem VPS ausführen behandelt die Client-Seite dieser Konfiguration.

Führen Sie noch eine Prüfung durch, bevor Sie die Einrichtung als abgeschlossen betrachten. Wiederholen Sie den Aktionsaufruf, nachdem Sie den Header authorization gelöscht haben. Der Quickstart des Projekts ruft /v1 vollständig ohne Bearer-Header auf. Wenn bei der Installation keine Laufzeit-Authentifizierung konfiguriert ist, führt der Dienst daher Aktionen für jeden aus, der den Port erreichen kann. Wenn der nicht authentifizierte Aufruf erfolgreich ist, haben Sie zwei Möglichkeiten: Konfigurieren Sie Laufzeit-Tokens und bestätigen Sie, dass der anonyme Aufruf nun fehlschlägt, oder beschränken Sie /api, /v1 und /mcp am Reverse Proxy auf die Adressen, von denen Ihre Agenten kommen. Nur /oauth/callback muss für das Internet erreichbar bleiben, weil dies der einzige Pfad ist, den die Browser-Weiterleitung eines Providers benötigt.

Die Aktionsliste auf das beschränken, was der Agent benötigt

Ein Gateway mit tausend dahinterliegenden Providern bietet einem Sprachmodell eine große Angriffsfläche. Sie wird noch größer, sobald das Modell Text liest, den es nicht selbst erstellt hat. Eine Seite, die von Ihrer eigenen SearXNG-Instanz als Antwort auf die Websuchen des Agents zurückgegeben wird, kann Anweisungen enthalten, die sich auf beliebige Aktionen beziehen, über die der Agent verfügt. Dieselbe Zurückhaltung, die einen Coding-Agent dazu bringt, die kleinste funktionierende Änderung vorzunehmen, sollte auch für seine Berechtigungen gelten: Gewähren Sie nur die wenigen Aktionen, die der Auftrag tatsächlich benötigt, und keine weiteren. Zwei Einstellungen schränken dies ein.

OOMOL_CONNECT_ALLOWED_ACTIONS akzeptiert eine durch Kommas getrennte Allowlist und unterstützt service.* sowie *. OOMOL_CONNECT_BLOCKED_ACTIONS ist die Denylist, und die Denylist hat Vorrang. Wenn Sie die Allowlist auf github.get_current_user,github.list_issues setzen, wird jede andere Aktion unabhängig von der Anfrage des Agents abgelehnt. Das ist der Unterschied zwischen einem Fehler und einem Sicherheitsvorfall. Laufzeit-Token erhalten zusätzlich zu den globalen Regeln eigene Aktionsregeln. Ihre Liste allowedProxies ist zunächst leer, daher wird POST /v1/proxy/:service abgelehnt, bis Sie diese Aktion freigeben. Dieser Proxy-Endpunkt leitet eine unformatierte Anfrage mit Ihren Zugangsdaten an einen Provider weiter. Lassen Sie ihn daher leer, sofern ihn nicht ein bestimmter Agent benötigt.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK ist standardmäßig auf false gesetzt. Dadurch wird verhindert, dass eine Verbindung zu einem selbst gehosteten Provider auf eine private Adresse wie den Cloud-Metadatendienst unter 169.254.169.254 oder auf Ihre Datenbank im selben Netzwerk zeigt. Lassen Sie diese Einstellung deaktiviert. Aktivieren Sie sie nur für einen Provider, den Sie selbst hosten.

Die Box sichern, die jedes Token enthält

Zwei Dinge sind wichtig, und jedes ist ohne das andere nutzlos. Die Datenbank unter /app/data/connect.sqlite im Volume connector-data enthält die versiegelten Zugangsdaten. Der Verschlüsselungsschlüssel unter .env entsiegelt sie. Ein Volume-Backup ohne den Schlüssel stellt nichts wieder her, und der Schlüssel ohne das Volume stellt ebenfalls nichts wieder her. Der Schlüssel gehört daher in Ihren Passwortmanager, und das Volume gehört in Ihre reguläre Backup-Rotation.

Stoppen Sie den Container, während Sie die SQLite-Datei kopieren. Eine Kopie, die während eines Schreibvorgangs erstellt wird, kann als beschädigte Datenbank wiederhergestellt werden.

docker volume ls | grep connector-data
docker compose stop connector
docker run --rm -v open-connector_connector-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/connector-data.tgz -C /data .
docker compose start connector

Der Volume-Name besteht aus Ihrem Projektverzeichnis und _connector-data. Deshalb steht der erste Befehl dort: Fügen Sie den tatsächlichen Namen in den dritten Befehl ein. Übertragen Sie das Archiv mit restic-Backups von einem VPS vom VPS weg. Restic verschlüsselt es, bevor es den VPS verlässt, weil dieses Archiv den Zugangsdatenbestand enthält.

Die Laufzeitumgebung speichert die letzten Aktionsausführungen als Audit-Datensätze, standardmäßig 5,000. Dadurch kann die Konsole anzeigen, welcher Agent was und wann ausgeführt hat. Dieses Protokoll sollten Sie zuerst lesen, wenn sich ein Agent ungewöhnlich verhält. Überwachen Sie außerdem https://connect.example.com/health mit einer Uptime-Kuma-Statusseite. Wenn das Gateway nicht mehr antwortet, schlagen Agenten auf schwer nachvollziehbare Weise fehl. Wenn bekannt ist, dass das Gateway nicht erreichbar ist, sparen Sie sich eine Stunde beim Lesen der Agentenausgabe.

Was fehlschlägt und welche Meldung Sie sehen

redirect_uri_mismatch beim Anbieter. Die Origin und die registrierte Callback-URL stimmen nicht überein. Vergleichen Sie die exakte Zeichenfolge aus /api/oauth/configs mit den App-Einstellungen des Anbieters. Prüfen Sie dabei auch https gegenüber http sowie einen eventuell vorhandenen abschließenden Schrägstrich.

Jeder /api-Aufruf gibt 401 zurück. Der Header für das Admin-Token fehlt oder ist falsch geschrieben. Der Header lautet Authorization: Bearer <token>. Die Webkonsole fordert dasselbe Token an.

Der Container läuft, und die Zugangsdaten liegen im Klartext vor. Das geschieht, wenn OOMOL_CONNECT_ENCRYPTION_KEY den Container nie erreicht, weil die Laufzeitumgebung die Zugangsdaten unverschlüsselt speichert, statt den Start zu verweigern. Belegen Sie dies in Ihrer eigenen Installation: Verbinden Sie einen Anbieter mit einem API-Key, den Sie erkennen können, und suchen Sie anschließend in der Datenbank danach.

docker compose cp connector:/app/data/connect.sqlite /tmp/connect.sqlite
grep -c 'github_pat_' /tmp/connect.sqlite
shred -u /tmp/connect.sqlite

Ein Wert über 0 bedeutet, dass der Schlüssel nicht wirksam ist. Prüfen Sie daher, ob .env im selben Verzeichnis wie compose.yaml liegt und ob docker compose config den Wert anzeigt. Wenn der Schlüssel gesetzt ist, gibt dieselbe Suche 0 zurück, weil der Datensatz mit AES-256-GCM (Advanced Encryption Standard, 256-Bit-Schlüssel, Galois/Counter-Modus) verschlüsselt ist.

Nach einer Wiederherstellung lässt sich nichts entschlüsseln. Der Verschlüsselungsschlüssel wurde geändert oder ging verloren. Er wird absichtlich niemals neben den Daten gespeichert. Daher gibt es keinen Wiederherstellungspfad und auch kein Support-Ticket, das weiterhilft. Verbinden Sie jeden Anbieter erneut. Eine Schlüsselrotation wird über eine separate Schlüsselvariable und einen Datenbefehl in der Laufzeitumgebung unterstützt. Lesen Sie daher vor einer Rotation die aktuellen Release Notes.

Der Agent meldet einen Fehler für eine Aktion, die im Katalog sichtbar ist. Erkennung und Ausführung sind getrennt. Eine Aktion kann in search_actions erscheinen und trotzdem von OOMOL_CONNECT_ALLOWED_ACTIONS, der Denylist oder den eigenen Regeln des Laufzeittokens abgelehnt werden.

Upgrades. Sichern Sie das Volume, ändern Sie den Image-Tag auf das neue Release und führen Sie anschließend docker compose pull && docker compose up -d aus. Überwachen Sie docker compose logs -n 50 connector auf eine Migrationsmeldung. Führen Sie danach den Health Check und eine echte Aktion erneut aus, bevor Sie dem System wieder vertrauen. Für ein Rollback setzen Sie den alten Tag wieder ein. Das funktioniert nur, weil Sie den Tag fest angegeben haben.

FAQ

Benötige ich eine öffentliche Domain, um Open Connector selbst zu hosten?

Für Anbieter, die einen API key verwenden, nein: Ein Gateway auf 127.0.0.1 reicht aus. Für OAuth ist sie in der Praxis erforderlich. Der Anbieter leitet einen Browser an Ihre Callback-URL weiter. Daher muss diese URL aus dem öffentlichen Internet erreichbar sein, und Anbieter lehnen einfaches http:// außerhalb von localhost ab. Setzen Sie OOMOL_CONNECT_ORIGIN vor dem ersten Start auf Ihren https://-Hostnamen und registrieren Sie <origin>/oauth/callback in der OAuth-Anwendung des Anbieters.

Was passiert, wenn ich den Verschlüsselungsschlüssel von Open Connector verliere?

Die gespeicherten Zugangsdaten können nicht entschlüsselt werden. Es gibt keine Wiederherstellungsmöglichkeit. Der Schlüssel wird absichtlich nie zusammen mit den Daten gespeichert. Daher kann niemand, der über die Datenbank verfügt, die Daten lesen. Das gilt auch für Sie. Ihre einzige Möglichkeit besteht darin, einen neuen Schlüssel zu setzen und jeden Anbieter erneut zu verbinden. Bewahren Sie den Schlüssel in einem Passwortmanager und die Datenbank in Ihrer Backup-Rotation auf. Für eine Wiederherstellung werden beide benötigt.

Kann mein AI agent das Zugriffstoken des Anbieters sehen?

Nicht, wenn er den Gateway verwendet. Der Agent authentifiziert sich mit einem Laufzeittoken, das mit oct_ beginnt. Der Gateway fügt die Zugangsdaten des Anbieters auf dem Server in die ausgehende Anfrage ein und gibt nur die Antwort zurück. Diese Eigenschaft wird durch zwei Dinge aufgehoben: Der /v1/proxy/:service-Endpunkt leitet unveränderte Anfragen mit Ihren Zugangsdaten weiter. Seine Berechtigungen beginnen nicht ohne Grund leer. Außerdem umgehen Sie den Gateway vollständig, wenn Sie selbst einen API key in den Agent einfügen.

Sollte der Gateway aus dem öffentlichen Internet erreichbar sein?

Nur /oauth/callback muss erreichbar sein. Veröffentlichen Sie den Container-Port auf 127.0.0.1, damit die NAT-Regeln von Docker ihn nicht über Ihre Firewall hinaus erreichbar machen können, und schalten Sie den Reverse Proxy davor. Testen Sie anschließend einen Aktionsaufruf ohne authorization-Header. Wenn er erfolgreich ist, beschränken Sie /api, /v1 und /mcp am Proxy auf die Adressen, die Ihre Agenten verwenden, bis nur noch authentifizierte Aufrufe funktionieren.

Ist Open Connector für den Produktionseinsatz geeignet?

Open Connector steht unter der Apache-2.0-Lizenz und wird schnell weiterentwickelt: Das Repository erschien am 29. Juni 2026, und v1.3.3 wurde am 30. Juli 2026 veröffentlicht. Betrachten Sie daher jede Versionsnummer in diesem Leitfaden als Stand vom 1. August 2026. Führen Sie die Software mit einem festgelegten Release-Tag aus, niemals auf latest oder tip. Lesen Sie vor jedem Upgrade die Release Notes und halten Sie ein Volume-Backup vor, das Sie bereits einmal wiederhergestellt haben. Das Design ist für einen Server in Ihrem Besitz solide. Das Risiko liegt in den häufigen Versionsänderungen, nicht in der Architektur.