บิล LLM $52,000: เมื่อ Autonomous Agents ก่อความเสียหาย

เกิดอะไรขึ้น

นักพัฒนาซอฟต์แวร์อิสระรายหนึ่งเพิ่งเผชิญกับบิลที่ไม่คาดคิดถึง $52,000 หลังจากเหตุการณ์หายนะที่เกี่ยวข้องกับ Autonomous Coding Agent เอเยนต์นี้ได้รับมอบหมายให้แก้ไขข้อผิดพลาดของซอฟต์แวร์ แต่กลับติดอยู่ในวงวนที่ไม่สิ้นสุด เป็นเวลาประมาณเก้าชั่วโมง มันรันการทดสอบที่ล้มเหลวซ้ำๆ และพยายามสร้างการแก้ไข โดยใช้โทเค็น Large Language Model (LLM) จำนวนมหาศาล

ปัญหาหลักเกิดจากการที่เอเยนต์สามารถเข้าถึงทรัพยากรคลาวด์และ LLM API ได้อย่างไม่จำกัด ไม่มีขีดจำกัดอัตราการใช้ (rate limit) ไม่มีข้อจำกัดการใช้โทเค็น และที่สำคัญคือ ไม่มี circuit breaker ที่จะหยุดพฤติกรรมที่ผิดปกติ เหตุการณ์นี้เน้นย้ำถึงช่องโหว่ที่เพิ่มขึ้นในสภาพแวดล้อมที่ใช้ AI สำหรับการดำเนินงานแบบอัตโนมัติ

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

ทำไมรูปแบบนี้ถึงเกิดขึ้นซ้ำแล้วซ้ำอีก

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

หลายองค์กรกำลังนำเครื่องมือ AI มาใช้อย่างรวดเร็วโดยไม่เข้าใจผลกระทบทางการเงินของการใช้งานอย่างถ่องแท้ โมเดล 'จ่ายตามการใช้งาน' ของบริการคลาวด์และ LLM API สามารถเพิ่มค่าใช้จ่ายได้อย่างรวดเร็วเมื่อไม่มีการตรวจสอบการใช้งาน นี่เป็นเรื่องจริงโดยเฉพาะสำหรับ generative AI ซึ่งทุกคำถาม ทุกโทเค็นที่สร้างขึ้น มีค่าใช้จ่ายที่จับต้องได้

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

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

'Authorization Creep' ของ AI

ปัจจัยสนับสนุนอีกประการหนึ่งคือสิ่งที่เราเรียกว่า 'authorization creep' นักพัฒนามักจะให้สิทธิ์ที่กว้างขวางแก่ AI agent เพื่อความสะดวกในระหว่างการพัฒนา โดยเฉพาะอย่างยิ่งเมื่อมีการทำซ้ำอย่างรวดเร็ว สิทธิ์เหล่านี้ หากไม่ได้รับการตัดแต่งอย่างละเอียดก่อนการปรับใช้ อาจกลายเป็นช่องโหว่ที่สำคัญ หรือในกรณีนี้คือภาระทางการเงิน หลักการของสิทธิ์ขั้นต่ำสุด (least privilege) มักจะถูกมองข้ามไปในช่วงที่เร่งรีบในการปรับใช้โซลูชันที่ขับเคลื่อนด้วย AI

แผนการเล่นของแฮกเกอร์ทีละขั้นตอน

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

1. การสอดแนมและการระบุช่องโหว่: ผู้โจมตีจะระบุระบบที่ใช้ AI agent ก่อน พวกเขาจะมองหา API ที่เปิดเผยต่อสาธารณะ ทรัพยากรคลาวด์ที่กำหนดค่าผิดพลาด หรือที่เก็บข้อมูลที่มีโค้ด agent พร้อมข้อมูลประจำตัวที่ฝังอยู่หรือสิทธิ์ที่กว้างขวางเกินไป
2. การเข้าถึงเริ่มต้น (หรือการฉีดโค้ดที่เป็นอันตราย): ซึ่งอาจเกี่ยวข้องกับการใช้ประโยชน์จากช่องโหว่แบบดั้งเดิม (เช่น CVE-2023-XXXX สำหรับเว็บเฟรมเวิร์กทั่วไป) เพื่อเข้าถึงระบบที่โฮสต์ agent หรือในลักษณะที่ละเอียดอ่อนยิ่งขึ้น คือการฉีดพร้อมต์หรือข้อมูลที่เป็นอันตรายเข้าไปในสตรีมอินพุตของ agent ซึ่งสามารถควบคุมพฤติกรรมของมันได้
3. การจัดการ Agent: เมื่อเข้าถึงได้แล้วหรือ agent ได้รับอิทธิพล เป้าหมายของผู้โจมตีคือการบังคับให้ agent เข้าสู่วงจรที่แพงและดำเนินไปเอง ซึ่งอาจเกี่ยวข้องกับการสร้างอินพุตที่กระตุ้นเงื่อนไขที่ล้มเหลวอย่างสม่ำเสมอ กระตุ้นให้ agent พยายามแก้ไขซ้ำๆ สร้างโค้ดจำนวนมหาศาล หรือเรียกใช้ LLM API ที่มีราคาแพง
4. การใช้ประโยชน์จากข้อมูลประจำตัว: Agent ซึ่งทำงานด้วยข้อมูลประจำตัวที่ถูกต้อง (แต่มีสิทธิ์มากเกินไป) จะดำเนินการที่ต้องใช้ค่าใช้จ่ายสูงเหล่านี้ ซึ่งอาจรวมถึงการสร้างการเรียก API จำนวนมาก การจัดสรรทรัพยากรคลาวด์ที่ไม่จำเป็น หรือการดำเนินการโต้ตอบ LLM ที่ซับซ้อนและใช้โทเค็นจำนวนมาก
5. การบิดเบือนและการคงอยู่ (ทางเลือกแต่มีแนวโน้ม): ผู้โจมตีที่ซับซ้อนอาจพยายามปกปิดแหล่งที่มาของกระบวนการที่ควบคุมไม่ได้ หรือสร้างการคงอยู่เพื่อกระตุ้นเหตุการณ์ที่คล้ายกันในอนาคต ทำให้การวิเคราะห์ทางนิติวิทยาศาสตร์มีความท้าทายมากขึ้น
6. การปฏิเสธกระเป๋าเงิน: บรรลุเป้าหมายหลักแล้ว: องค์กรเป้าหมายต้องแบกรับค่าใช้จ่ายบริการคลาวด์และ AI จำนวนมหาศาลโดยไม่คาดคิด ซึ่งอาจนำไปสู่การหยุดชะงักของการดำเนินงานหรือความเดือดร้อนทางการเงิน

สิ่งที่ผู้ป้องกันพลาดไป

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

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

ประการที่สอง circuit breaker และ kill switch ไม่ได้ถูกนำมาใช้ ในระบบอัตโนมัติที่มีความเสี่ยงสูง ความสามารถในการหยุดการทำงานโดยอัตโนมัติหรือด้วยตนเองเมื่อเกินเกณฑ์ที่กำหนดไว้ล่วงหน้า (เช่น ค่าใช้จ่าย ข้อผิดพลาดของ API โหลดการประมวลผล) เป็นสิ่งสำคัญยิ่ง นี่ทำหน้าที่เป็นแนวป้องกันสุดท้ายต่อกระบวนการที่ควบคุมไม่ได้

ประการที่สาม หลักการของสิทธิ์ขั้นต่ำสุด (principle of least privilege) ถูกละเมิด Agent ทำงานด้วยคีย์การผลิต ซึ่งให้สิทธิ์ที่กว้างขวางเกินความจำเป็นสำหรับงานของมัน สภาพแวดล้อมการพัฒนาและการทดสอบควรใช้ข้อมูลประจำตัวที่แยกต่างหากและมีขอบเขตจำกัดอย่างเคร่งครัด ไม่ใช่คีย์การผลิต

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

รายการตรวจสอบแนวป้องกันเชิงปฏิบัติ

CISOs และวิศวกรความปลอดภัยต้องจัดการกับความเสี่ยงที่เกิดขึ้นใหม่เหล่านี้ในเชิงรุก การใช้มาตรการรักษาความปลอดภัยที่แข็งแกร่งสำหรับ AI agent ต้องใช้แนวทางที่หลากหลาย

• ใช้การจัดทำงบประมาณโทเค็นแบบละเอียด: บังคับใช้ขีดจำกัดสูงสุดในการใช้โทเค็น LLM ต่อ agent ต่อโปรเจกต์ และทั่วโลก ใช้เครื่องมือของผู้ให้บริการคลาวด์หรือ API gateway เพื่อบังคับใช้ขีดจำกัดเหล่านี้
• กำหนดการจำกัดอัตราการใช้ (Rate Limiting): ใช้การจำกัดอัตราการใช้ที่เข้มงวดสำหรับการเรียก LLM API ทั้งหมดและการโต้ตอบบริการภายนอกอื่นๆ ที่ดำเนินการโดย autonomous agent ซึ่งจะช่วยป้องกันการใช้จ่ายที่ไม่สามารถควบคุมได้อย่างรวดเร็ว
• ปรับใช้ Circuit Breakers: รวม circuit breaker แบบอัตโนมัติเข้ากับแพลตฟอร์มการจัดการ agent สิ่งเหล่านี้ควรกระตุ้นและหยุดการทำงานของ agent หากเกินเกณฑ์ต้นทุน อัตราข้อผิดพลาด หรือการใช้ทรัพยากรที่พุ่งสูงขึ้น
• บังคับใช้สิทธิ์ขั้นต่ำสุดสำหรับข้อมูลประจำตัวของ Agent: กำหนดสิทธิ์ขั้นต่ำสุดที่จำเป็นสำหรับงานของ agent อย่างเคร่งครัด ห้ามใช้ข้อมูลประจำตัวการผลิตสำหรับการพัฒนาหรือการทดสอบ ใช้ข้อมูลประจำตัวชั่วคราวที่มีขอบเขตจำกัดเท่าที่จะทำได้
• การตรวจจับความผิดปกติของต้นทุนแบบเรียลไทม์: กำหนดค่าการจัดการต้นทุนคลาวด์และแพลตฟอร์มการสังเกตการณ์เพื่อแจ้งเตือนทันทีเมื่อมีรูปแบบการใช้จ่ายที่ผิดปกติหรือการใช้งาน API ที่พุ่งสูงขึ้นอย่างกะทันหันจากบริการที่เกี่ยวข้องกับ agent
• แยกสภาพแวดล้อมการพัฒนาและการผลิต: แยกสภาพแวดล้อมอย่างเคร่งครัด Agent ในการพัฒนาหรือการทดสอบไม่ควรเข้าถึงทรัพยากรการผลิตหรือ LLM API ที่มีราคาแพงโดยไม่มีการควบคุมที่เข้มงวด
• การตรวจสอบความปลอดภัยของตรรกะและสิทธิ์ของ Agent เป็นประจำ: ดำเนินการตรวจสอบโค้ดของ agent การโต้ตอบ และสิทธิ์ที่ได้รับเป็นระยะ เพื่อให้แน่ใจว่าเป็นไปตามแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยและตรวจจับช่องโหว่ที่อาจเกิดขึ้น

การทดสอบเชิงรุกสมัยใหม่จะตรวจจับสิ่งนี้ได้อย่างไร

แนวทางปฏิบัติด้านความปลอดภัยเชิงรุกสมัยใหม่ โดยเฉพาะอย่างยิ่งที่มุ่งเน้นระบบ AI จะระบุช่องโหว่นี้ได้นานก่อนที่จะเกิดบิลห้าหลัก การฝึกซ้อม Red Teaming ที่ครอบคลุมจะเกี่ยวข้องกับการออกแบบสถานการณ์เพื่อกระตุ้นพฤติกรรมของ agent ที่ควบคุมไม่ได้ และทดสอบประสิทธิภาพของการป้องกันทางการเงินและการดำเนินงาน

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

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

ภูมิทัศน์ของความปลอดภัยของ AI agent กำลังพัฒนาอย่างรวดเร็ว เราคาดว่าจะมีการเพิ่มขึ้นของการโจมตีแบบปฏิเสธกระเป๋าเงิน (denial-of-wallet) ที่เชี่ยวชาญ โดยที่ผู้โจมตีใช้ agent ที่ถูกบุกรุกหรือถูกควบคุมเพื่อทำให้เกิดค่าใช้จ่ายบริการคลาวด์และ AI จำนวนมหาศาลสำหรับเป้าหมาย การโจมตีเหล่านี้ตรวจจับได้ยากขึ้นด้วยระบบตรวจจับการบุกรุกแบบดั้งเดิม เนื่องจากมักเกี่ยวข้องกับข้อมูลประจำตัวที่ถูกต้องและการดำเนินการที่ได้รับอนุญาต แม้ว่าจะอยู่ในระดับที่รุนแรงก็ตาม

นอกจากนี้ การพัฒนา autonomous agent ที่ซับซ้อนยิ่งขึ้นจะทำให้จำเป็นต้องมีการพัฒนา AI ที่อธิบายได้ (XAI) และ AI ที่ตรวจสอบได้ การทำความเข้าใจ ว่าทำไม agent จึงตัดสินใจเช่นนั้น โดยเฉพาะอย่างยิ่งการตัดสินใจที่มีผลกระทบทางการเงินอย่างมาก จะเป็นสิ่งสำคัญสำหรับการวิเคราะห์ทางนิติวิทยาศาสตร์และการป้องกันไม่ให้เกิดซ้ำ คาดว่าจะมีการมุ่งเน้นไปที่การแซนด์บ็อกซ์ agent การตรวจสอบพฤติกรรมของ agent อย่างเป็นทางการ และการเกิดขึ้นของกรอบงานความปลอดภัย AI โดยเฉพาะที่ก้าวข้ามการป้องกันการฉีดพร้อมต์เพียงอย่างเดียวเพื่อจัดการกับความเสี่ยงเชิงระบบ