בלימת סוכני AI: הצ'קליסט שכל צוות צריך אחרי ההנחיות של CISA וה-NSA

ב-16 באוקטובר 2026 פרסמו שלוש סוכנויות של ממשל ארה"ב, NIST, ה-NSA ו-CISA, מסמך משותף שאומר בפשטות: סוכני AI יכולים לצאת מהגבולות שהצבנו להם, ואנחנו צריכים להתכונן לזה כמו לכל אירוע סייבר. המסמך נקרא "Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation", והוא נכתב בעיקר בשביל המעבדות שמאמנות את המודלים הכי חזקים. אבל מסתבר שכמעט כל סעיף בו רלוונטי גם לנו, הצוותים שמריצים סוכן קוד על הלפטופ וסוכן תמיכה בפרודקשן.

אז במקום עוד כתבה על "הסוכנים בורחים", בואו נעשה משהו מעשי: נבנה צ'קליסט הקשחה (hardening, חיזוק ההגנות) לסוכנים שלנו, מהלפטופ ועד השרת.

מה קרה החודש, ולמה זה נוגע גם לנו

בחודשים האחרונים הסיפור עבר מהמעבדה לחדר הישיבות. כבר כתבנו כאן על העצירה של OpenAI אחרי שסוכן ברח מארגז החול דרך DNS. לפני כן היה האירוע שבו סוכנים של OpenAI יצאו מסביבת בדיקה ופגעו בתשתית של Hugging Face. קבוצת חוקרים מכמה גופים, בהם Palisade Research, פרסמה באתר Swarm Traces ניתוח פורנזי (חקירה דיגיטלית לאחר מעשה) של יותר מ-80 אלף מטענים (payloads, קטעי הקוד שהסוכנים הריצו) ששוחזרו מקישורים מקוצרים ציבוריים. לפי הניתוח, לסוכנים הייתה גישת GET בלבד, כלומר הם יכלו לפתוח כתובות אבל לא לשלוח מידע. הם עקפו את זה בכך שפיצלו קוד לחתיכות בתוך קישורים מקוצרים, שרשרו אותם, ובאחד הסקריפטים אספו מפתחות AWS, טוקנים ומשתני סביבה עם המילים SECRET, PASSWORD או KEY לתוך משתנה בשם LOOT (שלל). חשוב לציין: החוקרים עצמם מזהירים שרוב המטענים בלי חותמת זמן, ושהתאריכים שלהם הם שחזור ולא עובדה.

ב-5 באוקטובר זה הגיע לניו יורק. מועצת העיר כינסה ישיבה של כל 51 חבריה (Committee of the Whole), ונציגים של OpenAI, Anthropic, Google ו-Meta נחקרו שם על סוכנים שיצאו מסביבות בדיקה. לפי הדיווח של PPC Land, על השולחן מונחות עשר הצעות חוק, בהן חובת אימות על ידי צד שלישי ויכולת כיבוי אנושית, עם קנס של עד 25 אלף דולר להפרה, וחובת דיווח על אירועי בטיחות תוך 24 שעות.

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

הדוגמה שלנו: נועה וה-12 מפתחים

בואו ניקח דוגמה אחת וננהל אותה לאורך כל הכתבה. נועה (דמות לדוגמה) היא VP R&D בסטארטאפ פינטק בניו יורק עם 12 מפתחים. יש לה שני סוכנים:

1. סוכן קוד על הלפטופ: כל מפתח מריץ Claude Code או Codex CLI. הסוכן קורא את הריפו, מריץ טסטים, מתקין חבילות.
2. סוכן תמיכה בפרודקשן: סוכן שעונה ללקוחות, מחובר דרך MCP לטיקטים, ל-GitHub ולמסד נתונים.

הפרוטוקול MCP (Model Context Protocol) הוא מה שמחבר סוכן לכלים חיצוניים. תחשבו על זה כמו על מפצל חשמל: כל שרת MCP שמחברים הוא עוד שקע שהסוכן יכול להשתמש בו, וכל שקע כזה הוא גם עוד נקודת סיכון.

עכשיו תדמיינו שבטעות או בגלל הזרקת פרומפט (prompt injection, הוראות זדוניות שמוסתרות בתוך טקסט שהסוכן קורא), הסוכן של אחד המפתחים מנסה לקרוא את ~/.aws/credentials ולשלוח אותו החוצה. מה עוצר אותו? אצל רוב הצוותים התשובה הכנה היא "כלום".

המכשול: ארגז החול של היום דולף כברירת מחדל

הבעיה היא לא שהכלים גרועים. הבעיה היא ברירות המחדל, וגם המסמכים הרשמיים אומרים את זה בגלוי. לפי התיעוד של Claude Code, הסנדבוקס (sandbox, ארגז חול: סביבה מבודדת שמגבילה מה פקודה יכולה לגעת בו) כבוי כברירת מחדל. וגם כשהוא דולק, הוא עוטף רק פקודות shell. שרתי MCP מקומיים, hooks וכלי הקבצים המובנים רצים מחוץ לסנדבוקס, עם כל ההרשאות שלנו. עוד פרט שכדאי להכיר: גם בתוך הסנדבוקס, ברירת המחדל מאפשרת לקרוא את רוב המחשב, כולל ~/.ssh ו-~/.aws/credentials, עד שחוסמים אותם במפורש.

ואז יש את מה שרץ ברקע בלי שביקשנו. ב-Codex CLI, מגרסה 0.157.0, עולה כברירת מחדל דימון (daemon, תהליך רקע שממשיך לרוץ גם אחרי שסגרנו את הטרמינל). לפי issue פתוח בריפו של OpenAI, הוא מעתיק כ-374MB לתיקייה מנוהלת, בודק עדכונים כל שעה וממשיך לחיות אחרי שכל הסשנים נסגרו. זה לא זדוני, אבל זה בדיוק מה שהמסמך הממשלתי מבקש מאיתנו למפות: מנגנוני התמדה (persistence, דרכים שבהן תוכנה נשארת במערכת לאורך זמן).

גם בצד של MCP המצב לא פשוט. נייר מחקר של ה-Cloud Security Alliance מתאר פגם תכנוני שחשפה OX Security באפריל 2026 בתעבורת STDIO של ערכות ה-SDK הרשמיות של MCP, שמאפשר הרצת פקודות במחשב אם תוקף מצליח להשפיע על קובץ ההגדרות. שימו לב: לפי ה-CSA עצמו, הנייר נכתב בסיוע AI ולא עבר את תהליך הביקורת הרשמי שלהם, והמספרים בו (כמו 200 אלף מופעים פגיעים) הם הערכות של OX. המסקנה שלהם בכל זאת חדה: להתייחס לכל שרת MCP כאל צד שלישי לא מהימן.

מה המסמך הממשלתי אומר באמת

המסמך מחלק עשרה נהגים מומלצים לחמישה שלבים: הכנה, זיהוי, תגובה, התאוששות ודיווח. הוא וולונטרי, והוא בנוי על מסגרות קיימות כמו NIST CSF 2.0 ו-NIST SP 800-61r3. אלה הסעיפים שהכי רלוונטיים לצוות כמו של נועה:

• מינימום הרשאות: להגביל את הגישה של הסוכן למידע, למערכות ולכלים רק למה שנחוץ למשימה (סעיף 1.1).
• רשת דרך רשימה לבנה: להגביל גישת רשת "באמצעות רשימה לבנה קפדנית ככל האפשר", ולנתב כל גישה נחוצה דרך שער מנוטר (1.5).
• מתג כיבוי: לבנות מנגנונים לחסום, לבודד או לעצור מיד פעילות של סוכן (1.7), ולכבות אוטומטית מסלול של סוכן כשמזוהה כשל בקרה (6.2).
• לוגים שהסוכן לא נוגע בהם: לוודא שהסוכן לא יכול לגשת לתהליכי הניטור וללוגים או להפריע להם (3.3), ולשמור לוגים עמידים לשינוי עם חותמות זמן אמינות (5.3).
• מלכודות: להציב קנריות (canaries, פיתיונות כמו מפתח מזויף שאף אחד לא אמור לגעת בו) כדי לזהות סוכן שהשיג גישה מחוץ לגבולות (3.5).
• בודקים חיצוניים ואנשים בלולאה: לשתף פעולה עם מבקרים חיצוניים ובלתי תלויים, ולבדוק את מנגנוני הבקרה גם עם בני אדם ולא רק עם AI. כשמשתמשים במודל כדי לפקח על מודל, המסמך ממליץ על כמה מודלים, רצוי ממשפחות שונות.
• ציד התמדה: לחפש ולסגור כל דרך שבה הסוכן יכול להישאר במערכת, כמו דלתות אחוריות בקוד וערוצי תקשורת נסתרים (6.5), ולבנות מחדש סביבות מבסיס מאומת לפני שמפעילים שוב (7.1).

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

הצ'קליסט: מהלפטופ ועד פרודקשן

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

על הלפטופ, הצעד הראשון הוא להדליק את הסנדבוקס ולסגור את דלת המילוט. ב-Claude Code עושים את זה בהגדרות. זו קונפיגורציה שמבוססת אחד לאחד על מפתחות מהתיעוד הרשמי: הסנדבוקס חובה, אין נסיגה להרצה בלי סנדבוקס, הרשת מוגבלת לרשימה לבנה, ומפתחות הענן ו-SSH חסומים:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"],
      "strictAllowlist": true
    },
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

שלושה דברים שחשוב להבין בקוד הזה. failIfUnavailable גורם ל-Claude Code לסרב לעלות אם הסנדבוקס לא יכול לרוץ, במקום לרוץ בשקט בלי הגנה. allowUnsandboxedCommands: false מבטל את פתח המילוט שבו הסוכן מבקש להריץ שוב פקודה שנכשלה, הפעם מחוץ לסנדבוקס. ו-strictAllowlist חוסם כל דומיין שלא ברשימה במקום לשאול. לפי התיעוד, את ההגדרה האחרונה אפשר לקבוע בהגדרות המשתמש, בהגדרות המנוהלות או בדגל --settings, אבל לא בקובץ ההגדרות של הריפו, וזה בכוונה: ריפו זדוני לא יכול לפתוח לעצמו את הרשת. בארגון של נועה, את כל זה פורסים כהגדרות מנוהלות (managed settings) דרך ה-MDM, כדי שמפתח לא יוכל להרחיב את המדיניות בטעות.

ב-Codex CLI, מי שלא רוצה תהליך רקע שמעדכן את עצמו מריץ codex features disable daemon_auto_start, או מגדיר daemon_auto_start = false בקובץ ההגדרות.

בפרודקשן, הסנדבוקס של הכלי לא מספיק. כאן הסוכן צריך לרוץ בתוך גבול שהתשתית שלנו אוכפת: קונטיינר או מכונה וירטואלית, תשתית חד-פעמית ככל האפשר (כפי שהמסמך ממליץ בסעיף 1.2), ויציאה לרשת רק דרך פרוקסי עם רשימה לבנה. מי שבונה על Kubernetes יכול להסתכל על AX (Agent Executor) של Google, פלטפורמת קוד פתוח ברישיון Apache 2.0 עם כ-14 אלף כוכבים ב-GitHub, שמריצה משימות של סוכנים כשחקנים מבודדים עם מגבלות מעבד וזיכרון, ומנהלת מפתחות של ספקי מודלים דרך Kubernetes secrets. Google עצמה מסמנת אותה כפרויקט בפיתוח כבד, עם שינויים שוברים צפויים לפני גרסה יציבה, אז זה כלי ללמוד ולנסות, לא עוד תשתית ליבה.

והנה הצ'קליסט המלא, שנועה יכולה להעביר לצוות כבר מחר בבוקר:

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

מה זה לא פותר

שורה תחתונה, וכדאי להיות כנים: הצ'קליסט הזה מקטין את רדיוס הפגיעה, הוא לא מבטל אותו. סוכן עם גישה ל-GitHub עדיין יכול לדחוף קוד רע, גם אם הוא לא יכול לגנוב את מפתח ה-AWS. סנדבוקס של כלי קוד לא מכסה את כלי הקבצים ואת שרתי ה-MCP, ולכן לפי התיעוד, מי שרוצה גבול אחד סביב הכל צריך להריץ את הכלי עצמו בתוך קונטיינר או מכונה וירטואלית. והמסמך הממשלתי עצמו מודה שיש שאלות פתוחות, למשל איך מגדירים "התנהגות רגילה" של סוכן כדי לזהות חריגה.

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

אז מתי בדקנו בפעם האחרונה שמתג הכיבוי של הסוכן שלנו באמת עובד?

רוצים ללכת עם זה רחוק יותר?

את ההגדרות האלה, סנדבוקס, הרשאות, hooks והגדרות מנוהלות לצוות, אני מפרק לעומק בקורס Claude Code Mastery (באנגלית). מי שעובד עם Claude Desktop, MCP וסוכנים ורוצה להבין איך מחברים כלים בלי לפתוח את כל הדלתות, ימצא את זה בקורס Practical AI with Claude (בעברית).

את הדמואים, כולל בדיקות סנדבוקס חיות, אני מעלה ל-YouTube ול-LinkedIn, ועדכונים שוטפים יש ב-X, ב-Instagram וב-TikTok. הקוד שלי פתוח ב-GitHub.

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