วิธีรัน Claude Code บนเซิร์ฟเวอร์ให้ปลอดภัยและจำกัดสิทธิ์

ความหมายของการรัน Claude Code บนเซิร์ฟเวอร์อย่างปลอดภัย

การรัน Claude Code บนเซิร์ฟเวอร์อย่างปลอดภัยนั้น คุณต้องคงการแจ้งเตือนเพื่อขอสิทธิ์ไว้ รันด้วยผู้ใช้เฉพาะที่ไม่มีสิทธิ์ระดับ root และกำหนดขอบเขตที่ชัดเจนสำหรับการรันแบบอัตโนมัติแทนการให้ความไว้วางใจโดยสมบูรณ์ โดยใช้ sandbox ที่มีมาให้ในตัว, คอนเทนเนอร์ หรือ VPS แบบใช้แล้วทิ้งที่ไม่มีข้อมูลสำคัญของคุณ แฟล็ก --dangerously-skip-permissions จะข้ามขั้นตอนการขออนุมัติระหว่างโมเดลกับเชลล์ของคุณ การแลกเปลี่ยนนี้อาจสมเหตุสมผลสำหรับงานอัตโนมัติ แต่ต้องทำภายในขอบเขตที่จำกัดขอบเขตความเสียหายหากเกิดคำสั่งที่ผิดพลาดเท่านั้น คู่มือนี้จะอธิบายว่าแฟล็กดังกล่าวเปลี่ยนแปลงการทำงานอย่างไร และวิธีสร้างขอบเขตดังกล่าวโดยแบ่งเป็นระดับการแยกส่วนที่เข้มงวดขึ้นตามลำดับ

สิ่งที่ Claude Code สามารถทำได้บนเครื่องของคุณ

Claude Code คือ coding agent ที่ทำงานใน terminal ของคุณ มันสามารถอ่านไฟล์ เขียนไฟล์ และรัน shell command ในฐานะผู้ใช้ที่เรียกใช้งานมัน นี่คือคุณค่าหลักของเครื่องมือนี้: มันสามารถ clone repository, แก้ไขโค้ด, รันการทดสอบ, อ่านผลลัพธ์ที่ล้มเหลว และแก้ไขโค้ดวนซ้ำได้โดยที่คุณไม่ต้องพิมพ์คำสั่งเอง หากคุณยังไม่ได้ติดตั้งบนเซิร์ฟเวอร์ การรัน Claude Code บน VPS ด้วย tmux ได้ครอบคลุมขั้นตอนการติดตั้งและการจัดการ session ไว้แล้ว หน้านี้จะกล่าวถึงอำนาจที่คุณมอบให้มันเมื่อติดตั้งเสร็จสิ้น

ความเสี่ยงคือประโยคเดิมที่ต้องอ่านซ้ำ กระบวนการที่รัน shell command ในฐานะผู้ใช้ของคุณสามารถทำทุกอย่างที่ผู้ใช้ของคุณทำได้ มันสามารถอ่าน ~/.ssh/id_ed25519, ~/.aws/credentials และไฟล์ .env ทุกไฟล์ที่ผู้ใช้ของคุณเปิดได้ มันสามารถรัน curl และส่งข้อมูลไปยัง host ใดก็ตามที่เซิร์ฟเวอร์เข้าถึงได้ มันสามารถรัน git push --force ได้ ตัว agent ไม่มีเจตจำนงเป็นของตัวเอง อันตรายอยู่ที่งานอาจผิดพลาด หรือข้อความที่มันอ่านระหว่างทำงานอาจมีคำสั่งที่เขียนโดยผู้อื่นแฝงอยู่ เช่น หน้าเว็บที่มันดึงข้อมูลมา หรือความคิดเห็นใน issue ที่ถูกขอให้แก้ไข กรณีหลังนี้เรียกว่า prompt injection และเป็นเหตุผลว่าทำไม "โมเดลปกติจะมีความสมเหตุสมผล" จึงไม่ใช่แผนการรักษาความปลอดภัย คำสั่งอาจมาจากแหล่งที่ใกล้ตัวกว่านั้นได้ เพราะ Claude Code สอง session บนเครื่องเดียวกันสามารถส่งข้อความถึงกันได้ และข้อความจาก session พี่น้องก็เป็นเพียงข้อความที่ agent ผู้รับอ่านเท่านั้น คุณต้องวางแผนรับมือกรณีที่การทำงานผิดพลาด ไม่ใช่กรณีที่การทำงานเป็นไปตามปกติ

อธิบายระบบสิทธิ์การเข้าถึงด้วยภาษาที่เข้าใจง่าย

ในโหมด Manual ระบบ Claude Code จะขออนุญาตก่อนดำเนินการเสมอ การอ่านไฟล์ภายในโปรเจกต์จะเกิดขึ้นโดยไม่มีการแจ้งเตือน แต่หากมีการแก้ไขไฟล์หรือรันคำสั่ง shell ระบบจะแสดงการแก้ไขหรือคำสั่งนั้นให้คุณเห็นก่อนและรอการยืนยัน คุณสามารถอนุมัติการกระทำนั้นครั้งเดียว หรือเลือกที่จะไม่ให้ระบบถามซ้ำอีกได้ ตัวเลือกที่สองนี้จะมีผลจนกว่าจะจบเซสชันสำหรับการแก้ไขไฟล์ แต่สำหรับคำสั่ง shell ระบบจะบันทึกการตั้งค่านี้ไว้อย่างถาวรสำหรับ repository และคำสั่งนั้นๆ ดังนั้นการตอบตกลงอย่างรวดเร็วบนเซิร์ฟเวอร์จะมีผลยาวนานกว่าตัวเซสชัน สำหรับกฎที่คุณต้องการคงไว้ถาวร ไฟล์การตั้งค่าจะเก็บรายการอนุญาต (allow), รายการที่ต้องถาม (ask) และรายการปฏิเสธ (deny) ไว้ ตัวอย่างเช่น: อนุญาต git status, ถามเมื่อมีการใช้ git push, ปฏิเสธการอ่าน .env โดยกฎการปฏิเสธจะมีลำดับความสำคัญสูงสุดเสมอ เกณฑ์มาตรฐานนี้มีการเปลี่ยนแปลงเช่นกัน โดยโหมด Auto ซึ่งมีตัวจำแนกประเภทคอยตรวจสอบการกระทำแทนคุณ ได้กลายเป็นค่าเริ่มต้นสำหรับเซสชันใหม่ในแผน Pro, Max และ Team ตั้งแต่วันที่ 14 สิงหาคม 2026 และตั้งแต่ Claude Code v2.1.283 เป็นต้นไป โหมดนี้ได้กลายเป็นโหมดเริ่มต้นในตัวสำหรับเซสชัน terminal แบบโต้ตอบและ VS Code ในทุกแผนการใช้งาน เว้นแต่คุณจะกำหนดค่าเริ่มต้นไว้ ดังนั้นจึงควรทำความเข้าใจว่า แต่ละโหมดสิทธิ์อนุญาตให้ทำอะไรได้บ้าง ก่อนที่คุณจะตัดสินใจว่าเซิร์ฟเวอร์ที่คุณไม่สามารถเฝ้าดูได้ตลอดเวลานั้นควรใช้โหมดใด

การออกแบบนี้ตั้งสมมติฐานว่ามีมนุษย์คอยเฝ้าดู terminal อยู่ ซึ่งเป็นเรื่องจริงหากใช้งานบนแล็ปท็อป แต่บนเซิร์ฟเวอร์ ประเด็นสำคัญมักอยู่ที่ไม่มีใครเฝ้าดูอยู่ คุณอาจเริ่มงานระยะยาวภายใน tmux แล้วไปนอน แต่หากเอเจนต์หยุดเพื่อถามคำถามตอนตี 2 งานนั้นก็จะไม่คืบหน้าจนกว่าจะถึงเช้า การหยุดชะงักนี้ทำให้เสียทั้งเงินและเวลา เพราะ เซสชัน Claude Code ที่ไม่ได้ใช้งานจะสูญเสีย warm prompt cache และการโต้ตอบครั้งถัดไปจะต้องเสียค่าใช้จ่ายในการสร้าง cache ใหม่ นี่คือเหตุผลตามตรงที่ผู้คนเลือกใช้ flag สำหรับข้ามการถามบนเซิร์ฟเวอร์ และปัญหาที่มันช่วยแก้ไขนั้นเป็นเรื่องจริง ส่วนที่เหลือของคู่มือนี้จะกล่าวถึงวิธีการแก้ไขปัญหานี้โดยไม่ต้องละทิ้งมาตรการป้องกันทั้งหมดที่มีอยู่

สิ่งที่ --dangerously-skip-permissions เปลี่ยนแปลง

claude --dangerously-skip-permissions จะปิดขั้นตอนการขออนุมัติ การแก้ไขไฟล์จะเกิดขึ้นโดยไม่มีการแจ้งเตือน คำสั่ง shell จะทำงานโดยไม่มีการถามยืนยัน และการตรวจสอบ protected-path ที่ปกติจะคอยป้องกันตำแหน่งที่สำคัญก็จะถูกข้ามไปด้วย กฎการปฏิเสธ (deny rules) ที่คุณกำหนดไว้ชัดเจนจะยังคงมีผล และการกระทำที่รุนแรงมากบางอย่างยังคงมีการหยุดถาม แต่สรุปการทำงานได้ง่ายๆ คือ: สิ่งใดก็ตามที่โมเดลตัดสินใจให้รัน มันก็จะรันทันที

มีข้อเท็จจริง 2 ประการเกี่ยวกับ flag นี้ที่สำคัญบนเซิร์ฟเวอร์ ประการแรก มันจะถูกบล็อกเมื่อ Claude Code ทำงานในฐานะ root หรือภายใต้ sudo บน Linux และ macOS เนื่องจาก root ที่ไม่มีการถามยืนยันสามารถเปลี่ยนแปลงไฟล์หรือบริการใดๆ บนเครื่องได้ ตัว agent จำเป็นต้องมีบัญชีผู้ใช้ที่ไม่มีสิทธิ์พิเศษ (unprivileged account) ของตัวเองอยู่แล้ว และ flag นี้จะบังคับให้เป็นเช่นนั้น ประการที่สอง flag นี้ไม่ได้เปลี่ยนพฤติกรรมของโมเดลแต่อย่างใด มันเพียงแค่เอาตัวมนุษย์ออกจากวงจรการตัดสินใจเท่านั้น ดังนั้นทุกความผิดพลาดที่ปกติแล้วการถามยืนยันจะช่วยตรวจพบได้ ตอนนี้จะถูกดำเนินการทันที

ดังนั้น นี่คือการประเมินตามความเป็นจริง หากคุณข้ามการตรวจสอบสิทธิ์ คำถามด้านความปลอดภัยจะเปลี่ยนจาก "agent จะทำอะไรที่เลวร้ายหรือไม่" ไปเป็น "การกระทำที่ผิดพลาดหนึ่งครั้งจะสร้างความเสียหายได้มากเพียงใด" คุณต้องเลิกพยายามควบคุมทุกการตัดสินใจ และเริ่มควบคุมขอบเขตความเสียหาย (blast radius) แทน การจำกัดความเสียหายคือคำตอบ และมันมีระดับการป้องกันที่แบ่งเป็นขั้นๆ

Sandbox ในตัวของ Claude Code

ก่อนจะเข้าสู่ขั้นตอนต่างๆ โปรดทราบว่าปัจจุบัน Claude Code มาพร้อมกับ sandbox ระดับ OS สำหรับคำสั่งที่รัน ซึ่งช่วยลดเหตุผลส่วนใหญ่ที่ทำให้ผู้ใช้ต้องใช้ flag ข้ามการตรวจสอบ (skip flag) ลงไปได้มาก บน Linux ระบบจะใช้ bubblewrap เพื่อแยกส่วนระบบไฟล์ (filesystem isolation) ร่วมกับ socat เพื่อกำหนดเส้นทาง network traffic ผ่าน proxy ภายใน sandbox คำสั่งจะสามารถเขียนข้อมูลได้เฉพาะในไดเรกทอรีของโปรเจกต์และไดเรกทอรีชั่วคราวของเซสชันเท่านั้น และสามารถเข้าถึงเครือข่ายได้ผ่าน proxy ที่ตรวจสอบทุกโดเมนเทียบกับรายการที่อนุญาต (allow list) เท่านั้น เมื่อคำสั่งต้องการเข้าถึงโดเมนใหม่เป็นครั้งแรก Claude Code จะสอบถามคุณ หากอยู่ในโหมดอัตโนมัติ (auto mode) ตัวจำแนกประเภทจะตรวจสอบโฮสต์ใหม่ให้แทน

เปิดใช้งานด้วยคำสั่ง /sandbox ภายในเซสชัน สำหรับ Ubuntu และ Debian ให้ติดตั้งแพ็กเกจที่จำเป็นสองรายการก่อน:

sudo apt install bubblewrap socat

บน Ubuntu 24.04 ขึ้นไป นโยบาย AppArmor เริ่มต้นจะขัดขวางไม่ให้ bubblewrap สร้าง user namespace ที่จำเป็น แผงควบคุม sandbox จะแจ้งเตือนคุณเมื่อมีบางอย่างไม่พร้อมใช้งาน และเอกสารประกอบเรื่องการทำ sandboxing ของ Claude Code จะมีโปรไฟล์ AppArmor แบบสั้นที่ช่วยแก้ไขปัญหานี้ให้

Sandbox มีโหมดอนุญาตอัตโนมัติ (auto-allow mode): คำสั่งที่อยู่ใน sandbox จะรันโดยไม่มีการแจ้งเตือนใดๆ เนื่องจากขอบเขตที่บังคับใช้ในปัจจุบันทำหน้าที่แทนการแจ้งเตือนแบบเดิมแล้ว คำสั่งที่ไม่สามารถรันภายใน sandbox ได้จะกลับไปใช้กระบวนการขออนุญาตตามปกติ ดังนั้นการกระทำที่ผิดปกติจริงๆ ก็ยังคงมีการสอบถามอยู่ สำหรับ workflow บนเซิร์ฟเวอร์ส่วนใหญ่ นี่คือสิ่งที่มาแทนที่ skip flag ได้อย่างเหมาะสม เพราะคุณจะได้รับคำถามน้อยลงมากโดยมีขอบเขตที่บังคับใช้ในระดับ OS แทนที่จะไม่มีการตรวจสอบเลย

โปรดเข้าใจข้อจำกัดของมันอย่างตรงไปตรงมา โดยค่าเริ่มต้นคำสั่งใน sandbox ยังคงสามารถอ่านระบบไฟล์ส่วนใหญ่ได้ รวมถึงไฟล์ข้อมูลรับรอง (credential files) เว้นแต่คุณจะปฏิเสธการเข้าถึง path เหล่านั้น ซึ่งการตั้งค่า sandbox.credentials มีไว้เพื่อการนี้โดยเฉพาะ Proxy เครือข่ายจะตรวจสอบชื่อโดเมนและไม่ได้ตรวจสอบเนื้อหาของ traffic เอง ดังนั้นการอนุญาตแบบกว้างเช่น github.com จึงยังคงเปิดช่องให้มีการย้ายข้อมูลออกไปได้ Docker ไม่สามารถทำงานภายใน sandbox นี้ได้ Sandbox ช่วยยกระดับความปลอดภัยพื้นฐานขึ้นมาก แต่มันไม่ใช่ขอบเขตการแยกส่วนที่สมบูรณ์ ซึ่งเป็นเหตุผลว่าทำไมขั้นตอนต่างๆ ด้านล่างนี้จึงยังคงมีความสำคัญ

ลำดับขั้นของการจำกัดสิทธิ์

มี 3 ขั้น โดยเรียงตามระดับการแยกส่วนที่เพิ่มขึ้น ให้เลือกขั้นที่ต่ำที่สุดที่เหมาะสมกับบริการอื่น ๆ ที่ทำงานอยู่บนเครื่องนั้น

ขั้นที่ 1: การใช้ผู้ใช้ที่ไม่มีสิทธิ์ (unprivileged user) แยกเฉพาะ ตัว agent จะได้รับบัญชีผู้ใช้ของตัวเอง, ไดเรกทอรี home ของตัวเอง, ไดเรกทอรีโปรเจกต์ของตัวเอง และไม่มีสิทธิ์ sudo:

sudo adduser --disabled-password --gecos "" agent

ขอบเขตของบัญชีผู้ใช้จะป้องกันไม่ให้ agent เข้าถึงไฟล์ของคุณ ไม่ว่าจะเป็น SSH keys หรือโปรเจกต์อื่น ๆ ทั้งหมดบนเครื่อง นอกจากนี้ยังทำให้การใช้ flag skip เป็นไปได้จริง เนื่องจาก flag นี้จะปฏิเสธการทำงานหากรันด้วยสิทธิ์ root นี่เป็นหลักการเดียวกับ การรันทุกบริการด้วยผู้ใช้ที่ไม่มีสิทธิ์ ซึ่งนำมาประยุกต์ใช้กับ agent สิ่งที่ขั้นที่ 1 ไม่สามารถจำกัดได้คือ เครือข่าย และสิ่งที่สามารถอ่านได้โดยทุกคน (world-readable) บนเครื่อง

ขั้นที่ 2: การใช้คอนเทนเนอร์ (container) Anthropic ได้เผยแพร่ devcontainer อ้างอิงที่รัน Claude Code ในฐานะผู้ใช้ที่ไม่ใช่ root พร้อมด้วยกฎ firewall ที่จำกัดโฮสต์ที่ agent สามารถเข้าถึงได้ และคอนเทนเนอร์ที่คุณสร้างขึ้นเองก็สามารถทำหน้าที่เดียวกันนี้ได้ ระบบไฟล์จะถูกจำกัดเหลือเพียง volume ที่คุณ mount ไว้ และการเชื่อมต่อขาออกจะถูกจำกัดตามกฎของคอนเทนเนอร์ นี่เป็นขั้นกลางที่เหมาะสมเมื่อเซิร์ฟเวอร์ของคุณโฮสต์บริการอื่น ๆ ที่คุณให้ความสำคัญ ข้อจำกัดของมันคือคอนเทนเนอร์ใช้ kernel ร่วมกับโฮสต์ และการ mount ที่ไม่ระมัดระวังเพียงครั้งเดียวจะทำลายขอบเขตนี้ทันที หากคุณส่ง /var/run/docker.sock ให้กับคอนเทนเนอร์ มันจะสามารถเข้าถึงโฮสต์ทั้งหมดได้

ขั้นที่ 3: การใช้ VPS แยกเฉพาะ ขั้นที่แข็งแกร่งที่สุดคือวิธีที่ตรงไปตรงมาที่สุด นั่นคือการให้ agent ใช้เครื่องทั้งเครื่องที่ไม่มีข้อมูลสำคัญใด ๆ ของคุณอยู่เลย VPS ขนาดเล็กมีค่าใช้จ่ายเพียงไม่กี่ดอลลาร์ต่อเดือน ให้ตั้งค่าโดยใช้ คู่มือการตั้งค่า VPS ใหม่ใน 10 นาทีแรก จากนั้นทำ snapshot สถานะที่สะอาดไว้ แล้วปล่อยให้ agent ทำงาน โดยไม่มีสิ่งอื่นใดอยู่ในนั้น ไม่มี SSH key ส่วนตัว มีเพียง deploy key ที่จำกัดสิทธิ์ไว้เฉพาะ repository เดียวเท่านั้น ไม่มี cloud credentials และไม่มีข้อมูลการผลิต (production data) เมื่อการทำงานผิดพลาด หรือเมื่อคุณต้องการเริ่มต้นใหม่เพียงแค่ restore snapshot หรือทำลายและสร้างเครื่องใหม่ในเวลาไม่กี่นาที รัศมีของความเสียหายจะจำกัดอยู่แค่ค่าเช่าเครื่อง นี่คือการตั้งค่าที่ทำให้ --dangerously-skip-permissions ไม่น่ากลัวอีกต่อไป เพราะผลลัพธ์ที่เลวร้ายที่สุดที่เป็นไปได้คือการต้องสร้างเซิร์ฟเวอร์ใหม่และเพิกถอน token หนึ่งรายการ

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

การปกป้องข้อมูลรับรอง

กฎที่สำคัญที่สุดคือ: ผู้ใช้ของ agent ต้องไม่สามารถอ่านความลับที่อยู่ในความดูแลของส่วนอื่นได้

ให้มอบ API key แก่ agent เท่านั้น ห้ามมอบให้ส่วนอื่น นำ key ไปไว้ในไฟล์ที่ผู้ใช้ของ agent เป็นเจ้าของและตั้งค่าสิทธิ์เป็น 600 จากนั้นจึงโหลดไฟล์ดังกล่าวเมื่อ shell เริ่มทำงาน:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

จากนั้นให้ปิดช่องโหว่ในทิศทางอื่น สำหรับการติดตั้ง Debian และ Ubuntu รุ่นเก่า รวมถึงบัญชีที่ถูกสร้างขึ้นระหว่างการติดตั้ง ไดเรกทอรี home อาจถูกตั้งค่าให้อ่านได้โดยผู้ใช้ทุกคนในเครื่อง ดังนั้นให้จำกัดสิทธิ์ของไดเรกทอรีตนเองด้วย chmod 750 /home/youruser ตรวจสอบด้วย ls -ld /home/* และแก้ไขทุกรายการที่บัญชีของ agent สามารถแสดงรายการออกมาได้

จำกัดขอบเขตของ token ทุกตัว การใช้ GitHub token แบบละเอียดที่จำกัดสิทธิ์ไว้เพียง repository เดียว หรือการใช้ deploy key แยกตาม repository จะช่วยให้มั่นใจได้ว่าหากข้อมูลรับรองรั่วไหล ความเสียหายจะจำกัดอยู่เพียงโปรเจกต์เดียว ไม่ใช่ทั้งบัญชีของคุณ หากคุณใช้งาน sandbox ให้เพิ่มการตั้งค่าข้อมูลรับรองเพื่อปฏิเสธการเข้าถึงด้วย ~/.ssh และ ~/.aws แม้แต่การอ่านข้อมูล และควรเก็บข้อมูลรับรองสำหรับ production ไว้นอกเครื่องทั้งหมด เพราะ agent ไม่สามารถทำข้อมูลรั่วไหลได้หากข้อมูลนั้นไม่ได้อยู่ในเครื่องตั้งแต่แรก หากเก็บความลับเหล่านั้นไว้ใน password manager ที่โฮสต์เอง ให้แยกเครื่องที่ใช้งานออกจากเครื่องของ agent และตรวจสอบความปลอดภัยแยกต่างหาก เพราะ จุดอ่อนของ Vaultwarden คือ admin token และไฟล์สำรองข้อมูล ไม่ใช่ตัว vault ที่ถูกเข้ารหัสไว้เอง

Git คือตาข่ายนิรภัย

ทุกการเปลี่ยนแปลงที่ agent ทำการ commit จะสามารถตรวจสอบและย้อนกลับได้ โดย git จะมอบความสามารถทั้งสองอย่างนี้ให้โดยอัตโนมัติหาก agent ทำงานบน branch และทำการ commit ไปเรื่อยๆ ในระหว่างดำเนินการ:

git switch -c agent/refactor-auth

งานที่ agent ไม่ได้ commit จะไม่มีการป้องกันเช่นนี้: คำสั่ง git reset --hard จะทิ้งการเปลี่ยนแปลงที่ยังไม่ได้ commit ของไฟล์ที่ถูกติดตามอยู่ และ git จะไม่ครอบคลุมถึงสิ่งใดก็ตามที่อยู่นอก repository เลย ให้ตรวจสอบการทำงานหลังจากนั้นด้วย git diff main...agent/refactor-auth เพื่อดูว่ามีการ commit อะไรไปบ้าง จากนั้นใช้ git status และ git diff HEAD บน branch นั้นเพื่อดูสิ่งที่ยังไม่ได้ commit ให้ merge เฉพาะส่วนที่ดี และลบ branch ทิ้งหากการทำงานนั้นไม่ได้ผลลัพธ์ การทำงานที่แก้ไขไฟล์เพียง 3 ไฟล์นั้นอ่านทำความเข้าใจได้ง่ายกว่าการเขียนทับโมดูลไปครึ่งหนึ่ง ซึ่งเป็นเหตุผลเชิงปฏิบัติสำหรับ ทักษะที่ควบคุมให้ agent ทำการเปลี่ยนแปลงที่เล็กที่สุดเท่าที่ใช้งานได้ ให้ป้องกัน branch หลักที่ฝั่ง forge เพื่อไม่ให้ token ของ agent สามารถ push เข้าไปได้ และไม่สามารถ force-push ไปยังที่ใดได้ ประวัติการ commit ยังทำหน้าที่เป็น audit log ของสิ่งที่เกิดขึ้นในขณะที่คุณหลับ ซึ่งมีค่ามากกว่าการเลื่อนดู terminal ย้อนหลังใดๆ

เครือข่ายเป็นส่วนหนึ่งของขอบเขตความเสียหาย (blast radius)

เอเจนต์สามารถรัน curl ได้ ประโยคนั้นคือปัญหาทั้งหมดของการส่งข้อมูลออก (egress): สิ่งใดก็ตามที่เอเจนต์อ่านได้ มันก็สามารถส่งไปยังที่อื่นได้เช่นกัน และเอเจนต์ที่ถูก prompt injection อาจทำเช่นนั้นได้ ผู้ใช้ทั่วไปที่ไม่มีสิทธิ์พิเศษไม่ได้จำกัดเรื่องนี้เลย เพราะผู้ใช้ทุกคนสามารถเข้าถึงทุกสิ่งที่เซิร์ฟเวอร์เข้าถึงได้ แซนด์บ็อกซ์ (sandbox) จะจำกัดขอบเขตนี้ตามโดเมนผ่านพร็อกซีของมัน คอนเทนเนอร์สามารถจำกัดขอบเขตด้วยกฎไฟร์วอลล์ของตัวเอง ส่วน VPS เฉพาะทางจะจำกัดสิ่งที่อาจรั่วไหลได้ตั้งแต่ต้น ซึ่งเป็นวิธีแก้ปัญหาที่แข็งแกร่งที่สุดในทั้งสามวิธี

อย่าพยายามแก้ปัญหาการส่งข้อมูลออกด้วย ufw เพียงอย่างเดียว ufw อนุญาตให้ทราฟฟิกขาออกทั้งหมดโดยค่าเริ่มต้น และการเขียนกฎขาออกที่ยังคงอนุญาตให้ apt, npm, git และ Claude API ทำงานได้นั้นเป็นงานที่ยุ่งยากและมักจะล้มเหลวโดยไม่มีการแจ้งเตือน ให้เลือกจำกัดขอบเขตที่ระดับแซนด์บ็อกซ์ คอนเทนเนอร์ หรือระดับเครื่องแทน ซึ่งการใช้รายการอนุญาตโดเมน (domain allow list) หรือการใช้เครื่องเปล่าจะทำงานได้สะอาดกว่า

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

เสริมความปลอดภัยให้กับเครื่องก่อน

ไม่ว่าคุณจะเลือกใช้ระดับใด เครื่องเซิร์ฟเวอร์จำเป็นต้องมีการตั้งค่าพื้นฐานก่อนที่เอเจนต์จะเริ่มทำงาน ได้แก่ การใช้เฉพาะ SSH keys เท่านั้น, การไม่อนุญาตให้ root ล็อกอิน, การตั้งค่า firewall เป็นแบบ default-deny และการเปิดใช้งานการอัปเดตความปลอดภัยอัตโนมัติ ให้สร้างรายการตรวจสอบของคุณที่นี่และดำเนินการตามลำดับจนครบ:

FAQ

การใช้ --dangerously-skip-permissions บนเซิร์ฟเวอร์มีความปลอดภัยหรือไม่?

โดยตัวมันเองแล้วไม่ปลอดภัย แฟล็กนี้จะลบขั้นตอนการขออนุมัติทั้งหมดออก ดังนั้นคำสั่งที่ไม่พึงประสงค์จะถูกรันทันทีที่โมเดลสร้างคำสั่งนั้นขึ้นมา การใช้งานนี้จะเป็นทางเลือกที่ยอมรับได้เมื่อมีการจำกัดขอบเขตความเสียหายไว้แล้ว เช่น การใช้บัญชีผู้ใช้ที่ไม่มีสิทธิ์พิเศษ (unprivileged user) เป็นอย่างน้อย และสำหรับการทำงานแบบไม่ต้องเฝ้าหน้าจอ (unattended work) ควรใช้คอนเทนเนอร์หรือ VPS แบบใช้แล้วทิ้งที่เก็บเพียงหนึ่งโปรเจกต์และหนึ่งโทเค็นที่มีขอบเขตจำกัด ห้ามใช้แฟล็กนี้บนเครื่องที่เก็บข้อมูลรับรอง (credentials) สำหรับใช้งานจริงหรือข้อมูลที่คุณสูญเสียไม่ได้เด็ดขาด

Claude Code มีระบบ sandbox หรือไม่?

มี Claude Code มาพร้อมกับ sandbox ในตัวสำหรับคำสั่งเชลล์ ซึ่งเปิดใช้งานด้วยคำสั่ง /sandbox โดยใช้ bubblewrap บน Linux และ Seatbelt บน macOS ซึ่งจะจำกัดการเขียนไฟล์ไว้เฉพาะในไดเรกทอรีของโปรเจกต์ และกำหนดเส้นทางการเข้าถึงเครือข่ายผ่านพร็อกซีที่อนุญาตเฉพาะโดเมนที่ผ่านการอนุมัติเท่านั้น โหมด auto-allow จะรันคำสั่งใน sandbox โดยไม่ต้องรอการอนุมัติ จึงช่วยลดการขัดจังหวะได้เช่นเดียวกับการใช้แฟล็ก skip โดยที่ยังคงมีการบังคับใช้ขอบเขตความปลอดภัยระดับ OS อย่างไรก็ตาม นี่ไม่ใช่ขอบเขตการแยกส่วนที่สมบูรณ์ ดังนั้นควรใช้งานร่วมกับบัญชีผู้ใช้เฉพาะหรือเครื่องเฉพาะสำหรับการรันงานแบบไม่ต้องเฝ้าหน้าจอ

ทำไมแฟล็ก skip ถึงปฏิเสธการรันในฐานะ root?

เนื่องจาก root ที่ไม่มีการแจ้งเตือนขออนุญาตสามารถแก้ไขไฟล์และบริการใดๆ บนระบบได้ Claude Code จึงบล็อก --dangerously-skip-permissions เมื่อรันในฐานะ root หรือภายใต้ sudo บน Linux และ macOS วิธีแก้ไขไม่ใช่การพยายามข้ามการตรวจสอบนี้ แต่ให้สร้างผู้ใช้ที่ไม่มีสิทธิ์พิเศษสำหรับเอเจนต์และรันในบัญชีนั้นแทน เพราะขอบเขตของบัญชีผู้ใช้คือชั้นการป้องกันชั้นแรกที่ประหยัดที่สุด

Claude Code สามารถอ่าน SSH keys และไฟล์ .env ของฉันได้หรือไม่?

มันสามารถอ่านทุกอย่างที่ผู้ใช้ซึ่งรันโปรแกรมนั้นสามารถอ่านได้ และแม้แต่นโยบายเริ่มต้นของ sandbox ก็อนุญาตให้อ่านเส้นทางของข้อมูลรับรองได้จนกว่าคุณจะปฏิเสธการเข้าถึง ดังนั้นควรให้เอเจนต์รันในฐานะผู้ใช้ของมันเอง รักษาไดเรกทอรี home ของคุณให้มีโหมด 750 หรือเข้มงวดกว่านั้น ปฏิเสธเส้นทางของข้อมูลรับรองในการตั้งค่า sandbox และเก็บความลับที่ใช้ในงานจริงไว้นอกเครื่องโดยสิ้นเชิง ความลับที่เครื่องไม่เคยจัดเก็บย่อมไม่สามารถถูกอ่านหรือรั่วไหลได้

วิธีที่ปลอดภัยที่สุดในการรัน Claude Code แบบไม่ต้องเฝ้าหน้าจอคืออะไร?

การใช้ VPS ราคาประหยัดที่แยกออกมาสำหรับงานของเอเจนต์โดยเฉพาะ โดยทำการ hardened ภายในสิบนาที ทำ snapshot ไว้ในสถานะสะอาด รัน Claude Code ภายใต้ผู้ใช้ที่ไม่มีสิทธิ์พิเศษโดยเปิดใช้งาน sandbox ใช้ไฟล์โหมด 600 สำหรับเก็บ API key ใช้ deploy key แยกตาม repository และทำงานทั้งหมดบน branch ที่คุณตรวจสอบก่อนทำการ merge หากการรันงานเกิดข้อผิดพลาด คุณเพียงแค่เพิกถอนโทเค็นนั้นและกู้คืน snapshot โดยที่ทรัพย์สินอื่นของคุณจะไม่ได้รับผลกระทบใดๆ