สรุปสั้น
บริษัท Anthropic ได้เพิ่มเอนด์พอยต์ใหม่ในชุด Compliance API เพื่อให้ทีมความมั่นคงปลอดภัยมองเห็นกิจกรรมของ Claude Code ที่รันบนเครื่องของผู้พัฒนาได้ชัดเจนที่สุดเท่าที่เคยมีมา Claude Code เป็นเอเจนต์แบบ local ที่อ่านไฟล์ รันคำสั่งเชลล์ เรียกใช้เครื่องมือผ่าน MCP และลงมือทำงานผ่านข้อมูลรับรองที่มีอยู่บนเครื่องของผู้พัฒนา เอเจนต์ลักษณะนี้ไม่ใช่หมวดหมู่เฉพาะกลุ่มเล็ก ๆ อีกต่อไป เพราะมันรันบนเครื่องปลายทางและมักสืบทอดข้อมูลรับรอง ตำแหน่งในเครือข่าย และสิทธิ์ของพนักงานมาด้วย การที่ส่วนประมวลผล (โมเดล) ทำงานบนคลาวด์ของ Anthropic แต่ส่วนที่ลงมือจริง (harness) ทำงานบนเครื่องปลายทาง ทำให้การมองเห็นและการควบคุมต้องไปอยู่ที่ปลายทางนั้นด้วย
ก่อนหน้านี้ Compliance API ครอบคลุมกิจกรรมฝั่ง claude.ai และ Claude Desktop เป็นหลัก โดยครอบคลุม Claude Code น้อยมาก การเพิ่มเอนด์พอยต์สำหรับเซสชันบนเครื่องจึงช่วยให้องค์กรกำกับดูแลเอเจนต์ที่รันในเครื่องได้ดีขึ้น อย่างไรก็ตาม บทความต้นทางย้ำว่าลำพังบันทึกกิจกรรม (activity log) ไม่สามารถบอกได้ว่าการเข้าถึงของเอเจนต์นั้นชอบธรรมหรือไม่ การกำกับดูแลที่แท้จริงต้องเชื่อมโยงสัญญาณเหล่านั้นเข้ากับเจ้าของ วัตถุประสงค์ ตัวตน ข้อมูลรับรอง และสิทธิ์ของเอเจนต์ ซึ่งเป็นสิ่งที่ล็อกเพียงอย่างเดียวยังทำไม่ได้
รายละเอียดข่าว
เว็บไซต์ The Hacker News เผยแพร่บทความเมื่อวันที่ 31 สิงหาคม 2569 อธิบายแนวทางกำกับดูแล Claude Code หลังจาก Anthropic เพิ่มความสามารถด้านการมองเห็นเซสชันบนเครื่องปลายทาง บทความอธิบายว่า harness อย่าง Claude Code ไม่ใช่แชตบอต แต่เป็นตัวประสานงาน (orchestrator) ที่รับอินพุตจากผู้ใช้แล้วส่งไปยังโมเดลพร้อมบริบทของเซสชันทั้งหมด ตัวโมเดลเองไม่เก็บสถานะ (state) ฝั่งเซิร์ฟเวอร์ แต่รับทุกอย่างที่ต้องใช้จาก harness ในแต่ละรอบ ส่วนที่รันคำสั่งจริง ยืนยันตัวตนกับบุคคลที่สาม และเชื่อมต่อกับเซิร์ฟเวอร์ MCP คือ harness ไม่ใช่ตัวโมเดล เปรียบได้กับร่างกายมนุษย์ที่โมเดลเป็นสมองซึ่งประมวลผลและตัดสินใจ ส่วน harness คือมือ ขา และอวัยวะรับสัมผัสที่ลงมือทำจริงบนเครื่องปลายทาง
ประเด็นสำคัญคือ เนื่องจากการทำงานส่วนใหญ่ของ Claude Code เกิดขึ้นบนเครื่อง จึงไม่มีคอนโซลกลางไว้ตรวจสอบเอเจนต์บนเครื่องปลายทางข้ามการตั้งค่า ตัวตน สิทธิ์การเข้าถึง และรันไทม์ต่าง ๆ ก่อนเดือนสิงหาคม 2569 การควบคุมในตัวของ Anthropic มีมุมมองต่อสิ่งที่เอเจนต์เหล่านั้นทำอยู่จริงอย่างจำกัด จนทีมงานต้องพึ่งส่วนขยายภายนอกเพื่อให้ได้การกำกับดูแลขั้นต่ำ การเพิ่มเอนด์พอยต์บันทึกเซสชันบนเครื่องใน Compliance API จึงเป็นก้าวที่ช่วยลดช่องว่างนี้ลง
สามชั้นของการเก็บข้อมูลเพื่อกำกับดูแลเอเจนต์
บทความแบ่งการเก็บข้อมูลเพื่อกำกับดูแลเอเจนต์ AI บนเครื่องออกเป็นสามชั้น ชั้นแรกคือ managed settings ซึ่งเป็นกลไกบังคับใช้นโยบายของ Anthropic ทุกเครื่องที่ติดตั้ง Claude Code จะมีระเบียน managed-settings เป็นไฟล์ JSON บน Mac และ Linux และเป็นระเบียนใน registry บน Windows โดยกฎในนี้มีลำดับความสำคัญเหนือการตั้งค่าระดับ global, project และ user ทำให้บังคับใช้มาตรฐานพื้นฐานกับทุกเซสชันในองค์กรได้ กฎที่ตั้งได้ครอบคลุมทั้งรายการอนุญาต/ปฏิเสธเซิร์ฟเวอร์ MCP เฉพาะราย, regex คุมคำสั่ง bash และการปิดไม่ให้ skill รันคำสั่ง อย่างไรก็ตาม นโยบายแบบตายตัวเหล่านี้ไม่รับรู้บริบทหรือเจตนา และอาจลดพื้นที่การทำงานของผู้พัฒนาลงมาก
ชั้นที่สองคือ Compliance API เมื่อวันที่ 11 สิงหาคม 2569 Anthropic เปิดตัวเอนด์พอยต์ใหม่สำหรับเซสชันบนเครื่อง ได้แก่ GET /v1/compliance/apps/sessions/local (คืนรายการเมทาดาทาของเซสชัน), GET /v1/compliance/apps/sessions/local/{session_id} (เมทาดาทาของเซสชันเดียว) และ GET /v1/compliance/apps/sessions/local/{session_id}/messages (บทสนทนาเต็ม) ทุกสิ่งที่ถูกส่งไปยังโมเดลจะถูกบันทึกใน 3 ประเภทบล็อก คือ text, tool_use และ tool_result ซึ่งครอบคลุมทั้งคำสั่งของผู้ใช้ คำสั่ง bash การอ่าน/เขียนไฟล์ และแม้แต่คำสั่ง MCP เนื่องจากโมเดลไม่เก็บสถานะฝั่งเซิร์ฟเวอร์ และไฟล์ .md ของ skill กับ plugin อยู่แค่บนเครื่อง harness จึงต้องส่งบริบททั้งหมดให้โมเดลใหม่ทุกรอบ อะไรก็ตามที่ไปถึงโมเดลก็จะไปถึง Compliance API ด้วย เมื่อแปลบทสนทนาอย่างถูกวิธี ก็สามารถบันทึกการใช้เครื่องมือและสร้างบัญชีรายการเอเจนต์ได้ว่าแต่ละตัวมี skill ใด ใช้เซิร์ฟเวอร์ MCP ใด และมี plugin อะไรบ้าง
ชั้นที่สามคือสิ่งที่ เฉพาะการเก็บข้อมูลที่ปลายทาง (endpoint/EDR) เท่านั้นจะบอกได้ ทั้ง Compliance API และ OpenTelemetry จับได้เพียงสิ่งที่เอเจนต์ “ทำ” แต่มองไม่เห็นสิ่งที่อยู่บนดิสก์ เช่น ไฟล์คอนฟิก, skill/plugin ที่ติดตั้งไว้และไฟล์ .md ของมัน (ถ้ายังไม่ถูกใช้ในเซสชัน) หรือโปรเซสที่ถูกเรียกนอกเซสชัน การเก็บไฟล์คอนฟิก ดึงไฟล์ .md ของ skill/plugin และเทียบเคียงกับล็อก EDR จึงช่วยจับคำสั่ง bash เสี่ยง ๆ ที่มาจากเอเจนต์ได้
จุดที่ Compliance API มองไม่เห็น และข้อควรระวัง
บทความชี้ว่าบางการกระทำบนเครื่องไม่เคยไปถึงโมเดล Compliance API จึงมองไม่เห็น กรณีที่ชัดที่สุดคือ hooks ซึ่งทำงานบนเครื่อง ระหว่างที่โมเดลตัดสินใจกับตอนที่เครื่องมือทำงานจริง และสามารถบล็อกไม่ให้เครื่องมือรันหรือไม่ให้ส่งพรอมป์ได้ ในกรณีเหล่านี้ OpenTelemetry (OTel) ซึ่งเป็นมาตรฐานโอเพนซอร์สสำหรับ trace/metric/log และมีมาให้ใน harness ทั่วไปอยู่แล้ว จะบันทึกการตัดสินใจเรื่องสิทธิ์และผู้ที่ตัดสินใจ รวมถึงการเปลี่ยนสิทธิ์เข้าสู่โหมด bypassPermissions หรือ auto ที่จะปรากฏใน OTel แต่ไม่ปรากฏใน Compliance API
ยังมีขอบเขตที่ชัดเจนอีกข้อ คือหากรัน Claude Code บนโมเดลที่ไม่ใช่ของ Anthropic จะไม่ได้รับการครอบคลุมจาก Compliance API เลย เพราะมันบันทึกเฉพาะการโต้ตอบกับโมเดลของ Anthropic เท่านั้น เซสชันที่รันบน Bedrock, Foundry หรือ Google Cloud จึงไม่ถูกครอบคลุม นอกจากนี้บทความยังเตือนว่าบทสนทนาของเซสชันบนเครื่องอาจมีข้อมูลอ่อนไหว ทั้งข้อมูลส่วนบุคคล (PII) ความลับ (secrets) และข้อมูลลูกค้า อีกทั้ง Claude Code ยังเก็บประวัติเซสชันไว้บนเครื่องเป็นค่าเริ่มต้น 30 วันเพื่อให้ผู้ใช้กลับมาทำงานต่อได้เร็ว ซึ่งหมายความว่าผู้โจมตีที่เข้าถึงเครื่องได้ก็อ่านไฟล์เหล่านั้นได้เช่นกัน ที่เก็บบทสนทนาจึงกลายเป็นแหล่งข้อมูลอ่อนไหวในตัวเองที่ต้องปกป้องให้เหมาะสม
ผลกระทบ
การเพิ่มเอนด์พอยต์เซสชันบนเครื่องเป็นก้าวสำคัญสำหรับองค์กรที่ให้ผู้พัฒนาใช้เอเจนต์เขียนโค้ดอย่าง Claude Code เพราะช่วยให้ทีมความมั่นคงเห็นได้ว่าเอเจนต์ทำอะไรผ่านการโต้ตอบกับโมเดล อย่างไรก็ตาม บทความสรุปว่าแม้จะรวมทั้งสามชั้น (managed settings + บันทึกเซสชัน + การเก็บข้อมูลปลายทาง) เข้าด้วยกัน ก็ยังไม่เพียงพอ เพราะไม่มีชั้นใดจับบริบทขององค์กรและไม่ได้ผูกการเข้าถึงเข้ากับเจตนา ผู้ดูแลที่นั่งอ่านบทสนทนาย่อมแยกไม่ออกระหว่าง plugin อันตรายที่ดึงมาจากอินเทอร์เน็ตกับ plugin ที่วิศวกรภายในเขียนขึ้นเอง การอุดช่องว่างนี้ต้องอาศัยบริบทจากที่อื่นในองค์กร เช่น การเทียบเคียง skill และ plugin ที่รันบนเครื่องกับที่เก็บโค้ดภายในที่บริหารจริง เพื่อยืนยันความชอบธรรม จุดยืนของบทความคือ เทเลเมทรีบอกได้ว่าเกิดอะไรขึ้น แต่การกำกับดูแลต้องเชื่อมสัญญาณเหล่านั้นเข้ากับเจ้าของ วัตถุประสงค์ ตัวตน และสิทธิ์ของเอเจนต์ เพื่อกำหนดว่าการเข้าถึงนั้นสมเหตุสมผลหรือไม่ ปรับให้เหลือสิทธิ์เท่าที่จำเป็น และเพิกถอนเมื่อหมดหน้าที่
หมายเหตุ: บทความต้นทางเขียนโดยนักวิจัยด้านความปลอดภัยจากผู้จำหน่ายโซลูชันกำกับดูแลตัวตนของเอเจนต์ (Token Security) ข้อสรุปที่ว่า “สามชั้นยังไม่พอ ต้องใช้ identity governance” รวมถึงสถิติต่าง ๆ ที่อ้างในบทความ (เช่น สัดส่วนเอเจนต์แบบ local หรือสัดส่วนเซิร์ฟเวอร์ MCP จากชุมชน) เป็นข้อมูลและมุมมองของผู้จำหน่ายรายนั้น บทความนี้ตัดส่วนเชิญชวนใช้ผลิตภัณฑ์ออก และคงไว้เฉพาะสาระเชิงเทคนิคเกี่ยวกับความสามารถของ Claude Code และ Compliance API เท่านั้น
คำแนะนำ
องค์กรที่ให้ผู้พัฒนาใช้ Claude Code หรือเอเจนต์เขียนโค้ดลักษณะเดียวกันควรวางแผนกำกับดูแลแบบหลายชั้น เริ่มจากบังคับใช้ managed settings เป็นมาตรฐานพื้นฐาน (ผ่าน GUI สำหรับแผนองค์กร หรือเขียนระเบียนผ่าน MDM) กำหนดรายการอนุญาต/ปฏิเสธเซิร์ฟเวอร์ MCP และคุมคำสั่ง bash ที่เสี่ยง จากนั้นเก็บบันทึกเซสชันผ่าน Compliance API ควบคู่กับ OpenTelemetry เพื่อครอบคลุมส่วนที่ไม่ไปถึงโมเดล เช่น hooks และการเปลี่ยนสิทธิ์เข้าสู่โหมด bypass ควรตั้งนโยบายการใช้งานอย่างรับผิดชอบ เช่น ห้ามพิมพ์ความลับดิบ ๆ ลงในเซสชัน ติดป้ายโปรเจกต์/เซสชันที่มีข้อมูลลูกค้าหรือข้อมูลอ่อนไหว และลบตามกำหนดเวลา พร้อมปกป้องที่เก็บบทสนทนาบนเครื่อง (ค่าเริ่มต้นเก็บ 30 วัน) เสมือนแหล่งข้อมูลอ่อนไหว สุดท้าย พึงตระหนักว่าเซสชันที่รันบนโมเดลนอกระบบ Anthropic (Bedrock, Foundry, Google Cloud) จะไม่ถูกครอบคลุมโดย Compliance API และต้องหาแนวทางเก็บข้อมูลอื่นมาเสริม