เมื่อ AI ที่ยืนยันตัวตนแล้วกลายเป็นช่องโหว่ใหม่ขององค์กร

AI security วันนี้ ไม่ใช่แค่ป้องกันคน แต่ต้องป้องกันเครื่องที่มีสิทธิถูกต้อง

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

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

เมื่อ script kiddies ได้อาวุธระดับรัฐ และ gateway ไม่ได้ช่วยเท่าที่คิด

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

ยิ่งกว่านั้น ชั้นป้องกันที่องค์กรคิดว่าปลอดภัยที่สุดกลับกลายเป็นจุดบอด เช่น AI gateway ที่ถูกใช้เป็นด่านแรกของ agent จำนวนมาก พบว่ามีช่องโหว่ถึงเจ็ดรายการในเวลาเดือนเดียว และหนึ่งในนั้นคือบั๊ก LiteLLM ที่ผู้โจมตีใช้จริงจนต้องถูกเพิ่มเข้าไปในบัญชีช่องโหว่ที่ถูกใช้โจมตีแล้วของหน่วยงานรัฐด้านความปลอดภัย ช่องโหว่นี้อนุญาตให้รันคำสั่งบนโฮสต์ผ่าน gateway และเมื่อเชื่อมต่อกับบั๊กอีกตัวสามารถทำงานได้แม้ไม่มี credential ถ้ากลยุทธ์หลักขององค์กรคือ “ส่งทุกอย่างผ่าน gateway” ก็เท่ากับย้ายความเสี่ยงทั้งหมดไปกองไว้ที่จุดเดียว

ระบบ autonomous security ไม่ใช่เวทมนตร์ ถ้าไม่มี guardrails และตัวตนที่ชัดเจน

หลายองค์กรหลงเชื่อว่าระบบ autonomous security จะเป็นคำตอบทุกอย่าง เพราะสามารถวิเคราะห์ log วางแผนตอบสนอง และทำ action ได้เอง แต่ความจริงคือหากปล่อยให้ LLM คิดและลงมือโดยไม่มีขอบเขตและเครื่องมือเฉพาะทางในลูป ความเสี่ยงด้านความปลอดภัย AI จะยิ่งพุ่งสูง ระบบป้องกันอัตโนมัติสมัยใหม่ออกแบบให้ LLM เป็นแกนคิด แล้วเรียกใช้ฟังก์ชันหรือ API เช่น การสแกน การบล็อก IP หรือการแยกอุปกรณ์ออกจากเครือข่ายโดยตรง ถ้าออกแบบดี agent เหล่านี้ช่วยย่นเวลา incident response ลงอย่างมาก แต่เงื่อนไขสำคัญคือ LLM ต้องทำงานภายใน guardrails ที่ชัดเจน และผูกกับเครื่องมือด้านความปลอดภัยที่เชื่อถือได้ในทุกขั้น

ปัญหาคือ โมเดลความปลอดภัยแบบเดิมไม่เคยนับรวมพฤติกรรมของ AI ที่ทำงานใน production อย่างจริงจัง control plane จำนวนมากไม่รู้ด้วยซ้ำว่าตอนนี้ agent ตัวไหนกำลังทำงาน ใครเป็นผู้มอบหมาย งานนั้นคืออะไร และใช้ credential อะไร ทำให้บริบทที่ใช้ตัดสินใจอนุญาตหรือบล็อกไม่ครบ ผลคือ gateway อาจบล็อกการละเมิดนโยบายที่ชัดเจน แต่ไม่สามารถแยกแยะ action ที่ทางเทคนิค “ทำได้” กับ action ที่เชิงปฏิบัติการ “ไม่ควรทำ” เช่น agent การเงินไปแก้ข้อมูลในระบบผลิตเพราะเข้าใจบริบทผิด นี่คือ memory drift และการดัดแปลงข้อมูลในระดับที่ policy เดิมมองไม่เห็น

ตัวอย่าง Visa และบทเรียนเกี่ยวกับการปล่อยให้ AI แก้โค้ดเองใน production

กรณีของระบบ patch โค้ดอัตโนมัติที่ถูกปล่อยใช้งานเป็นโอเพนซอร์สโดยองค์กรการชำระเงินรายใหญ่ เป็นตัวอย่างชัดว่า autonomous security สามารถก้าวล้ำมากแค่ไหน ระบบนี้จะสแกนหาช่องโหว่ เขียน patch และตรวจสอบ patch ของตัวเองผ่าน panel เชิง adversarial ก่อนจะบันทึกลงไฟล์ต้นฉบับ โดยไม่มีขั้นตอนให้มนุษย์อนุมัติระหว่าง patch กับไฟล์ที่ถูกแก้ไขเลย กล่าวอีกแบบคือ default ของระบบคือการให้ AI มีสิทธิแก้โค้ด production โดยตรง

แน่นอนว่าผู้พัฒนามองว่านี่คือการย้าย bottleneck จากการค้นหาช่องโหว่มาเป็นการพิสูจน์ว่าได้แก้ไขแล้ว เพราะ AI หาช่องโหว่เร็วเกินกว่าที่มนุษย์จะตามทัน แต่ผู้เชี่ยวชาญด้าน AI security รายอื่นเสนอทางเลือกตรงกันข้าม คือให้ agent เสนอการเปลี่ยนแปลง เช่น DNS record ได้ แต่ต้องมี authorization gate ภายนอกที่ไม่ให้ agent อนุมัติการกระทำของตัวเอง ข้อถกเถียงนี้สะท้อนจุดอันตรายสำคัญ องค์กรที่ยอมให้ AI ลงมือแก้โค้ดและระบบผลิตโดยไม่มี gate ที่เหมาะสมกำลังเชิญความเสี่ยง memory poisoning attacks และการดัดแปลงข้อมูลด้วย credential ที่ถูกต้อง เข้าสู่ workflow ปกติของ DevSecOps

สิ่งที่องค์กรต้องทำใน 30 วัน ถ้าไม่อยากให้ AI agents กลายเป็นผู้โจมตีในบ้าน

คำถามไม่ใช่ว่าเราควรใช้ AI agents หรือไม่ แต่คือจะใช้แบบไม่พาตัวเองเข้าไปอยู่กลางสนามรบอย่างไร ในระยะสั้นที่สุด องค์กรต้องยอมรับว่าการเริ่มต้นด้วย gateway เป็นจุดผิดพลาด และหันมาออกแบบสายโซ่ control แบบอิงบริบทและตัวตนของ agent ก่อน ภายใน 30 วัน ควรเริ่มจากการสร้าง agent registry อย่างง่าย เลือก agent ใน production สักสิบตัว แล้วระบุให้ชัดเจนว่าเจ้าของคือใคร ใช้ทำอะไร เชื่อมต่อกับเครื่องมือใด และถือ credential แบบไหน เพียงขั้นตอนนี้ก็จะเริ่มเห็นปัญหา governance ที่ซ่อนอยู่

1. ปรับแนวคิดสู่ zero-trust สำหรับทั้งมนุษย์และ AI agents เน้นสิทธิเท่าที่จำเป็นต่อการทำงาน
2. ให้ความรู้และฝึกอบรมพนักงานเรื่องความเสี่ยงด้านความปลอดภัย AI และโฉมหน้าการโจมตีใหม่ที่ใช้ AI
3. ตรวจสอบและควบคุมการใช้ AI ภายในองค์กร ลด shadow AI ที่อาจทำให้ข้อมูลสำคัญหลุดออกไปนอกรั้วโดยไม่รู้ตัว
4. ออกแบบระบบ autonomous security โดยให้ LLM ทำงานภายใต้ guardrails ที่ชัดเจนและผูกกับเครื่องมือด้านความปลอดภัยเฉพาะทาง ไม่ใช่ปล่อยให้คิดเองทำเอง
5. เริ่มสร้าง agent registry และลำดับการวาง control ที่ให้ความสำคัญกับ identity และ attribution ก่อน gateway เสมอ

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