אירוח עצמי של Open Connector עבור סוכני AI

מה עושה Open Connector עבור סוכן AI

אירוח עצמי של Open Connector מציב שער אימות (auth gateway) יחיד בין סוכני ה-AI שלכם לבין כל ממשק API של תוכנה כשירות (SaaS) שהם קוראים לו, כך שהסוכן לעולם אינו מחזיק ב-token של ספק השירות. זהו שער בקוד פתוח מבית OOMOL Lab, המופץ תחת רישיון Apache 2.0. הוא רץ כמכולה (container) אחת, שומר את מצבו בקובץ SQLite יחיד, וחושף פעולות של ספקים באמצעות HTTP ו-MCP (פרוטוקול הקשר למודל).

הקושי מתחיל באינטגרציה השנייה. לכל ספק יש תהליך OAuth (אימות פתוח) משלו, זמן חיים שונה ל-refresh token, ושמות scope ייחודיים. חיבור ידני של חמישה ספקים לסוכן משמעו חמישה מטפלי redirect, חמישה מאגרי הרשאות, וחמישה לולאות רענון שחייבות לרוץ לפני ש-token פג תוקף. כמעט אף אחד לא כותב קוד כזה. במקום זאת, יוצרים personal access token אחד בעל תוקף ארוך לכל שירות ומדביקים אותו בתצורת הסוכן, בקובץ סביבה, או ב-prompt עצמו. ה-token הזה הופך לקריא עבור כל כלי שהסוכן מריץ, והוא מגיע לתוך התמליל (transcript), מה שמוביל לכשל שמתואר ב-שמירה על סודות מחוץ לסוכני AI.

שער אימות מפצל את פרטי ההרשאה לשניים. השער מאחסן את פרטי ההרשאה של הספק ומריץ את תהליך ה-OAuth. הסוכן מקבל runtime token שתקף אך ורק מול השער. כאשר הסוכן קורא לפעולה, השער טוען את פרטי ההרשאה השמורים, מזריק אותם לבקשה היוצאת בצד השרת, ומחזיר רק את גוף התגובה. הסוכן לעולם אינו מקבל את ה-access token של הספק, כך שתמליל סוכן שדלף עולה לכם ב-runtime token אחד שניתן לביטול, במקום בחשבון ה-GitHub שלכם.

הקטלוג מפרסם יותר מ-1,000 ספקים ו-10,000 פעולות מוכנות מראש; אלו נתונים של הפרויקט עצמו ולא משהו שניתן לאמת מבחוץ. מה שכן ניתן לאמת הוא המבנה: נקודת קצה (endpoint) אחת ב-HTTP לכל פעולה, חיבור שמור אחד לכל ספק, ו-token אחד לכל סוכן. אם הצד של הסוכן בתחום זה עדיין חדש ומונחים כמו tool call או MCP server טרם התקבעו, המסלול המדורג ב-איך ללמוד סוכני AI מאפס בונה את הלולאה, את הכלים, ואת הרגלי הבטיחות ששער מסוג זה מניח שכבר רכשתם.

מדוע לארח באופן עצמי את Open Connector במקום להשתמש בשירות מחבר מנוהל

שירות מחבר מנוהל מבצע את אותה עבודה, והוא מחזיק בתוכו את ה-refresh tokens עבור כל ספק שאליו אתם מתחברים. refresh token עבור Google או GitHub הוא מפתח בעל תוקף ארוך לתיבת הדואר ולמאגרים שלכם, והוא בדרך כלל נשאר תקף גם לאחר שינוי סיסמה. פריצה אליהם הופכת לפריצה אליכם. אירוח עצמי מעביר את הרשומות הללו לקובץ SQLite על מכונה שאתם שוכרים ומנהלים, כשהן חתומות במפתח שלעולם לא עוזב את השרת שלכם.

אמרו את העלות בקול רם לפני שאתם מתחילים. ה-VPS הזה הופך לשרת החשוב ביותר שאתם מריצים. הוא מחזיק אישורי גישה פעילים עבור תריסר שירותים בקובץ אחד, ולכן הוא ראוי ליחס שאתם מעניקים למארח של מנהל סיסמאות: firewall שחושף רק את פורט 443, ללא כניסות משותפות, גיבוי שבאמת שחזרתם פעם אחת, והתראה כאשר הוא מפסיק להגיב. אם לא הייתם מציבים את כספת הסיסמאות שלכם על השרת הזה, אל תציבו עליו גם את ה-connector.

קבעו גרסה לפני התקנה של כל רכיב

Open Connector הוא פרויקט חדש. המאגר הופיע לראשונה ב-29 ביוני 2026, ונכון ל-1 באוגוסט 2026, הגרסה המתויגת העדכנית ביותר היא v1.3.3, שפורסמה ב-30 ביולי 2026 ונושאת גם את התג latest. ה-registry מפרסם גם תג tip, שנבנה מה-commit העדכני ביותר ב-main.

בפרויקט חדש כל כך, תגים דינמיים משתנים לעיתים קרובות. תג docker compose pull שקופץ בין שתי גרסאות עלול לשנות endpoint שהסוכן (agent) שלכם מסתמך עליו, ואתם תבזבזו את הערב בניסיון לאתר את התקלה כבעיה בסוכן. קבעו (pin) את ה-image לתג גרסה ספציפי, ושדרגו רק כאשר תחליטו לעשות זאת, לאחר קריאת הערות השחרור (release notes).

פריסת Open Connector מאחורי TLS בשרת VPS עצמאי

לפני הפעלת המכולה, עליך להכין:

• Docker עם תוסף Compose, על Ubuntu 24.04 או הפצה דומה.
• שם מתחם (hostname) שרשומת ה-A שלו מצביעה על ה-VPS הזה, לדוגמה connect.example.com.
• Reverse proxy שכבר מבצע TLS termination עבור שם המתחם הזה.
• שני סודות אקראיים, שיופקו להלן.

המדריך Traefik reverse proxy for multiple Docker Compose apps מכסה את צד ה-proxy. תשתית התעודות המלאה, מתחילתה ועד סופה עבור יישום בודד, מפורטת במדריך n8n on a VPS with Docker and HTTPS.

תחילה, צור את הסודות. מפתח ההצפנה מאבטח את פרטי ההתחברות השמורים. אסימון הניהול (admin token) מגן על ממשק הניהול ועל כל הממשק של /api. לאף אחד מהם אין ערך ברירת מחדל, והסביבה תעלה ללא שגיאה גם בלעדיהם.

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

העתק את שני הערכים למנהל הסיסמאות שלך כעת, לפני ההפעלה הראשונה. למפתח ההצפנה אין מנגנון שחזור, והסיבה לכך מפורטת ברשימת הכשלים בהמשך.

כעת, הגדר את compose.yaml. הקובץ שונה מהדוגמה המקורית בשני מקומות, ושניהם קריטיים.

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:

השינוי הראשון הוא שימוש ב-tag קבוע במקום latest. השינוי השני הוא הפורט. הקובץ המקורי מפרסם את 3000:3000, שמאזין לכל הממשקים במארח. Docker כותב את הפורטים המפורסמים לטבלת ה-NAT (network address translation) לפני ששרשרת ה-ufw רואה את החבילה, לכן ufw deny 3000 לא חוסם את הפורט הזה; זהו המלכוד המתואר ב-why Docker ports bypass ufw. כתיבת 127.0.0.1:3000:3000 מפרסמת את השירות על ממשק ה-loopback בלבד, וה-reverse proxy שלך מתחבר מאותו מארח.

הסימון :? מגדיר כל משתנה כחובה, כך שה-stack יסרב לעלות כאשר .env חסר, במקום לעלות עם פרטי התחברות לא מוצפנים. שמירת הערכים ב-.env במקום בקובץ ה-compose היא התבנית המומלצת ב-Docker Compose env files and 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 ישיב ל-{ "ok": true } ברגע שהסביבה תעלה. ss חייב להדפיס 127.0.0.1:3000. שורה המציגה 0.0.0.0:3000 מעידה על כך שמיפוי הפורטים נותר כפי שהיה במקור, והשער (gateway) משיב ישירות לכל האינטרנט. שגיאת Connection refused בבדיקת התקינות (health check) משמעותה שהמכולה עדיין לא מאזינה, לכן קרא את הלוגים לפני שתשנה את הגדרות ה-proxy.

    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"

מדוע OAuth מחייב שם מארח (hostname) אמיתי

OOMOL_CONNECT_ORIGIN היא ההגדרה שאנשים נוטים לדלג עליה, ודילוג עליה גורם ל־OAuth להיכשל באופן שנראה כמו באג אצל ספק השירות. סביבת הריצה בונה את ה-redirect URI שלה מתוך אותו מקור (origin), במבנה של <origin>/oauth/callback. אם לא מגדירים אותו, המקור כברירת מחדל הוא http://localhost:3000, ולכן סביבת הריצה שולחת לספק כתובת redirect URI של http://localhost:3000/oauth/callback, בעוד שאפליקציית ה-OAuth שלכם רשמה https://connect.example.com/oauth/callback. שתי המחרוזות אינן זהות, ולכן GitHub משיב:

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

ספק OAuth מפנה את הדפדפן בחזרה לאותו URI, מה שאומר שזו חייבת להיות כתובת שהעולם החיצון יכול להגיע אליה, וספקים דוחים שימוש ב-http:// פשוט עבור כל דבר שאינו localhost. זו הסיבה המלאה לכך שהטמעה זו זקוקה לשם מארח ולתעודה. הגדירו את המקור לפני ההפעלה הראשונה, כיוון שהערך נקרא בזמן העלייה: לאחר עריכת .env או compose.yaml, הריצו שוב את docker compose up -d כדי להחיל את השינויים.

חיבור הספק הראשון שלך באמצעות OAuth

תחילה, צור את אפליקציית ה-OAuth אצל הספק. ב-GitHub, הנתיב הוא Settings, לאחר מכן Developer settings, לאחר מכן OAuth Apps, ולבסוף New OAuth App. הגדר את ה-authorization callback URL ל-https://connect.example.com/oauth/callback. שמור את ה-client ID ואת ה-client secret.

כל קריאת /api נושאת את ה-admin token, לכן בצע לו export פעם אחת עבור ה-session של ה-shell.

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

הרשימה הזו מציגה את ה-redirect URI שה-runtime מצפה לו עבור כל ספק, מה שהופך אותה לבדיקה המהירה ביותר לכך שה-origin שלך הוחל. אם עדיין מופיע localhost, המכולה פועלת עם הערך הישן ותהליך ה-OAuth ייכשל בשלב האחרון.

אחסן את פרטי ה-client, ולאחר מכן התחל תהליך הרשאה.

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

הקריאה השנייה מחזירה authorizationUrl. פתח אותו בדפדפן, אשר את ה-scopes, והספק יחזיר את הדפדפן ל-/oauth/callback, שם ה-runtime מחליף את ה-code ומאחסן את ה-credential. ה-web console ב-origin שלך מבצע את אותם השלבים דרך טופס, תחת אותו ה-admin token. ספקים המשתמשים ב-API key פשוט מדלגים על כל זה: PUT /api/connections/<service> עם {"authType":"api_key","values":{"apiKey":"..."}} מאחסן את ה-key ישירות.

הקצו לכל סוכן אסימון זמן-ריצה, לעולם לא את פרטי ההזדהות

הסוכן מבצע אימות מול ה-gateway באמצעות אסימון זמן-ריצה (runtime token), המונפק על ידי ה-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"}'

התגובה מכילה אסימון המתחיל ב-oct_. הנפיקו אסימון אחד לכל סוכן ותנו לו שם בהתאם לסוכן, כיוון שביטול אסימון שאינכם יכולים לזהות משמעו ביטול של כולם. לאחר מכן, הסוכן קורא לפעולות באמצעות 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":{}}'

תשובה תקינה היא מעטפת שבה השדה success הוא true, כאשר ה-payload של ה-provider נמצא תחת data. אסימון ה-GitHub אינו מופיע בתגובה זו בשום מקום. עבור לקוח MCP, כוונו אותו ל-https://connect.example.com/mcp עם אותו ה-bearer header, וה-gateway יציע כלי גילוי כגון search_actions ו-execute_action במקום כלי אחד לכל API, מה ששומר על רשימת הכלים של הסוכן מצומצמת. המדריך הרצת שרתי MCP על גבי VPS מכסה את הצד של הלקוח בחיבור זה.

בצעו בדיקה נוספת לפני שתסיימו. חזרו על קריאת הפעולה כאשר ה-header authorization מחוק. ה-quickstart של הפרויקט עצמו קורא ל-/v1 ללא bearer כלל, לכן התקנה ללא אימות זמן-ריצה מוגדר תבצע פעולות עבור כל מי שיכול להגיע לפורט. אם הקריאה הלא-מאומתת שלכם מצליחה, יש לכם שתי דרכים לפתרון: הגדירו אסימוני זמן-ריצה וודאו שהקריאה האנונימית נכשלת כעת, או הגבילו את /api, /v1 ו-/mcp ב-reverse proxy לכתובות מהן מגיעים הסוכנים שלכם. רק /oauth/callback חייב להישאר פתוח לעולם, כיוון שזהו הנתיב היחיד לו זקוק ה-browser redirect של ה-provider.

צמצום רשימת הפעולות למינימום הנדרש לסוכן

שער (gateway) שמאחוריו אלפי ספקים יוצר שטח פנים רחב מדי עבור מודל שפה. שטח זה מתרחב ברגע שהמודל מתחיל לקרוא טקסט שהוא לא כתב בעצמו, שכן דף שמוחזר על ידי מופע SearXNG עצמאי שמשיב לחיפושי האינטרנט של הסוכן עלול להכיל הוראות המכוונות לכל פעולה שהסוכן מורשה לבצע. אותה ריסון שגורם ל-סוכן כתיבת קוד לבצע את השינוי הקטן ביותר שעובד צריך לחול גם על ההרשאות שלו: העניקו לו רק את קומץ הפעולות שהמשימה באמת דורשת, ולא מעבר לכך. שני בקרים מצמצמים זאת.

OOMOL_CONNECT_ALLOWED_ACTIONS מקבל רשימת היתרים (allowlist) מופרדת בפסיקים ומבין את service.* ו-*. OOMOL_CONNECT_BLOCKED_ACTIONS הוא רשימת החסימות (denylist), ורשימת החסימות גוברת. הגדרת רשימת ההיתרים ל-github.get_current_user,github.list_issues משמעותה שכל פעולה אחרת תסורב ללא קשר לבקשת הסוכן, וזהו ההבדל בין טעות לבין אירוע אבטחה. אסימוני זמן-ריצה (runtime tokens) נושאים כללי פעולה משלהם בנוסף לכללים הגלובליים, ורשימת ה-allowedProxies שלהם מתחילה כריקה, לכן POST /v1/proxy/:service מסורב עד שתעניקו לו הרשאה. נקודת הקצה של ה-proxy מעבירה בקשה גולמית לספק עם פרטי הזיהוי שלכם מצורפים, לכן השאירו אותה ריקה אלא אם סוכן ספציפי זקוק לה.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK מוגדר כברירת מחדל ל-false, מה שמונע מחיבור לספק שמתארח באופן עצמי להצביע על כתובת פרטית כגון שירות המטא-דאטה של הענן ב-169.254.169.254, או על מסד הנתונים שלכם באותה רשת. השאירו הגדרה זו כבויה. הפעילו אותה רק עבור ספק שאתם מארחים בעצמכם.

גיבוי השרת המכיל את כל האסימונים

שני דברים הם בעלי חשיבות, וכל אחד מהם חסר תועלת ללא השני. מסד הנתונים ב-/app/data/connect.sqlite בתוך ה-volume ששמו connector-data מכיל את פרטי הזיהוי המוצפנים. מפתח ההצפנה ב-.env משמש לפענוח שלהם. גיבוי של ה-volume ללא המפתח לא יאפשר שחזור, והמפתח ללא ה-volume לא יאפשר שחזור; לכן, יש לשמור את המפתח במנהל הסיסמאות שלכם ואת ה-volume בסבב הגיבויים הרגיל שלכם.

עצרו את ה-container לפני העתקת קובץ ה-SQLite, כיוון שהעתקה המתבצעת בזמן כתיבה עלולה להוביל לשחזור מסד נתונים פגום.

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

שם ה-volume מורכב מתיקיית הפרויקט שלכם בצירוף _connector-data, וזו הסיבה שהפקודה הראשונה מופיעה שם: הדביקו את השם האמיתי בפקודה השלישית. שלחו את הארכיון מחוץ ל-VPS באמצעות גיבויי restic מ-VPS, פעולה המצפינה את הנתונים לפני שהם עוזבים את השרת, שכן ארכיון זה הוא מאגר פרטי הזיהוי.

זמן הריצה שומר את הפעולות האחרונות כרשומות ביקורת (audit records), כברירת מחדל 5,000 רשומות, כך שהקונסולה יכולה להציג לכם איזה סוכן ביצע איזו פעולה ומתי. לוג זה הוא הדבר הראשון שיש לקרוא כאשר סוכן מתנהג בצורה חריגה. כוונו גם דף סטטוס של Uptime Kuma אל https://connect.example.com/health. כאשר ה-gateway מפסיק להגיב, סוכנים נכשלים בדרכים מבלבלות, וידיעה שה-gateway אינו זמין חוסכת שעה של קריאת פלטי סוכנים.

מה משתבש, ואיזו הודעה תראה

redirect_uri_mismatch אצל הספק. כתובת המקור וכתובת ה-callback הרשומה אינן תואמות. השווה את המחרוזת המדויקת מ-/api/oauth/configs מול הגדרות היישום אצל הספק, כולל בדיקה של https מול http וכל לוכסן (trailing slash) בסוף.

כל קריאת /api מחזירה 401. כותרת ה-admin token חסרה או שגויה. הכותרת היא Authorization: Bearer <token>, וממשק הניהול (web console) דורש את אותו האסימון.

המכולה רצה, והפרטים נשמרים בטקסט גלוי. זה מה שקורה כאשר OOMOL_CONNECT_ENCRYPTION_KEY לא מגיע למכולה, כיוון שסביבת הריצה שומרת את רשומות פרטי ההתחברות ללא הצפנה במקום לסרב לעלות. הוכח זאת בהתקנה שלך: חבר ספק עם מפתח API שניתן לזהות, ולאחר מכן חפש אותו במסד הנתונים.

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

ספירה הגבוהה מ-0 משמעותה שהמפתח אינו פעיל. ודא ש-.env נמצא באותה תיקייה כמו compose.yaml ושהערך ב-docker compose config מוצג כראוי. כאשר המפתח מוגדר, אותה חיפוש יחזיר 0, כיוון שהרשומה חתומה ב-AES-256-GCM (תקן הצפנה מתקדם, מפתח 256-ביט, מצב Galois/counter).

שום דבר לא מתפענח לאחר שחזור. מפתח ההצפנה השתנה או אבד. הוא לעולם לא נכתב לצד הנתונים, כחלק מהתכנון, לכן אין נתיב שחזור ואין כרטיס תמיכה שיכול לסייע. חבר מחדש את כל הספקים. החלפת מפתחות (rotation) נתמכת באמצעות משתנה מפתח נפרד ופקודת נתונים בסביבת הריצה; קרא את הערות הגרסה הנוכחיות לפני שתבצע החלפה כלשהי.

הסוכן מקבל שגיאה המציינת פעולה שמופיעה בקטלוג. גילוי וביצוע הם תהליכים נפרדים. פעולה יכולה להופיע ב-search_actions ועדיין להידחות על ידי OOMOL_CONNECT_ALLOWED_ACTIONS, על ידי רשימת החסימות (denylist), או על ידי הכללים של אותו אסימון סביבת ריצה.

שדרוגים. גבה את ה-volume, ערוך את תג התמונה (image tag) לגרסה החדשה, ולאחר מכן בצע docker compose pull && docker compose up -d. עקוב אחר docker compose logs -n 50 connector כדי לראות שורת הגירה (migration), והרצ מחדש את בדיקת התקינות ופעולה אחת אמיתית לפני שתסמוך על המערכת שוב. חזרה לגרסה קודמת (rollback) משמעותה החזרת התג הישן, פעולה שעובדת רק אם ביצעת לו קיבוע (pinning).

FAQ

האם אני זקוק לשם מתחם ציבורי כדי לארח את Open Connector בעצמי?

עבור ספקים המשתמשים ב-API key, לא: שער (gateway) ב-127.0.0.1 מספיק. עבור OAuth, בפועל כן. הספק מפנה את הדפדפן ל-callback URL שלך, לכן הכתובת הזו חייבת להיות נגישה מהאינטרנט הציבורי, וספקים מסרבים להשתמש ב-http:// שאינו localhost. הגדירו את OOMOL_CONNECT_ORIGIN לשם המתחם (hostname) שלכם ב-https:// לפני ההפעלה הראשונה, ורשמו את <origin>/oauth/callback באפליקציית ה-OAuth של הספק.

מה קורה אם אאבד את מפתח ההצפנה של Open Connector?

לא ניתן לפענח את פרטי ההתחברות השמורים, ואין אפשרות לשחזור. המפתח אינו נשמר לצד הנתונים בכוונה תחילה, כך שאף אחד שמחזיק במסד הנתונים לא יכול לקרוא אותם, כולל אתם. האפשרות היחידה שלכם היא להגדיר מפתח חדש ולחבר מחדש כל ספק. שמרו את המפתח במנהל סיסמאות ואת מסד הנתונים בסבב הגיבויים שלכם, כיוון ששחזור דורש את שניהם.

האם סוכן ה-AI שלי יכול לראות את ה-access token של הספק?

לא כאשר הוא מבצע קריאות דרך ה-gateway. הסוכן מבצע אימות מול ה-runtime token שמתחיל ב-oct_, וה-gateway מחדיר את פרטי ההתחברות של הספק לבקשה היוצאת בשרת, ומחזיר רק את התגובה. שני דברים מבטלים את ההגנה הזו: ה-endpoint של /v1/proxy/:service, שמעביר בקשות גולמיות עם פרטי ההתחברות שלכם מצורפים (ושההרשאות שלו מתחילות ריקות מסיבה טובה), והדבקה ידנית של API key לתוך הסוכן, מה שעוקף את ה-gateway לחלוטין.

האם ה-gateway צריך להיות נגיש מהאינטרנט הציבורי?

רק /oauth/callback צריך להיות נגיש. פרסמו את פורט המכולה ב-127.0.0.1 כדי שחוקי ה-NAT של Docker לא יחשפו אותו מעבר ל-firewall שלכם, והציבו את ה-reverse proxy מלפנים. לאחר מכן, בדקו קריאת פעולה אחת ללא ה-header של authorization. אם היא מצליחה, הגבילו את /api, /v1 ו-/mcp ב-proxy לכתובות שבהן הסוכנים שלכם משתמשים, עד שרק קריאות מאומתות יעבדו.

האם Open Connector מוכן לשימוש בסביבת ייצור (production)?

הוא מופץ תחת רישיון Apache 2.0 ומתפתח במהירות: המאגר הופיע ב-29 ביוני 2026 וגרסה v1.3.3 שוחררה ב-30 ביולי 2026, לכן התייחסו לכל מספר גרסה במדריך זה כאל תמונת מצב של 1 באוגוסט 2026. הריצו אותו כשהוא מקובע ל-release tag, לעולם לא על latest או tip, קראו את הערות השחרור לפני כל שדרוג, ושמרו גיבוי של ה-volume שביצעתם לו שחזור לפחות פעם אחת. התכנון יציב עבור שרת שבבעלותכם, והסיכון הוא קצב השינויים בגרסאות, לא הארכיטקטורה.