אבטחת סוכן AI מתחילה בכלל אחד: סוכן ה-AI שלך לעולם לא צריך להחזיק את האישורים שלך. הנה דפוס הברוקר בן 38 השנים שמיישם זאת.
סוכני AI הם סגנים מבולבלים. זה דפוס אבטחה בן 38 שנה, והתשובה ישנה בדיוק: שים ברוקר — שכבת ביניים אמינה, ניתנת לתצפית, דטרמיניסטית, ניתנת לביקורת, בלתי ניתנת לזיוף, מצומצמת טווח ומבוססת מדיניות, שאינה AI — בין הסוכן ל-API של ה-SaaS שהוא צריך לקרוא להם, כשהברוקר מחזיק את האישורים שהסוכן שלך לא אמור להחזיק.
בשנת 1988, נורם הארדי פרסם מאמר קצר שתיאר תקרית אמיתית מתקופתו ב-Tymshare. מהדר פורטרן בשם FORT שכן בתיקיית מערכת בשם SYSX. כדי לאסוף סטטיסטיקות שימוש, המהדר היה צריך לכתוב ל-(SYSX)STAT, ולכן מערכת ההפעלה העניקה ל-FORT "רישיון קבצי בית", שאישר לו לכתוב כל קובץ בתוך SYSX. קובץ החיוב של המערכת, (SYSX)BILL, היה גם הוא שם. משתמש שהפעיל את המהדר יכול היה לספק שם קובץ לקבלת פלט ניפוי שגיאות אופציונלי. יום אחד, משתמש סיפק את (SYSX)BILL. המהדר ביקש מהמערכת לפתוח את הקובץ לכתיבה; המערכת, שזיהתה את רישיון קבצי הבית, אפשרה זאת. נתוני החיוב נמחקו. המהדר עשה בדיוק את מה שתוכנן לעשות. הכשל היה ארכיטקטוני.
הארדי קרא לזה בעיית הסגן המבולבל: תוכנה עם הרשאות (הסגן) מחזיקה בסמכות משלה; קורא עם פחות הרשאות מבקש ממנה לבצע פעולה; הסגן מתבלבל לגבי סמכות מי הוא פועל, ומשתמש בסמכות שלו. הפתרון הוא להוציא את הסמכות מהסגן ולשים אותה מאחורי שכבה נפרדת שמתווכת את הקריאה לפי דרישה. זו שכבת הברוקר.
שלושים ושמונה שנים אחר כך, כל סוכן AI שהחברה שלך מריצה הוא סגן מבולבל. ורובם פועלים בלי ברוקר.
למה סוכני AI מחמירים את בעיית האבטחה
ל-FORT של הארדי היה ערוץ קלט אחד: שורת הפקודה. לסוכן AI מודרני יש עשרות: גופי אימייל, דפי אינטרנט שנשלפו, קבצי PDF שהועלו, פלטים מכלי MCP, הודעות מסוכנים עמיתים במערכת מרובת סוכנים. כל דבר שנכנס לחלון ההקשר יכול להוציא הוראות, והסוכן מתוכנן להתייחס לכולם כלגיטימיים.
זה שובר הנחה שעליה נשענת בקרת גישה מסורתית: הקורא שולט בקלט. באפליקציית ווב, הקורא (הסשן המאומת) והקלט (גוף בקשת HTTP) מגיעים מאותו מקום. עבור סוכן, הקורא הוא מי שמעצב את הפרומפט, כלומר תוקף שיכול לכתוב אימייל או לזרוע תוצאה בחיפוש הוא גם קורא.
בנובמבר 2025, חוקרי אבטחה ב-PromptArmor הדגימו איך זה נראה בפרודקשן. הם הסתירו הוראות זדוניות בגופן 1-פיקסלים במדריך אינטגרציה. כשמפתח הפנה את Antigravity IDE של Google לשם, הסוכן עקף את הגנת הקבצים מבוססת .gitignore שלו על ידי הרצת פקודת מעטפת ל-cat. לאחר מכן הוא הדליף את תוכן קבצי .env לכתובת webhook.site בשליטת התוקף דרך סוכן הדפדפן של Antigravity. המשתמש הגדיר הכל נכון. הסנדבוקס עבד. הסוכן פשוט לא הצליח להבחין בין מה שהמשתמש ביקש למה שהקלט הורה לו לעשות.
אותה תבנית כמו FORT של הארדי, עשורים אחר כך: סמכות רחבה, קלט לא מהימן, אין דרך להפריד ביניהם.
לקהילה יש תשובות. הן פשוט מפוזרות.
זו לא בעיה חדשה. קהילת האבטחה כותבת תשובות כבר עשורים:
אבטחה מבוססת יכולות (דניס ו-ואן הורן, 1966; מאוחר יותר שפת E ועבודתו של מארק מילר על Caja בגוגל). העיקרון: אל תעניק סמכות סביבתית על בסיס זהות או מיקום; העבר יכולות מפורשות ובלתי ניתנות לזיוף לכל משאב שהתוכנה רשאית לגשת אליו. יכולת כוללת מה מותר לעשות ו-על מה, ואי אפשר לבלבל אותה עם משהו אחר.
אישורים מתווכים (הוגדרו ב-OWASP LLM Top 10). אל תכניס טוקנים של API להקשר של ה-LLM. שכבת ביניים אמינה מבצעת את הקריאה בשם הסוכן; המודל מחליט מה לעשות, הברוקר מטפל ב-איך. הזרקת פרומפט שמבקשת מהמודל להדפיס את האישורים לא מקבלת כלום. האישורים לא שם.
דפוס טוקן פנטום (Curity, במקור ל-OAuth במיקרו-שירותים). הסוכן מחזיק מזהה סשן אטום, לא את טוקן ה-bearer האמיתי. פרוקסי מאמת את המזהה, מחליף את האישורים האמיתיים בקצה הרשת, ומעביר הלאה. אם הסוכן מדליף את סביבתו, התוקף מקבל מחרוזת שפגה בסיום הסשן.
הזרקת אישורים לפי דרישה (מערכות זהות לעומסי עבודה כמו Aembit). צור אישור קצר טווח ומצומצם טווח לכל קריאה במקום להנפיק טוקנים ארוכי טווח.
שום דבר מזה לא חסר בספרות. זה חסר בברירת המחדל. רוב פלטפורמות הסוכנים עדיין נותנות למודל טוקן OAuth, בלי ברוקר באמצע, ומקוות לטוב.
איך הברוקר של Zero עובד
לא המצאנו אף אחד מהדפוסים למעלה. חיברנו אותם לברוקר אחד שמופעל כברירת מחדל לכל סוכן ב-Zero. זו שכבת הביניים האמינה שהדפוסים מתארים, שנבנתה לפלטפורמת סוכני AI. כל קריאה שסוכן מבצע ל-מחבר עוברת דרכו. כל מחבר הוא SaaS חיצוני אחד (Slack, GitHub, Notion וכו').
הברוקר יושב בין כל סוכן לכל מחבר. אישורים אמיתיים חיים רק בצד הברוקר של הקו המקווקו.
חשוב עליו כעל שלוש שכבות.
1. בידוד אישורים
הסנדבוקס של הסוכן לעולם לא מחזיק אישור מחבר אמיתי. כשאתה מחבר SaaS ל-Zero, טוקן ה-OAuth או מפתח ה-API נשמר בצד הברוקר. הסנדבוקס מקבל מחרוזת ממלא מקום שנראית מספיק כמו סוד סביבה כדי שכלים קיימים ימשיכו לעבוד, אבל אף SaaS לא יקבל אותה.
כאשר הסוכן מבצע בקשה למארח מחבר רשום, הברוקר מתאים את הבקשה, פותר את תבנית האימות של המחבר, ומזריק את האישור האמיתי בקצה הרשת. הבקשה עולה למעלה עם אימות תקף; הסוכן מעולם לא החזיק משהו שימושי. סוכן שהוזרק בפרומפט ומדפיס משתני סביבה שלו נותן לתוקף ממלא מקום, לא טוקן SaaS.
זהו דפוס טוקן פנטום, מיושם על סוכני AI.
2. שער מדיניות מחבר
מחבר ב-Zero צריך להיות יותר ממפסק הפעלה/כיבוי. כל מחבר מתאר את בסיסי ה-API שהוא מכסה ואיך להזריק אישור. כאשר שירות ה-upstream מפרסם מיפוי יציב של scope ל-endpoint, הוא גם יכול לתאר איזו הרשאה בשם מכסה כל שיטה ונתיב. slack-api-ref של Slack הוא דוגמה טובה.
כך שכאשר סוכן שמחובר ל-Slack קורא ל-chat.postMessage, הברוקר יכול למפות את הבקשה ל-chat:write. כאשר הוא קורא לוגי ביקורת, זה admin.analytics:read. לכל סוכן, permission_policies מגדיר איך הרשאות אלו מתנהגות: לאפשר, לחסום או לבקש. המדיניות נאכפת בברוקר לפני הזרקת האימות, לא כרמז למודל. אם הסוכן מנסה לבצע קריאה שמכוסה בהרשאה חסומה, אולי בגלל הזרקת פרומפט, הקריאה לא מגיעה לרשת.
לא כל מחבר מקבל את הרזולוציה הזו היום. חלק מה-API upstream לא מפרסמים מיפוי יציב של scope ל-endpoint. הממשק של GitHub ב-GraphQL הוא הדוגמה הקלאסית: צד ה-REST ניתן למיפוי, אבל צד ה-GraphQL עדיין לא. עבור מחברים כאלה, הברוקר עדיין שולט בהזרקת האישורים ובנתיב הרשת, בעוד ששער ההרשאות חוזר למדיניות גסה יותר ברמת מחבר או מארח שהפלטפורמה יכולה לאכוף בפועל. אנו משלימים זאת ככל שמידע upstream מתווסף. איננו טוענים לכיסוי שלא בנינו.
טוקנים לא נושאים סמכות סביבתית. סמכות מתווכת לכל סוכן, ברזולוציה שה-upstream תומך בה. זו חצי התשובה המבוססת יכולות.
3. לולאת תפעול וביקורת
העדפת מינימום הרשאות עובדת רק אם מצב הכשל שמיש. סוכנים גדלים. שישה שבועות פנימה, סוכן מחקר שהתחיל בקריאה מ-Notion עשוי להזדקק לכתוב סיכום חזרה. מצבי הכשל הנפוצים במקומות אחרים: הסוכן רץ בשקט בלי ההרשאה החדשה ונשבר, או שהמפעיל מעניק הרשאות יתר בפאניקה ולא מחזיר אותן לעולם.
בקשת מחבר שנדחתה מחזירה 403 מובנה: מחבר, שיטה, נתיב, כתובת בסיס, ושמות ההרשאות התואמות כשהברוקר מזהה אותן. פרומפט המערכת של הסוכן מסביר לו איך לאבחן את הדחייה ואיך לבקש בדיוק את ההרשאה שפגע בה, ומייצר קישור הענקה בלחיצה אחת למשתמש או למנהל. זה שומר את מסלול ההסלמה צמוד להרשאה המבוקשת במקום להפוך ל"פשוט תן הכל".
בקשות לשינוי הרשאות נכנסות לתור. בעלי workspace ומנהלים יכולים לאשר או לדחות אותן מהדשבורד; בקשות שאושרו מעדכנות את מדיניות הסוכן, והניסיון הבא עובר. רוב הפלטפורמות מדלגות על הלולאה הזו. בלעדיה, "מינימום הרשאות" נשאר במצגת במקום לרוץ בפרודקשן.
אותו נתיב ברוקר מזין את הביקורת. לוגי רשת לכל הרצה מתעדים פעילות רשת בסנדבוקס ב-HTTP, TCP, DNS ותצפיות חבילה ברמה נמוכה יותר לתעבורה לא-TCP. בקשות תואמות מחבר כוללות מטא-דאטה מובנית של הברוקר: מחבר, הרשאה תואמת כשיש, תוצאת אישור/דחייה, מטא-דאטה של פתרון אימות, ודגל חיוב. אם מישהו ישאל אחר כך "מה עשה הסוכן הזה ביום שלישי ב-3 בצהריים?", תוכל לשחזר את התשובה מהתיעוד. מניעה מפספסת דברים. מסלול הביקורת הוא הדרך לגלות מה קרה.
מה שלא פתרנו
גם עם כל האמור לעיל, סוכן עם הרשאת chat:write לגיטימית עדיין יכול להשתכנע לפרסם הודעה מביכה בערוץ שיש לו אליו גישה. הברוקר מצמצם את הנזק; הוא לא מבטל אותו.
החצי השני של התשובה הוא אישור לפעולות רגישות, ולידציה של פלט, והתייחסות לתשובות כלים כלא מהימנות כברירת מחדל. העבודה הזו בתכנון, לא במוצר עדיין. כל מי שטוען שפתר את בעיית הסגן המבולבל מקצה לקצה מוכר לך משהו.
זה צריך להיות הבסיס, לא פיצ'ר
אבטחה מבוססת יכולות קיימת מאז שנות ה-70. אישורים מתווכים נמצאים ב-OWASP LLM Top 10. טוקנים פנטום קדמו לעידן ה-LLM. שום דבר מזה לא חסר כי אף אחד לא ידע את התשובה. זה חסר כי פלטפורמות סוכנים מוקדמות התמקדו ב"שהדמו יעבוד" ודחו את האבטחה לגרסה עתידית, שלרוב לא הגיעה.
הדור הבא של פלטפורמות צריך לשאוף גבוה יותר. טוקנים לא צריכים להיכנס להקשר המודל. סמכות צריכה להיות ממופה לכל סוכן. הסלמת הרשאות צריכה לעבור דרך אדם. כל פעולה צריכה להיות ניתנת לביקורת מקצה לקצה. כל זה לא חדש. כל זה צריך להיות הבסיס.
כשאתה בוחר פלטפורמת סוכנים, "האם זה מאובטח?" לא יוביל אותך לשום מקום. כל ספק יגיד כן. שאלה טובה יותר: הראה לי את הברוקר שלך, והסבר מה קורה כשסוכן מבקש הרשאה שאין לו.
הברוקר יושב לפני כל סוכן ב-Zero כברירת מחדל. מלאי מחברים, מיפוי הרשאות, מדיניות הרשאות ולוגיקת הברוקר נמצאים כולם ב-מאגר הקוד של Zero. מצאת מחבר שלא כיסינו? פתח issue.
מקורות
בסיסיים
- נורם הארדי, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (מאמר היסוד של מערכות יכולות)
- Mark Miller ואחרים, Caja: אבטחה מבוססת יכולות לווב, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
תקריות מהעולם האמיתי שצוינו
- PromptArmor, Google Antigravity Exfiltrates Data, נובמבר 2025
- Simon Willison, סקירה וניתוח, נובמבר 25, 2025
