วิธีใช้ Disposable VM สำหรับ AI Coding Agent อย่างปลอดภัย

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

จำกัดสิ่งที่เอเจนต์สามารถเข้าถึงได้บนเครือข่าย

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

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

การมีสถานะที่สะอาดในแต่ละงานเป็นประโยชน์ที่มักถูกมองข้าม เอเจนต์ที่ใช้เวลา 3 ชั่วโมงกับทิกเก็ตล่าสุดได้ทิ้งแพ็กเกจที่ติดตั้งไว้, การไมเกรตที่ทำค้างไว้, 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 ในขณะที่เครื่องยังอยู่ในสถานะปกติ

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

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

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

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

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

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

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

FAQ

การแยกส่วนด้วยคอนเทนเนอร์เพียงพอสำหรับ Coding Agent หรือไม่

สำหรับการทำงานส่วนใหญ่ถือว่าเพียงพอ โดยมีเงื่อนไข 2 ประการ คอนเทนเนอร์ต้องไม่รันด้วย --privileged และต้องไม่มีการเมานต์ /var/run/docker.sock เข้าไปในคอนเทนเนอร์ เนื่องจากทั้งสองกรณีนี้จะเปิดช่องทางให้กระบวนการทำงานสามารถเข้าถึงสิทธิ์ root บนโฮสต์ได้ คอนเทนเนอร์ใช้เคอร์เนลร่วมกับโฮสต์ ดังนั้นขอบเขตการป้องกันจึงต่ำกว่าเครื่องเสมือน (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 บนเซิร์ฟเวอร์นั้นสามารถใช้ซ็อกเก็ตที่ส่งต่อมาได้ในขณะที่คุณเชื่อมต่ออยู่ ดังนั้นควรใช้ deploy key ที่จำกัดขอบเขตเฉพาะ repository บนเครื่องใดก็ตามที่คุณใช้งานร่วมกับผู้อื่น

Agent ต้องการ VPS ขนาดเท่าใด

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

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

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