פלייבוק הרשאות לסוכני AI: לסגור את הסוכן לפני שהוא ימחק לכם את המכונה

הקדשתי 47 שעות לכיוונון הרשאות של סוכן קוד אוטונומי על Ubuntu 24.04 במרץ 2026, וכבר בשבוע הראשון המודל ניסה להריץ rm -rf /home/abagent (להמחשה בלבד - לא להריץ) כי קובץ markdown אקראי אמר לו לעשות את זה. הפקודה נכשלה מיד. לא בגלל שהסוכן היה חכם, אלא בגלל ש-ProtectHome=yes בתוך drop-in של systemd באורך 23 שורות הפך את /home לבלתי נראה עבור התהליך. זה בדיוק הפער בין הרשאות סוכן שאפשר לישון לידן לבין כאלה שלא.

למה הרשאות של סוכן שונות מהרשאות של אפליקציה

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

תכל'ס, יש שלושה סוגי נזק שראיתי קורים במו עיניי במהלך בדיקות בתחילת 2026:

1. מחיקת מערכת קבצים: הסוכן קורא קובץ שאומר לו "תריץ ניקיון", ואז מריץ rm -rf ~/projects (להמחשה בלבד - לא להריץ).
2. הדלפת סודות: הסוכן קורא את ~/.ssh/id_ed25519 ושולח אותו ב-POST ל-webhook שהפרומפט נקב בשמו.
3. נזק לריפו: הסוכן מריץ git push --force (להמחשה בלבד - לא להריץ) על main כי הוא חשב שהוא עוזר.

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

מה אתם הולכים לבנות

בסוף התהליך הסוכן שלכם יחיה בתוך namespace של הקרנל שבו /home בכלל לא מ-mounted, יסרב לכל פקודת shell שלא נמצאת ב-allowlist בפורמט JSON, וינתב אישורים לטלפון שלכם במקום לטרמינל. הדפוס עובד עבור OpenClaw, Claude Code, סוכני Cursor, Codex CLI, וכל דבר אחר שקורא ל-execve(). השמות של ה-frameworks משתנים. הקרנל לא משתנה. וזה בדיוק היופי: אתם לומדים את זה פעם אחת ומשתמשים בזה בכל כלי שיגיע אחר כך.

לפני שמתחילים: דרישות מקדימות

• Linux עם systemd (Ubuntu 22.04 ומעלה, Debian 12 ומעלה, Fedora 39 ומעלה). משתמשי macOS, גשו ל-FAQ למטה - יש שם מסלול נפרד.
• חשבון משתמש ייעודי עבור הסוכן, לא משתמש ההתחברות שלכם. זה לא המלצה, זה תנאי. סוכן שרץ תחת המשתמש שלכם רואה את כל מה שאתם רואים.
• Signal או Telegram על הטלפון. השהיית מייל הורגת את הזרימה: עד שתפתחו את התיבה, האישור כבר יפוג.

צעד 1: להפיל את קובץ ה-hardening של systemd

השכבה הזו של 10 דקות עושה את רוב העבודה. תריצו את הסוכן תחת systemd user service, ואז הפילו לתוכו security.conf. כל שורה כאן עושה משהו ספציפי, אז אל תעתיקו על עיוור: תקראו את ההערות.

# /home/abagent/.config/systemd/user/agent-gateway.service.d/security.conf
[Service]
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes

# חיתוך בחזרה של סביבת העבודה של הסוכן בלבד
ReadWritePaths=/home/abagent/.agent/workspace
ReadWritePaths=/home/abagent/.agent/logs

# חסימה מפורשת של מאגר הסודות
InaccessiblePaths=/home/abagent/.ssh
InaccessiblePaths=/home/abagent/.gnupg
InaccessiblePaths=/home/abagent/.aws

# רשת: localhost בלבד. חוסם git push, curl exfil, npm install.
IPAddressDeny=any
IPAddressAllow=localhost

# סינון syscalls (V8 עדיין עובד כאן)
SystemCallFilter=@system-service
SystemCallFilter=~@privileged @resources @reboot @swap @mount

# תקרות משאבים כדי שלולאה שיצאה משליטה לא תהרוס את המכונה
MemoryMax=1G
CPUQuota=50%
TasksMax=128
LimitNOFILE=4096

שימו לב למה שקורה כאן בפועל. ProtectHome=yes מסתיר את כל /home, ואז שתי שורות ReadWritePaths מחזירות בדיוק את שתי התיקיות שהסוכן באמת צריך. שלוש שורות InaccessiblePaths חוסמות במפורש את ה-SSH keys, ה-GPG וה-AWS credentials, גם אם איכשהו תוסיף תיקיה שמכילה אותם. IPAddressDeny=any חותך את הרשת ברמת ה-socket: לא git push, לא curl, לא npm install. ועכשיו תטענו מחדש, תפעילו מחדש, ותבדקו את הציון:

systemctl --user daemon-reload
systemctl --user restart agent-gateway
systemd-analyze --user security agent-gateway.service

היעד: מתחת ל-4.0. Node.js לא מוקשח בדרך כלל מקבל ציון בין 8.5 ל-9.5. אתם אמורים לנחות בסביבות 2.7. אם הציון עדיין גבוה, אתם פספסתם שורה, ותכף נראה ב-troubleshooting איך לצוד אותה.

צעד 2: להגדיר שער allowlist

צעד 1 עוצר נזק למערכת קבצים ולרשת. צעד 2 עוצר פקודות גרועות מלרוץ בכלל. frameworks שונים קוראים לזה אחרת. הדפוס זהה: קובץ JSON, default deny, allowlist של בינאריים בטוחים, ו-fallback של "תשאל את האדם". זהו. אם אתם זוכרים רק ארבע מילים מהסעיף הזה, שיהיו אלה: default deny, ask on miss.

OpenClaw: exec.approvals

// ~/.openclaw/exec-approvals.json
{
  "version": 1,
  "defaults": {
    "security": "deny",
    "ask": "on-miss",
    "askFallback": "deny"
  },
  "agents": {
    "main": {
      "security": "allowlist",
      "ask": "on-miss",
      "askFallback": "deny",
      "allowlist": [
        "/usr/bin/node",
        "/usr/bin/git",
        "~/.local/bin/rg",
        "/opt/homebrew/bin/jq"
      ]
    }
  }
}

שימו לב ש-askFallback מוגדר ל-deny. זה אומר שכשהטלפון שלכם offline ואין מי לאשר, התשובה היא לא. fail closed, לא fail open. זה הבסיס הנכון.

Claude Code: settings.json permissions

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Read(./src/**)",
      "Edit(./src/**)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(curl:*)",
      "Read(./.env*)",
      "Read(~/.ssh/**)"
    ]
  }
}

כללי ה-deny יושבים מעל כללי ה-allow בעדיפות, כך שגם אם glob כלשהו ב-allow היה תופס git push, דפוס ה-deny מנצח. frameworks שהופכים את הסדר הזה פשוט לא בטוחים להרצה ב-production. זו לא דקות, זה fail-safe: ברירת המחדל חייבת להיות "לא".

צעד 3: לנתב אישורים לערוץ נפרד

זה החלק שרוב האנשים מדלגים עליו ואז מתחרטים. כשה-allowlist מפספס והסוכן שואל "מותר לי להריץ את זה?", הפרומפט חייב להופיע איפשהו שהתוקף לא כתב. הטרמינל שלכם לא בטוח כי התוקף שולט במה שגולל מולכם. הודעת Signal פרטית בטוחה. הודעת Telegram פרטית בטוחה. דחיפת push לטלפון בטוחה. ההבדל הוא לא נוחות, ההבדל הוא מי שולט בערוץ.

העברה ל-Signal עבור OpenClaw

תוסיפו את זה ל-openclaw.json שלכם:

{
  "approvals": {
    "channel": "signal",
    "recipient": "+1XXXXXXXXXX",
    "format": "full-command",
    "timeout_seconds": 180,
    "on_timeout": "deny"
  }
}

כשהסוכן רוצה להריץ משהו שלא נמצא ב-allowlist, הטלפון שלכם רוטט עם הפקודה המילולית עצמה. אתם משיבים /approve abc123 allow-once או /approve abc123 deny. שימו לב ל-timeout_seconds: 180 ול-on_timeout: deny: אם לא עניתם תוך 3 דקות, התשובה היא לא, אוטומטית. Lies-in-the-Loop קורסת כאן לחלוטין, כי התוקף לא יכול לגלול את הטלפון שלכם. ה-format: full-command חשוב: אתם רוצים לראות את הפקודה המלאה, לא תקציר שמישהו יכול לזייף.

ומה עם Claude Code על macOS?

ה-build של Claude Code ל-macOS משתמש ב-companion app עם IPC על Unix socket החתום ב-HMAC, כך שאישורים מופיעים כהתראת מערכת. ב-Linux ה-companion עדיין לא קיים, אז העברה לצ'אט היא הערוץ הבטוח היחיד. כן, זה אומר ש-Linux דורש קצת יותר עבודה כאן. שווה כל דקה.

צעד 4: להתפתח מ-permissive ל-locked-down

מעבר מ"אין כללים" ל"deny הכל" במכה אחת הורג לכם את הזרימה. תעשו את זה ב-3 שלבים על פני 7 ימים. זו לא עצלות, זו שיטה: כל יום מלמד אתכם מה הסוכן באמת צריך, וה-allowlist הסופי בנוי על נתונים אמיתיים ולא על ניחושים.

1. יום 1, תצפית: הגדירו security: "full" ו-ask: "off". עשו journalctl --user-unit agent-gateway -f כדי לרשום כל פקודה. אתם בונים baseline. אל תחליטו כלום עדיין, רק תקליטו.
2. יום 2 עד 5, allowlist: עברו ל-security: "allowlist" עם הבינאריים מהלוג שלכם. הגדירו ask: "on-miss". תקבלו פינג 5 עד 11 פעמים ביום. כל פינג או מצטרף לרשימה או נחסם. זו העבודה האמיתית של השבוע.
3. יום 6 עד 7, נעילת הרשת: החילו IPAddressDeny=any. כל דבר שנשבר מספר לכם מה רצה להתקשר הביתה ואם אתם סומכים עליו. הפתעות כאן הן בדיוק מה שאתם רוצים לגלות לפני שתסמכו על הסוכן ירוץ לבד.

הגנה רב-שכבתית: מה עובד ומה לא

פתרון תקלות

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

הסוכן לא מצליח להגיע ל-proxy של LiteLLM: ה-proxy שלכם לא נמצא על localhost. הוסיפו את כתובת ה-Tailscale שלו ל-IPAddressAllow, או העבירו את ה-proxy ל-127.0.0.1.

ציון ה-hardening עדיין מעל 5.0: הריצו systemd-analyze --user security agent-gateway.service --no-pager. שלושת העבריינים הגרועים ביותר הם בדרך כלל RestrictAddressFamilies, SystemCallFilter, ו-CapabilityBoundingSet=. תטפלו בהם לפי הסדר ותראו את הציון צונח.

עריכות ה-allowlist לא נכנסות לתוקף: OpenClaw עושה cache ל-exec-approvals.json לכל session. הריצו /reset או הפעילו מחדש את ה-gateway. זה תפס אותי פעם, חיפשתי באג בקובץ שכבר היה תקין.

שאלות נפוצות

כמה זמן לוקח לסגור סוכן AI?

בערך 25 דקות אם אתם מעתיקים את ה-configs: 10 ל-drop-in של systemd, 10 ל-allowlist, 5 ל-Signal. תקדישו עוד 7 ימים לכיוונון ה-allowlist לפני שאתם סומכים על ריצות אוטונומיות. הרבעת השעה הראשונה מקימה את ההגנה, השבוע הופך אותה למדויקת.

האם sandbox לסוכני AI הכרחי על macOS?

כן, אם כי הכלים שלכם חלשים יותר. השתמשו ב-sandbox-exec עם profile שחוסם file-write* ו-network-outbound מחוץ ל-allowlist מפורש, הריצו את הסוכן תחת חשבון משתמש ייעודי (דפוס ה-sandvault), ונתבו אישורים לטלפון. TCC של macOS לבדו פשוט לא מספיק.

האם prompt injection יכול לעקוף את ההרשאות האלה?

prompt injection לא יכול לעקוף namespaces של הקרנל. הוא בהחלט יכול לעקוף פרומפטים של אישור שמוצגים באותו טרמינל כמו פלט המתקפה. זו בדיוק הנקודה של ערוץ ה-Signal: מחרוזת האישור חיה איפשהו שהתוקף לא יכול לשכתב.

מה ההבדל בין permissions של Claude Code לבין exec.approvals של OpenClaw?

ה-permissions של Claude Code תופסים קריאות כלי וארגומנטים בשכבת הסוכן. ה-exec.approvals של OpenClaw תופס נתיבי בינארי שנפתרו בשכבת ה-gateway. להגנה הכי הדוקה השתמשו בשניהם: התאמת ארגומנטים בסוכן, התאמת בינארי ב-gateway. שתי שכבות שתופסות שני סוגי פספוס.

האם להריץ את הסוכן ב-Docker או ב-Podman?

עבור סוכן יחיד על מכונה אישית, unit מוקשח של systemd נותן לכם 80% מהערך עם 20% מהכאב. עברו ל-Podman ב-rootless כשאתם ב-3 סוכנים ומעלה, בשביל בידוד UID לכל סוכן. ראו כלי סוכנים להגדרות שמתרחבות.