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

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

אירוח עצמי של Open Connector מציב שער אימות אחד בין סוכני ה־AI שלכם לבין כל API של software as a service (SaaS) שהם קוראים לו, כך שהסוכן אינו מחזיק אף פעם אסימון של ספק. זהו שער שקוד המקור שלו זמין, מבית OOMOL Lab, והוא מורשה כיום לפי רישיון Apache 2.0 ששונה בתנאים נוספים. גרסאות עד v1.9.4, כולל, נשארות תחת Apache 2.0; ב־v1.9.5 הוכנס השינוי. אספקת שירות מתארח או מנוהל שהערך העיקרי שלו הוא הפונקציונליות של OpenConnector מחייבת רישיון מסחרי מ־OOMOL. הוא פועל כמכולה אחת, שומר את מצבו בקובץ SQLite יחיד, וחושף פעולות של ספקים באמצעות HTTP ובאמצעות MCP (model context protocol).

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

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

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

מדוע לארח בעצמך את Open Connector במקום להשתמש בשירות connector מתארח

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

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

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

Open Connector הוא פרויקט צעיר. מדריך זה נועל את v1.3.3, שפורסמה ב־30 July 2026, כגרסת ההתקנה ל־1 August 2026. זו כבר אינה הגרסה החדשה ביותר. ה־registry מפרסם גם תגית tip, שנבנתה מה־commit החדש ביותר בענף main.

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

פריסת Open Connector מאחורי TLS ב־VPS שבבעלותכם

לפני שהמכולה מופעלת, ודאו שיש לכם:

• Docker Engine בגרסה 28.0.0 ומעלה, עם תוסף Compose, על Ubuntu 24.04 או על מערכת דומה
• שם מארח שרשומת ה־A שלו מפנה ל־VPS הזה, לדוגמה connect.example.com
• reverse proxy שכבר מבצע סיום TLS (אבטחת שכבת התעבורה) עבור שם המארח הזה
• שני secrets אקראיים, שייווצרו בהמשך

המדריך reverse proxy של Traefik עבור כמה יישומי Docker Compose עוסק בצד של ה־proxy. תהליך הגדרת התעודות המלא, מההתחלה ועד הסוף עבור יישום יחיד, מופיע במדריך n8n על VPS עם Docker ו־HTTPS.

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

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:

השינוי הראשון הוא תג מקובע במקום latest. השני הוא הפורט. הקובץ במעלה הזרם מפרסם את 3000:3000, שקושר את הפורט לכל הממשקים במארח. Docker כותב את הפורטים שפורסמו בטבלת ה־NAT (תרגום כתובות רשת) לפני שחבילת המידע מגיעה אי פעם לשרשרת הסינון של ufw, ולכן ufw deny 3000 אינו סוגר את הפורט הזה. זהו המכשול המתואר במדריך מדוע פורטים של Docker עוקפים את ufw. כתיבת 127.0.0.1:3000:3000 מפרסמת את הפורט בממשק loopback בלבד, וה־reverse proxy שלכם מתחבר מאותו מארח. לפני Docker Engine 28.0.0, מארחים באותו מקטע L2 יכלו להגיע לפורטים שפורסמו ל־localhost, ולכן המדריך הזה דורש גרסה 28.0.0 ומעלה.

ה־:? מסמן שכל משתנה הוא חובה, ולכן ה־stack מסרב להתחיל כאשר .env חסר, במקום להתחיל עם אישורים שאינם מוצפנים. שמירת הערכים ב־.env במקום בקובץ ה־compose היא התבנית המתוארת במדריך קובצי סביבה ו־secrets ב־Docker Compose. שמרו על /v1 ועל /mcp פרטיים ב־reverse proxy עד שתיצרו את אסימון ה־runtime הראשון בהמשך.

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 } לאחר שה־runtime פועל. ss חייב להדפיס 127.0.0.1:3000. שורה שמכילה 0.0.0.0:3000 פירושה שה־listener קשור לכל ממשקי IPv4, אך היא אינה מוכיחה שהשירות נגיש מהאינטרנט: חומות אש במעלה הזרם או כללים בשרשרת DOCKER-USER של Docker עדיין יכולים לחסום תעבורה חיצונית. שגיאת Connection refused בבדיקת התקינות פירושה שהמכולה עדיין אינה מאזינה, ולכן קראו את הלוגים לפני שתשנו את ה־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"

מדוע callbacks של OAuth מחייבים origin נכון

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

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

ספק OAuth מפנה את הדפדפן חזרה לכתובת זו, ולכן הדפדפן חייב להיות מסוגל להגיע אליה. OAuth אינו מחייב בכל מקרה hostname ציבורי: התיעוד של OpenConnector מציג callbacks של GitHub ב־http://localhost:3000/oauth/callback. בפריסה זו על VPS נעשה שימוש ב־hostname ובתעודה, כדי שהדפדפן יגיע אל ה־gateway דרך ה־HTTPS origin שלו. הגדירו את ה־origin לפני ההפעלה הראשונה, משום שהערך נקרא בזמן האתחול: לאחר עריכת .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 ישירות.

יש להקצות לכל agent אסימון runtime, ולא את ה־credential

ה־agent מזדהה מול ה־gateway באמצעות אסימון runtime, שה־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_. הנפיקו אסימון אחד לכל agent ותנו לו שם לפי שם ה־agent, משום שביטול אסימון שאי־אפשר לזהות מחייב ביטול של כולם. לאחר מכן ה־agent קורא ל־actions באמצעות 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, ומטען הספק נמצא תחת data. אסימון GitHub אינו מופיע בתגובה בשום מקום. עבור לקוח MCP, הגדירו את היעד שלו ל־https://connect.example.com/mcp עם אותו header מסוג bearer. ה־gateway מציע כלי discovery כגון search_actions ו־execute_action, במקום כלי אחד לכל API. כך נשארת רשימת הכלים של ה־agent קצרה. הפעלת שרתי MCP ב־VPS מכסה את צד הלקוח של החיבור הזה.

בצעו בדיקה נוספת לפני שאתם מסיימים. חזרו על קריאת ה־action לאחר מחיקת ה־header authorization. ה־quickstart של הפרויקט עצמו קורא ל־/v1 ללא bearer כלל. לכן התקנה שבה לא הוגדרה autenticação של runtime תבצע actions עבור כל מי שיכול להגיע אל הפורט. אם הקריאה ללא אימות מצליחה, עומדות בפניכם שתי אפשרויות: להגדיר אסימוני runtime ולוודא שהקריאה האנונימית נכשלת כעת, או להגביל ב־reverse proxy את /api, /v1 ו־/mcp לכתובות שמהן ה־agents שלכם מגיעים. /oauth/callback חייב להיות נגיש לדפדפן שמשלים את תהליך ההרשאה; הוא אינו חייב להיות פתוח לכל האינטרנט.

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

שער (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 אינו מחייב זאת באופן גורף: OpenConnector מתעד callback מקומי של GitHub ב־http://localhost:3000/oauth/callback. הדפדפן שמשלים את ההרשאה חייב להגיע ל־callback URL. בפריסת VPS זו, הגדירו את OOMOL_CONNECT_ORIGIN ל־hostname של https:// לפני ההפעלה הראשונה, ורשמו את <origin>/oauth/callback ב־OAuth app של הספק.

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

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

האם סוכן ה־AI שלי יכול לראות את אסימון הגישה של הספק?

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

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

ה־OAuth callback חייב להיות נגיש לדפדפן שמשלים את ההרשאה, אך אין צורך לאפשר גישה מכל רחבי האינטרנט. ב־Docker Engine 28.0.0 או בגרסה חדשה יותר, עם ברירת המחדל של bridge networking, פרסמו את פורט המכולה על 127.0.0.1 כדי שהפורט המפורסם יהיה נגיש רק מהמארח, והציבו לפניו reverse proxy. גרסאות ישנות יותר של Docker אפשרו למארחים באותו מקטע L2 להגיע לפורטים שפורסמו על localhost. לאחר מכן בדקו קריאה אחת לפעולה ללא כותרת authorization. אם היא מצליחה, הגבילו ב־proxy את /api, /v1 ו־/mcp לכתובות שמהן הסוכנים שלכם פועלים, עד שרק קריאות שעברו אימות יצליחו.

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

גרסאות נוכחיות משתמשות ברישיון Apache 2.0 ששונה באמצעות תנאים נוספים; גרסאות עד v1.9.4, כולל v1.3.3 המקובעת, נותרות תחת Apache 2.0. שירות connector מתארח או מנוהל, שהערך העיקרי שלו הוא הפונקציונליות של OpenConnector, דורש רישיון מסחרי מ־OOMOL בהתאם לרישיון הנוכחי. פקודות ההתקנה של v1.3.3 הן snapshot מתאריך 1 August 2026, והגרסה הזו שוחררה ב־30 July 2026. הפעילו אותה כשהיא מקובעת ל־release tag, לעולם לא על latest או tip, קראו את release notes לפני כל שדרוג, ושמרו גיבוי של volume ששחזרתם פעם אחת. התכנון מתאים לשרת שנמצא בבעלותכם; הסיכון הוא תחלופת הגרסאות, לא הארכיטקטורה.