סוכן קוד יכול להריץ פקודות על המחשב שלכם. אנחנו צריכים להחליט מה מותר לו לעשות בעצמו ואילו פעולות צריכות לחכות לאישור שלנו. נתחיל מבקשת ההרשאה, ואז נסתכל על מצבי הרשאות ועל כללים קבועים. נפריד גם בין אישורים לבין מגבלות גישה, ונראה איך נקודות שמירה ובידוד מאפשרים לכם להפחית הפרעות במקומות שבהם קל יותר לצמצם טעויות ולהתאושש מהן.
בואו נתחיל מבקשת ההרשאה הזו. נניח שאתם מבקשים מהסוכן לנקות את ה-build ולעשות deploy מחדש לפרויקט.
כדי לבצע את זה, הסוכן מחליט להריץ פקודת shell. זו מוחקת את תיקיית dist, ואז מריצה את סקריפט ה-deploy.
הפקודה שמוצגת צריכה אישור לפני שהיא רצה. אתם יכולים לאשר אותה פעם אחת, לשמור כלל לפקודות דומות כשהאפשרות הזו מוצעת, או לסרב לה. קראו מה כוללת הבחירה באישור תמידי לפני שאתם בוחרים בה.
הסוכן מבקש להריץ את הפקודה על המחשב שלכם. למחיקת תיקיית ה-build ולהרצת סקריפט ה-deploy תהיה השפעה אמיתית אם תאשרו. נצלו את העצירה הזו כדי לקרוא את הפקודה ולהחליט אם ההשפעות האלה תואמות למה שביקשתם.
בקשת הרשאה מאפשרת לכם לעבור על פעולה לפני שהיא רצה. קראו את הפעולה המבוקשת לפני שאתם מאשרים אותה. קשה מאוד או בלתי אפשרי לבטל מחיקת קבצים, ו-deploy יכול לשנות שירות שרץ. הבקשה נותנת לכם הזדמנות לעצור פעולה לא רצויה לפני שהיא רצה.
Claude Code מאפשר לכם לקבוע מדיניות לפעולות חוזרות. כמו שראינו בשבוע 1, Shift+Tab עובר בין מצבי ההרשאות הזמינים. אלה כוללים ידני, אישור עריכות, תכנון, וכשזמין, אוטומטי. בדקו את המצב שמוצג בסשן שלכם, כי סדר המצבים הזמינים תלוי בהתקנה שלכם. המצב קובע איך הסשן מתנהג לגבי אישורים. כללים קבועים מאפשרים לכם להכריע מראש במקרים חוזרים, ולשמור את ההחלטות האלה לסשנים שקובץ ההגדרות הזה חל עליהם.
כללים קבועים יושבים בקובץ ההגדרות. כלל allow מתיר פקודות שמתאימות לו בלי הבקשה הרגילה. הדוגמאות הן npm test ו-git status. לפני שאתם מתירים npm test, בדקו מה סקריפט הבדיקות של הפרויקט מריץ, כי שם הפקודה לבדו לא הופך סקריפט לבטוח. כלל deny חוסם פקודות שמתאימות לו, כמו צורות המחיקה הרקורסיבית וה-force push שמוצגות כאן. כללים חלים ברמה שבה אתם שומרים אותם, למשל פרויקט אחד או הגדרות המשתמש שלכם. הם תואמים תבניות של פקודות, אז כלל קצר לדוגמה הוא לא איסור מלא על כל דרך למחוק קבצים או לשכתב היסטוריה.
Claude Code בודק כללי הרשאות בסדר deny, ask, ואז allow. כלל deny שמתאים חוסם את הפקודה גם אם כלל ask או allow תואם גם הוא. אם אין התאמת deny, התאמת ask מחייבת בקשת אישור. אם אף אחד מהם לא תואם, התאמת allow מתירה את הפקודה. כשאף כלל לא תואם, מצב ההרשאות ובדיקות אחרות קובעים מה קורה. פקודה שלא מכוסה לא תמיד מייצרת בקשת אישור.
deny גובר על ask, ו-ask גובר על allow. זה מאפשר לכם להשאיר חסומה פקודה שמתאימה לכלל גם כשכלל allow רחב יותר תואם לה. הכלל חייב באמת להתאים, אז בדקו את התחום שלו והשתמשו גם בהגבלות גישה כשאתם צריכים לצמצם נזק.
יש כאן שתי החלטות שקל לבלבל ביניהן: למה פעולה יכולה להגיע, והאם היא צריכה אישור לפני שהיא רצה. הראשונה היא גישה. הגדרה לקריאה בלבד מאפשרת לסוכן לבחון קבצים בלי לשנות אותם. הגדרה שמוגבלת לפרויקט יכולה להתיר עריכות רק בתוך הפרויקט. הגדרה רחבה הרבה יותר יכולה להגיע לכל מה שחשבון מערכת ההפעלה ופרטי ההזדהות הזמינים מתירים, ואולי בכל המחשב.
השנייה היא פיקוח: מתי הסוכן עוצר כדי לשאול. אתם יכולים לדרוש אישורים תכופים, להתיר עבודה שגרתית בתוך גבול גישה ולשאול לפני יציאה ממנו, או לארגן הרצה בלי אישורים אינטראקטיביים בכלל. אלה מתארים מדיניות אישורים, לא כמה גישה יש לתהליך.
אתם יכולים לשלב גישה רחבה עם בקשות אישור תכופות, או גישה מוגבלת עם הרשאה לפעול בחופשיות בתוך הגבול. הראשון תלוי בכך שתתפסו פעולה מזיקה. השני מגביל על מה פעולה מאושרת יכולה להשפיע. מצבי ההרשאות והכללים של Claude Code מטפלים באישורים. הגדרות הסביבה המבודדת שלו יכולות להגביל את גישת הפקודות למערכת הקבצים ולרשת. כלים אחרים עשויים להציג את הבקרות האלה אחרת, אבל כדאי לשאול את שתי השאלות בנפרד.
ל-Claude Code יש דגל בשם --dangerously-skip-permissions. הוא מפעיל מצב שעוקף את בקשות האישור והבדיקות הרגילות.
כשהדגל הזה פעיל, פקודות רגילות יכולות לרוץ בלי האישור שלכם, כולל פקודות הרסניות. אל תסמכו על בקשת אישור שתעצור פקודה מזיקה לפני שהיא רצה. הדגל לא נותן לכם סביבה מבודדת. אם אתם רוצים להגביל למה הסוכן יכול להגיע, אתם חייבים להקים את זה בנפרד. פקודה לא רצויה יכולה לנבוע מניחוש שגוי של המודל או מהזרקת פרומפט, הוראה שהוברחה לתוך משהו שהוא קורא, כמו שראינו במבוא. בלי בקשת אישור שתעצור אותה, הפקודה הזו יכולה לרוץ לפני שתשימו לב אליה.
השתמשו בדגל הזה רק בסביבה מבודדת וחד-פעמית שבה פקודה שגויה לא יכולה להגיע לקבצים חשובים, למפתחות, או לשירותים. קונטיינר או מכונה וירטואלית יכולים לספק את ההפרדה הזו אם לא חשפתם להם תיקיות רגישות של המארח או פרטי הזדהות. השאירו את בקרות האישור הרגילות פעילות כשאתם עובדים ישירות על הלפטופ שלכם. לחסוך כמה בקשות אישור זו לא סיבה לתת לפקודות גישה לא מבוקרת לקבצים היומיומיים שלכם.
התחילו עם הרשאות מחמירות וקראו את הבקשות. לפני שאתם מקלים בהן למשימה מסוימת, ארגנו דרך להתאושש מסוגי הטעויות שעלולות לנבוע מהמשימה הזו. לפני שהסוכן עורך את הפרויקט, עברו על הגרסה העובדת שאתם רוצים לשמור ועשו לה קומיט. כמו בסרטון ה-git הראשון, בחרו את גרסאות הקבצים ששייכות לקומיט הזה ובדקו שהקבצים שאתם צריכים נכללים בו. שמרו את המזהה של הקומיט כדי שתוכלו להשוות שינויים מאוחרים יותר לנקודת ההתחלה השמורה הזו.
אחרי שהגרסה הזו שמורה, התירו יותר עבודה שגרתית במקומות שבהם אתם יכולים להתאושש מטעויות. אתם יכולים להשתמש במצב אישור עריכות לשינויים בתוך הפרויקט, או להעניק גישה לתיקייה נוספת אחת שהמשימה צריכה. עשו את השינוי במקום שבו הנזק האפשרי מוגבל, והמשיכו לסקור את התוצאה.
לחצו Esc כדי לעצור את התגובה הנוכחית, ואז בחנו את השינויים. עצירת הסוכן לא מבטלת את העריכות שלו. הפקודה /rewind יכולה לשחזר עריכות של כלי הקבצים ש-Claude Code תיעד, כמו שראינו בסרטון על הסשנים. בסרטון ה-git שחזרנו קובץ במעקב מנקודת שמירה אחרי שבדקנו אילו עריכות יבוטלו. במקרה אחר שדורש שחזור, בררו איזו גרסה ואיזו עבודה אתם רוצים לשמור, ואז בקשו מהסוכן להסביר את הפעולה המתאימה לפני שמריצים אותה.
כלי השחזור האלה לא מבטלים כל פקודת shell או השפעה חיצונית. עד עכשיו התייחסנו לקבצים ש-git תיעד, שאפשר לשחזר אותם כל עוד הגרסאות השמורות נשארות זמינות. סוכן עם גישה רחבה יותר יכול לפגוע גם במנגנון השחזור עצמו. הוא יכול לשכתב או למחוק היסטוריית git, לעשות push לשינויים מזיקים ל-remote אם פרטי ההזדהות שלו מאפשרים זאת, או למחוק את כל הפרויקט. הנזק האפשרי תלוי בקבצים, בשירותים, ובפרטי ההזדהות שהכלים שלו יכולים להגיע אליהם.
חשבו מעבר לשחזור הפרויקט הנוכחי. אם המחשב היה נמחק לגמרי, הייתם צריכים עותק נוסף של כל הנתונים החשובים שלכם. שמרו גיבויים במקום שהסוכן לא יכול לשנות או למחוק. זה ממילא הרגל טוב, כי נוזקות ותוכנות כופר יכולות למחוק מחשב באותה יסודיות כמו סוכן רשלן. בהמשך הקורס נראה איך להקים מכונה מבודדת לסוכן שכמעט אין עליה כלום, מה שמקל על זה מאוד, ו נחזור לאבטחה לעומק.
היכולת להתאושש היא מה שקונה לכם מהירות. הקלו במגבלות לפי כמה שקל לכם לבטל טעות. זה עובד לעריכות ש-git תיעד. שמרו שליטה הדוקה יותר על פעולות שקומיט מקומי לא יכול לבטל, כמו לפרסם משהו או למחוק נתונים שיושבים במקום אחר. git עוזר לשחזר קבצים שתועדו, בעוד שסביבה מבודדת מגבילה למה פקודה יכולה להגיע. שימוש בשניהם יכול להפחית סיכון ולאפשר לעבודה השגרתית להתקדם עם פחות הפרעות.
התרשים הזה מציג כמה אישורים אתם דורשים, כסקאלה שאפשר לכוונן. בקצה השמאלי, אתם סוקרים פעולות לעיתים קרובות לפני שהן רצות. בקשות תכופות נותנות לכם יותר הזדמנויות לתפוס טעות, אבל הן לוקחות מכם זמן. הן לא מבטיחות בטיחות, כי אתם עדיין יכולים לאשר פקודה מזיקה.
בקצה הימני, פעולות רצות בלי לחכות לאישור שלכם. זה מפחית הפרעות, אבל טעות יכולה להתקדם רחוק יותר לפני שתראו אותה. כמה נזק היא יכולה לעשות עדיין תלוי בגישה שלה.
אתם יכולים לבחור הגדרה בין הקצוות האלה ולשנות אותה ככל שהמשימה משתנה. התחילו מחמירים בזמן שאתם לומדים מה הסוכן מבקש לעשות.
הפחיתו בקשות אישור לעבודה שבה הפכתם את השחזור לפשוט או הגבלתם את הגישה של הסוכן. קומיט נקי עוזר בעריכות בקבצים שבמעקב, בעוד שקונטיינר או סביבה מבודדת שמוגדרים כראוי יכולים להגביל למה פקודות מגיעות. חזרו לאישורים מחמירים יותר לקוד לא מוכר ולפעולות שאתם לא יכולים לבטל בקלות. בדקו את הפעולות האלה לפני שהן רצות.
כדי לבחור הגדרה, שאלו במה הגישה הנוכחית של הסוכן מאפשרת לו לפגוע ומה יידרש כדי להתאושש מהנזק הזה. שחזור של קובץ שתועד יכול להיות פשוט. חשיפת סוד או שינוי של שירות מרוחק עלולים להיות בלתי הפיכים. בידוד מצמצם למה הסוכן יכול להגיע, אז ככל שהוא עושה יותר בלי לשאול, כך עליכם להגביל בקפידה רבה יותר את הנזק האפשרי.
אין הגדרה אחת לכל משימה. התחילו מאישורים מחמירים, ואז הקלו בהם לעבודה ספציפית שאתם מבינים את ההשפעות שלה ויכולים לצמצם אותן. המשיכו לבדוק את העבודה בזמן שאתם עושים את זה. משימות מוצלחות קודמות לא הופכות פעולה בלתי הפיכה לבטוחה, ונקודת שמירה עוזרת רק עם סוגי השינויים שהיא מתעדת.
כל מה שראינו עד עכשיו מניח שאתם יכולים לקרוא בקשת הרשאה ולשפוט אותה. בפועל, זה נעשה קשה יותר. סוכנים כותבים לא פעם פקודות ארוכות שמשרשרות צעדים רבים עם &&, ומעבירים בפייפ את הפלט של תוכנית אחת לתוכנית הבאה. הנה בקשת הרשאה לפקודה כזאת. בשורה אחת היא מתקינה חבילות, מריצה את בודק הטיפוסים ומסננת את הפלט שלו, מנקה תיקיית בנייה, מחליפה ענף, ובונה מחדש גרסה להפצה.
כדאי להסתכל מקרוב על צעד אחד באמצע. הוא מריץ rm -rf על כל מה שנמצא בתוך התיקייה שהמשתנה BUILD_DIR מצביע עליה. אם המשתנה הזה במקרה ריק, הנתיב הופך ל-/*. ואז הפקודה מנסה למחוק את כל מה שהיא יכולה להגיע אליו משורש הדיסק. כדי לזהות את זה צריך לקרוא בעיון, והבקשה נראית בדיוק כמו כל הבקשות התמימות שהיו לפניה.
כשכמעט כל הבקשות תמימות, אנשים מפסיקים לקרוא אותן בעיון. לזה קוראים עייפות אישורים. Anthropic מדווחת שמשתמשי Claude Code מאשרים 93 אחוז מבקשות ההרשאה. במחקר ש-Anthropic פרסמה באוגוסט 2026, בקשה אחת במשימת קוד בתשלום הוחלפה בפקודה מסוכנת בעליל. רק 13.6 אחוז מתוך 1,053 הנבדקים חסמו אותה. בתחילת סשן, בערך 17 אחוז תפסו אותה. אחרי חמישים בקשות קודמות או יותר, רק בערך 5 אחוז.
זו אחת הסיבות ש-Claude Code הוסיף מצב אוטומטי, שהוא היום מצב ברירת המחדל שלו. במצב אוטומטי, מודל מסווג נפרד בודק כל פעולה לפני שהיא רצה, וחוסם את אלה שנראות מסוכנות. באותו מחקר, המצב האוטומטי חסם 89 אחוז מהפקודות שהוחלפו. זה הרבה יותר טוב מהנבדקים, אבל זו לא ערובה. לפי המדידות של Anthropic עצמה, המסווג פספס 17 אחוז מהמקרים האמיתיים שבהם הסוכן הלך רחוק יותר ממה שהמשתמש ביקש. אז להסתמך על מצב אוטומטי פירושו להסתמך על שיקול הדעת של מודל אחר, ושיקול הדעת הזה יכול לטעות.
לכן התייחסו לעצות בסרטון הזה כתמונת מצב עדכנית של תחום צעיר. הכלים, ברירות המחדל שלהם והשיטות המומלצות משתנים מהר, ואבטחה של סוכני קוד היא עדיין בעיה פתוחה. כשפקודה ארוכה מכדי לבדוק אותה, אפשר לדחות אותה, ולבקש מהסוכן להריץ את הצעדים אחד-אחד או להסביר כל חלק. מה שעומד במבחן הוא המבנה שבו השתמשנו. הגבילו את מה שהסוכן יכול להגיע אליו, ודאגו שתהיה לכם דרך לשחזר.
אתם מחליטים גם על גישה וגם על פיקוח. גישה היא למה פעולה יכולה להגיע, ופיקוח הוא מתי היא צריכה את האישור שלכם. ב-Claude Code, השתמשו במצבים ובכללים בשביל אישורים, ושקלו הגדרות של סביבה מבודדת ואת הסביבה שמסביב בשביל מגבלות גישה.
התחילו מחמירים וצרו נקודת שמירה לפני שאתם מתירים עריכה שגרתית יותר. עשו קומיט לגרסה שאתם רוצים לשמר, ואז הקלו באישורים רק לעבודה שאת ההשפעות האפשריות שלה אתם יכולים לצמצם ולהתאושש מהן.
חזרו לאישור צמוד יותר כשהמשימה מגיעה לקוד לא מוכר, לנתונים רגישים, או לפעולה שקשה לבטל. גרסת קוד שמורה לא מבטלת כל דבר שפקודה יכולה לעשות. הבחירות האלה מאפשרות לכם לתת לסוכן מרחב עבודה מועיל ובאותו זמן להשאיר את הטעויות האפשריות שלו בשליטה. בכל פעם שאתם מתחילים משימה, בדקו גם למה היא יכולה להגיע וגם מה היא יכולה לעשות בלי לשאול.