קלוד קוד בתוך מכונה וירטואלית: הכלי שמכבה את ההרשאות בכוונה

חברת האבטחה Trail of Bits מתחזקת כלי בשם coop, שמריץ את קלוד קוד ואת קודקס בתוך מכונה וירטואלית מתכלה. המאגר אינו חדש — הוא נפתח באפריל 2026, והקומיט האחרון בו הוא מאתמול — אבל הוא עלה לדיון רק עכשיו, ושווה להכיר אותו בגלל החלטה אחת שנראית במבט ראשון כמו באג.

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

מה הכלי עושה בפועל

coop הוא CLI שכתוב ב-Rust וברישיון Apache-2.0. שלוש פקודות מסכמות את כל השימוש:

coop setup
coop up
coop claude

הראשונה בונה תבנית דיסק פעם אחת, השנייה מרימה מכונה לפרויקט שאתם עומדים בו, והשלישית נכנסת אליה ומריצה את קלוד קוד. המכונה היא אובונטו 24.04 עם Docker, עם ה-CLI של GitHub ועם קלוד קוד וקודקס מותקנים כבר בתבנית.

מתחת למכסה יש שני מנועים, והבחירה ביניהם נעשית בזמן הקומפילציה של הבינארי ולא בזמן ריצה: בלינוקס זה Firecracker, אותו microVM שמריץ פונקציות בענן, ובמק זה Lima שעוטף את Virtualization.framework של אפל.

הסעיף שהופך את זה למעניין

בתוך המכונה, coop כותב לקלוד קוד קובץ הגדרות מנוהל עם defaultMode: bypassPermissions ו-skipDangerousModePermissionPrompt: true, ומשגר אותו עם הדגל ‎--dangerously-skip-permissions‎. המשתמש בתוך המכונה מחזיק גם sudo בלי סיסמה.

כל אחד מהפרטים האלה, בנפרד, הוא בדיוק מה שמדריכי אבטחה מזהירים מפניו. מסמך מודל האמון של הפרויקט מסביר למה כאן זה הפוך, והנימוק שלו קצר: אין גבול הרשאות בתוך המכונה שצריך להגן עליו, כי המכונה כולה היא רדיוס הפיצוץ. בלשונו, “there is no privilege boundary inside the guest to protect”.

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

מי שרוצה בכל זאת אישורים בסשן בודד מריץ ‎coop claude --ask‎, וקלוד קוד עולה עם מצב ההרשאות הרגיל.

ומה שחשוב לומר ביושר

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

• מפתחות המודל נכנסים כברירת מחדל: ‎ANTHROPIC_API_KEY‎ ואסימון ה-OAuth של קלוד קוד מועברים אל תוך המכונה, כי בלעדיהם קלוד קוד שם אינו עובד
• האסימון של GitHub דווקא כבוי כברירת מחדל, וזו החלטה נכונה. מי שמדליק אותו כדי לשכפל מאגר פרטי צריך לדעת שהתיעוד אומר במפורש מה קורה אחר כך: coop מריץ בתוך המכונה gh auth setup-git, וזה הופך את האסימון למצב קבוע על הדיסק של המכונה שכל תהליך שם יכול לקרוא
• הערוץ הרחב ביותר חזרה אליכם הוא סנכרון הקבצים: משיכת קבצים מהמכונה אל המחשב שלכם מביאה תוכן, שמות ו-symlinks שהסוכן כתב, ומודל האמון מסמן אותה כמקום המרכזי שבו בריחה מהתיקייה עלולה לקרות

מצב הפרוקסי, ולמה שווה להדליק אותו

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

מי לא יכול להשתמש בזה

התיעוד מונה שני מנועים בלבד, ואף אחד מהם אינו לווינדוס: מק על שבבי Apple Silicon, ולינוקס על x86_64. בנייה ללינוקס ARM קיימת אך לא נבדקה, וווינדוס אינו מוזכר.

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

שורה תחתונה

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

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

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