Agentic AI Security: เมื่อ AI ลงมือทำเองได้ ต้องคุมอะไร

Agentic AI security (ความปลอดภัยของ AI ที่วางแผนและลงมือทำงานเองได้) คือการกำหนดว่า AI ประเภทนี้ทำอะไรได้บ้าง และตรวจสอบย้อนหลังได้ว่ามันทำอะไรไปแล้ว สิ่งที่ AI ทำเองได้ เช่น เรียกใช้เครื่องมือ แก้ไขข้อมูล ส่งข้อความ หรือใช้จ่ายเงิน OWASP Agentic Security Initiative ระบุว่า agent ต่างจากระบบอัตโนมัติที่ทำงานเฉพาะอย่าง เพราะ agent วางแผน ตัดสินใจ และลงมือทำต่อเนื่องหลายขั้นตอนข้ามหลายระบบ และมักทำในนามของผู้ใช้ คำถามจึงเปลี่ยนไป จากเดิมที่ถามว่า "คำตอบถูกไหม" เป็น "ถ้า agent ทำผิดพลาด หรือมีคนชักนำให้ทำผิด มันจะทำอะไรได้บ้าง"

เมื่อ AI ลงมือทำเอง อะไรเปลี่ยนไป

แชตบอทสร้างข้อความให้คนอ่าน แต่ agent ลงมือทำขั้นต่อไปเอง ปัญหาคือโมเดลแยกคำสั่งออกจากเนื้อหาที่อ่านเจอไม่ได้อย่างน่าเชื่อถือ OWASP จึงจัด Agent Goal Hijack (การแอบเปลี่ยนเป้าหมายของ agent) เป็นความเสี่ยงอันดับแรก (ASI01) ใน Top 10 for Agentic Applications 2026 คำสั่งที่ซ่อนอยู่ในเว็บ เอกสาร หรืออีเมล อาจทำให้ agent เปลี่ยนสิ่งที่กำลังทำอยู่ได้ แนวปฏิบัติร่วมที่ CISA, NSA และหน่วยงานพันธมิตรเผยแพร่เมื่อ 1 พฤษภาคม 2026 ชี้ว่า การที่ agent ทำงานเองได้และเชื่อมต่อกับหลายระบบ นำความเสี่ยงใหม่มาด้วย เช่น การยกระดับสิทธิ์ (privilege escalation) พฤติกรรมที่เกิดขึ้นเอง (emergent behavior) และช่องว่างด้านความรับผิดชอบ คือไม่ชัดว่าใครเป็นผู้รับผิดชอบการกระทำของ agent

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

กำหนดระดับความเป็นอิสระของแต่ละ agent

ระดับความเป็นอิสระของ agent เป็นเรื่องของการออกแบบ ไม่ใช่คุณสมบัติที่ติดมากับโมเดล งานวิจัยปี 2025 ของ Feng, McDonald และ Zhang เสนอการแบ่งเป็นห้าระดับตามบทบาทของผู้ใช้ ซึ่งใช้เป็นภาษากลางในการคุยกันได้จริง เริ่มจาก operator คือผู้ใช้สั่งทุกการกระทำ ถัดมาคือ collaborator (แบ่งงานกัน) และ consultant (agent นำ ผู้ใช้ให้คำแนะนำ) ส่วน approver คือ agent ทำงานเอง และถามผู้ใช้เฉพาะจุดที่เสี่ยงสูง ระดับสุดท้ายคือ observer ที่ agent ทำทุกอย่าง ผู้ใช้มีเพียง log และสวิตช์ฉุกเฉิน ข้อเสนอนี้ไม่ใช่มาตรฐาน แต่ช่วยให้เห็นชัดขึ้นว่าอิสระที่เพิ่มขึ้นต้องแลกกับการควบคุมที่ลดลง

แนวปฏิบัติร่วมของ CISA และพันธมิตรแนะนำว่า ไม่ควรให้ agent เข้าถึงข้อมูลหรือระบบอย่างกว้างหรือไม่จำกัด โดยเฉพาะข้อมูลอ่อนไหวและระบบสำคัญ OWASP เรียกแนวคิดเดียวกันนี้ว่า least agency (ให้ agent มีอิสระเท่าที่จำเป็น) กฎที่ใช้ได้จริงคือ กำหนดระดับความเป็นอิสระตามสิ่งที่แย่ที่สุดที่เครื่องมือของ agent ทำได้ ไม่ใช่ตามว่าโมเดลดูเก่งแค่ไหน งานค้นคว้าแบบอ่านอย่างเดียวปล่อยให้ทำงานโดยมีคนดูแลน้อยได้ แต่การย้ายเงิน ลบข้อมูล หรือส่งข้อความถึงคนนอกองค์กร ควรอยู่ที่ระดับ approver หรือต่ำกว่า (คือให้คนควบคุมมากขึ้น) และควรเพิ่มความเป็นอิสระก็ต่อเมื่อมีหลักฐานจาก log และการทดสอบเท่านั้น

สิทธิ์และตัวตน: ให้ agent น้อยเข้าไว้

• ตัวตนแยกสำหรับแต่ละ agent: OWASP ระบุว่า agent ที่ไม่มีตัวตนของตัวเองที่ควบคุมได้ จะทำงานโดยไม่มีใครระบุได้ว่าใครรับผิดชอบ จึงใช้หลักสิทธิ์เท่าที่จำเป็น (least privilege) ได้ไม่จริง ให้มอง agent เป็น non-human identity (ตัวตนที่ไม่ใช่คน เช่น service account) ดู Non-Human Identity และ Service Account
• ข้อมูลรับรองอายุสั้น (credential) ที่จำกัดตามงาน: OWASP แนะนำให้ออก token (ข้อมูลที่ใช้พิสูจน์สิทธิ์) แคบ ๆ ต่อหนึ่งงาน โดยผูกกับผู้ใช้ ทรัพยากร วัตถุประสงค์ และระยะเวลา แล้วกำหนดขอบเขตสิทธิ์ อัตราการเรียก และ egress allowlist (รายการปลายทางที่อนุญาตให้ส่งข้อมูลออกไปได้) แยกตามเครื่องมือ เช่น ให้อ่านฐานข้อมูลได้อย่างเดียว และตัวสรุปอีเมลต้องไม่มีสิทธิ์ส่งหรือลบ
• ตรวจสิทธิ์ ณ ขณะลงมือ: สิทธิ์ที่ตรวจตอนเริ่ม workflow อาจเปลี่ยนก่อนงานจบ ตัวอย่างจาก OWASP คือการสั่งซื้อที่ยังดำเนินต่อด้วยสิทธิ์เดิม ทั้งที่วงเงินของผู้ใช้ถูกลดไปแล้ว
• อย่าส่งสิทธิ์ทั้งหมดต่อให้ sub-agent: ถ้า manager agent (agent ที่คอยสั่งงาน) ส่งสิทธิ์ทั้งชุดของตัวเองให้ worker ที่ทำงานแคบ ๆ worker จะมีอำนาจมากเกินกว่าที่งานต้องใช้

การอนุมัติโดยคนที่ได้ผลจริง

OWASP เรียกร้องให้คนอนุมัติการกระทำที่มีผลกระทบสูง และประกาศของ CISA ก็เรียกร้องกลไกกำกับดูแลที่เข้มแข็ง แต่จุดอ่อนอยู่ที่ตัวคน รายการ Human-Agent Trust Exploitation (ASI09) ของ OWASP เตือนว่า คนมักเชื่อ agent ที่ดูมั่นใจมากเกินไป และ agent ที่ถูกแอบยึดการควบคุมสามารถแต่งเหตุผลที่ฟังดูน่าเชื่อ เพื่อให้คนอนุมัติการกระทำที่เสี่ยงได้

• อนุมัติที่การกระทำ ไม่ใช่คำอธิบาย: ให้แสดงการกระทำที่จะเกิดขึ้นจริง พร้อมค่าที่ส่งเข้าไป และผลข้างเคียงที่คาดไว้ โดยควรแสดงเป็น dry run (การจำลองรันโดยยังไม่เปลี่ยนแปลงจริง) หรือ diff (ส่วนที่จะเปลี่ยน) แทนการแสดงเหตุผลของ agent
• ขออนุมัติเฉพาะเรื่องสำคัญ: ได้แก่ ลบ โอน เผยแพร่ ส่งออกไปภายนอก และเปลี่ยนสิทธิ์ OWASP ระบุว่า ถ้าคนเคยอนุมัติเป็นชุดแล้วสำเร็จซ้ำ ๆ จนผ่อนการตรวจลง จะเป็นทางไปสู่ความล้มเหลวแบบลูกโซ่ (ASI08)
• ทำให้ preview ไม่มีผลข้างเคียง: OWASP ยกกรณี preview แบบ "อ่านอย่างเดียว" ที่พอเปิดแล้วไปเรียก webhook (การเรียกระบบอื่นโดยอัตโนมัติ) จึงควรบล็อกการเรียกเครือข่ายและการเปลี่ยนสถานะระหว่าง preview
• สรุปความเสี่ยงด้วยภาษาธรรมดา: แสดงสรุปความเสี่ยงสั้น ๆ แทนเหตุผลที่โมเดลสร้างขึ้น และทำให้ผู้ใช้แจ้งพฤติกรรมน่าสงสัยได้ง่าย

ระบบหลาย agent: ความไว้ใจระหว่าง agent

ในระบบหลาย agent ข้อความจาก agent ตัวอื่นดูเหมือนทราฟฟิกภายในที่น่าไว้ใจ OWASP ยกตัวอย่าง confused deputy (ผู้ที่ถูกหลอกให้ใช้อำนาจของตัวเองแทนผู้โจมตี) ซึ่งแสดงอันตรายนี้ได้ชัด อีเมลที่ถูกสร้างขึ้นมาหลอก ทำให้ agent คัดแยกอีเมลสั่ง agent การเงินให้ย้ายเงิน agent การเงินเชื่อว่าเป็นคำขอภายใน จึงจ่ายเงินโดยไม่ตรวจว่าผู้ใช้ต้นทางต้องการอย่างนั้นหรือไม่

• ให้ agent ยืนยันตัวตนซึ่งกันและกัน: ให้แต่ละ agent มี credential ของตัวเอง ยืนยันตัวตนทั้งสองฝ่าย (mutual authentication) ลงลายมือชื่อดิจิทัลในข้อความ และใช้ nonce (ค่าสุ่มที่ใช้ได้ครั้งเดียว) หรือ timestamp ป้องกัน replay (การนำข้อความเก่ามาส่งซ้ำ) (ASI07)
• อย่าสืบทอดอำนาจ: agent ผู้รับต้องตรวจเจตนาของผู้ใช้ต้นทางและนโยบายของตัวเอง ไม่ใช่ดูแค่ว่าผู้ส่งมีตำแหน่งสูง
• แยกการวางแผนออกจากการลงมือ: ให้ policy engine (ตัวตรวจนโยบาย) ที่เป็นอิสระตรวจทุกขั้นตอนที่มีผลสูง และตั้งโควตากับ circuit breaker (ตัวตัดวงจรอัตโนมัติเมื่อผิดปกติ) ไว้ระหว่าง planner (ตัววางแผน) กับ executor (ตัวลงมือ) เพื่อไม่ให้ความผิดพลาดจุดเดียวลามไปทั้งระบบ (ASI08)

หน่วยความจำและสถานะ

agent เก็บประวัติสนทนา บทสรุป embedding (ข้อมูลที่แปลงข้อความเป็นตัวเลขเพื่อใช้ค้นหา) และเอกสารที่ดึงมา รายการ Memory and Context Poisoning (ASI06) ของ OWASP อธิบายว่าข้อมูลที่ถูกแก้ไขให้ผิดจะค้างอยู่ข้าม session ได้ ตัวอย่างหนึ่งคือหน่วยความจำของผู้ช่วยที่ถูกฝังข้อมูลผ่าน indirect prompt injection (การซ่อนคำสั่งไว้ในเนื้อหาที่ agent ไปอ่านเจอ) ซึ่งกระทบทั้ง session ปัจจุบันและครั้งต่อ ๆ ไป อีกตัวอย่างคือรายการปลอมใน shared memory ที่ agent ตัวอื่นนำไปใช้ต่อ

• ตรวจก่อนเขียนลงหน่วยความจำ: สแกนรายการใหม่ก่อนบันทึก และอย่านำผลลัพธ์ของ agent เองกลับเข้าหน่วยความจำที่เชื่อถือได้โดยอัตโนมัติ
• แบ่งส่วนหน่วยความจำ: แยกตามผู้ใช้ session และโดเมน และล้างสถานะทิ้งระหว่างงานที่ต้องใช้สิทธิ์ต่างกัน
• ติดตามที่มาและเตรียมทางย้อนกลับ: บันทึกแหล่งที่มาของแต่ละรายการ ให้หน่วยความจำที่ยังไม่ได้ยืนยันหมดอายุเอง และเก็บ snapshot (ภาพสำเนา ณ เวลาหนึ่ง) ไว้ rollback (ย้อนกลับ) เมื่อหน่วยความจำถูกวางยา

การเฝ้าระวัง log และสวิตช์ตัดการทำงาน

กิจกรรมของ agent อาจดูถูกต้องตามปกติทุกอย่าง OWASP ยกสถานการณ์หนึ่งที่คำสั่งที่ถูกแทรกเข้ามาทำให้ agent เรียกเครื่องมือผู้ดูแลระบบที่เชื่อถือได้ต่อกันเป็นลูกโซ่ โดยใช้ credential ที่ถูกต้อง เครื่องมือบน endpoint (เครื่องผู้ใช้หรือเซิร์ฟเวอร์) จึงไม่เห็นมัลแวร์เลย ดังนั้น agent ต้องมี telemetry (ข้อมูลบันทึกพฤติกรรมการทำงาน) ของตัวเองด้วย

• บันทึกทุกเป้าหมาย การเรียกเครื่องมือ และข้อความระหว่าง agent: ใช้ log ที่ตรวจพบได้ถ้ามีการแก้ไข (tamper-evident) และผูกกับตัวตนของแต่ละ agent
• วางค่าพฤติกรรมพื้นฐานและเตือนเมื่อเบี่ยงเบน: ตั้งพฤติกรรมปกติไว้เป็นฐาน แล้วแจ้งเตือนเมื่อเกิดสิ่งเหล่านี้ เป้าหมายเปลี่ยนโดยไม่คาดคิด ลำดับการเรียกเครื่องมือผิดปกติ การข้ามขั้นตอนตรวจสอบ และการได้สิทธิ์เพิ่มผ่านการมอบหมายงานต่อ
• จำกัดค่าใช้จ่ายและอัตราการเรียก: กำหนดงบการใช้งานที่ชะลอการทำงานเองอัตโนมัติเมื่อใช้เกิน ช่วยหยุดการเรียกวนซ้ำและค่าใช้จ่ายที่บานปลาย
• สร้างสวิตช์ตัดการทำงานก่อนจะต้องใช้: เตรียม kill switch (ปุ่มหยุด agent ทันที) ที่เพิกถอน credential และกักกัน agent ได้ พร้อมระบุชื่อผู้ที่มีสิทธิ์ใช้

ควรทดสอบแบบปรับตามระบบ บทความเทคนิคของ NIST เมื่อมกราคม 2025 เรื่องการประเมิน agent hijacking (การยึดการควบคุม agent) รายงานว่า ในชุดทดสอบของ NIST การโจมตีที่ปรับให้เข้ากับระบบที่ทดสอบ ทำให้อัตราสำเร็จเพิ่มจาก 11% (ของการโจมตีพื้นฐานที่แรงที่สุด) เป็น 81% และการลองซ้ำหลายครั้งทำให้อัตราสำเร็จสูงขึ้นอีก ผลจากเกณฑ์วัดที่ทดสอบครั้งเดียวจึงไม่ใช่หลักฐานว่าปลอดภัย

เชื่อมเข้ากับการกำกับดูแล

NIST AI Risk Management Framework (กรอบบริหารความเสี่ยง AI ของ NIST) มีโครงสร้างง่าย ๆ สี่ส่วน คือ Govern, Map, Measure, Manage เมื่อใช้กับ agent Map คือการบันทึกวัตถุประสงค์ เครื่องมือ ข้อมูล และระดับความเป็นอิสระของ agent แต่ละตัว Measure คือ red teaming (การให้ทีมจำลองการโจมตี) และการทดสอบแบบปรับตามระบบ Manage คือการเฝ้าระวัง การตอบสนองต่อเหตุการณ์ และความสามารถในการปิด agent ส่วน Govern คือการมีเจ้าของที่ระบุชื่อได้ครบทุก agent ดูรายละเอียดของกรอบนี้ได้ใน NIST AI RMF คืออะไร มาตรฐานด้านนี้ยังอยู่ระหว่างก่อตัว CAISI ของ NIST เปิดตัว AI Agent Standards Initiative เมื่อกุมภาพันธ์ 2026 ซึ่งรวมงานด้านความปลอดภัยและตัวตนของ agent ด้วย ก่อนอ้างอิงจึงควรตรวจสถานะล่าสุดกับ NIST

ข้อควรระวัง

• ถือว่า system prompt คือมาตรการควบคุม: system prompt (คำสั่งตั้งต้นที่ให้โมเดล) ถูกเขียนทับได้ จึงควรบังคับข้อจำกัดที่เครื่องมือ ตัวตน และนโยบายที่อยู่นอกโมเดล
• ใช้ service account ร่วมกันทุก agent: ระบุไม่ได้ว่าใครเป็นผู้กระทำ และถ้า agent ตัวเดียวถูกเจาะ ทุกตัวก็เสียหายไปด้วย
• ขออนุมัติทุกเรื่อง: คนจะเลิกอ่านรายละเอียด และความเสี่ยงจริงจะหลุดผ่านไป
• เชื่อข้อความภายในระหว่าง agent: agent สิทธิ์ต่ำที่ถูกเจาะ ยืมอำนาจของ agent สิทธิ์สูงไปใช้ได้
• คิดว่าระบบเฝ้าระวังเดิมครอบคลุม agent แล้ว: เครื่องมือที่เชื่อถือได้ซึ่งใช้ credential ที่ถูกต้องไม่ดูเหมือนมัลแวร์ ระบบเดิมจึงไม่เห็น

ขั้นแรกที่ทำได้ทันที

• ทำบัญชี agent: รวมตัวที่ฝังอยู่ในผลิตภัณฑ์ SaaS และเครื่องมือนักพัฒนาด้วย และจดไว้ว่าแต่ละตัวเข้าถึงเครื่องมือและข้อมูลอะไรได้
• จัดระดับแต่ละตัวตามการกระทำที่แย่ที่สุดที่เครื่องมือทำได้ แล้วกำหนดระดับความเป็นอิสระให้สอดคล้องกัน
• เปลี่ยน credential ถาวร เป็น credential อายุสั้นที่จำกัดตามงานและผูกกับตัวตนของ agent แต่ละตัว
• ใส่ด่านอนุมัติ ไว้หน้าการกระทำที่ลบ ส่ง จ่าย เผยแพร่ และเปลี่ยนสิทธิ์
• รวม log ไว้ที่เดียวและระบุว่าใครหยุด agent ได้ จากนั้นลองทำ red team หนึ่งครั้ง โดยฝังคำสั่งไว้ในเอกสารหรืออีเมล แล้วดูว่า agent ทำอะไร

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

การจำลองโจมตี agent ด้วยคำสั่งหลอกที่ซ่อนในเอกสาร เป็นส่วนหนึ่งของ red teaming ที่อธิบายทั้งขั้นตอนและกติกาใน AI Red Teaming: ทดสอบความปลอดภัยของระบบ AI อย่างไร

เอเจนต์ AI ที่เรียกระบบผ่าน API เจอปัญหาเรื่องสิทธิ์แบบเดียวกัน ดู API Security และ OWASP API Top 10

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• OWASP Top 10 for Agentic Applications 2026: ความเสี่ยงสิบข้อ ASI01 ถึง ASI10 เผยแพร่ 9 ธันวาคม 2025 พร้อมแนวทางลดความเสี่ยงของแต่ละข้อ
• OWASP Agentic AI: Threats and Mitigations: เอกสารอ้างอิงแบบจำลองภัยคุกคาม (threat model) จาก Agentic Security Initiative เผยแพร่กุมภาพันธ์ 2025
• CISA: Careful Adoption of Agentic AI Services: แนวปฏิบัติที่ออกร่วมกับ ASD's ACSC, NSA และพันธมิตร เมื่อ 1 พฤษภาคม 2026
• NIST AI Risk Management Framework: กรอบแบบสมัครใจที่มีฟังก์ชัน Govern, Map, Measure, Manage
• NIST CAISI: AI Agent Standards Initiative: งานด้านความปลอดภัยและตัวตนของ agent ของ NIST
• NIST: Strengthening AI Agent Hijacking Evaluations: อธิบายว่าทำไมการประเมินควรปรับตามระบบและทำซ้ำ
• Levels of Autonomy for AI Agents (arXiv:2506.12469): ข้อเสนอห้าระดับความเป็นอิสระ เป็นงานวิจัย