AI agent ได้ก้าวข้ามผ่านหน้าต่างแชทไปแล้ว ในปัจจุบันพวกมันสามารถจองการประชุม, อัปเดตข้อมูลลูกค้า, สอบถามฐานข้อมูลภายใน และสั่งการธุรกรรมทางการเงินได้ การเปลี่ยนผ่านจาก "ผู้ให้คำแนะนำ" (advisor) สู่ "ผู้ปฏิบัติการ" (operator) นี้ได้เปลี่ยนทุกอย่างเกี่ยวกับความเสี่ยง เมื่อซอฟต์แวร์หยุดแค่การแนะนำและเริ่มลงมือทำ ทุกๆ API endpoint จึงกลายเป็นประตูที่อาจถูกบุกรุกได้ โมเดลความปลอดภัยแบบดั้งเดิมถูกสร้างขึ้นบนพื้นฐานของพฤติกรรมมนุษย์ที่คาดเดาได้ เช่น คนล็อกอิน, คลิกผ่านเส้นทางที่คุ้นเคย และล็อกเอาต์ แต่เอเจนต์อัตโนมัติ (Autonomous agents) ไม่ได้ทำตามรูปแบบเหล่านั้น พวกมันทำงานแบบวนลูป, ลองใหม่ (retry) และแตกแขนงการทำงานผ่านการเรียกใช้งาน (calls) นับร้อยครั้งภายในไม่กี่วินาที เลเยอร์ของ API ซึ่งเดิมทีออกแบบมาเพื่อการร้องขอที่เริ่มต้นโดยมนุษย์ กำลังเผชิญกับแรงกดดันจากการทำงานอัตโนมัติอย่างต่อเนื่อง หากระบบป้องกันของคุณยังคงพึ่งพาเพียงกฎตายตัว (static rules) ที่เขียนขึ้นเมื่อไตรมาสที่แล้ว คุณกำลังเปิดประตูทิ้งไว้กว้างสำหรับข้อมูลรั่วไหลและการเข้าถึงโดยไม่ได้รับอนุญาต คุณต้องการการป้องกันแบบเรียลไทม์ที่สามารถประเมินทุกการเรียกใช้งานในขณะที่มันเกิดขึ้นจริง

จำกัดสิทธิ์ของเอเจนต์

ทางลัดที่อันตรายที่สุดเพียงอย่างเดียวในการปรับใช้เอเจนต์ คือการมอบ API key ที่ทรงพลังเพียงอันเดียวให้ใช้งาน การใช้คีย์เดียวที่เข้าถึงได้ทุกระบบหมายความว่า หากผู้โจมตีสามารถเจาะระบบเอเจนต์ผ่านพรอมต์ที่ถูกวางยา (poisoned prompt) หรือการแทรกแซงการเชื่อมต่อ (hijacked integration) พวกเขาจะได้รับสิทธิ์ในการเข้าถึงทุกอย่างในระบบทันที การกู้คืนระบบจะกลายเป็นฝันร้าย เพราะขอบเขตความเสียหาย (blast radius) จะครอบคลุมตั้งแต่บริการอีเมลไปจนถึงฐานข้อมูลหลัก (production database) ของคุณ

จงเลิกพฤติกรรมนั้นทันที เริ่มต้นด้วย OAuth 2.0 สำหรับการมอบอำนาจแบบมอบหมาย (delegated authorization) เอเจนต์ไม่ควรยืนยันตัวตนในฐานะ superuser ที่มีสิทธิ์ล้นฟ้า แต่ควรใช้โทเคน (token) ที่เป็นตัวแทนของทั้งตัวเอเจนต์เองและผู้ใช้ปลายทางที่มันให้บริการ เมื่อเซสชันของมนุษย์สิ้นสุดลง สิทธิ์การเข้าถึงของเอเจนต์ก็ควรจะสิ้นสุดลงตามไปด้วย

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

Context-Bound Scopes ช่วยเพิ่มความปลอดภัยอีกชั้นหนึ่ง โดยกำหนดให้โทเคนทุกอันเป็นแบบอ่านอย่างเดียว (read-only) เป็นค่าเริ่มต้น หากเอเจนต์จำเป็นต้องเขียนข้อมูล เช่น การดำเนินการคืนเงินหรือการอัปเดตสัญญา ให้ใช้ระบบการอนุมัติโดยมนุษย์ (human approval gate) อย่าปล่อยให้โมเดลตัดสินใจเพียงลำพังเมื่อมีการเคลื่อนย้ายเงิน, การเปลี่ยนแปลงบัญชี หรือการลบข้อมูล สิทธิ์การใช้งานควรสอดคล้องกับสถานการณ์ ณ ขณะนั้น ไม่ใช่สิทธิ์สูงสุดที่มีได้

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

ลองพิจารณาเอเจนต์ช่วยงานขายที่อ่านข้อมูลผู้มุ่งหวังจาก CRM และเขียนอีเมลติดตามผลผ่าน Mail API แทนที่จะใช้คีย์แอดมินที่ใช้งานได้ตลอดกาล เอเจนต์จะได้รับโทเคนที่มีอายุ 15 นาทีจาก Identity Provider ของคุณ โทเคนนี้จะอนุญาตให้อ่าน CRM และส่งอีเมลได้ แต่จะบล็อกการลบข้อมูลติดต่อและการเข้าถึงระบบเรียกเก็บเงิน หากเอเจนต์ได้รับคำสั่งที่น่าสงสัยให้ส่งออกฐานข้อมูลทั้งหมด ขอบเขต (scope) ที่จำกัดไว้จะช่วยป้องกันความพยายามนั้นได้ทันที

หยุดการโจมตีแบบ Indirect Prompt Injection

Prompt injection ไม่ใช่แค่ลูกเล่นสำหรับแชทบอทอีกต่อไป ในยุคของเอเจนต์ (agentic era) มันทำหน้าที่เหมือนการรันโค้ดจากระยะไกล (remote code execution) ที่ถูกส่งมาทางอีเมล

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

แนวป้องกันแรกของคุณคือการตรวจสอบข้อมูลขาเข้าอย่างเข้มงวด (strict input validation) ให้ถือว่าพารามิเตอร์ทุกตัวที่ AI สร้างขึ้นนั้นไม่น่าเชื่อถือจนกว่าจะได้รับการพิสูจน์ในทางตรงกันข้าม ให้ใช้การตรวจสอบ JSON-schema ที่ API gateway ของคุณ

ประการที่สอง ติดตั้งตัวกรองการรั่วไหลของข้อมูล (data exfiltration filters) ไว้ในเส้นทางการตอบกลับ (response path) การตอบกลับของ API ควรผ่านการตรวจสอบก่อนที่จะส่งถึง AI โดยสแกนหารูปแบบที่ตรงกับข้อมูลลับ (secrets), โทเคนยืนยันตัวตน (authentication tokens) หรือข้อมูลส่วนบุคคลจำนวนมาก หากการคิวรี CRM ส่งคืนข้อมูลหนึ่งหมื่นรายการแทนที่จะเป็นรายการเดียว ให้ทำการบล็อกทันที หากเพย์โหลด (payload) มี API key ภายใน ให้ทำการปกปิด (redact) ข้อมูลนั้น เอเจนต์ไม่จำเป็นต้องใช้ข้อมูลลับดิบในการทำงาน และช่องทางขาออกต้องไม่กลายเป็นเส้นทางลักลอบส่งข้อมูลที่ถูกขโมยออกไป

ประการที่สาม บังคับใช้การทำ Domain Whitelisting เอเจนต์จำเป็นต้องสื่อสารกับบริการปฏิทิน, ผู้ให้บริการชำระเงิน และระบบคลังสินค้าภายในของคุณ แต่มันไม่จำเป็นต้องสื่อสารกับเว็บไซต์แชร์ไฟล์ทั่วไป, บริการ pasteboard หรือปลายทางจัดเก็บข้อมูลบนคลาวด์ต่างประเทศ ให้จำกัดการทำ DNS resolution และการร้องขอ HTTP ขาออกไว้เฉพาะในรายการที่อนุญาต (allow-list) เท่านั้น แม้ว่าผู้โจมตีจะหลอกล่อให้เอเจนต์พยายามส่งข้อมูลไปยังที่อื่น เลเยอร์เครือข่ายก็จะปฏิเสธการเชื่อมต่อโดยอัตโนมัติ

สร้างสถาปัตยกรรมแบบ Zero-Trust

Zero-trust ไม่ใช่ผลิตภัณฑ์ที่คุณติดตั้ง แต่มันคือปรัชญาการออกแบบที่สร้างขึ้นบนสมมติฐานเดียวคือ: เอเจนต์ถูกเจาะระบบไปแล้ว จงดำเนินการตามนั้น

นั่นหมายถึงการแยกอัตลักษณ์ (identity) ออกจากกันอย่างชัดเจน ผู้ใช้ที่เป็นมนุษย์และเอเจนต์ไม่ใช่เอนทิตีเดียวกัน แม้ว่าเอเจนต์จะดำเนินการในนามของผู้ใช้ก็ตาม ควรแยกอัตลักษณ์ของบริการ (service identities) สำหรับตัวเอเจนต์เองให้แตกต่างจากเซสชัน SSO ของมนุษย์ บันทึกการตรวจสอบ (audit logs) ของคุณควรบันทึกทั้งสองอัตลักษณ์ไว้คู่กัน เมื่อมีบางอย่างผิดพลาด คุณ