เปิดกล่องดำ "ระบบสิทธิ์" ของ Claude Code: เมื่อ AI ที่ทรงพลังต้องมาพร้อมรั้วที่รัดกุม

เกริ่นนำ: ยิ่งทำได้มาก ยิ่งต้องคุมให้ดี

เครื่องมือ AI ที่ทำงานแบบ agentic อย่าง Claude Code นั้นมีความสามารถสูงมาก มันสามารถรันคำสั่ง bash แก้ไขไฟล์ เชื่อมต่อเครือข่าย และสั่งงาน subagent ได้ทั่วทั้งโปรเจกต์ของเรา แต่ความสามารถที่สูงนี้ก็มาพร้อมความเสี่ยงที่สูงตามไปด้วย ยิ่งเครื่องมือทำอะไรได้มากเท่าไร ความเสียหายที่อาจเกิดขึ้นก็ยิ่งมากขึ้นเท่านั้น

หลายคนรู้จักระบบสิทธิ์ของ Claude Code ผ่านหน้าต่างยืนยันที่ขึ้นมาให้กด "อนุญาต" ไปเรื่อย ๆ โดยไม่เข้าใจว่าเบื้องหลังนั้นมีโครงสร้างที่ซับซ้อนกว่านั้นมาก บทความนี้จะพาไปทำความเข้าใจว่าระบบความไว้วางใจ (trust architecture) ของ Claude Code ทำงานอย่างไร ตั้งแต่นโยบายระดับองค์กรที่อยู่เหนือการตั้งค่าส่วนตัว ไปจนถึงกลไกที่ตัดสินว่าคำสั่งหนึ่ง ๆ จะถูกปฏิเสธ ถูกถาม หรือได้รับอนุญาตให้ทำงานทันที

ลำดับชั้นของการตั้งค่า 5 ระดับ

Claude Code จัดการการตั้งค่าผ่านลำดับชั้นที่ตายตัว การเข้าใจลำดับนี้คือกุญแจสำคัญที่แยกระหว่างการตั้งค่าที่ใช้งานได้จริง กับการตั้งค่าที่ถูกเขียนทับไปโดยไม่รู้ตัว

ลำดับจากสูงสุดไปต่ำสุดมีดังนี้

1. Managed — นโยบายที่ฝ่าย IT ขององค์กรติดตั้งไว้ในไดเรกทอรีระดับระบบ ไม่มีการตั้งค่าใดเขียนทับได้
2. CLI arguments — คำสั่งที่ระบุตอนเรียกใช้งาน มีผลเหนือกว่าทุกระดับที่อยู่ต่ำกว่า
3. Local (.claude/settings.local.json) — การตั้งค่าเฉพาะเครื่อง ไม่ถูกเก็บใน git เป็นการปรับแต่งส่วนตัว
4. Project (.claude/settings.json) — ถูกเก็บไว้ใน version control และใช้ร่วมกันทั้งทีม
5. User (~/.claude/settings.json) — ค่าเริ่มต้นส่วนตัวที่ติดตัวไปทุกโปรเจกต์

จุดที่สำคัญที่สุดอยู่บนสุด นั่นคือการตั้งค่าระดับ Managed ถูกออกแบบมาเพื่อให้องค์กรบังคับใช้นโยบายที่พนักงานแต่ละคนไม่สามารถหลีกเลี่ยงได้ ถ้าฝ่าย IT ตั้งค่าห้ามใช้เครื่องมือบางอย่างไว้ ต่อให้ตั้งค่าระดับ Local หรือ Project อย่างไรก็ไม่สามารถเปิดใช้งานกลับมาได้ นี่ไม่ใช่แค่ "คำแนะนำ" แต่เป็นการบังคับใช้จริง

ผลที่ตามมาคือ นักพัฒนาที่ทำโปรเจกต์ส่วนตัวจะเจอแต่การตั้งค่าระดับ User และ Project เป็นหลัก ในขณะที่วิศวกรในองค์กรใหญ่อาจพบว่าความสามารถบางอย่างถูกล็อกไว้ตั้งแต่แรกโดยที่ตัวเองไม่เคยเห็นการตั้งค่านั้นเลย ทั้งสองประสบการณ์นี้เป็นสิ่งที่ตั้งใจออกแบบไว้ตั้งแต่ต้น

กติกาการตัดสินสิทธิ์: 3 ขั้นตอนที่ต้อง "ผ่านให้ถูกลำดับ"

ภายในแต่ละระดับการตั้งค่า กฎเรื่องสิทธิ์จะถูกประเมินตามหลักการ "ใครเจอก่อนชนะ" (first-match-wins) ผ่าน 3 ขั้นตอนตามลำดับนี้

1. Deny (ปฏิเสธ) — ถ้าคำสั่งตรงกับกฎห้ามข้อใดข้อหนึ่ง จะถูกบล็อกทันที ไม่มีการประเมินต่อ
2. Ask (ถาม) — ถ้าตรงกับกฎที่ต้องขออนุญาต ระบบจะถามผู้ใช้ก่อน
3. Allow (อนุญาต) — ถ้าตรงกับกฎที่อนุญาตไว้ ระบบจะทำงานทันทีโดยไม่ถาม

ถ้าไม่ตรงกับกฎใดเลย ระบบจะใช้พฤติกรรมเริ่มต้นของเครื่องมือนั้น ๆ

กฎเหล่านี้เขียนในรูปแบบ Tool หรือ Tool(specifier) และรองรับรูปแบบ glob pattern เช่น Bash(npm test) สำหรับคำสั่งเฉพาะ Bash(rm *) สำหรับคำสั่งลบไฟล์ที่อันตราย หรือ Write(*.env) สำหรับการเขียนไฟล์ environment สิ่งที่ทำให้ระบบนี้ยืดหยุ่นแต่ก็เปราะบางไปพร้อมกันคือ ถ้าตั้งกฎ deny แบบกว้างเกินไป อาจบล็อกการทำงานที่เราตั้งใจจะอนุญาตไปด้วยโดยไม่รู้ตัว

จุดที่นักพัฒนามักพลาดคือเรื่อง "ใครมาก่อนในขั้นตอนเดียวกัน" ยกตัวอย่างเช่น ถ้าตั้งกฎห้าม Bash(rm *) และตั้งกฎอนุญาต Bash(rm -rf node_modules) ไว้ กฎห้ามจะทำงานก่อนเสมอ กฎอนุญาตจะไม่ถูกใช้เลย เพราะลำดับขั้นตอน (deny ก่อน ask ก่อน allow) นั้นตายตัว ข้อสรุปเชิงปฏิบัติคือ ควรเขียนกฎ deny ให้แคบและเฉพาะเจาะจงที่สุด ส่วนกฎ allow ให้เขียนกว้างได้ตามความเหมาะสม

นอกจากนี้ยังมีกลไก permissions.deny ที่เข้ามาแทนที่ระบบเก่าอย่าง ignorePatterns เพื่อควบคุมการเข้าถึงไฟล์แบบเจาะจง เป้าหมายหลักคือไฟล์ประเภท .env โฟลเดอร์เก็บ credentials คีย์ลับต่าง ๆ เพราะเมื่อ Claude Code อ่านเนื้อหาไฟล์ เนื้อหานั้นจะถูกส่งผ่าน API ไปยังผู้ให้บริการคลาวด์ด้วย หากไฟล์นั้นมีรหัสผ่านฐานข้อมูล production อยู่ ก็เท่ากับว่าข้อมูลลับได้ถูกส่งออกไปแล้ว การตั้งค่า permissions.deny จึงเปรียบเสมือนไฟร์วอลล์ป้องกันจุดนี้

แซนด์บ็อกซ์: จำกัดพื้นที่แทนการจำกัดตัวเอเจนต์

Claude Code มีระบบแซนด์บ็อกซ์ระดับปฏิบัติการ (OS-level sandboxing) สำหรับคำสั่ง bash ซึ่งไม่ใช่แค่แนวคิด แต่เป็นกลไกที่ระบบปฏิบัติการบังคับใช้จริง เพื่อจำกัดสิ่งที่โปรเซสซึ่งถูกสร้างโดย Claude Code จะทำได้

แซนด์บ็อกซ์นี้จำกัดการเข้าถึงเครือข่ายด้วยรายการโดเมนที่อนุญาต (allowlist) โดยค่าเริ่มต้นจะเข้าถึงได้เฉพาะโดเมนที่จำเป็นต่อการทำงานเท่านั้น ส่วนการเข้าถึงเครือข่ายอื่น ๆ จะถูกบล็อก แต่สามารถเพิ่มโดเมนเข้าไปในรายการได้ตามความต้องการของแต่ละงาน เช่น package registry หรือ API ภายในองค์กร นอกจากนี้ยังควบคุมได้ถึงระดับ Unix socket, การผูก port ภายในเครื่อง และการยกเว้นคำสั่งบางประเภท ทำให้สามารถกำหนดกฎแบบละเอียด เช่น "อนุญาตให้ติดตั้ง npm ได้ แต่ห้าม curl ไปยัง URL ใด ๆ ที่ไม่ได้กำหนดไว้"

จุดที่น่าสนใจคือ เมื่อเปิดใช้แซนด์บ็อกซ์ Claude Code สามารถอนุมัติคำสั่ง bash โดยอัตโนมัติได้ เพราะขอบเขตความเสียหายถูกจำกัดไว้แล้ว แม้คำสั่ง rm -rf / ที่รันในแซนด์บ็อกซ์จะยังทำลายไฟล์ในเครื่องได้ แต่จะไม่สามารถส่งข้อมูลออกไปยังเซิร์ฟเวอร์ภายนอกได้ เช่นเดียวกับคำสั่ง curl ที่จะไม่สามารถเข้าถึงโดเมนนอกรายการที่อนุญาต นี่คือแนวคิดออกแบบหลัก คือ "ทำให้การทำงานอัตโนมัติปลอดภัยด้วยการจำกัดสภาพแวดล้อม แทนที่จะจำกัดตัวเอเจนต์" ซึ่งแลกการเตือนขออนุญาตบ่อย ๆ กับขอบเขตความปลอดภัยที่แน่นอนกว่า

อย่างไรก็ตาม แซนด์บ็อกซ์ก็ยังมี "ทางออกฉุกเฉิน" คือถ้าจำเป็นต้องรันคำสั่งที่ไม่ได้อยู่ในแซนด์บ็อกซ์ ระบบจะถามผู้ใช้ก่อน แต่ในองค์กรที่ต้องการความมั่นใจแบบเข้มงวด สามารถปิดทางออกนี้ผ่านการตั้งค่าระดับ Managed ได้

Checkpoint: ตาข่ายนิรภัยที่ไม่ครอบคลุมทุกอย่าง

ก่อนแก้ไขไฟล์ทุกครั้ง Claude Code จะสร้าง snapshot ของไฟล์ที่เกี่ยวข้องไว้ล่วงหน้า ถ้ามีอะไรผิดพลาด การกด Escape สองครั้งจะย้อนทั้งโค้ดและบทสนทนากลับไปยังจุด checkpoint นั้น ๆ ได้ ถือเป็นระบบ undo ที่ดีสำหรับสิ่งที่มันครอบคลุม นั่นคือการแก้ไขไฟล์ผ่านเครื่องมือ Write และ Edit ของ Claude Code เท่านั้น

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

Devcontainer: ไอโซเลชันระดับเครือข่าย และปัญหาการรั่วไหลข้อมูลที่แก้ไม่หมด

Development container (devcontainer) ช่วยแยกเครือข่ายด้วยไฟร์วอลล์แบบ default-deny คือปฏิเสธการเชื่อมต่อทั้งหมดยกเว้นที่กำหนดไว้ล่วงหน้า การตั้งค่านี้จำกัดโฮสต์ที่ Claude Code เข้าถึงได้ ทำให้แม้แต่การตั้งค่าแบบ --dangerously-skip-permissions ก็อันตรายน้อยลง เพราะตัว container เองเป็นตัวจำกัดขอบเขตความเสียหายอยู่แล้ว

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

แต่มีข้อควรระวังสำคัญคือเรื่องการรั่วไหลของข้อมูล (exfiltration) devcontainer ไม่สามารถป้องกันการรั่วไหลของ credentials จากโปรเจกต์ที่มีเจตนาร้ายได้ ถ้าโค้ดในโปรเจกต์มีคำสั่งแฝงที่ทำให้ Claude Code อ่าน credentials แล้วเข้ารหัสส่งออกไปผ่านช่องทางที่ได้รับอนุญาตอยู่แล้ว ไฟร์วอลล์ของ container ก็จะไม่ช่วยอะไร เพราะข้อมูลออกไปผ่านช่องทางที่ "ได้รับอนุญาต" อยู่แล้วนั่นเอง นี่ไม่ใช่เรื่องสมมติ เพราะการโจมตีแบบ supply chain ที่แฝงคำสั่งไว้ในคอมเมนต์โค้ดหรือไฟล์ README เป็นช่องทางโจมตีที่รู้จักกันดี

ทางแก้ที่เหมาะสมคือการป้องกันแบบหลายชั้น (layered defense) — ใช้ permissions.deny เพื่อป้องกันไม่ให้ Claude Code อ่าน credentials ตั้งแต่แรก ร่วมกับการแยกเครือข่ายผ่าน container เพื่อจำกัดว่าข้อมูลจะไปที่ไหนได้บ้าง แต่ละชั้นเพียงอย่างเดียวไม่เพียงพอ ต้องใช้ร่วมกันจึงจะยกระดับความปลอดภัยได้จริง

ระบบ Hook: ชั้นควบคุมที่ละเอียดกว่าที่คิด

Hook คือชั้นส่วนขยาย (extensibility layer) ของระบบสิทธิ์ ที่ไม่ได้จำกัดอยู่แค่ 2 เหตุการณ์ที่นักพัฒนาส่วนใหญ่รู้จักกันทั่วไปเท่านั้น แต่ครอบคลุมทุกช่วงจังหวะสำคัญของวงจรการทำงานแบบ agentic

เหตุการณ์ hook ที่สำคัญ ได้แก่

• PreToolUse — เกิดขึ้นก่อนเครื่องมือใด ๆ ทำงาน สามารถบล็อก อนุญาตโดยอัตโนมัติ หรือส่งให้ผู้ใช้ตัดสินใจ รวมถึงแก้ไขข้อมูลนำเข้าก่อนทำงานได้ด้วย ถือเป็น hook หลักของทั้งระบบ
• PostToolUse — เกิดขึ้นหลังเครื่องมือทำงานสำเร็จ ไม่สามารถบล็อกได้แล้ว (เพราะทำงานไปแล้ว) แต่ให้ข้อมูลเพิ่มเติมกลับไปยัง Claude ได้ เช่นบันทึก log หรือรัน linter
• PostToolUseFailure — เกิดขึ้นเมื่อเครื่องมือทำงานล้มเหลว ใช้สำหรับรายงานข้อผิดพลาดหรือสั่งงานสำรอง
• PermissionRequest — เกิดขึ้นก่อนที่ระบบจะแสดงหน้าต่างขออนุญาตต่อผู้ใช้ hook นี้สามารถอนุมัติหรือปฏิเสธอัตโนมัติแทนการให้ผู้ใช้กดยืนยันเอง
• Notification — เกิดขึ้นเมื่อมีการแจ้งเตือนประเภทต่าง ๆ เช่น การขออนุญาต หรือการยืนยันตัวตน
• SubagentStart / SubagentStop — เกิดขึ้นเมื่อ subagent เริ่มทำงานหรือสิ้นสุด โดย SubagentStop สามารถบล็อกไม่ให้หยุดทำงานได้ เหมาะกับการตรวจสอบคุณภาพผลลัพธ์ก่อนยอมรับ
• TeammateIdle / TaskCompleted — ใช้ในระบบทีมเอเจนต์ เพื่อบังคับเงื่อนไขคุณภาพ เช่น ตรวจสอบว่าไฟล์ผลลัพธ์มีอยู่จริงก่อนให้ปิดงาน
• PreCompact — เกิดขึ้นก่อนการบีบอัดบริบทของบทสนทนา ใช้บันทึกสถานะสำคัญไว้ก่อน
• SessionEnd — เกิดขึ้นเมื่อจบเซสชัน เหมาะสำหรับงานทำความสะอาดหรือสรุปผล

สามรูปแบบของ Hook: Command, Prompt, และ Agent

Hook ไม่ได้มีแค่รูปแบบสคริปต์เชลล์เท่านั้น แต่แบ่งออกเป็น 3 ประเภทตามลักษณะการตรวจสอบ

Command hook เป็นรูปแบบพื้นฐาน ทำงานผ่านคำสั่งเชลล์ที่รับข้อมูล JSON ทางมาตรฐานเข้า (stdin) และส่งผลลัพธ์ผ่านทาง exit code เหมาะกับการตรวจสอบที่มีคำตอบตายตัว เช่น ตรวจสอบรูปแบบข้อความหรือการมีอยู่ของไฟล์ ทำงานเร็วและคาดเดาผลได้แน่นอน

Prompt hook ใช้โมเดลภาษาขนาดเล็กและเร็ว (ค่าเริ่มต้นคือ Haiku) ในการประเมินว่าควรอนุญาตหรือไม่ เหมาะสำหรับการตรวจสอบที่ต้องใช้วิจารณญาณมากกว่าการจับคู่รูปแบบตายตัว เช่น ตรวจสอบว่าการแก้โค้ดสอดคล้องกับหลักสถาปัตยกรรมของโปรเจกต์หรือไม่ หรือว่า Claude ควรหยุดทำงานแล้วหรือยัง

Agent hook คล้ายกับ prompt hook แต่มีความสามารถหลายรอบ (multi-turn) และเข้าถึงเครื่องมือได้ แทนที่จะเรียกโมเดลครั้งเดียว agent hook จะสั่งงาน subagent ที่สามารถอ่านไฟล์ ค้นหาโค้ด และตรวจสอบโปรเจกต์จริง ๆ ได้นานสูงสุด 50 รอบก่อนจะสรุปผล เหมาะกับกรณีที่ต้องตรวจสอบไฟล์จริงหรือผลการทดสอบ ไม่ใช่แค่ข้อมูลจาก hook เท่านั้น

ทั้งสามแบบมีรูปแบบผลลัพธ์คล้ายกัน คือคืนค่า {"ok": true} เพื่ออนุญาต หรือ {"ok": false, "reason": "..."} เพื่อบล็อกพร้อมเหตุผลที่จะถูกส่งกลับไปให้ Claude ใช้ปรับการทำงานต่อ

Hook แบบ Async: ไม่ต้องรอให้ทดสอบเสร็จก่อนทำงานต่อ

โดยปกติ hook จะทำให้ Claude ต้องรอจนกว่าจะทำงานเสร็จก่อนจึงจะไปต่อได้ ซึ่งสำหรับงานที่ใช้เวลานาน เช่น การรันชุดทดสอบหรือการ deploy การรอแบบนี้อาจทำให้เสียเวลามาก การตั้งค่า "async": true จะทำให้ hook นั้นทำงานในพื้นหลัง ส่งผลให้ Claude ทำงานต่อได้ทันทีโดยไม่ต้องรอ เมื่อกระบวนการเบื้องหลังเสร็จสิ้น ข้อความผลลัพธ์จะถูกส่งเข้าไปในบทสนทนาของ Claude ในรอบถัดไป

ตัวอย่างการใช้งานที่พบบ่อยคือ hook ประเภท PostToolUse ที่รันชุดทดสอบทุกครั้งที่มีการเขียนหรือแก้ไขไฟล์ โดยการทดสอบจะทำงานในพื้นหลังขณะที่ Claude ยังทำงานต่อไปเรื่อย ๆ หากพบว่าการทดสอบล้มเหลว ข้อความแจ้งเตือนจะปรากฏในบริบทของ Claude ในรอบถัดไป เพื่อให้ Claude แก้ไขปัญหานั้นต่อ

การตั้งค่าแต่ละระดับ กับความหมายในการทำงานเป็นทีม

แต่ละระดับการตั้งค่ามีคุณสมบัติที่ต่างกันและมีความหมายต่อการทำงานร่วมกันเป็นทีม

• User scope เป็นการตั้งค่าส่วนตัวที่ติดตัวไปทุกที่ เหมาะกับความชอบส่วนตัว เช่น โมเดลที่เลือกใช้เป็นค่าเริ่มต้น ไม่ถูกแชร์กับใคร
• Project scope ถูกแชร์ผ่าน version control เป็นการตั้งค่าที่ทั้งทีมตกลงร่วมกัน เช่น hook, สิทธิ์การใช้งาน, ปลั๊กอิน และตัวแปรสภาพแวดล้อมที่ทุกคนต้องใช้ การเปลี่ยนแปลงต้องผ่านการรีวิวโค้ดเหมือนไฟล์อื่น ๆ
• Local scope เป็นการปรับแต่งเฉพาะเครื่อง ไม่ถูกเก็บใน git เหมาะกับ path เฉพาะเครื่อง หรือคีย์ API สำหรับพัฒนาส่วนตัว
• Managed scope ควบคุมโดยฝ่าย IT มองไม่เห็นสำหรับนักพัฒนาส่วนใหญ่ บังคับใช้นโยบายองค์กร ไม่สามารถตรวจสอบหรือเขียนทับได้จากฝั่งผู้ใช้ นี่คือสาเหตุที่ทำให้บางครั้งเครื่องมือทำงานได้ในโปรเจกต์ส่วนตัว แต่ใช้ไม่ได้ในเครื่องที่ทำงาน

จุดที่น่าสนใจคือ เมื่อการตั้งค่าระดับ Project อนุญาตให้ใช้เครื่องมือหนึ่ง แต่นโยบายระดับ Managed ห้ามไว้ นโยบาย Managed จะชนะเสมอโดยไม่มีข้อความแจ้งเตือนใด ๆ เครื่องมือนั้นจะใช้ไม่ได้เฉย ๆ ดังนั้นหากพบว่าอะไรบางอย่างทำงานได้ในโปรเจกต์ส่วนตัวแต่ไม่ได้ในที่ทำงาน ควรตรวจสอบว่ามีการตั้งค่า Managed อยู่หรือไม่

MCP: เส้นทางที่ปลอดภัยกว่าสำหรับการเชื่อมต่อภายนอก

เมื่อ Claude Code ต้องเชื่อมต่อกับบริการภายนอก มีสองเส้นทางหลัก คือรันคำสั่งผ่าน bash โดยตรง หรือใช้ MCP server เส้นทางแบบ MCP ให้ความปลอดภัยที่ดีกว่า เพราะให้อินเทอร์เฟซเครื่องมือที่มีโครงสร้างชัดเจน ทุกการเรียกใช้งานจะผ่านระบบสิทธิ์ สามารถถูกดักจับด้วย hook ได้ และสร้าง log ที่มีโครงสร้างชัดเจน ในขณะที่คำสั่ง bash ที่รัน curl พร้อม credentials นั้นไม่มีความโปร่งใสแบบนี้เลย เพราะ credentials จะปรากฏอยู่ในคำสั่งดิบ ในบริบทของบทสนทนา และอาจถูกส่งไปยังผู้ให้บริการโมเดลด้วย

แนวทางที่ปลอดภัยคือการสร้าง MCP server สำหรับแหล่งข้อมูลที่ละเอียดอ่อน แทนที่จะให้ Claude Code เข้าถึงฐานข้อมูล production ผ่าน bash โดยตรง ควรให้เครื่องมือ MCP ที่ห่อหุ้มการเข้าถึงฐานข้อมูลด้วยการยืนยันตัวตน การบันทึก log และข้อจำกัดของคำสั่ง query ที่เหมาะสมแทน

เมื่อเครื่องมือเดียวกันใช้ได้ทั้งสองด้าน: โอกาสและความเสี่ยงด้านความปลอดภัย

เครื่องมือ agentic coding อย่าง Claude Code นั้นเป็นเทคโนโลยีที่ใช้ได้สองทาง (dual-use) ความสามารถเดียวกันที่ช่วยทีมความปลอดภัยตรวจสอบโค้ดและสร้าง patch แก้ไข ก็สามารถช่วยผู้ไม่หวังดีค้นหาช่องโหว่และสร้างโค้ดโจมตีได้เช่นกัน ความสามารถในการอ่านทั้งโปรเจกต์ เข้าใจโครงสร้าง และแก้ไขแบบเจาะจง มีประโยชน์เท่ากันทั้งฝ่ายป้องกันและฝ่ายโจมตี

ในด้านการป้องกัน ระบบ agentic กำลังทำให้ความรู้ด้านความปลอดภัยเข้าถึงได้ง่ายขึ้น วิศวกรที่ไม่มีพื้นฐานด้านความปลอดภัยก็สามารถใช้ Claude Code ตรวจสอบโค้ด ระบุรูปแบบช่องโหว่ทั่วไป และสร้างโค้ดที่แข็งแรงขึ้นได้ ในขณะที่ฝ่ายโจมตีก็สามารถขยายการโจมตีด้วยเครื่องมือแบบเดียวกันได้เช่นกัน แนวทางที่เหมาะสมสำหรับองค์กรจึงไม่ใช่การจำกัดการใช้ Claude Code เพราะจะเสียข้อได้เปรียบด้านการป้องกันไปโดยไม่ได้ช่วยลดการใช้งานฝั่งโจมตีเลย แต่คือการออกแบบระบบความปลอดภัยโดยตั้งสมมติฐานว่าฝ่ายตรงข้ามก็มีเครื่องมือที่ทรงพลังไม่แพ้กัน แล้วออกแบบการป้องกันให้รองรับสมมติฐานนั้น

ตัวอย่างแนวปฏิบัติจริงที่น่าสนใจคือ ทีมวิศวกรรมความปลอดภัยบางแห่งใช้วิธีคัดลอกแผนโครงสร้างพื้นฐาน (infrastructure-as-code) เข้าไปถาม Claude Code ว่า "การเปลี่ยนแปลงนี้จะทำอะไรบ้าง และเราจะเสียใจภายหลังหรือไม่" การเปลี่ยนแปลงที่ปกติต้องรอคิวให้ทีมความปลอดภัยตรวจสอบ สามารถได้รับการตรวจสอบเบื้องต้นภายในไม่กี่วินาที ทำให้เกิดวงจรตอบรับที่รวดเร็วขึ้นและลดการรอคอยของนักพัฒนา โดยไม่ได้แทนที่การตรวจสอบของทีมความปลอดภัยจริง แต่ทำให้การตรวจสอบเบื้องต้นเกิดขึ้นอย่างต่อเนื่องตั้งแต่ขั้นตอนการสร้างงาน

Paper Trading: เริ่มต้นในพื้นที่ปลอดภัยก่อนขยายขอบเขต

แนวคิด "paper trading" หรือการจำลองการทำงานจริงโดยไม่มีผลกระทบจริง สามารถนำมาใช้กับการเริ่มต้นใช้งาน Claude Code ได้โดยตรง ก่อนที่จะให้เอเจนต์เข้าถึงระบบ production ฐานข้อมูล production หรือ credentials จริง ควรสร้างขอบเขตที่เอเจนต์สามารถทำงานได้อย่างอิสระโดยไม่มีความเสี่ยงก่อน

แนวทางนี้หมายถึงการใช้สภาพแวดล้อมแบบแซนด์บ็อกซ์ที่มีข้อมูลจำลอง ระบบ staging ที่เลียนแบบโครงสร้าง production แต่ไม่มีข้อมูลจริงที่ละเอียดอ่อน หรือสภาพแวดล้อมพัฒนาในเครื่องที่จำลองบริการภายนอกไว้ เพื่อให้เอเจนต์สามารถทำงานอัตโนมัติ ทำผิดพลาด ค้นพบกรณีขอบ (edge case) และล้มเหลวได้โดยไม่มีผลกระทบจริง

แนวปฏิบัติที่สอดคล้องกันจากผู้ที่รันเอเจนต์แบบอัตโนมัติต่อเนื่องเป็นเวลานานคือ เริ่มต้นด้วย paper trading ตรวจสอบพฤติกรรมในสภาพแวดล้อมที่ปลอดภัยก่อน แล้วค่อย ๆ ขยายขอบเขตออกไป ระบบสิทธิ์ การแยกแซนด์บ็อกซ์ hook และการตั้งค่าระดับ Managed ทั้งหมดนี้รวมกันสร้างสเปกตรัมตั้งแต่ "Claude Code ทำอะไรไม่ได้เลยโดยไม่ถามก่อน" ไปจนถึง "Claude Code ทำได้ทุกอย่างภายในสภาพแวดล้อมที่แยกไว้แล้ว" ตำแหน่งที่เหมาะสมบนสเปกตรัมนี้ขึ้นอยู่กับบริบทการทำงาน ระดับความเสี่ยงที่ยอมรับได้ และปริมาณการตรวจสอบที่ได้ทำในสภาพแวดล้อมปลอดภัยมาก่อนแล้ว

สรุป: ความไว้วางใจไม่ใช่สวิตช์ปิดเปิด แต่คือสเปกตรัมที่ต้องออกแบบ

ระบบสิทธิ์ของ Claude Code ไม่ใช่แค่หน้าต่างยืนยันที่คอยกวนใจ แต่คือสถาปัตยกรรมหลายชั้นที่ทำงานร่วมกัน ตั้งแต่ลำดับชั้นการตั้งค่า 5 ระดับ กระบวนการประเมินสิทธิ์ 3 ขั้นตอน การแยกแซนด์บ็อกซ์ระดับปฏิบัติการ ระบบ hook ที่ครอบคลุมทุกจังหวะของการทำงาน ไปจนถึงระบบ checkpoint ที่มีทั้งจุดแข็งและช่องว่างที่ต้องรู้ทัน

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