Jak samodzielnie hostować Open Connector dla agentów AI

Rola Open Connector w działaniu agenta AI

Samodzielne hostowanie Open Connector pozwala umieścić jedną bramę uwierzytelniającą między agentami AI a każdym wywoływanym przez nie interfejsem API typu SaaS, dzięki czemu agent nigdy nie przechowuje tokenów dostawcy. Jest to brama typu source-available od OOMOL Lab, obecnie licencjonowana na zmodyfikowanej licencji Apache 2.0 z dodatkowymi warunkami. Wydania do wersji v1.9.4 pozostają na licencji Apache 2.0; wersja v1.9.5 wprowadziła zmiany. Świadczenie hostowanej lub zarządzanej usługi, której główną wartością jest funkcjonalność OpenConnector, wymaga licencji komercyjnej od OOMOL. Narzędzie działa jako jeden kontener, przechowuje stan w pojedynczym pliku SQLite i udostępnia akcje dostawców przez HTTP oraz MCP (model context protocol).

Problemy zaczynają się przy drugiej integracji. Każdy dostawca posiada własny przepływ OAuth (open authorization), własny czas życia tokena odświeżania oraz własne nazwy zakresów (scope). Ręczne podłączanie pięciu dostawców do agenta oznacza konieczność stworzenia pięciu procedur obsługi przekierowań, pięciu magazynów poświadczeń oraz pięciu pętli odświeżania, które muszą zostać wykonane przed wygaśnięciem tokena. Prawie nikt nie pisze takiego kodu samodzielnie. Zamiast tego generuje się jeden długożyjący osobisty token dostępu (personal access token) dla każdej usługi i wkleja go do konfiguracji agenta, pliku środowiskowego lub bezpośrednio do promptu. Taki token jest następnie odczytywalny przez każde narzędzie uruchamiane przez agenta i trafia do transkrypcji, co prowadzi do awarii opisanej w utrzymywanie sekretów poza zasięgiem agentów AI.

Brama uwierzytelniająca dzieli poświadczenie na dwie części. Brama przechowuje poświadczenie dostawcy i obsługuje przepływ OAuth. Agent otrzymuje token wykonawczy, który jest ważny wyłącznie w relacji z bramą. Gdy agent wywołuje akcję, brama ładuje zapisane poświadczenie, wstrzykuje je do wychodzącego żądania po stronie serwera i zwraca jedynie treść odpowiedzi. Agent nigdy nie otrzymuje tokena dostępu dostawcy, więc wyciek transkrypcji agenta skutkuje utratą jedynie jednego, możliwego do unieważnienia tokena wykonawczego, zamiast całego konta GitHub.

Katalog reklamuje ponad 1000 dostawców i 10 000 gotowych akcji, co jest daną własną projektu, której nie można zweryfikować z zewnątrz. Można natomiast zweryfikować strukturę: jeden punkt końcowy HTTP na akcję, jedno zapisane połączenie na dostawcę, jeden token na agenta. Jeśli strona kliencka agenta jest jeszcze nowością, a terminy takie jak tool call czy MCP server nie zostały jeszcze w pełni ustalone, ścieżka opisana w jak uczyć się agentów AI od podstaw pozwala zbudować pętlę, narzędzia oraz nawyki bezpieczeństwa, które brama taka jak ta zakłada jako już posiadane.

Dlaczego warto hostować Open Connector samodzielnie zamiast korzystać z zewnętrznej usługi typu connector

Zewnętrzna usługa typu connector wykonuje tę samą pracę i przechowuje tokeny odświeżania dla każdego podłączonego dostawcy. Token odświeżania dla Google lub GitHub to długowieczny klucz dostępu do poczty oraz repozytoriów. Naruszenie bezpieczeństwa u dostawcy staje się naruszeniem bezpieczeństwa użytkownika. Samodzielne hostowanie przenosi te dane do bazy SQLite na maszynie wynajmowanej i administrowanej przez użytkownika, zabezpieczonej kluczem, który nigdy nie opuszcza serwera.

Przed rozpoczęciem należy jasno określić koszty. Ten VPS staje się najważniejszym serwerem w infrastrukturze. Przechowuje on aktywne poświadczenia do kilkunastu usług w jednym pliku, dlatego wymaga traktowania na równi z hostem menedżera haseł: firewalla udostępniającego wyłącznie port 443, braku współdzielonych kont, kopii zapasowej, która została przynajmniej raz przetestowana pod kątem przywracania, oraz alertów w przypadku braku odpowiedzi serwera. Jeśli na danej maszynie nie byłoby bezpiecznie przechowywać skarbca haseł, nie należy na niej również uruchamiać usługi connector.

Przypnij wersję przed rozpoczęciem instalacji

Open Connector jest młodym projektem. Niniejszy przewodnik utrzymuje wersję v1.3.3, opublikowaną 30 lipca 2026 roku, jako przypiętą migawkę instalacyjną na dzień 1 sierpnia 2026 roku. Nie jest to już najnowsze wydanie. Rejestr publikuje również tag tip, budowany z najnowszego commita w gałęzi main.

W tak nowym projekcie zmienne tagi są często aktualizowane. Tag docker compose pull, który przeskakuje dwa wydania, może zmienić endpoint, od którego zależy agent, co wymusi poświęcenie wieczoru na debugowanie problemu z agentem. Przypnij obraz do tagu wydania i aktualizuj go w wybranym przez siebie momencie, po uprzednim zapoznaniu się z informacjami o wydaniu.

Wdrożenie Open Connector za terminacją TLS na własnym VPS

Przed uruchomieniem kontenera wymagane są:

• Docker Engine 28.0.0 lub nowszy z wtyczką Compose, na systemie Ubuntu 24.04 lub zbliżonym
• nazwa hosta, której rekord A wskazuje na ten VPS, na przykład connect.example.com
• reverse proxy, które już obsługuje terminację TLS (transport layer security) dla tej nazwy hosta
• dwa losowe sekrety, wygenerowane poniżej

Przewodnik Traefik reverse proxy dla wielu aplikacji Docker Compose opisuje konfigurację proxy. Analogiczny proces obsługi certyfikatów, od początku do końca dla pojedynczej aplikacji, znajduje się w poradniku n8n na VPS z Dockerem i HTTPS.

Najpierw wygeneruj sekrety. Klucz szyfrujący zabezpiecza przechowywane dane uwierzytelniające. Token administratora chroni konsolę webową oraz cały interfejs /api. Żaden z nich nie posiada wartości domyślnej, a środowisko uruchomieniowe wystartuje bez nich, co nie jest zalecane.

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

Skopiuj obie wartości do menedżera haseł przed pierwszym uruchomieniem. Klucz szyfrujący nie posiada ścieżki odzyskiwania, a przyczyna tego stanu rzeczy znajduje się na liście awarii poniżej.

Teraz compose.yaml. Różni się on od przykładu upstream w dwóch miejscach i oba są istotne.

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:

Pierwsza zmiana to przypięty tag zamiast latest. Druga to port. Plik upstream publikuje 3000:3000, co wiąże usługę z każdym interfejsem na hoście. Docker zapisuje opublikowane porty w tablicy NAT (network address translation), zanim łańcuch filtrów ufw przetworzy pakiet, dlatego ufw deny 3000 nie zamyka tego portu – jest to pułapka opisana w dlaczego porty Dockera omijają ufw. Zapis 127.0.0.1:3000:3000 publikuje usługę wyłącznie na interfejsie loopback, a reverse proxy łączy się z tego samego hosta. Przed wersją Docker Engine 28.0.0 hosty w tym samym segmencie L2 mogły uzyskać dostęp do portów opublikowanych na localhost, dlatego ten przewodnik wymaga wersji 28.0.0 lub nowszej.

Znacznik :? oznacza każdą zmienną jako wymaganą, dzięki czemu stos odmawia uruchomienia, gdy brakuje .env, zamiast startować z niezaszyfrowanymi danymi. Przechowywanie wartości w .env, a nie w pliku compose, jest wzorcem opisanym w pliki env i sekrety w Docker Compose. Utrzymuj /v1 oraz /mcp jako prywatne w reverse proxy, dopóki nie utworzysz pierwszego tokena środowiska uruchomieniowego poniżej.

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 odpowiada na { "ok": true }, gdy środowisko uruchomieniowe jest gotowe. ss musi zwrócić 127.0.0.1:3000. Linia zawierająca 0.0.0.0:3000 oznacza, że proces nasłuchujący jest powiązany z każdym interfejsem IPv4, ale nie dowodzi dostępności z Internetu: firewalle upstream lub reguły w łańcuchu DOCKER-USER Dockera nadal mogą blokować ruch zewnętrzny. Błąd "Connection refused" podczas sprawdzania stanu oznacza, że kontener jeszcze nie nasłuchuje, więc przed ingerencją w proxy należy sprawdzić logi.

    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"

Dlaczego wywołania zwrotne OAuth wymagają poprawnego źródła (origin)

OOMOL_CONNECT_ORIGIN to ustawienie, które jest często pomijane, a jego brak powoduje błędy OAuth przypominające usterki po stronie dostawcy. Środowisko uruchomieniowe buduje URI przekierowania na podstawie tego źródła, w formacie <origin>/oauth/callback. Jeśli pozostanie nieustawione, źródło domyślnie przyjmuje wartość http://localhost:3000, więc środowisko wysyła do dostawcy URI przekierowania http://localhost:3000/oauth/callback, podczas gdy aplikacja OAuth ma zarejestrowane https://connect.example.com/oauth/callback. Ciągi te różnią się, dlatego GitHub zwraca błąd:

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

Dostawca OAuth przekierowuje przeglądarkę z powrotem na ten URI, więc adres musi być osiągalny dla tej przeglądarki. OAuth nie wymaga uniwersalnie publicznej nazwy hosta: dokumentacja OpenConnector opisuje wywołania zwrotne GitHub pod adresem http://localhost:3000/oauth/callback. To wdrożenie na VPS wykorzystuje nazwę hosta oraz certyfikat, dzięki czemu przeglądarka dociera do bramy przez jej źródło HTTPS. Ustaw źródło przed pierwszym uruchomieniem, ponieważ wartość ta jest odczytywana podczas startu: po edycji .env lub compose.yaml, uruchom ponownie docker compose up -d, aby zastosować zmiany.

Podłączanie pierwszego dostawcy przez OAuth

Najpierw utwórz aplikację OAuth u dostawcy. W serwisie GitHub ścieżka prowadzi przez Settings, następnie Developer settings, potem OAuth Apps i New OAuth App. Ustaw adres URL wywołania zwrotnego autoryzacji na https://connect.example.com/oauth/callback. Zachowaj identyfikator klienta (client ID) oraz klucz tajny klienta (client secret).

Każde wywołanie /api przenosi token administratora, dlatego wyeksportuj go jednorazowo dla bieżącej sesji powłoki.

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

To zestawienie pokazuje identyfikator URI przekierowania, którego środowisko uruchomieniowe oczekuje dla każdego dostawcy. Jest to najszybszy sposób sprawdzenia, czy zmiana źródła (origin) weszła w życie. Jeśli nadal widnieje tam localhost, kontener działa ze starą wartością, a proces OAuth zakończy się niepowodzeniem w ostatnim kroku.

Zapisz poświadczenia klienta, a następnie rozpocznij autoryzację.

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"}'

Drugie wywołanie zwraca authorizationUrl. Otwórz ten adres w przeglądarce, zatwierdź zakresy (scopes), a dostawca przekieruje przeglądarkę z powrotem do /oauth/callback, gdzie środowisko uruchomieniowe wymieni kod i zapisze poświadczenia. Konsola internetowa w Twoim źródle przeprowadza te same kroki za pomocą formularza, korzystając z tego samego tokena administratora. Dostawcy używający zwykłego klucza API pomijają cały ten proces: PUT /api/connections/<service> wraz z {"authType":"api_key","values":{"apiKey":"..."}} zapisuje klucz bezpośrednio.

Nadaj każdemu agentowi token wykonawczy, nigdy dane uwierzytelniające

Agent uwierzytelnia się w bramie za pomocą tokena wykonawczego, który generuje admin API.

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"}'

Odpowiedź zawiera token rozpoczynający się od oct_. Należy wydać jeden token na agenta i nazwać go zgodnie z nazwą tego agenta, ponieważ cofnięcie uprawnień dla niezidentyfikowanego tokena oznacza konieczność unieważnienia wszystkich. Następnie agent wywołuje akcje za pośrednictwem standardowego protokołu HTTP.

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":{}}'

Poprawna odpowiedź to koperta, której pole success ma wartość true, a ładunek dostawcy znajduje się pod data. Token GitHub nie występuje w tej odpowiedzi. W przypadku klienta MCP należy wskazać go na https://connect.example.com/mcp z tym samym nagłówkiem bearer, a brama udostępni narzędzia do wykrywania, takie jak search_actions oraz execute_action, zamiast jednego narzędzia na API, co pozwala zachować krótką listę narzędzi agenta. Uruchamianie serwerów MCP na VPS opisuje stronę kliencką tej konfiguracji.

Przed zakończeniem prac należy wykonać jeszcze jedną kontrolę. Należy powtórzyć wywołanie akcji z usuniętym nagłówkiem authorization. Szybki start projektu wywołuje /v1 bez żadnego tokena bearer, więc instalacja bez skonfigurowanego uwierzytelniania wykonawczego wykona akcje dla każdego, kto ma dostęp do portu. Jeśli nieuwierzytelnione wywołanie zakończy się powodzeniem, istnieją dwa rozwiązania: skonfigurować tokeny wykonawcze i potwierdzić, że anonimowe wywołanie teraz kończy się błędem, lub ograniczyć dostęp do /api, /v1 oraz /mcp na reverse proxy wyłącznie do adresów, z których łączą się agenci. Adres /oauth/callback musi być osiągalny dla przeglądarki kończącej autoryzację; nie musi być on otwarty dla całego Internetu.

Ograniczenie listy działań do niezbędnego minimum

Brama z tysiącem dostawców w tle stanowi rozległą powierzchnię ataku dla modelu językowego. Powierzchnia ta powiększa się, gdy model zaczyna przetwarzać tekst, którego sam nie wygenerował, ponieważ strona zwrócona przez własną instancję SearXNG odpowiadającą na zapytania agenta może zawierać instrukcje wymierzone w działania, do których agent ma uprawnienia. Ta sama powściągliwość, która sprawia, że agent programistyczny wprowadza najmniejszą działającą zmianę, powinna dotyczyć jego uprawnień: należy przyznać tylko te działania, które są faktycznie wymagane do wykonania zadania, i żadne inne. Dwa mechanizmy kontrolne pozwalają na zawężenie tych uprawnień.

OOMOL_CONNECT_ALLOWED_ACTIONS przyjmuje listę dozwolonych działań rozdzielonych przecinkami i obsługuje service.* oraz *. OOMOL_CONNECT_BLOCKED_ACTIONS to lista zabronionych działań, która ma priorytet. Ustawienie listy dozwolonych na github.get_current_user,github.list_issues oznacza, że każde inne działanie zostanie odrzucone, niezależnie od żądania agenta, co stanowi różnicę między błędem a incydentem bezpieczeństwa. Tokeny uruchomieniowe nakładają własne reguły działań na reguły globalne, a ich lista allowedProxies jest domyślnie pusta, więc POST /v1/proxy/:service jest odrzucane, dopóki nie zostanie jawnie przyznane. Ten punkt końcowy proxy przekazuje surowe żądanie do dostawcy wraz z dołączonymi danymi uwierzytelniającymi, dlatego należy pozostawić go pustym, chyba że wymaga go konkretny agent.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK domyślnie przyjmuje wartość false, co uniemożliwia połączeniu z samodzielnie hostowanym dostawcą wskazywanie na adresy prywatne, takie jak usługa metadanych chmury pod adresem 169.254.169.254 lub baza danych w tej samej sieci. Należy pozostawić tę opcję wyłączoną. Należy ją włączyć tylko dla dostawcy hostowanego we własnym zakresie.

Tworzenie kopii zapasowej serwera przechowującego wszystkie tokeny

Dwie rzeczy mają znaczenie i każda z nich jest bezużyteczna bez drugiej. Baza danych w /app/data/connect.sqlite wewnątrz wolumenu connector-data przechowuje zabezpieczone poświadczenia. Klucz szyfrujący w .env służy do ich odszyfrowania. Kopia zapasowa wolumenu bez klucza nie pozwala na odzyskanie danych, a sam klucz bez wolumenu jest bezużyteczny, dlatego klucz powinien znajdować się w menedżerze haseł, a wolumen w standardowym cyklu kopii zapasowych.

Zatrzymaj kontener przed skopiowaniem pliku SQLite, ponieważ kopia wykonana w trakcie zapisu może zostać przywrócona jako uszkodzona baza danych.

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

Nazwa wolumenu to nazwa katalogu projektu z dodanym _connector-data, dlatego pierwsze polecenie jest niezbędne: wklej właściwą nazwę do trzeciego polecenia. Wyślij archiwum z VPS, korzystając z kopii zapasowych restic z VPS, co szyfruje dane przed ich wysłaniem, ponieważ archiwum to stanowi magazyn poświadczeń.

Środowisko uruchomieniowe przechowuje ostatnie wykonane akcje jako rekordy audytu, domyślnie 5000 z nich, dzięki czemu konsola może wskazać, który agent wykonał daną operację i kiedy. Ten dziennik jest pierwszym miejscem, które należy sprawdzić, gdy agent zachowuje się w sposób nietypowy. Skieruj również stronę statusu Uptime Kuma na https://connect.example.com/health. Gdy brama przestaje odpowiadać, agenci zgłaszają błędy w niejasny sposób, a wiedza o tym, że brama nie działa, pozwala zaoszczędzić godzinę analizowania danych wyjściowych agenta.

Co ulega awarii i jaki komunikat zobaczysz

redirect_uri_mismatch u dostawcy. Adres źródłowy i zarejestrowany adres URL wywołania zwrotnego (callback URL) różnią się. Porównaj dokładny ciąg znaków z /api/oauth/configs z ustawieniami aplikacji u dostawcy, uwzględniając https w odniesieniu do http oraz ewentualny końcowy ukośnik.

Każde wywołanie /api zwraca błąd 401. Brakuje nagłówka tokena administratora lub zawiera on błąd. Nagłówek to Authorization: Bearer <token>, a konsola internetowa wymaga tego samego tokena.

Kontener działa, a poświadczenia są zapisane otwartym tekstem. Dzieje się tak, gdy OOMOL_CONNECT_ENCRYPTION_KEY nigdy nie dociera do kontenera, ponieważ środowisko uruchomieniowe przechowuje rekordy poświadczeń bez szyfrowania, zamiast odmówić uruchomienia. Zweryfikuj to we własnej instalacji: połącz dostawcę z rozpoznawalnym kluczem API, a następnie wyszukaj go w bazie danych.

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

Wynik powyżej 0 oznacza, że klucz nie jest aktywny. Sprawdź, czy .env znajduje się w tym samym katalogu co compose.yaml oraz czy docker compose config wyświetla odpowiednią wartość. Gdy klucz jest ustawiony, to samo wyszukiwanie zwraca 0, ponieważ rekord jest zabezpieczony za pomocą AES-256-GCM (Advanced Encryption Standard, klucz 256-bitowy, tryb Galois/Counter).

Po przywróceniu danych nic nie ulega deszyfracji. Klucz szyfrujący został zmieniony lub utracony. Zgodnie z założeniami projektowymi nigdy nie jest on zapisywany obok danych, więc nie istnieje ścieżka odzyskiwania ani wsparcie techniczne, które mogłoby pomóc. Połącz ponownie każdego dostawcę. Rotacja jest obsługiwana za pomocą oddzielnej zmiennej klucza oraz polecenia danych w środowisku uruchomieniowym, dlatego przed wykonaniem rotacji zapoznaj się z aktualnymi informacjami o wydaniu (release notes).

Agent zgłasza błąd dotyczący akcji widocznej w katalogu. Wykrywanie i wykonywanie to odrębne procesy. Akcja może pojawić się w search_actions, a mimo to zostać odrzucona przez OOMOL_CONNECT_ALLOWED_ACTIONS, listę zabronionych (denylist) lub reguły przypisane do danego tokena środowiska uruchomieniowego.

Aktualizacje. Wykonaj kopię zapasową wolumenu, zmień tag obrazu na nową wersję, a następnie wykonaj docker compose pull && docker compose up -d. Monitoruj docker compose logs -n 50 connector pod kątem wpisu o migracji, a następnie ponownie uruchom test sprawności (health check) i wykonaj jedną rzeczywistą akcję, zanim ponownie zaufasz systemowi. Wycofanie zmian (rollback) polega na przywróceniu starego tagu, co jest możliwe tylko wtedy, gdy został on wcześniej przypięty (pinned).

FAQ

Czy do samodzielnego hostowania Open Connector potrzebna jest domena publiczna?

W przypadku dostawców korzystających z klucza API nie: wystarczy brama na 127.0.0.1. OAuth również nie zawsze tego wymaga: OpenConnector dokumentuje lokalny callback GitHub jako http://localhost:3000/oauth/callback. Przeglądarka kończąca autoryzację musi mieć możliwość połączenia się z adresem URL callbacku. W przypadku wdrożenia na VPS, przed pierwszym uruchomieniem ustaw OOMOL_CONNECT_ORIGIN na swoją nazwę hosta https:// i zarejestruj <origin>/oauth/callback w aplikacji OAuth dostawcy.

Co się stanie, jeśli zgubię klucz szyfrujący Open Connector?

Zapisane poświadczenia nie mogą zostać odszyfrowane i nie ma możliwości ich odzyskania. Klucz celowo nie jest przechowywany razem z danymi, więc nikt posiadający bazę danych nie może ich odczytać, włącznie z użytkownikiem. Jedyną opcją jest ustawienie nowego klucza i ponowne połączenie każdego dostawcy. Klucz należy przechowywać w menedżerze haseł, a bazę danych w rotacji kopii zapasowych, ponieważ przywrócenie danych wymaga obu tych elementów.

Czy mój agent AI widzi token dostępu dostawcy?

Nie, gdy wywołuje go przez bramę. Agent uwierzytelnia się za pomocą tokena wykonawczego zaczynającego się od oct_, a brama wstrzykuje poświadczenia dostawcy do żądania wychodzącego na serwerze, zwracając jedynie odpowiedź. Dwie sytuacje naruszają tę zasadę: punkt końcowy /v1/proxy/:service, który przekazuje surowe żądania z dołączonymi poświadczeniami (dlatego uprawnienia są domyślnie puste), oraz samodzielne wklejenie klucza API do agenta, co całkowicie pomija bramę.

Czy brama powinna być dostępna z publicznego Internetu?

Callback OAuth musi być dostępny dla przeglądarki kończącej autoryzację, co nie wymaga dostępu z całego Internetu. W przypadku Docker Engine 28.0.0 lub nowszego oraz domyślnej sieci typu bridge, opublikuj port kontenera na 127.0.0.1, aby opublikowany port był dostępny tylko z hosta, a następnie umieść przed nim reverse proxy. Starsze wersje Docker pozwalały hostom w tym samym segmencie L2 na dostęp do portów opublikowanych na localhost. Następnie przetestuj jedno wywołanie akcji bez nagłówka authorization. Jeśli zakończy się sukcesem, ogranicz /api, /v1 oraz /mcp na proxy do adresów używanych przez agentów, aż do momentu, gdy działać będą tylko uwierzytelnione wywołania.

Czy Open Connector jest gotowy do zastosowań produkcyjnych?

Obecne wydania korzystają ze zmodyfikowanej licencji Apache 2.0 z dodatkowymi warunkami; wydania do v1.9.4, w tym przypięta wersja v1.3.3, pozostają na licencji Apache 2.0. Hostowana lub zarządzana usługa konektora, której główną wartością jest funkcjonalność OpenConnector, wymaga licencji komercyjnej od OOMOL zgodnie z aktualną licencją. Polecenia instalacji v1.3.3 pozostają migawką z 1 sierpnia 2026, a to wydanie zostało opublikowane 30 lipca 2026. Uruchamiaj wersję przypiętą do tagu wydania, nigdy na latest lub tip, przed każdą aktualizacją czytaj informacje o wydaniu i przechowuj kopię zapasową wolumenu, którą przynajmniej raz przetestowano pod kątem przywracania. Projekt jest solidny dla serwera, którego jesteś właścicielem, a ryzyko wynika z częstych zmian wersji, a nie z samej architektury.