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

ความเสี่ยง AI Agent: จาก indirect prompt injection ถึง memory poisoning
หัวใจของความเสี่ยง AI Agent คือมันไม่ได้เชื่อฟังเฉพาะคำสั่งจากผู้ใช้ แต่ยังอ่านเว็บเพจ เอกสาร อีเมล API response หรือแม้แต่อีก Agent หนึ่ง แล้วเอาทุกอย่างไปปะปนใน context window โดยไม่มีทางแยกว่าอะไรคือคำสั่งจริง อะไรคือคำสั่งแฝงที่เป็นอันตราย นี่คือสิ่งที่เรียกว่า indirect prompt injection เมื่อผู้โจมตีไม่ต้องออกแรงเจาะระบบหรือขโมยรหัสผ่านอีกต่อไป เพียงปลูกข้อความที่ออกแบบมาในเอกสารหรือระบบที่ Agent จะอ่าน Agent ที่ถือ Credential อยู่แล้วในระบบด้านในจะเดินแทนผู้โจมตีอย่างว่าง่าย และทุกระบบจะปล่อยผ่านเพราะทุกอย่างดูถูกต้อง ยกเว้น “เจตนา” ที่ถูกบิด ตัวอย่างจริงมีแล้วเมื่อเอกสารหนึ่งไฟล์ที่ถูกวางยา ทำให้ Agent วิ่งค้นหาผ่านระบบที่เชื่อมต่ออยู่และส่งต่อ API key Credential และข้อมูลลูกค้าจาก CRM ให้ผู้โจมตีโดยที่มนุษย์เจ้าของสิทธิ์ไม่ต้องทำอะไรเลย นี่คือภาพของ memory poisoning และ data drift ที่รุนแรง เพราะ Agent มักเก็บประวัติการทำงาน สถานะระบบ หรือประวัติการสนทนา เพื่อปรับคำแนะนำในอนาคต หมายความว่าหากความทรงจำนั้นถูกปนเปื้อน ความผิดพลาดและการรั่วไหลจะกลายเป็นพฤติกรรมใหม่ที่ระบบมองว่าเป็นเรื่องปกติ และแทบไม่มีการเตือนจากระบบเดิม

ระบบตรวจสอบตัวตนแบบเดิมมองไม่เห็นว่าใครคือ Agent ใครคือคน
องค์กรส่วนใหญ่ลงทุนกับระบบตรวจสอบตัวตนและการควบคุมสิทธิ์มานาน แต่ระบบเหล่านี้ถูกออกแบบมาเพื่อถามคำถามเดียวว่า “Principal นี้มีสิทธิ์ทำสิ่งนี้หรือไม่” ไม่ได้ถูกสร้างมาเพื่อบอกต่อว่าคนที่เรียกใช้งานเป็นมนุษย์ บริการแบบเดิม หรือ AI Agent ที่ตัดสินใจเองภายใต้ Credential เดียวกัน ผลลัพธ์คือ support agent ที่ขับเคลื่อนด้วย language model กับวิศวกรที่รันคำสั่งเฉพาะกิจอาจใช้ role เดียวกันและดูเหมือนผู้ใช้เดียวในตารางฐานข้อมูล เมื่อทุกอย่างถูก “ยุบรวม” เป็นอัตลักษณ์เดียว เราไม่สามารถเขียนนโยบายแยกสำหรับ Agent ไม่สามารถตรวจสอบย้อนหลังว่าใครทำอะไร และไม่สามารถปิดสิทธิ์เฉพาะ Agent ตัวใดตัวหนึ่งได้ ความเสี่ยง AI Agent จึงไม่ได้อยู่ที่สิทธิ์สูงหรือต่ำ แต่อยู่ที่การขาดความสามารถในการแยกแยะและระบุตัวตน Agent อย่างเป็นอิสระ การจำกัด Agent ให้มีสิทธิ์ไม่เกินมนุษย์ที่มันรับงานจากอาจช่วยไม่ให้มันทำเกินคน แต่ถ้า Agent ยี่สิบตัวใช้สิทธิ์ของคนคนเดียว โดยไม่มี identity แยก บันทึกเหตุการณ์ และเส้นทางการเพิกถอน เราก็ยังตาบอดอยู่ดี คำกล่าวที่ควรจำคือ “เราไม่อาจป้องกันประชากรที่เราไม่รู้จำนวน ไม่อาจเขียนนโยบายให้กับผู้เรียกที่แยกไม่ออก และไม่อาจตรวจสอบฝูงงานที่ในจุดตัดสินใจดูไม่ต่างจาก workload ข้างๆ เลย”

ภัยคุกคาม Agentic AI กำลังทำให้การโจมตีไซเบอร์เป็นเรื่องของทุกคน
ยุค Agentic AI ทำให้แฮกเกอร์สามารถยกระดับการโจมตีไซเบอร์อย่างที่ระบบป้องกันตามไม่ทัน ภัยคุกคาม Agentic AI คือการที่ผู้ไม่ประสงค์ดีใช้ AI Agent เป็นเครื่องมือหลักในการสุ่มหาช่องโหว่และสร้างโค้ดโจมตี ทำให้ความเร็วและความถี่ของการโจมตีเพิ่มสูงขึ้นและรับมือยากขึ้นกว่าเดิม ตัวอย่างที่ชัดเจนคือ AgentFlayer ซึ่งเป็นชุด chain แบบ zero click ที่สามารถยึด AI assistant ขององค์กรโดยไม่ต้องมีการคลิกหรือการมีส่วนร่วมจากผู้ใช้ เมื่อผู้โจมตีใส่เอกสารที่ถูกวางยาเพียงหนึ่งไฟล์ Agent จะวิ่งค้นในระบบเชื่อมต่อและส่ง API key Credential และข้อมูลลูกค้ากลับมาโดยที่เจ้าของสิทธิ์ไม่รู้ตัว หนึ่งในคำกล่าวที่ควรใช้เตือนองค์กรคือ “การโจมตีนี้ไม่ใช่ภัยในอนาคต แต่มันถูกส่งมอบ แก้ไข และบันทึกลงฐานข้อมูลช่องโหว่แล้ว และกลุ่มช่องโหว่กำลังขยายตัวเร็วกว่าจำนวนแพตช์” ขณะเดียวกัน รายงานหนึ่งระบุว่าแคมเปญจารกรรมไซเบอร์ที่ขับเคลื่อนด้วย AI สามารถให้ระบบ AI ทำงานแทคติกได้ราว 80 ถึง 90 เปอร์เซ็นต์ ต่อองค์กรประมาณสามสิบแห่ง โดยมนุษย์เข้ามาตัดสินใจเพียงไม่กี่จุด นั่นหมายความว่าผู้โจมตีที่ทักษะต่ำกว่าเดิมสามารถใช้ Agent ที่อาศัย LLM เป็นอาวุธ ทำให้การโจมตีขั้นสูงกลายเป็นเรื่องที่ “ทุกคนทำได้”

วิธีปิดจุดบอด: ทำให้ระบบรู้ว่าใครคือ Agent และหยุดมันก่อนสาย
การรักษาความปลอดภัย AI ในองค์กรต้องเลิกพึ่งเกตเวย์เป็นด่านแรก เพราะชั้นนี้เองยังเต็มไปด้วยช่องโหว่ ตัวอย่างเช่นช่องโหว่ใน gateway ของ LiteLLM ที่ถูกเพิ่มเข้าไปในรายการช่องโหว่ที่ถูกโจมตีจริง และเปิดทางให้ผู้โจมตีรันคำสั่งบนโฮสต์ผ่าน gateway โดยไม่ต้องใช้ Credential เมื่อจับคู่กับช่องโหว่อีกตัวหนึ่ง หากเรายังไม่รู้ด้วยซ้ำว่า Agent ใดกำลังทำอะไร การไปบังคับใช้ที่เกตเวย์ก่อนจะมีข้อมูล identity และ attribution จึงเท่ากับบังคับใช้บนความมืด สิ่งที่องค์กรควรทำทันทีคือ 1 ค้นหา Agent ที่ไม่เคยได้รับอนุมัติ สมมติไว้ก่อนว่ามี แล้วติดธง workload ที่เรียกใช้โมเดลโดยไม่มีการลงทะเบียน เพื่อเปลี่ยนจากความเชื่อใจนักพัฒนาให้ทำตามนโยบาย มาเป็นการเห็นรายชื่อคนที่ไม่ทำ 2 ทำให้ provenance หรือแหล่งที่มาของ Agent เป็นข้อเท็จจริง ไม่ใช่การเดา โดยลงทะเบียน Agent ทุกตัว ผูก identity แยกให้แต่ละ Agent และทำให้ข้อมูลนี้ติดไปกับทราฟฟิกเสมอ เพื่อให้ระบบปลายทางสามารถตัดสินใจบนฐานของ “นี่คือ Agent ตัวไหน ใครมอบหมายงาน และกำลังทำภารกิจอะไร” ใน 30 วันแรก ควรเริ่มจาก Agent ที่อยู่ใน production จำนวนสักสิบตัว ระบุเจ้าของ วัตถุประสงค์ เครื่องมือที่อนุมัติ และ Credential ที่ใช้ ซึ่งจะกลายเป็นจุดตั้งต้นของ registry และกติกาการกำกับดูแล Agent ขององค์กร จากนั้นจึงค่อยวางการป้องกันแบบหลายชั้น เริ่มจากชั้นที่ Agent คิด ตรวจสอบเนื้อหาก่อนและหลังส่งให้โมเดลเพื่อดัก prompt injection และการรั่วข้อมูล ตามด้วยชั้นที่ Agent ลงมือทำ คือการกำหนดสิทธิ์ระดับเครื่องมือให้จำกัดเฉพาะความสามารถและขอบเขตที่จำเป็น แล้วจึงมาถึงชั้นเครือข่ายและทรัพยากร ที่ควบคุมว่าข้อมูลจะออกไปไหน และปลายทางใดจะยอมรับคำขอจาก Agent แบบใด ไม่ว่าตัว Agent จะโน้มน้าวตัวเองอย่างไร สุดท้าย การรักษาความปลอดภัย AI ต้องสร้าง “รั้ว” รอบ Agent ไม่ใช่แค่รอบเครือข่าย เราต้องยอมรับว่า AI Agent จะอยู่ในทุกระบบ สิ่งสำคัญไม่ใช่จะหยุดการใช้ Agent หรือไม่ แต่คือจะทำให้มันโปร่งใส ตรวจสอบได้ และถูกจำกัดโดยบริบทภารกิจ เวลา และทรัพยากรที่จำเป็นเท่านั้น






