סוכני AI זקוקים לגבולות, לא למפתחות מאסטר

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

כשבונים כלי MCP עבור אפליקציית Laravel מרובת-דיירים (multi-tenant), עליך לפתור בעיה אחת: איך לאפשר לסוכן להפעיל את האפליקציה מבלי לגשת לנתונים של מישהו אחר.

כל כלי MCP פועל כ-endpoint. סוכן קורא לכלי, והשרת שלך מריץ קוד. בהגדרת multi-tenant, כל כלי חייב לענות על שתי שאלות:

  • האם מותר לך לעשות זאת?
  • האם מותר לך לעשות זאת כאן?

אם תדלג על אלו, תיצור חור אבטחה.

בקשות Web משתמשות ב-sessions כדי לנהל multi-tenancy. כלי MCP משתמשים ב-tokens. אין session ואין middleware שקובע את ה-tenant context הנוכחי. אם תסתמך על global scopes שמחפשים "ארגון נוכחי" בתוך session, הם לא ימצאו דבר. שאילתה שאמורה להיות מוגבלת עלולה להחזיר כל שורה במסד הנתונים שלך.

אני משתמש בארבע הכללים האלו כדי להישאר בטוח:

  • סינון מפורש (Explicit filtering): לעולם אל תסתמך על ambient scope תחת אימות באמצעות token. השתמש ב-trait יחיד כדי לסנן לפי ארגון בכל פעם.
  • שימוש ב-UUIDs: לעולם אל תשתמש ב-IDs מסוג auto-increment. השתמש במזהים שאינם ניתנים לניחוש כדי שסוכנים לא יוכלו לנחש רשומות אחרות.
  • שימוש חוזר בהרשאות: אל תיצור סטים חדשים של הרשאות עבור סוכנים. השתמש באותן מחרוזות יכולת (ability strings) שהאפליקציה שלך משתמשת בהן.
  • סימון side effects: השתמש ב-annotations כדי לסמן כלים כ-read-only או כ-write-enabled.

באמצעות שימוש ב-trait יחיד לחיפושי ארגון, אתה יוצר מקום אחד לביקורת (audit). אם החיפוש מחזיר null, הכלי אומר לסוכן שהרשומה לא נמצאה. הסוכן לא מקבל שום מידע על דיירים אחרים.

זו לא בעיה של AI. זו בעיה של multi-tenancy והרשאות (authorization). MCP הופך את החשיפה של האפליקציה שלך לקלה, לכן עליך להיות ממושמע לגבי הגבולות שלך.

סוכן צריך לעשות בדיוק את מה שאדם יכול לעשות, בתוך ה-tenant שלו, ולא יותר.

מקור: https://dev.to/nasrulhazim/giving-an-ai-agent-the-keys-without-giving-it-the-building-rbac-org-scoped-mcp-tools-in-laravel-43oi

קהילת למידה אופציונלית: https://t.me/GyaanSetuAi