ช่องโหว่ด้านความปลอดภัยของ AI Agent: องค์กรกว่าครึ่งเคยประสบปัญหา แต่การควบคุมยังตามไม่ทัน
ภัยคุกคามทางไซเบอร์กำลังพัฒนาไปอย่างรวดเร็ว โดยเฉพาะอย่างยิ่งเมื่อเทคโนโลยีปัญญาประดิษฐ์ (AI) เข้ามามีบทบาทสำคัญในภาคธุรกิจมากขึ้น AI Agent หรือตัวแทน AI ที่มีความสามารถในการทำงานอัตโนมัติ ได้รับการอนุมัติให้เข้าถึงระบบและข้อมูลสำคัญขององค์กรมากขึ้นเรื่อยๆ แต่ในขณะเดียวกัน มาตรการรักษาความปลอดภัยที่ออกแบบมาเพื่อควบคุม AI Agent เหล่านี้กลับยังตามไม่ทัน
จากการสำรวจองค์กรกว่า 107 แห่ง พบว่า มากกว่าครึ่ง (54%) เคยประสบเหตุการณ์ด้านความปลอดภัยที่เกี่ยวข้องกับ AI Agent หรือเกิดเหตุการณ์เกือบจะเกิดอันตราย (near-miss) ซึ่งแสดงให้เห็นถึงช่องโหว่ด้านความปลอดภัยที่น่ากังวลอย่างยิ่ง
ช่องโหว่ที่น่าจับตามอง: AI Agent กับความเสี่ยงที่เพิ่มขึ้น
การสำรวจนี้ชี้ให้เห็นถึง "ช่องว่างความปลอดภัยของ AI Agent" (agent security gap) ซึ่งหมายถึงระยะห่างระหว่างระดับความเป็นอิสระที่องค์กรอนุญาตให้ AI Agent ทำงานได้ กับมาตรการควบคุมที่มีอยู่เพื่อจำกัดความเสียหาย
- อุบัติการณ์ด้านความปลอดภัยที่เกิดขึ้นจริง: 54% ขององค์กรที่ใช้ AI Agent ในการดำเนินงานจริง เคยประสบเหตุการณ์ด้านความปลอดภัยอย่างน้อยหนึ่งครั้ง โดย 18% เป็นเหตุการณ์ที่ยืนยันแล้วว่าเกิดความเสียหาย และอีก 36% เป็นเหตุการณ์ที่เกือบจะเกิดอันตรายแต่สามารถตรวจจับได้ก่อน
- การบริหารจัดการตัวตน (Identity) ที่ยังอ่อนแอ: มีเพียงประมาณหนึ่งในสาม (32%) ขององค์กรเท่านั้นที่ให้ AI Agent แต่ละตัวมีตัวตน (identity) และสิทธิ์การเข้าถึงที่จำกัด (scoped identity) เป็นของตนเอง ส่วนที่เหลือส่วนใหญ่ยังคงใช้การแชร์ข้อมูลประจำตัว (credentials) หรือใช้ API Keys, บัญชีผู้ใช้ของมนุษย์ หรือบัญชีบริการร่วมกัน ซึ่งเพิ่มความเสี่ยงอย่างมากหากมี Agent ตัวใดตัวหนึ่งถูกเจาะระบบหรือได้รับสิทธิ์มากเกินไป
- การแยกส่วน (Isolation) ที่น้อยเกินไป: มีเพียง 30% ขององค์กรเท่านั้นที่แยก AI Agent ที่มีความเสี่ยงสูงสุดไว้ในสภาพแวดล้อมที่ถูกจำกัด (sandbox) เพื่อจำกัดขอบเขตความเสียหายหากเกิดเหตุการณ์ขึ้น การขาดการแยกส่วนนี้ทำให้เมื่อเกิดปัญหาขึ้น ความเสียหายอาจลุกลามไปเป็นวงกว้างได้ง่าย
สาเหตุของช่องว่าง: การพึ่งพาเครื่องมือจากผู้ให้บริการหลัก
องค์กรส่วนใหญ่ยังคงพึ่งพาเครื่องมือรักษาความปลอดภัยที่มาพร้อมกับผู้ให้บริการ AI หรือคลาวด์เป็นหลัก เช่น ระบบป้องกันของ OpenAI (51%), ระบบควบคุมบนคลาวด์ของ Google และ Microsoft, หรือระบบจัดการ Agent ของ Anthropic
- เครื่องมือที่ยืมมาใช้: การรักษาความปลอดภัย AI Agent ส่วนใหญ่ยังคงใช้เครื่องมือที่มีอยู่เดิมที่ออกแบบมาสำหรับโมเดล AI หรือโครงสร้างพื้นฐานคลาวด์เป็นหลัก แทนที่จะเป็นเครื่องมือที่ออกแบบมาเพื่อจัดการกับความปลอดภัยของ Agent โดยเฉพาะ
- การลงทุนที่จำกัด: งบประมาณที่จัดสรรให้กับการรักษาความปลอดภัย AI Agent ยังคงเป็นสัดส่วนที่น้อยมากของงบประมาณด้านความปลอดภัยทั้งหมด
- ความพึงพอใจที่สวนทางกับความเสี่ยง: แม้ว่าองค์กรจะประสบปัญหาด้านความปลอดภัยบ่อยครั้ง แต่ความพึงพอใจโดยรวมต่อเครื่องมือรักษาความปลอดภัยที่ใช้อยู่กลับสูงถึง 4.2 จาก 5 คะแนน ซึ่งอาจสะท้อนถึงการขาดความเข้าใจในความเสี่ยงที่แท้จริง หรือการมองว่าเครื่องมือที่มีอยู่เพียงพอแล้ว
ความท้าทายในการรักษาความปลอดภัย AI Agent
- การบริหารจัดการตัวตนของ Agent: การให้ Agent แต่ละตัวมีตัวตนและสิทธิ์ที่จำกัดอย่างเหมาะสม ถือเป็นความท้าทายที่สำคัญที่สุดในการรักษาความปลอดภัย Agent ที่ไม่ใช่ของมนุษย์ (non-human identity)
- การขาดการแยกส่วน Agent ความเสี่ยงสูง: การที่ Agent ที่มีความเสี่ยงสูงไม่ถูกแยกออกจากระบบหลัก ทำให้เมื่อเกิดการโจมตีขึ้น ความเสียหายอาจขยายวงกว้างได้อย่างรวดเร็ว
- เทคโนโลยีที่ตามไม่ทัน: ความเร็วในการพัฒนาและความสามารถของ AI Agent นั้นก้าวไปเร็วกว่ามาตรการรักษาความปลอดภัยที่มีอยู่ ทำให้เกิดช่องว่างที่ผู้ไม่หวังดีสามารถใช้ประโยชน์ได้
สิ่งที่องค์กรควรพิจารณา
องค์กรที่นำ AI Agent มาใช้งานควรให้ความสำคัญกับการปรับปรุงมาตรการรักษาความปลอดภัยอย่างจริงจัง โดยพิจารณาถึง:
- การสร้างตัวตนที่ชัดเจนสำหรับ Agent ทุกตัว: การให้ Agent แต่ละตัวมี Identity และสิทธิ์การเข้าถึงที่จำกัด (least-privilege access) เป็นสิ่งสำคัญอันดับแรก
- การแยกส่วน Agent ที่มีความเสี่ยงสูง: การใช้ Sandbox หรือสภาพแวดล้อมที่ถูกจำกัด เพื่อจำกัดขอบเขตความเสียหายเมื่อเกิดเหตุการณ์
- การประเมินเครื่องมือรักษาความปลอดภัย: พิจารณาเครื่องมือที่ออกแบบมาเพื่อ Agent AI โดยเฉพาะ นอกเหนือจากเครื่องมือพื้นฐานที่ผู้ให้บริการมีให้
- **การลงทุน
ขอบคุณ แหล่งข้อมูล
https://venturebeat.com/ai/the-agent-security-gap-54-of-enterprises-have-already-had-an-ai-agent-incident-and-most-still-let-agents-share-credentials