איך לתת לסוכן קידוד VM זמני ובטוח

מדוע VM זמני עדיף על המחשב הנייד שלך

תנו לסוכן קידוד VM זמני, והדבר החמור ביותר שהוא יכול לעשות הוא להשמיד מכונה שאפשר לבנות מחדש בתוך עשר דקות. לסוכן עדיין יש הרשאות root, הוא עדיין מתקין חבילות, והוא עדיין מריץ את חבילת הבדיקות בלי לבקש אישור לכל שלב. ההבדל הוא המקום שבו נגרם הנזק. במחשב נייד, הסוכן חולק את ספריית הבית עם מפתחות ה-SSH שלכם, עם פרופיל הדפדפן, עם קובצי .env ועם כל מאגר אחר ששכפלתם אי-פעם. בשרת זמני, יש לו מעטפת פקודה, עותק עבודה, ושום דבר אחר ששווה לגנוב.

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

הגדירו את מרחב הפגיעה לפני הוויכוח עליו

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

היא כוללת את ~/.ssh/id_ed25519, שבדרך כלל אינו מוצפן, משום שנמאס לכם להקליד את משפט הסיסמה. היא כוללת את ~/.aws/credentials ואת ~/.config/gh/hosts.yml, שהם טקסט פשוט מעצם תכנונם. היא כוללת כל repository מקביל תחת ~/code, לרבות אלה שמכילים מחרוזות חיבור לייצור בקובץ env מקומי. היא כוללת גם את היסטוריית ה-shell שלכם, שבה נשמרו tokens שהדבקתם פעם. היא כוללת גם את הרשת שאליה מחובר המחשב הנייד שלכם, שהיא לעיתים קרובות רשת ביתית או משרדית עם שירותים לא מאומתים.

כל זה אינו דורש agent זדוני. נדרשת פקודה אחת, שגויה בביטחון. rm -rf עם משתנה שלא הוגדר, שמתרחב ל-/, git clean -xfd בתיקייה הלא נכונה, docker system prune -af --volumes שלוקח איתו את מסד הנתונים המקומי שלכם, או chmod -R 777 מועיל בתיקיית הבית. Agents מאומנים על אותו internet שלימד את הפקודות האלה את כולם.

המנגנון שמגן עליכם אינו שיקול הדעת של ה-agent. ההגנה נובעת מכך שהמחשב שעליו נמצא הנזק הוא מחשב שהייתם מוכנים לאבד.

חישוב העלות משעמם, וזו בדיוק המטרה

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

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

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

המצב נכון ליולי 2026

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

מיקרו-VM מקומי. כלים בקטגוריה זו מאתחלים מכונה וירטואלית אמיתית על החומרה שלכם, מחברים אליה את המאגר שלכם ומאפשרים לסוכן לקבל הרשאות root בתוכה. clawk הוא הדוגמה העדכנית, והרעיון המרכזי שלו זהה בדיוק לתזה של פוסט זה: לספק לסוכני קידוד מכונת Linux וירטואלית זמנית, ולא להשתמש במחשב הנייד שלכם. נכון ליולי 2026, הוא מיועד ל-macOS 14 ומעלה על מעבדי Apple silicon, עם תמיכה ניסיונית ב-Linux באמצעות Firecracker, והוא מותקן באמצעות brew install clawkwork/tap/clawk. מריצים clawk בתוך מאגר כדי לאתחל את סביבת החול ולחבר אליה סוכן, את clawk down כדי לעצור אותה, ואת clawk destroy כדי להסיר אותה. הגבול הוא hypervisor, ולכן הוא חזק. המגבלה היא שה-VM פועל במחשב שאתם נושאים אתכם, ולכן הוא מתחרה על הזיכרון שלכם ונעצר כשאתם סוגרים את המכסה.

מכולה. Docker הוא הפתרון שכבר מותקן אצל רוב האנשים, והוא שימושי באמת.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm מסיר את המכולה בעת היציאה, ו---network none מונע ממנה גישה לרשת, וזו ברירת מחדל טובה לתהליך build או להרצת בדיקות. חשוב להבין מה פעולה זו אינה עושה: מכולה משתפת את ליבת ה-host, ולכן באג בליבה עשוי לאפשר יציאה ממנה, והגבול נעלם ברגע שמוסיפים --privileged או מחברים את /var/run/docker.sock כדי לאפשר לסוכן "להשתמש ב-Docker". חיבור ה-socket של Docker למכולה שקול להענקת הרשאות root ב-host לאותה מכולה.

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

תבנית ה-VPS: הקצו לסוכן משתמש משלו

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

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

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password פירושו שאין סיסמה שניתן לנחש, וניגשים לחשבון באמצעות sudo -u agent או באמצעות מפתח SSH. שימו לב ש-agent אינו נמצא בכוונה בקבוצה sudo. לסוכן עם sudo יש הרשאות root, ו-root יכול לקרוא את הקבצים של כל משתמש אחר. במקרה כזה ההפרדה שבניתם היא למראית עין בלבד. אם הסוכן באמת זקוק להתקנת חבילות, זו סיבה להקצות לו שרת שלם בבעלותו, ולא למסור לו את sudo בשרת משותף. הכללים הכלליים מופיעים ב-עקרון ההרשאות המזעריות למשתמשי Linux ב-VPS.

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

sudo -u agent cat /home/you/.ssh/id_ed25519

אתם אמורים לראות cat: /home/you/.ssh/id_ed25519: Permission denied. אם מופיע במקום זאת חומר מפתח, ספריית הבית שלכם מוגדרת במצב 755 והבידוד עדיין אינו ממשי. תקנו זאת באמצעות sudo chmod 700 /home/you.

השארת פרטי האימות מחוץ למכונה לחלוטין

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

עבור git, העבירו את ה-SSH agent במקום להעתיק מפתח. המפתח הפרטי נשאר במחשב הנייד שלכם, ורק בקשות חתימה עוברות דרך החיבור.

ssh -A agent@203.0.113.10
ssh -T git@github.com

הפקודה השנייה אמורה להחזיר את Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. כך מוכח ש-git push יפעל ללא קובץ מפתח בשרת. לאחר מכן הריצו במכונה את ls -la ~/.ssh ואשרו שאין בה מפתח פרטי.

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

עבור מפתחות API, הקצו ל-agent מפתח משלו עם מגבלת הוצאה משלו, ושמרו אותו בקובץ שבבעלות המשתמש agent, עם הרשאות 600. כאשר המכונה מושמדת, בטלו את המפתח במקום לנסות לברר אם דלף. גם שמירת הוצאות המודלים גלויה לפי מפתח היא הדרך לשמור על מספרים צפויים, כפי שמתואר ב-בקרת עלויות של AI agent ב-VPS.

הגבלת היעדים שאליהם הסוכן יכול לגשת ברשת

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

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

הכללים נקראים לפי הסדר, ולכן REJECT האחרון תופס את כל מה שהשורות הקודמות לא התירו. בדקו זאת כאותו סוכן:

sudo -u agent curl -sS -m 5 http://example.com

הפעולה אמורה להיכשל עם curl: (7) Failed to connect to example.com port 80: Connection refused, משום שכלל הדחייה משיב מיד במקום לאפשר לחיבור להיתקע. בקשת HTTPS לאותו מארח עדיין אמורה להצליח.

יש כאן שתי מגבלות שחשוב לציין. ראשית, הכללים האלה יאבדו באתחול הבא, אלא אם תשמרו אותם באמצעות sudo apt install -y iptables-persistent ולאחר מכן באמצעות sudo netfilter-persistent save. שנית, הסינון חל על פורטים ועל כתובות, ולא על שמות. כלל המתיר את פורט 443 מאפשר גישה לכל מארח HTTPS באינטרנט. די בכך כדי לגשת ל-API של המודל, אך גם כדי לגשת ל-pastebin. רשימת היתרים אמיתית לפי שמות מתחם מחייבת להעביר את התעבורה דרך proxy שקורא את שם המארח המבוקש. זהו מנגנון מורכב יותר ממה שרוב סביבות העבודה של מפתח יחיד מעוניינות להפעיל. ציינו רק את מה שבאמת מוגן: בקרת תעבורה יוצאת ברמת הפורטים, במחשב שהייתם מוכנים לאבד.

איפוס למצב נקי בין משימות

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

הגרסה הזולה היא לבצע checkout חדש לכל משימה.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

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

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

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

מתי מחשב נייד עם אמצעי זהירות אכן מספיק

יש להתייחס לכך בכנות. הגזמה בחשיבות הבידוד גורמת לאנשים להפסיק להקשיב.

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

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

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

FAQ

האם מבודד מספיק להפעיל סוכן תכנות בתוך container?

ברוב המשימות, כן, בתנאי שמתקיימים שני תנאים. אסור להפעיל את ה-container עם --privileged, ואסור למפות לתוכו את /var/run/docker.sock, משום שכל אחד מהם מספק לתהליך נתיב אל ה-root של המארח. ה-container משתף את ליבת המארח, ולכן הגבול שלו חלש יותר מזה של מכונה וירטואלית. אם הסוכן מריץ קוד לא מהימן שהורד מהאינטרנט, העדיפו VM אמיתי או שרת נפרד.

האם הסוכן זקוק ל-sudo בשרת?

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

כיצד אפשר לאפשר לסוכן לדחוף שינויים ל-git בלי להציב בשרת את מפתח ה-SSH שלי?

העבירו את סוכן ה-SSH שלכם באמצעות ssh -A בעת ההתחברות. בקשות חתימה עוברות דרך החיבור, בעוד שהמפתח הפרטי נשאר במחשב הנייד שלכם. כך ssh -T git@github.com מבצע אימות ו-git push פועל ללא מפתח פרטי בשרת. עם זאת, root בשרת יכול להשתמש בשקע שהועבר בזמן שאתם מחוברים. לכן, בכל מחשב שאתם משתפים עם אנשים אחרים, השתמשו במפתח פריסה המוגבל למאגר.

איזה גודל VPS דרוש לסוכן?

עבודת סוכן כוללת בעיקר עריכת קבצים, הפעלת תהליכי build והרצת בדיקות. לכן יש להתאים את גודל המחשב ל-build ולא למודל. מודל מתארח פועל בחומרה של הספק, ולכן הוא מוסיף תעבורת רשת וכמעט שאינו יוצר עומס מקומי. התחילו ב-2 GB RAM לעבודות תכנות, ועברו ל-8 GB אם המאגר בונה containers או מקמפל רכיבים משמעותיים.

באיזו תדירות עליי להשמיד ולבנות מחדש את המחשב?

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