אוטומציה בטוחה: מה אף פעם לא רץ לבד

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

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

איך אוכפים את זה בפועל

בקלוד קוד, מצבי ההרשאה עושים בדיוק את זה:

• ‎auto‎: מסווג רקע בודק כל פעולה לפני שהיא רצה וחוסם את מה שחורג מהבקשה — פחות שאלות, בלי לרדת לרמת הסיכון של דילוג מלא. מ-14 באוגוסט 2026 זו ברירת המחדל לשיחות חדשות בתוכניות Pro, Max ו-Team
• ‎dontAsk‎: מאשר רק מה שברשימה לבנה ודוחה את השאר — מתאים להרצות מתוזמנות נעולות
• ‎bypassPermissions‎: מדלג על הכול — רק בסביבה מבודדת, לעולם לא על מחשב עם גישה לחשבונות אמיתיים

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

איך הופכים את הכלל להבטחה

הכלל הזה שווה בדיוק כמו המקום שבו הוא רשום. גבול שנאמר בשיחה (“אל תדחוף עד שאבדוק”) עלול ללכת לאיבוד כשדחיסת הקשר מוחקת את ההודעה שקבעה אותו. גבול שיושב בקובץ ההגדרות שורד — וכללי ‎ask‎ נבדקים לפני המסווג ומאלצים שאלה גם במצב אוטומטי:

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

מי שרוצה חסימה מוחלטת ולא שאלה משתמש ב-‎deny‎, שנבדק עוד לפני כן ואינו ניתן לעקיפה.

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

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

הרעיון המלא, עם דוגמה שרצה: האוטומציה הראשונה שלכם ומדריך האוטומציה המלא.