למה אישור ידני של כל פעולת AI לא באמת מגן עליכם

מה זה Approval Fatigue

ל-Anthropic יש שם לתופעה הזו, והיא כותבת אותו במפורש: Approval Fatigue, ובעברית "עייפות מאישורים". ההגדרה שלהם פשוטה - עם הזמן זה מוביל למצב שבו אנשים מפסיקים לשים לב היטב למה שהם מאשרים.

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

מנגנון האבטחה לא נשבר בגלל שהוא תוכנן רע. הוא נשבר בגלל שהוא מניח ריכוז אנושי קבוע לאורך מאות החלטות ביום - הנחה שלא מחזיקה מים באף תחום אחר.

וזו לא תובנה חדשה אצלם. כבר באוקטובר 2025 הם כתבו שלחיצה מתמדת על Approve מאטה את הפיתוח ועלולה להוביל ל-Approval Fatigue, שבה משתמשים לא באמת שמים לב למה שהם מאשרים. מאז הקו הזה רק התחזק.

Anthropic לא מסתפקת ברמז. במאמר נפרד מ-25 במאי 2026, בפרסום על האופן שבו הם מכילים את Claude, הם כותבים על גישת ה-Human in the Loop משפט אחד חד: מבחינה תיאורטית זה עובד, אבל מצאנו שהגישה הזו fallible - כלומר ניתנת לכשל. הם גם חוזרים שם על אותו נתון בדיוק: הטלמטריה שלהם הראתה שמשתמשים אישרו בערך 93% מבקשות ההרשאה.

מה Anthropic בנתה במקום

המענה של Anthropic נקרא Auto Mode. במקום להסתמך על כך שהמפתח יקרא ויבין כל פעולה, רץ מודל מסווג (classifier) נפרד שבוחן כל פעולה מול מה שהמשתמש באמת ביקש - לפני שהיא מתבצעת.

המבנה מחולק לשלוש רמות:

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

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

• רמה 3 - עובר למסווג. פקודות shell, בקשות רשת, כלים חיצוניים, הרצת סוכני משנה, ופעולות על קבצים מחוץ לתיקיית הפרויקט.

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

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

המספרים שכדאי להסתכל עליהם

Anthropic לא הסתפקה בתיאוריה. היא לקחה 52 מקרים אמיתיים שבהם Claude היה overeager - כלומר ניסה לבצע פעולה מסוכנת או רחבה יותר ממה שהמשתמש באמת ביקש - והריצה עליהם את המערכת.

שווה לעצור על השילוב בין שתי השורות הראשונות, כי שם נמצא כל הטריק. הפילטר המהיר לבדו החמיץ רק 6.6% מהפעולות המסוכנות - טוב יותר מהצינור המלא. אבל הוא גם חסם בטעות 8.5% מהפעולות התקינות. הצינור המלא מחמיץ יותר (17%), אבל מוריד את החסימות בטעות ל-0.4%.

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

מה נחסם כברירת מחדל

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

• הורדה והרצה של קוד חיצוני, בסגנון הזרמת פלט של curl ישירות ל-bash

• שליחת מידע רגיש לנקודות קצה חיצוניות

• דיפלוי ומיגרציות לסביבת פרודקשן

• מחיקה המונית באחסון ענן

• הענקת הרשאות IAM או הרשאות ל-repository

• שינוי תשתית משותפת

• פתיחת Pull Request מול repository או ארגון אחר, ודחיפה ל-repository של צד שלישי - אלא אם ציינתם את היעד החיצוני הזה בעצמכם

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

התנאי היחיד שבו אישור ידני עדיף

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

שימו לב שההסתייגות הזו היא תנאי, לא פסילה. היא נכונה בדיוק כשמתקיים "אם אתם מאשרים כל פעולה בזהירות". ו-93% הוא בדיוק המדידה של כמה פעמים התנאי הזה לא מתקיים.

אז ההשוואה האמיתית היא לא "AI מול בן אדם". היא מסווג מול מה שקורה אצלכם בפועל. יש לכם מפתח שבאמת קורא כל בקשה, מבין את הפקודה ובודק את ההשלכות? תישארו איתו, הוא עדיף. אבל אם הנתון של 93% מתאר גם אתכם - אתם לא משווים מסווג לבדיקה אנושית קפדנית, אתם משווים מסווג ללחיצה על Enter.

למה זה נהיה דחוף עכשיו

עד עכשיו זו הייתה שאלה תיאורטית שאפשר היה לדחות. פחות מעכשיו: לפי התיעוד הרשמי, החל מ-14 באוגוסט 2026 Auto Mode הופך לברירת המחדל בסשנים חדשים בתוכניות Pro, Max ו-Team.

שווה לדייק: Enterprise, Claude API, Bedrock, Google Cloud ו-Microsoft Foundry אינם כלולים בשינוי הזה בשלב הראשון, אבל מנהלי מערכת ב-Enterprise יכולים כבר עכשיו להפוך את Auto Mode לברירת המחדל דרך ההגדרות המנוהלות.

אפשר להחליף מצב בכל רגע, וברירת מחדל שהגדרתם בעצמכם או כזו שמנוהלת על ידי הארגון לא משתנה. מנהלי מערכת בתוכניות Team ו-Enterprise יכולים לכבות את Auto Mode לארגון כולו דרך ההגדרה disableAutoMode בהגדרות המנוהלות. יש גם פרט קטן ונבון בתכנון: repository לא יכול להעניק לעצמו Auto Mode - ההגדרה מתעלמת מקובצי ההגדרות של הפרויקט ונקראת רק מהגדרות המשתמש.

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

התשובה העמוקה של Anthropic - לא לפקח, להגביל

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

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

בפועל זה מתורגם לשלוש שכבות סביבתיות:

• בידוד תהליכים - סנדבוקס ברמת מערכת ההפעלה ב-Claude Code (Seatbelt ב-macOS, bubblewrap ב-Linux), קונטיינרים מסוג gVisor ב-claude.ai, ומכונות וירטואליות מלאות ב-Claude Cowork.

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

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

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

ויש לזה גם מחיר חיובי שקל לפספס: לפי אותו פרסום, בשימוש הפנימי שלהם סנדבוקס הפחית את מספר בקשות ההרשאה ב-84% - בלי לוותר על בטיחות. כלומר ההגבלה הסביבתית לא רק מגנה טוב יותר, היא גם מייצרת פחות חלונות אישור מלכתחילה, וכך תוקפת את Approval Fatigue מהשורש.

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

וזה בדיוק ההבדל: פיקוח הוא הסתברותי, הגבלה היא דטרמיניסטית. Anthropic מדגישה שהשכבות צריכות לחפוף ולהשלים זו את זו - כשההגנה הסביבתית נכשלת, שכבת המודל אמורה לתפוס; כששכבת המודל נכשלת, הסביבה אמורה להחזיק.

מה זה אומר לארגון שלכם

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

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

• רשימות היתר למחברים - מודל של שני שערים: הרשאה של מנהל המערכת, ועל גביה אישור של המשתמש.

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

• הרצה בסנדבוקס - בניסוח שלהם, הסביבה שבה רץ הסוכן לא צריכה להחזיק שום אישור גישה ששווה לגנוב.

• רשימת היתר לתעבורה יוצאת - כל התעבורה שיוצאת מסביבת ההרצה עוברת דרך פרוקסי, כדי למנוע דליפת מידע.

• ניטור ומתג כיבוי - הזרמת כל הפעלת כלי למערכת ה-SIEM דרך OpenTelemetry, ומתג כיבוי ארגוני לתגובה מהירה.

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

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

השאלה שכדאי להחליף

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

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

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

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

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

סיכום

• 93% מבקשות ההרשאה מאושרות - אישור ידני הוא לא באמת שכבת סינון ברוב המקרים.

• Approval Fatigue היא תופעה מתועדת, לא תחושה. ככל שיש יותר בקשות, כך יורדת תשומת הלב לכל אחת.

• Auto Mode עצר כ-83% מ-52 פעולות מסוכנות אמיתיות, עם 0.4% חסימות שווא בלבד.

• זו לא חלופה לבדיקה אנושית קפדנית - Anthropic אומרת זאת במפורש לגבי תשתיות רגישות.

• סנדבוקס הפחית 84% מבקשות ההרשאה בשימוש הפנימי של Anthropic - פחות חלונות, לא פחות בטיחות.

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

• מ-14 באוגוסט 2026 זו ברירת המחדל בסשנים חדשים ב-Pro, Max ו-Team. הגיע הזמן להחליט מה המדיניות שלכם.

שאלות נפוצות על Approval Fatigue ו-Auto Mode

מה זה Approval Fatigue

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

כמה מבקשות ההרשאה משתמשי Claude Code באמת מאשרים

93%. זהו נתון רשמי שפרסמה Anthropic במאמר ההנדסי שלה על Auto Mode. המשמעות היא שרק כ-7% מהבקשות נדחות בפועל, מה שמעמיד בספק את ההנחה שאישור ידני מהווה שכבת סינון אמיתית.

כמה יעיל Auto Mode בפועל

Anthropic בדקה את הצינור המלא על 52 פעולות אמיתיות שבהן Claude ניסה לחרוג ממה שהמשתמש ביקש. שיעור ההחמצה היה 17%, כלומר Auto Mode עצר כ-83% מהפעולות המסוכנות. במקביל, על תעבורה אמיתית של 10,000 פעולות שיעור החסימות בטעות היה 0.4% בלבד.

מתי Auto Mode פחות בטוח מאישור ידני

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

מה Auto Mode חוסם כברירת מחדל

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

מה Anthropic ממליצה במקום אישור אנושי של כל פעולה

הגבלה סביבתית במקום פיקוח. Anthropic מנסחת זאת כך: במקום לפקח על מה שהסוכן עושה, אנחנו מפקחים על מה שהוא מסוגל לעשות, על ידי אכיפת גבולות גישה. בפועל מדובר בסנדבוקס ברמת מערכת ההפעלה (Seatbelt ב-macOS, bubblewrap ב-Linux), בידוד מערכת קבצים עם הרשאות כתיבה רק בתיקיית העבודה, ובקרת תעבורה יוצאת עם רשימות היתר. ההיגיון: Claude פרוץ עדיין יכול לפגוע במה שבתוך תיקיית העבודה, ולכן הארכיטקטורה מוודאת שזה הדבר היחיד שהוא יכול להגיע אליו.

אילו בקרות Anthropic ממליצה לארגונים שמפעילים סוכני AI

לפי המדריך של Anthropic למנהלי אבטחת מידע מיולי 2026: זהות שמגיעה מספק הזהויות של הארגון, רשימות היתר למחברים במודל של שני שערים, אישור ברמת הפעולה ולא רק ברמת הכלי, הרצה בסנדבוקס שבו אין שום אישור גישה ששווה לגנוב, רשימת היתר לתעבורה יוצאת דרך פרוקסי, הזרמת כל הפעלת כלי ל-SIEM דרך OpenTelemetry, ומתג כיבוי ארגוני. הביקורת האנושית לא נעלמת - היא עוברת מאישור של כל צעד לבדיקה של תוצאה אחת משמעותית, כמו Pull Request לפני פרודקשן.

האם Auto Mode יהיה ברירת המחדל

כן. לפי התיעוד הרשמי, החל מ-14 באוגוסט 2026 Auto Mode הופך לברירת המחדל בסשנים חדשים בתוכניות Pro, Max ו-Team. אפשר להחליף מצב בכל רגע, וברירת מחדל שהגדרתם בעצמכם או שמנוהלת על ידי הארגון נשארת כפי שהיא. מנהלי מערכת יכולים לכבות את Auto Mode לארגון כולו דרך ההגדרה disableAutoMode.