ทำไมควรใช้ VM แบบใช้แล้วทิ้งสำหรับ AI Coding Agent

เหตุผลที่ VM แบบใช้แล้วทิ้งปลอดภัยกว่าแล็ปท็อปของคุณ

หากคุณให้สิทธิ์ตัวแทนเขียนโค้ด (coding agent) เข้าถึง VM แบบใช้แล้วทิ้ง สิ่งที่เลวร้ายที่สุดที่อาจเกิดขึ้นคือการทำลายเครื่องที่คุณสามารถสร้างใหม่ได้ภายในสิบนาที ตัวแทนดังกล่าวยังคงได้รับสิทธิ์ root, ติดตั้งแพ็กเกจ และรันชุดทดสอบได้โดยไม่ต้องขออนุญาตในทุกขั้นตอน ความแตกต่างอยู่ที่ขอบเขตของความเสียหาย หากเป็นบนแล็ปท็อป ตัวแทนจะใช้ home directory ร่วมกับ SSH keys, โปรไฟล์เบราว์เซอร์, ไฟล์ .env และ repository อื่นๆ ทั้งหมดที่คุณเคย clone ไว้ แต่บนเซิร์ฟเวอร์แบบใช้แล้วทิ้ง ตัวแทนจะมีเพียง shell, โค้ดที่ checkout มา และไม่มีสิ่งอื่นใดที่มีค่าให้ต้องกังวล

นี่คือเหตุผลทั้งหมด ซึ่งเป็นประเด็นเรื่องความไม่สมมาตรมากกว่าเรื่องของโอกาสที่จะเกิดความผิดพลาด ตัวแทนที่ระมัดระวังบนแล็ปท็อปที่ได้รับการดูแลอย่างดีมักจะทำงานได้โดยไม่มีปัญหา แต่ในครั้งที่เกิดปัญหาขึ้นมา ความเสียหายที่ได้รับไม่ใช่แค่การ commit โค้ดที่ผิดพลาด แต่คือการที่คุณต้องกู้คืนข้อมูลจาก backup หากคุณมีสำรองไว้

ระบุขอบเขตความเสียหาย (Blast radius) ก่อนที่จะถกเถียงเรื่องนี้

Blast radius หมายถึงชุดของทรัพยากรที่กระบวนการหนึ่งสามารถเข้าถึงได้ สำหรับเอเจนต์ที่ทำงานภายใต้ผู้ใช้ปกติบนเครื่องคอมพิวเตอร์ปกติของคุณ ชุดทรัพยากรเหล่านั้นมีขนาดใหญ่กว่าที่คนส่วนใหญ่คาดคิด

ซึ่งรวมถึง ~/.ssh/id_ed25519 ซึ่งมักจะไม่ได้เข้ารหัสไว้เนื่องจากคุณเบื่อที่จะต้องพิมพ์รหัสผ่าน และรวมถึง ~/.aws/credentials กับ ~/.config/gh/hosts.yml ซึ่งถูกออกแบบมาให้เป็นข้อความธรรมดา (plain text) อยู่แล้ว นอกจากนี้ยังรวมถึง repository อื่นๆ ทั้งหมดภายใต้ ~/code รวมถึง repository ที่มี connection string ของระบบ production อยู่ในไฟล์ env ภายในเครื่อง รวมถึงประวัติการใช้งาน shell ของคุณซึ่งเก็บ token ที่คุณเคยคัดลอกมาวางไว้ และยังรวมถึงเครือข่ายที่แล็ปท็อปของคุณเชื่อมต่ออยู่ ซึ่งมักจะเป็นเครือข่ายบ้านหรือสำนักงานที่มีบริการที่ไม่ได้ผ่านการตรวจสอบสิทธิ์ทำงานอยู่

สิ่งเหล่านี้ไม่จำเป็นต้องอาศัยเอเจนต์ที่มุ่งร้าย แต่ต้องอาศัยเพียงคำสั่งเดียวที่ผิดพลาดอย่างมั่นใจ เช่น rm -rf ที่มีตัวแปรไม่ได้ตั้งค่าจนขยายผลกลายเป็น /, การใช้ git clean -xfd ในไดเรกทอรีที่ผิด, docker system prune -af --volumes ที่ลบฐานข้อมูลภายในเครื่องของคุณทิ้งไปด้วย หรือการใช้ chmod -R 777 ที่ดูเหมือนจะช่วยเหลือได้ดีในไดเรกทอรี home เอเจนต์เหล่านั้นถูกฝึกฝนมาจากอินเทอร์เน็ตแหล่งเดียวกับที่สอนคำสั่งเหล่านี้ให้กับคนอื่นๆ

กลไกที่จะช่วยคุณได้ไม่ใช่การตัดสินใจของเอเจนต์ แต่คือการที่เครื่องคอมพิวเตอร์ที่รองรับความเสียหายนั้นเป็นเครื่องที่คุณพร้อมจะสูญเสียมันไปได้

การคำนวณต้นทุนเป็นเรื่องน่าเบื่อ ซึ่งนั่นคือประเด็นสำคัญ

VPS ขนาดเล็กมีค่าใช้จ่ายเพียงไม่กี่ดอลลาร์ต่อเดือน การกู้คืนแล็ปท็อปสำหรับนักพัฒนาต้องใช้เวลาอย่างน้อยหนึ่งวัน และนั่นคือกรณีที่ดีที่สุดที่คุณสังเกตเห็นปัญหาทันทีและมีข้อมูลสำรองไว้แล้ว

ลองคำนวณด้วยตัวเลขของคุณเอง ใช้อัตราค่าจ้างรายชั่วโมงของคุณ คูณด้วยจำนวนชั่วโมงที่จะต้องใช้ในการติดตั้งระบบปฏิบัติการใหม่ การกู้คืน home directory การเปลี่ยน SSH key การเปลี่ยน personal access token และการ clone repository ใหม่จำนวน 20 รายการ เปรียบเทียบตัวเลขนี้กับค่าใช้จ่ายรายปีของเซิร์ฟเวอร์ขนาดเล็กที่สุดที่ผู้ให้บริการของคุณมี จุดคุ้มทุนจะอยู่ที่เหตุการณ์เพียงครั้งเดียวในรอบหลายปี และเหตุการณ์นั้นไม่จำเป็นต้องเป็นหายนะร้ายแรงก็เกินจุดคุ้มทุนนี้แล้ว การเสียเวลาเพียงช่วงบ่ายเดียวให้กับสภาพแวดล้อมการทำงานในเครื่องที่เสียหาย ก็เพียงพอที่จะครอบคลุมค่าใช้จ่ายของทั้งปีแล้ว

ส่วนที่สองของการคำนวณคือเรื่อง snapshots การทำ snapshot ก่อนรันคำสั่งที่มีความเสี่ยงจะเปลี่ยนผลลัพธ์ที่เลวร้ายจาก "การกู้คืนชีวิตการทำงานใหม่" ให้กลายเป็นเพียง "การย้อนกลับและลองใช้คำสั่งอื่น" ทางเลือกนี้ไม่มีอยู่บนแล็ปท็อปที่คุณกำลังใช้งานอยู่ เพราะคุณไม่สามารถทำ snapshot เครื่องในขณะที่คุณกำลังใช้งานมันเป็นโต๊ะทำงานของคุณได้

ภูมิทัศน์ ณ เดือนกรกฎาคม 2026

มีคำตอบที่ตรงไปตรงมา 3 ประการสำหรับคำถามที่ว่า "ควรให้ agent ทำงานที่ไหน" ซึ่งเป็นการแลกเปลี่ยนระหว่างสองปัจจัย ได้แก่ ความแข็งแกร่งของขอบเขตความปลอดภัย และระดับความยุ่งยากในการตั้งค่าที่คุณยอมรับได้

Micro VM ในเครื่อง. เครื่องมือในกลุ่มนี้จะบูต virtual machine จริงบนฮาร์ดแวร์ของคุณ ทำการ mount repository เข้าไป และอนุญาตให้ agent มีสิทธิ์ root ภายในนั้น clawk คือตัวอย่างในปัจจุบัน ซึ่งมีแนวคิดตรงกับหัวข้อของบทความนี้พอดี นั่นคือการมอบ Linux VM แบบใช้แล้วทิ้งให้กับ coding agent แทนที่จะใช้บนแล็ปท็อปของคุณ ณ เดือนกรกฎาคม 2026 เครื่องมือนี้รองรับ macOS 14 ขึ้นไปบน Apple silicon โดยมีการรองรับ Linux แบบทดลองผ่าน Firecracker และติดตั้งด้วย brew install clawkwork/tap/clawk คุณสามารถรัน clawk ภายใน repository เพื่อบูต sandbox และเชื่อมต่อ agent, ใช้ clawk down เพื่อหยุดการทำงาน และ clawk destroy เพื่อลบออก ขอบเขตความปลอดภัยคือ hypervisor ซึ่งมีความแข็งแกร่งสูง ข้อจำกัดคือ VM จะทำงานอยู่บนเครื่องที่คุณพกพาไปมา จึงแย่งทรัพยากรหน่วยความจำและจะหยุดทำงานเมื่อคุณปิดฝาแล็ปท็อป

Container. Docker คือคำตอบที่คนส่วนใหญ่ติดตั้งไว้แล้ว และมันมีประโยชน์อย่างแท้จริง

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

--rm จะลบ container ทิ้งเมื่อจบการทำงาน และ --network none จะตัดการเชื่อมต่อเครือข่ายทั้งหมด ซึ่งเป็นค่าเริ่มต้นที่ดีสำหรับการ build หรือการรัน test โปรดเข้าใจให้ชัดเจนว่าสิ่งนี้ทำอะไรไม่ได้บ้าง: container ใช้ kernel ร่วมกับ host ดังนั้นบั๊กใน kernel จึงเป็นช่องทางหลุดรอดออกไปได้ และขอบเขตความปลอดภัยจะหายไปทันทีที่คุณเพิ่ม --privileged หรือ mount /var/run/docker.sock เพื่อให้ agent "ใช้ Docker" ได้ การ mount Docker socket เข้าไปใน container เทียบเท่ากับการมอบสิทธิ์ root บน host ให้กับ container นั้น

VPS ธรรมดาที่คุณสามารถสร้างใหม่ได้. ไม่ต้องใช้เครื่องมือใหม่ มีขอบเขตความปลอดภัยระดับ kernel จริง มีระบบ snapshot ของผู้ให้บริการ และมันยังคงทำงานต่อไปแม้คุณจะปิดแล็ปท็อป นี่คือรูปแบบที่คู่มือส่วนที่เหลือจะอธิบาย และเป็นวิธีที่รองรับการทำงานของ agent ในระยะยาวได้ดีที่สุด เพราะงานที่ใช้เวลาสี่ชั่วโมงไม่ได้รับผลกระทบจากการที่คุณเดินทางกลับบ้าน

รูปแบบการใช้งาน VPS: กำหนดผู้ใช้เฉพาะสำหรับเอเจนต์

เริ่มต้นจากเซิร์ฟเวอร์ที่ผ่านการทำ hardening แล้ว บทความเรื่อง สิบนาทีแรกบน VPS ใหม่ ครอบคลุมส่วนที่ไม่เกี่ยวข้องกับเอเจนต์โดยเฉพาะ เช่น การอัปเดตระบบ, การเข้าสู่ระบบด้วยบัญชีที่ไม่ใช่ root, การใช้ SSH key เท่านั้น และการตั้งค่า firewall

จากนั้นให้สร้างบัญชีผู้ใช้ที่มีไว้สำหรับเอเจนต์เท่านั้น เพื่อป้องกันไม่ให้ข้อผิดพลาดภายในบัญชีดังกล่าวส่งผลกระทบต่อส่วนอื่นของเซิร์ฟเวอร์

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 key โปรดสังเกตว่า 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 หากคุณเห็นข้อมูลกุญแจลับแสดงขึ้นมา แสดงว่าไดเรกทอรี home ของคุณมีโหมดเป็น 755 และการแยกสิทธิ์ยังไม่เกิดขึ้นจริง ให้แก้ไขด้วยคำสั่ง sudo chmod 700 /home/you

เก็บข้อมูลรับรองไว้ภายนอกเครื่องทั้งหมด

จุดประสงค์ของการใช้เครื่องแบบใช้แล้วทิ้งจะหมดไปหากคุณคัดลอกความลับของระบบงานจริง (production secrets) ลงไป กฎนั้นเรียบง่ายคือ ห้ามมีข้อมูลรับรองใดๆ บนเครื่องนั้นที่คุณจะต้องกังวลหากต้องเปลี่ยนใหม่ในบ่ายวันนี้

สำหรับ git ให้ใช้วิธี forward SSH agent แทนการคัดลอก key ไปไว้ที่เครื่อง private key จะยังคงอยู่บนแล็ปท็อปของคุณ และมีเพียงคำขอลงลายมือชื่อเท่านั้นที่ส่งผ่านการเชื่อมต่อ

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 จะทำงานได้โดยไม่ต้องมีไฟล์ key อยู่บนเซิร์ฟเวอร์ ให้รัน ls -la ~/.ssh บนเครื่องหลังจากนั้นเพื่อยืนยันว่าไม่มี private key หลงเหลืออยู่

การทำ agent forwarding มีข้อควรระวังที่สำคัญประการหนึ่งคือ ในขณะที่คุณเชื่อมต่ออยู่ ใครก็ตามที่มีสิทธิ์ root บนเซิร์ฟเวอร์นั้นสามารถใช้ socket ที่ถูก forward มาเพื่อยืนยันตัวตนในนามของคุณได้ หากเป็นเซิร์ฟเวอร์ที่มีเพียงคุณเป็นผู้ใช้งานคนเดียวถือเป็นความเสี่ยงที่ยอมรับได้ แต่หากเป็นเครื่องที่ใช้งานร่วมกันถือว่าไม่ปลอดภัย และการใช้ deploy key ที่จำกัดสิทธิ์เฉพาะ repository หนึ่งๆ จะเป็นทางเลือกที่ดีกว่า โดยรายละเอียดของทางเลือกต่างๆ ได้อธิบายไว้ใน พื้นฐานการจัดการ SSH key

สำหรับ API key ให้สร้าง key แยกต่างหากสำหรับ agent โดยเฉพาะพร้อมกำหนดวงเงินการใช้งาน และเก็บไว้ในไฟล์ที่ผู้ใช้ agent เป็นเจ้าของด้วยโหมด 600 เมื่อเครื่องถูกทำลาย ให้เพิกถอน key นั้นทิ้งแทนที่จะต้องมาคอยกังวลว่าข้อมูลจะรั่วไหลหรือไม่ การติดตามค่าใช้จ่ายของโมเดลแยกตาม key ยังเป็นวิธีที่ช่วยให้ตัวเลขใน การควบคุมค่าใช้จ่าย AI agent บน VPS สามารถคาดการณ์ได้แม่นยำ

จำกัดขอบเขตการเข้าถึงเครือข่ายของเอเจนต์

การแยกส่วนระบบไฟล์ (Filesystem isolation) เป็นเพียงครึ่งหนึ่งของขอบเขตการป้องกัน อีกครึ่งหนึ่งคือการควบคุมขาออก (egress): สิ่งที่กระบวนการนั้นได้รับอนุญาตให้ติดต่อสื่อสารด้วย 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 โฮสต์บนอินเทอร์เน็ต ซึ่งเพียงพอต่อการเข้าถึง model API และเพียงพอต่อการเข้าถึง pastebin ด้วยเช่นกัน การทำรายการอนุญาตโดเมน (domain allow-list) ที่แท้จริงจำเป็นต้องให้ทราฟฟิกผ่านพร็อกซีที่อ่านชื่อโฮสต์ที่ร้องขอได้ ซึ่งเป็นกลไกที่ซับซ้อนเกินกว่าที่การตั้งค่าสำหรับนักพัฒนาคนเดียวส่วนใหญ่ต้องการ ให้ระบุเฉพาะสิ่งที่คุณมีจริง: การควบคุมขาออกระดับพอร์ต บนเครื่องที่คุณเตรียมใจไว้แล้วว่าอาจสูญเสียได้

การรีเซ็ตสู่สถานะสะอาดระหว่างงาน

การมีสถานะที่สะอาดในแต่ละงานเป็นประโยชน์ที่มักถูกมองข้าม เอเจนต์ที่ใช้เวลา 3 ชั่วโมงกับตั๋วใบก่อนหน้าอาจทิ้งแพ็กเกจที่ติดตั้งไว้, การทำ migration ที่ค้างคา, node_modules ที่ล้าสมัย และ git working tree ที่มีการเปลี่ยนแปลงซึ่งไม่มีใครตรวจสอบ งานถัดไปจะรับช่วงต่อสิ่งเหล่านี้ทั้งหมด และคุณจะต้องเสียเวลาตรวจสอบเพื่อแยกแยะว่าความยุ่งเหยิงใดเป็นของรอบการทำงานไหน เอเจนต์ที่ทำงานในขอบเขตแคบจะทิ้งสิ่งตกค้างไว้น้อยกว่าตั้งแต่แรก ดังนั้นการจับคู่เครื่องที่ใช้แล้วทิ้งเข้ากับ ทักษะที่ผลักดันให้เอเจนต์สร้างการเปลี่ยนแปลงที่เล็กที่สุดเท่าที่ใช้งานได้ จะช่วยให้ทั้งส่วนต่าง (diff) และสถานะที่เหลืออยู่มีขนาดเล็กพอที่จะตรวจสอบได้

วิธีที่ประหยัดที่สุดคือการ 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 ในขณะที่เครื่องยังอยู่ในสถานะปกติ

เก็บทุกสิ่งที่คุณต้องการไว้ภายนอกเครื่องที่ใช้แล้วทิ้ง ซึ่งส่วนใหญ่หมายถึงการ push branch ขึ้นไปแทนที่จะเก็บไว้ในเครื่อง หากเครื่องนั้นมีข้อมูลที่คุณจะเสียดายหากสูญหายไป ให้สำรองข้อมูลอย่างถูกต้องด้วย restic backups บน VPS เครื่องที่คุณสามารถทำลายทิ้งได้จะมีประโยชน์ก็ต่อเมื่อการทำลายนั้นไม่ส่งผลกระทบใดๆ อย่างแท้จริง

หากคุณต้องการสภาพแวดล้อมที่แยกจากกันหลายชุดโดยไม่ต้องจ่ายเงินสำหรับเซิร์ฟเวอร์หลายเครื่อง VPS ขนาดใหญ่หนึ่งเครื่องสามารถโฮสต์ guest VM ได้โดยตรง Nested virtualisation บน VPS อธิบายถึงวิธีการทำงาน รวมถึงวิธีตรวจสอบว่าผู้ให้บริการของคุณอนุญาตหรือไม่ การแยกส่วน (isolation) มีผลทั้งสองด้าน และหากคุณต้องการให้เอเจนต์สองตัวบนเครื่องเดียวกันประสานงานกันแทนที่จะถูกแยกออกจากกัน เซสชัน Claude Code หนึ่งสามารถส่งข้อความตรงไปยังอีกเซสชันหนึ่งได้ แทนที่จะต้องส่งต่องานผ่านตัวคุณทุกครั้ง

เมื่อการใช้งานแล็ปท็อปอย่างระมัดระวังนั้นเพียงพอแล้ว

จงซื่อสัตย์ในเรื่องนี้ เพราะการกล่าวอ้างเกินจริงเกี่ยวกับระบบแยกส่วน (isolation) จะทำให้ผู้คนเลิกรับฟัง

หากคุณตรวจสอบทุกคำสั่งก่อนที่จะสั่งรัน การใช้แล็ปท็อปก็ถือว่าเพียงพอแล้ว การแจ้งเตือนเพื่อขอสิทธิ์ (permission prompt) คือการควบคุมที่มีประสิทธิภาพจริง และบทความเรื่อง การรัน Claude Code บนเซิร์ฟเวอร์อย่างปลอดภัย ได้อธิบายรายละเอียดว่าแต่ละระดับของการแจ้งเตือนนั้นบล็อกการทำงานอะไรได้บ้าง หากงานของคุณเป็นเพียง repository เดียวและไม่มีข้อมูลรับรอง (credentials) สำหรับ production อยู่บนเครื่องเลย ขอบเขตความเสียหาย (blast radius) ก็ถือว่าน้อยอยู่แล้ว และหากเซสชันของ agent มีระยะเวลาสั้นและอยู่ภายใต้การดูแล ช่วงเวลาที่เสี่ยงต่อการถูกโจมตี (exposure window) ก็จะสั้นตามไปด้วย

คำตอบจะเปลี่ยนไปทันทีที่คุณข้ามขั้นตอนการตอบรับคำขอ ซึ่งเป็นเรื่องที่ควรพิจารณาในขณะนี้ เนื่องจาก auto mode จะกลายเป็นค่าเริ่มต้นของ Claude Code ในวันที่ 14 สิงหาคม 2026 และการติดตั้งใหม่จะไม่ถามก่อนแก้ไขไฟล์หรือรันคำสั่งอีกต่อไป การรันแบบไม่มีผู้ดูแล (unattended runs), งานที่รันข้ามคืน และเวิร์กโฟลว์ใดๆ ที่คุณอนุมัติแผนแล้วปล่อยทิ้งไว้ ล้วนเป็นการตัดขั้นตอนการตรวจสอบโดยมนุษย์ซึ่งเป็นตัวควบคุมความปลอดภัยออกไป นั่นคือจุดที่เครื่องจักรต้องทำหน้าที่แทน และหลักการเดียวกันนี้ยังใช้กับทุกสิ่งที่ขยายขอบเขตการเข้าถึงของ agent รวมถึง การรัน coding agent บน VPS ที่ครอบคลุมหลาย repository พร้อมกัน

การตัดสินใจนี้ไม่ได้ขึ้นอยู่กับว่าคุณเชื่อมั่นในตัวโมเดลมากเพียงใด แต่ขึ้นอยู่กับว่ามีสิ่งใดอยู่ใกล้กับโมเดลนั้นบ้างในยามที่มันทำงานผิดพลาด

FAQ

Container เพียงพอสำหรับการแยกส่วน (isolation) ของ coding agent หรือไม่?

สำหรับงานส่วนใหญ่ถือว่าเพียงพอ โดยมีเงื่อนไข 2 ประการ คือ container ต้องไม่รันด้วย --privileged และต้องไม่มีการ mount /var/run/docker.sock เข้าไปใน container เพราะทั้งสองอย่างนี้จะเปิดช่องทางให้ process สามารถเข้าถึงสิทธิ์ root บน host ได้ เนื่องจาก container ใช้ kernel ร่วมกับ host ขอบเขตการป้องกันจึงต่ำกว่า virtual machine หาก agent ต้องรันโค้ดที่ไม่น่าเชื่อถือซึ่งดึงมาจากอินเทอร์เน็ต ควรใช้ VM จริงหรือเซิร์ฟเวอร์แยกต่างหากจะปลอดภัยกว่า

agent จำเป็นต้องมีสิทธิ์ sudo บนเซิร์ฟเวอร์หรือไม่?

ไม่จำเป็น และการให้สิทธิ์ sudo จะทำลายการแยกส่วนที่คุณสร้างไว้ เพราะ root สามารถอ่านข้อมูลของทุกบัญชีบนเครื่องได้ ให้สร้างผู้ใช้สำหรับ agent โดยไม่ต้องมีสิทธิ์ sudo และให้สิทธิ์เขียนเฉพาะในไดเรกทอรีงานของตนเองเท่านั้น หากงานนั้นจำเป็นต้องติดตั้งแพ็กเกจจริงๆ ให้จัดหาเครื่องแยกต่างหากให้ agent แทนการให้สิทธิ์ root บนเครื่องที่ใช้งานร่วมกับผู้อื่น

จะให้ agent push งานไปยัง git ได้อย่างไรโดยไม่ต้องเก็บ SSH key ไว้บนเครื่อง?

ให้ทำการ forward SSH agent ด้วย ssh -A ในขณะที่คุณเชื่อมต่อ คำขอลงลายมือชื่อจะถูกส่งผ่านการเชื่อมต่อในขณะที่ private key ยังคงอยู่บนแล็ปท็อปของคุณ ดังนั้น ssh -T git@github.com จะทำการยืนยันตัวตนและ git push จะทำงานได้โดยไม่ต้องมี private key บนเซิร์ฟเวอร์ ข้อควรระวังคือ root บนเซิร์ฟเวอร์นั้นสามารถใช้ socket ที่ถูก forward มาได้ในขณะที่คุณเชื่อมต่ออยู่ ดังนั้นควรใช้ deploy key ที่จำกัดขอบเขตเฉพาะ repository บนเครื่องใดก็ตามที่คุณใช้งานร่วมกับผู้อื่น

VPS ขนาดเท่าใดที่ agent ต้องการ?

งานของ agent ส่วนใหญ่คือการแก้ไขไฟล์ รัน build และรันทดสอบ ดังนั้นควรเลือกขนาดเครื่องตามความต้องการของงาน build ไม่ใช่ตามโมเดล โมเดลที่โฮสต์อยู่จะรันบนฮาร์ดแวร์ของผู้ให้บริการ ซึ่งเพิ่มเพียง network traffic และแทบไม่มีภาระงานในเครื่อง ให้เริ่มต้นที่ RAM 2 GB สำหรับงานเขียนสคริปต์ และขยับไปที่ 8 GB หาก repository มีการ build container หรือคอมไพล์งานที่มีขนาดใหญ่

ควรทำลายและสร้างเครื่องใหม่บ่อยแค่ไหน?

ให้สร้างใหม่เมื่อสถานะของเครื่องเริ่มไม่สามารถอธิบายได้ และอย่างน้อยที่สุดคือเมื่อใดก็ตามที่ credential บนเครื่องอาจถูกเปิดเผย การทำ checkout ใหม่ระหว่างงานจะช่วยจัดการปัญหาความเปลี่ยนแปลงสะสมในแต่ละวัน (drift) และการทำ snapshot ก่อนที่ agent จะเริ่มรันงานครั้งแรกจะช่วยให้คุณมีอิมเมจระบบที่สะอาดสำหรับย้อนกลับมาใช้งาน หากการสร้างใหม่ดูเป็นเรื่องยุ่งยาก นั่นเป็นสัญญาณว่ามีข้อมูลสำคัญตกค้างอยู่บนเครื่องที่คุณควรจะมองว่าเป็นเครื่องที่ใช้แล้วทิ้งได้