Jake Williams นักวิจัยด้านความปลอดภัย ได้เปิดตัวเฟรมเวิร์ก CUSTODY ในสัปดาห์นี้ เพื่อช่วยให้องค์กรสามารถกำหนดสิทธิ์และขอบเขตการทำงานในขณะรันไทม์ (runtime permissions and boundaries) สำหรับ AI agent ที่ทำงานภายในเครือข่ายของบริษัทได้อย่างชัดเจน เครื่องมือนี้มีความสำคัญเพราะ AI agent ต่างจากซอฟต์แวร์ทั่วไปตรงที่สามารถดึงข้อมูล เรียกใช้บริการ และแก้ไขโมเดลได้แบบไดนามิก โดยที่ไม่มีนโยบายที่ชัดเจนและบังคับใช้ได้จริง ซึ่งกลายเป็นช่องโหว่ที่ผู้โจมตีเริ่มใช้ประโยชน์แล้ว

ทำไม AI agent จึงต้องการรั้วกั้น

ชุดเทคโนโลยี AI ขององค์กรในปัจจุบันประกอบด้วย แชทบอต (chat-bots), ระบบแนะนำ (recommendation engines), ระบบตัดสินใจอัตโนมัติ (autonomous decision-makers) และเอเจนต์เบื้องหลังอีกมากมายที่ดึงข้อมูลจาก API ภายในหรือบริการจากภายนอก แม้ว่าชุดเครื่องมือความปลอดภัยที่มีอยู่จะเน้นไปที่ไฟร์วอลล์ส่วนขอบ (perimeter firewalls), การป้องกันอุปกรณ์ปลายทาง (endpoint protection) และการแบ่งส่วนเครือข่าย (network segmentation) แต่เครื่องมือเหล่านี้ยังขาดวิธีการมาตรฐานในการกำหนดว่า “เอเจนต์นี้สามารถอ่านข้อมูลลูกค้าได้ แต่ห้ามเขียนข้อมูลลงในฐานข้อมูลการเงิน” การขาดการควบคุมในขณะรันไทม์เช่นนี้ได้นำไปสู่เหตุการณ์ที่เอเจนต์ที่ถูกเจาะระบบถูกนำไปใช้เพื่อดึงข้อมูลออก (exfiltrate data) หรือทำให้ค่าน้ำหนักของโมเดล (model weights) เสียหาย

CUSTODY เข้ามาเติมเต็มช่องโหว่นี้ได้อย่างไร

CUSTODY นำเสนอภาษาที่ใช้กฎเป็นฐาน (rule-based language) เพื่ออธิบายว่า AI agent ได้รับอนุญาตให้ทำอะไรได้บ้างเมื่อเชื่อมต่อกับเครือข่าย โดยนโยบายสามารถระบุได้ดังนี้:

  • การเข้าถึงทรัพยากร (Resource access) – ฐานข้อมูล, ที่เก็บไฟล์ หรือ API ใดบ้างที่เอเจนต์สามารถสอบถามข้อมูลได้
  • ข้อจำกัดในการดำเนินการ (Action limits) – เอเจนต์สามารถทำได้เพียงแค่อ่าน หรือสามารถเขียน, ลบ หรือสั่งการงานในขั้นตอนถัดไป (downstream jobs) ได้ด้วย
  • บริบทการทำงาน (Execution context) – ข้อจำกัดเกี่ยวกับสภาพแวดล้อมในการประมวลผล เช่น โควตา CPU หรือการแยกส่วนคอนเทนเนอร์ (container isolation)

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

การนำ CUSTODY ไปใช้ร่วมกับระบบเดิมที่มีอยู่

เฟรมเวิร์กนี้ทำงานควบคู่ไปกับเครื่องมือความปลอดภัยที่มีอยู่ในปัจจุบัน โดยสามารถเชื่อมต่อ (hook) เข้ากับแพลตฟอร์มการจัดการ (orchestration platforms), container runtimes และ API gateways ยอดนิยมได้ แต่ขั้นตอนที่แน่นอนจะแตกต่างกันไปตามแพลตฟอร์มของเอเจนต์ที่ใช้งาน องค์กรจำเป็นต้องจัดทำบัญชีรายการ AI (AI inventory), เขียนไฟล์นโยบายสำหรับเอเจนต์แต่ละประเภท และทดสอบชั้นการบังคับใช้ (enforcement layer) ก่อนการใช้งานจริง การขยายผลนโยบายเหล่านี้ไปยังเอเจนต์จำนวนมากจำเป็นต้องใช้ความพยายามในการดำเนินงานอย่างต่อเนื่อง เพื่อปรับปรุงกฎให้ทันสมัยอยู่เสมอเมื่อโมเดลมีการพัฒนาขึ้น

ข้อควรระวังและข้อโต้แย้ง

นักวิจารณ์ตั้งข้อสังเกตว่า CUSTODY ไม่ได้สร้างนโยบายโดยอัตโนมัติ ทีมความปลอดภัยต้องเป็นผู้กำหนดนโยบายด้วยตนเอง ซึ่งอาจต้องใช้แรงงานจำนวนมาก นอกจากนี้ยังมีความเสี่ยงเรื่องภาระด้านประสิทธิภาพ (performance overhead) หากมีการตรวจสอบทุกการเรียกใช้งานแบบเรียลไทม์ โดยเฉพาะอย่างยิ่งสำหรับบริการ inference ที่มีปริมาณงานสูง (high-throughput) และท้ายที่สุด ประสิทธิภาพของเฟรมเวิร์กนี้ขึ้นอยู่กับการยอมรับในวงกว้าง หากแพลตฟอร์ม AI ของผู้ให้บริการไม่สามารถเปิดช่องทาง (hooks) ที่จำเป็นได้ การควบคุมของ CUSTODY ก็อาจถูกข้ามผ่านไปได้

สิ่งที่ต้องจับตามองต่อไป

  • การตอบสนองของผู้ให้บริการ (Vendor response) – ผู้ให้บริการแพลตฟอร์ม AI รายใหญ่จะติดตั้ง hooks ที่รองรับ CUSTODY หรือจะนำเสนอเครื่องมือจัดการนโยบายในขณะรันไทม์ (runtime-policy engines) ของตนเองหรือไม่
  • การกำหนดมาตรฐาน (Standardisation) – ความเคลื่อนไหวใดๆ ที่มุ่งไปสู่การกำหนดข้อกำหนดมาตรฐานสำหรับสิทธิ์ของ AI agent ในระดับอุตสาหกรรม อาจทำให้ CUSTODY กลายเป็นมาตรฐานพื้นฐาน (de-facto baseline)
  • ความคิดเห็นจากชุมชน (Community feedback) – ผู้ใช้งานกลุ่มแรกจะช่วยเผยให้เห็นถึงความซับซ้อนของนโยบายในโลกความเป็นจริงและผลกระทบต่อประสิทธิภาพ ซึ่งจะช่วยกำหนดทิศทางของเวอร์ชันในอนาคต

องค์กรที่พึ่งพา AI agent ควรประเมิน CUSTODY ตั้งแต่ตอนนี้ โดยวางแผนว่าควรนำไปใช้ในส่วนใดของระบบความปลอดภัย และเริ่มทดลองใช้นโยบายก่อนที่คลื่นการโจมตีที่ขับเคลื่อนด้วย AI ระลอกถัดไปจะมาถึงเครือข่ายของพวกเขา