קלוד ב-Uber: ה-CISO מנטר סוכני AI כמו שמנטרים עובדים

מי מדבר כאן, ולמה זה מעניין

Uber מריצה את אחד השווקים בזמן אמת הגדולים בעולם, עם יותר מ-40 מיליון נסיעות והזמנות משלוח ביום, לפי הנתון שמופיע בפרסום. Philip Martin, ה-CISO של החברה, מוביל את הצוות שמגן על הנתונים של Uber ועל הנוסעים, הנהגים והשליחים. ב-13 באוקטובר 2026 פרסמה אנתרופיק ראיון איתו.

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

מה קלוד עושה בצוות האבטחה של Uber?

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

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

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

למה סוכן AI צריך תוכנית לאיומים פנימיים?

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

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

איך נראית הארכיטקטורה?

Martin מתאר שלוש שכבות שיושבות זו לצד זו:

• ADR, הטלמטריה של Uber עצמה: מערכת ש-Uber פתחה לאחרונה בקוד פתוח, שאוספת נתונים בזמן אמת מתוך סביבות הסוכנים שהחברה מריצה
• LLM gateway: השער שדרכו עובר השימוש ב-AI בחברה. לפי Martin הוא בונה גדר (perimeter) ושולט איך משתמשים ב-AI בתוך Uber
• Enterprise Frontier Safeguards של אנתרופיק: המסווגים של אנתרופיק, שההתראות שלהם מגיעות ל-Uber. לפי Martin, בעתיד הם ייכנסו ל-ADR כמקור נתונים נוסף

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

מה יש בקוד הפתוח של ADR?

לפי ה-README, ADR היא ״מערכת אבטחה ארגונית לסוכני AI״, ברישיון Apache 2.0. יש בה שלושה חלקים:

• גילוי: מיפוי של אפליקציות AI, סוכני טרמינל, תוספי IDE, מודלים מקומיים ושרתי MCP שרצים על מחשבי הארגון, וסימון של מה שלא מוכר
• חיישן: איסוף ונרמול של הטלמטריה מהסוכנים, כולל שימוש בכלים, מקלוד קוד, Cursor, קודקס, GitHub Copilot CLI ו-Claude Desktop, בין השאר
• זיהוי: גלאי שבנוי משני סוכנים, ובנצ’מרק של 304 משימות עם 134 שרתי MCP

וכאן פרט שחשוב לומר ביושר: Martin מתאר מערכת שגם ״לוקחת פעולה בזמן אמת״, אבל לפי ה-README, רכיב המניעה, זה שעוצר פעולות לא בטוחות, לא נכלל בגרסה הפתוחה. מה שאפשר להוריד היום רואה ומזהה. הוא לא חוסם.

מה Uber קיבלה מ-Enterprise Frontier Safeguards?

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

Uber עבדה עם הצוות של אנתרופיק על המנגנון. Martin מסכם את מה שהיה חשוב לו: ההגנות קיימות, אבל הנתונים של Uber לא נגישים לאנתרופיק בלי רשות, ו-Uber שולטת גם במה שקורה אחרי שהתראה נדלקת. ״שמתם אותנו במושב הנהג״, הוא אומר, משפט שבחברה כמו Uber כנראה לא נבחר במקרה.

ממה כדאי להיזהר כשקוראים את הסיפור

• אין אף מספר על תוצאות: לא כמה איומים זוהו, לא כמה זמן נחסך במידול איומים, ולא כמה התראות הגיעו. זה ראיון על גישה וארכיטקטורה, ולא דוח תוצאות
• זה ראיון, בבלוג של אנתרופיק: לקוח מדבר על מוצר של הספק, בבמה של הספק
• השילוב עדיין עתידי: ש-Enterprise Frontier Safeguards ״ייכנס ל-ADR כמקור נתונים״ הוא ניבוי של Martin, לא תיאור של מה שרץ. וגם המנגנון עצמו נפרס בשלבים מהסתיו, לפי ההכרזה
• הקוד הפתוח מצומצם מהמערכת המתוארת: כאמור, בלי רכיב החסימה

איך מתחילים תוכנית כזו עם קלוד קוד?

אין צורך במערכת של Uber כדי להתחיל. שלושת הרכיבים שלה קיימים כבר בקלוד קוד, ברמה של קובץ הגדרות.

טלמטריה ל-SIEM. קלוד קוד שולח אירועים ב-OpenTelemetry, והתיעוד מביא דוגמה מוכנה לשליחת אירועים ל-SIEM, כולל פרטי הכלים לביקורת של פקודות Bash ושל MCP. זה נכנס ל-managed settings:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_LOG_TOOL_DETAILS": "1",
    "OTEL_EXPORTER_OTLP_LOGS_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_LOGS_ENDPOINT": "https://siem.example.com:4318/v1/logs",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer your-siem-token"
  }
}

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

החלטות על כלים. האירוע claude_code.tool_decision מתעד כל אישור או דחייה של כלי, ומאיפה הגיעה ההחלטה: מההגדרות, מ-hook או מהמשתמש. והמזהה tool_use_id שבו זהה לזה שמקבל ה-hook, כך שאפשר לחבר בין שני המקורות. זו בדיוק ״התמונה שלנו של מה שקורה״ ש-Martin מדבר עליה.

התערבות בזמן אמת. העדיפות הראשונה של Martin היא להתערב כמה שיותר קרוב לרגע שבו אדם מקליד פרומפט, ולהגיד לו ״כנראה שאתם לא רוצים את זה״. בקלוד קוד, hook מסוג PreToolUse רץ לפני כל קריאה לכלי, ויכול להחזיר החלטת deny עם הסבר. זה רכיב המניעה שחסר בקוד הפתוח של ADR, ובתיעוד ה-hooks יש דוגמה מלאה.

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

שורה תחתונה

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

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