ההקשר של ה-Repo שלכם הוא כעת משטח תקיפה

רוב האנשים חושבים שאבטחת AI פירושה למנוע ממודל לכתוב קוד גרוע.

התפיסה הזו צרה מדי.

הסיכון האמיתי הוא כל מה שה-AI קורא לפני שהוא כותב קוד. ה-repository שלכם הוא כבר לא רק מקום לקוד. עבור סוכן AI, הוא זרם קלט (input stream).

סוכן קורא את ה-README שלכם, הערות מיגרציה ישנות, תיעוד מיושן וקבצי הוראות מקומיים. הוא רואה סקריפטים של תלויות (dependencies), shell hooks ושינויי קוד קודמים.

מפתחים מתייחסים לעיתים קרובות להקשר (context) הזה כניטרלי. הם רואים בהערות ישנות רעש או עומס. סוכן AI רואה בהן הוראות.

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

הקשר גרוע יכול להיות "משעמם":

הקשר גרוע יכול להיות עוין:

אופן הכישלון הוא זהה. הסוכן פועל לפי הנחה שלא התכוונתם אליה.

כדי לתקן זאת, עליכם להפסיק להתייחס לסוכנים כאל כלי autocomplete פשוטים. הם אוטומציה. התייחסו אליהם כאל תשתית (infrastructure).

פעלו לפי הצעדים הבאים כדי לאבטח את תזרים העבודה (workflow) שלכם:

  1. הגבילו את ההיקף אל תתנו לסוכן גישה לכל המערכת אם הוא זקוק רק לשלושה קבצים. השתמשו במשימות מוגדרות היטב וב-worktrees זמניים.

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

  3. הקשיחו את ההרצה הריצו משימות מסוכנות בתוך sandbox. שמרו על הרשאות (credentials) מוגבלות בהיקףן. סקרו הגדרות hook בדיוק כפי שאתם סוקרים CI pipelines. ודאו שהרצת בדיקות אינה מעניקה גישה לכל secret ב-shell שלכם.

  4. דרשו נראות (visibility) אתם חייבים להיות מסוגלים לענות על השאלות הבאות:

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

התייחסו לסוכני ה-AI שלכם באותו אופן.

נקה את ההקשר שלך. צמצם את ההיקף שלך. בצע הרצה בסנדבוקס. בדוק כל diff כאילו אדם כתב אותו.

מקור: https://dev.to/hefty_69a4c2d631c9dd70724/your-repo-context-is-an-attack-surface-now-5dhj