מנגנוני הגנה לסוכן והגדרות LDAP בזמן ריצה

עבדתי היום על שתי בעיות שונות. לשתיהן הייתה מטרה זהה: להפוך גבולות למפורשים ולקלים לשליטה.

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

האתגר הוא שכלי MCP משתמשים באימות באמצעות טוקן (token authentication). המשמעות היא שחסר להם הקשר הסשן (session context) שיש לבקשת אינטרנט סטנדרטית. אם מסתמכים על טווח (scope) גלובלי של שוכר (tenant), המערכת עלולה להחזיר נתונים מכל ארגון.

פתרתי זאת באמצעות שלושה כללים:

  • לסנן לפי ארגון באופן מפורש בכל שאילתה. אל תסתמכו על scope גלובלי.
  • להשתמש באותן מחרוזות הרשאה (permission strings) כמו באפליקציית הווב. לסוכן לעולם לא צריכה להיות יותר כוח מהאדם המשתמש בו.
  • להשתמש ב-UUIDs לצורך חיפושים במקום ב-IDs עם קידום אוטומטי (auto-increment).

התייחסו לכל כלי כאל נקודת קצה (endpoint) שאינה מהימנה. מקמו את הלוגיקה שלכם במקום שבו תוכלו לבדוק אותה בנקודה אחת.

המשימה השנייה כללה פורטל זהות. העברתי את הגדרות ה-LDAP מקבצים סטטיים לממשק משתמש (UI) של הגדרות. כעת מנהלי מערכת יכולים לשנות את המארח (host), הפורט והפרטים (credentials) ללא פריסה (deployment) חדשה.

הוספתי גם שליטה על פקיעת זמן חיבור (connection timeouts) ואפשרויות SASL. זה יצר מכשול טכני עם JSON.

כשמאחסנים מפתחות מסוג integer ב-JSON, הם מוחזרים כמחרוזות (strings) בעת פענוח (decode). פונקציות LDAP דורשות מפתחות מסוג integer. נאלצתי לכתוב mapper כדי להמיר את המפתחות הללו חזרה ל-integers לפני השימוש.

כדי לשמור על בטיחות, הוספתי שני מנגנוני הגנה:

  • להצפין סיסמאות bind במצב מנוחה (at rest). לעולם אל תשימו סודות בזיכרון המטמון (cache) כטקסט גלוי (plaintext).
  • לאמת שדות JSON לפני השמירה. הגדרה שגויה צריכה להיכשל בשלב השמירה, ולא ברגע שמשתמש ננעל מחוץ למערכת.

השתמשתי גם ב-assembler יחיד הן לבדיקת חיבורים והן לשמירתם. זה מבטיח שהחיבור שאתם בודקים הוא בדיוק מה שאתם שומרים.

הנדסה היא לא רק בניית הפיצ'ר. הנדסה היא בניית מנגנוני ההגנה.

מקור: https://dev.to/nasrulhazim/dev-log-2026-06-24-agent-guardrails-and-runtime-ldap-config-2hi5