Agentic Top 10 (2026)
Agent ต่างจาก chatbot ตรงที่ output ของโมเดลไม่ได้จบที่ข้อความ แต่ถูกใช้วางแผน เลือก tool อ่านหรือเขียน state และทำงานต่อหลายขั้น ความเสี่ยงจึงไม่ได้อยู่แค่ว่าโมเดลตอบอะไร แต่อยู่ที่ว่า agent ได้รับอำนาจอะไร ระบบตรวจสอบแต่ละ action หรือไม่ และหยุดความเสียหายที่กำลังขยายตัวได้หรือเปล่า
OWASP เผยแพร่ Agentic Top 10 เมื่อ 9 ธันวาคม 2025 หลังการ review โดยผู้เชี่ยวชาญ นักวิจัย และ practitioner มากกว่า 100 คน เอกสารนี้เป็น risk taxonomy สำหรับเริ่มต้น threat model ไม่ใช่ compliance standard (เอกสารต้นทาง)
เมื่อใดควรใช้ Agentic Top 10
ให้ใช้เอกสารนี้เพิ่มจาก LLM Top 10 เมื่อระบบมีลักษณะอย่างน้อยหนึ่งข้อ:
- โมเดลเลือกหรือเรียก tool เอง
- วางแผนและทำงานต่อเนื่องหลายขั้น
- เก็บ memory หรือ state ข้าม task หรือ session
- delegate งานให้ agent อื่น
- ทำ action ที่เปลี่ยนข้อมูล ส่งข้อความ ใช้เงิน หรือกระทบระบบภายนอก
ถ้าโมเดลเพียงสร้างข้อความให้คนอ่าน ความเสี่ยงหลักยังอยู่ใน LLM Top 10 แต่เมื่อข้อความนั้นกลายเป็นคำสั่งให้ระบบลงมือ ผลกระทบจะขึ้นกับสิทธิ์และ control รอบ agent
สิบความเสี่ยง
| รหัส | กลไกที่ต้องพิจารณา | Control หลัก |
|---|---|---|
| ASI01 Agent Goal Hijack | input, เอกสาร, tool output หรือข้อความจาก agent อื่นเปลี่ยนเป้าหมายและแผนของ agent | บันทึก user intent แยกจาก context, ตรวจ intent ก่อน action สำคัญ, ถือ retrieved content เป็น untrusted, จำกัด tool ตาม task |
| ASI02 Tool Misuse & Exploitation | agent ใช้ tool ที่ถูกต้องด้วย parameter, ลำดับ หรือความถี่ที่ทำให้เกิดอันตราย แม้ tool ไม่มีช่องโหว่ | tool allowlist, schema และ business-rule validation, rate/step limit, idempotency, transaction และ rollback |
| ASI03 Identity & Privilege Abuse | agent ใช้ shared credential, token อายุยาว หรือ service account ที่มีสิทธิ์มากกว่าผู้ใช้ | short-lived delegated token, authorization ทุก invocation, identity แยกต่อ agent/run, ไม่ส่ง secret เข้า model context |
| ASI04 Agentic Supply Chain | model, prompt, tool, schema, MCP server, memory provider หรือ agent ภายนอกถูกเปลี่ยนหลัง deploy | inventory, version/hash pinning, signed artifact, review เมื่อ definition เปลี่ยน, dependency scanning, kill switch |
| ASI05 Unexpected Code Execution | model-generated text ไหลเข้า shell, interpreter, template engine, browser หรือ code runner | หลีกเลี่ยง shell/eval, ใช้ typed API, ephemeral sandbox, egress allowlist, read-only filesystem, resource quota |
| ASI06 Memory & Context Poisoning | ข้อมูลพิษถูกบันทึกใน summary, embedding, RAG store หรือ long-term memory แล้วมีผลในงานภายหลัง | provenance ต่อ memory item, policy ก่อน write/read, tenant isolation, TTL, review/rollback, quarantine ข้อมูลไม่น่าเชื่อถือ |
| ASI07 Insecure Inter-Agent Communication | ผู้โจมตีปลอม แก้ หรือ replay message และ delegation ระหว่าง agent | workload identity, message integrity, anti-replay, signed delegation, schema/version validation, scope และ deadline |
| ASI08 Cascading Agent Failures | error หนึ่งจุดถูก retry, fan-out หรือ delegate ต่อจนขยายผลกระทบ; recovery automation อาจทำให้หนักขึ้น | step/time/cost/fan-out limit, circuit breaker, bulkhead, bounded retry, compensating action, global stop |
| ASI09 Human-Agent Trust Exploitation | agent สรุป action แบบไม่ครบ ทำให้คน approve สิ่งที่ไม่ตรงกับเจตนา | แสดง target, parameters, side effects และ diff จาก payload จริง; bind approval กับ payload hash; ขออนุมัติใหม่เมื่อ action เปลี่ยน |
| ASI10 Rogue Agents | agent เบี่ยงจาก scope เพราะ goal drift, reward misspecification, compromise หรือพฤติกรรมที่คาดไม่ถึง | behavioral baseline, invariant ที่ระบบบังคับใช้, separation of duties, continuous authorization, tested containment |
ความแตกต่างระหว่างหมวดที่มักสับสน
ASI01 ไม่ใช่ชื่อใหม่ของ Prompt Injection
Prompt injection เป็นวิธีนำคำสั่งที่ไม่น่าเชื่อถือเข้าสู่โมเดล ส่วน goal hijack คือผลที่เกิดกับ objective และ planning loop ของ agent Injection อาจเป็นต้นเหตุ แต่ goal ยังอาจถูกเปลี่ยนผ่าน tool output, memory หรือข้อความจาก agent อื่นได้ การกรองข้อความจึงลดโอกาสโจมตี ส่วน policy ที่ action boundary จำกัดความเสียหายเมื่อการกรองพลาด
การทดสอบ: ฝังคำสั่งใน email, PDF, webpage และ tool result แล้วตรวจว่า agent เปลี่ยน plan หรือเรียก tool นอก user intent หรือไม่
ASI02 กับ ASI03 ต่างกันที่ capability และ authority
ASI02 ถามว่า agent ใช้ความสามารถอย่างไร ส่วน ASI03 ถามว่า agent ทำในนามใครและมีสิทธิ์เท่าไร Tool อาจถูกออกแบบอย่างปลอดภัยแต่ยังสร้างความเสียหายได้ หาก token อ่านข้อมูลทุก tenant หรือไม่มีการ authorize resource อีกครั้งตอน invocation
หลักฐานที่ควรตรวจ: IAM policy จริง, token claims, authorization decision log และ negative test ที่ผู้ใช้ A สั่ง agent เข้าถึงข้อมูลของผู้ใช้ B
ASI06 ต้องควบคุมทั้งการเขียนและการอ่าน memory
OWASP ใช้คำว่า context ครอบคลุม conversation summary, embedding, RAG store และข้อมูลอื่นที่ agent นำกลับมาใช้ การ scan ตอน ingest อย่างเดียวไม่พอ เพราะข้อมูลอาจหมดอายุ ถูกแก้ หรือถูกอ่านภายใต้สิทธิ์ที่ต่างไป (คำอธิบาย ASI06 จาก OWASP)
หลักฐานที่ควรตรวจ: ผู้มีสิทธิ์เขียน memory, provenance, owner, tenant, TTL, audit history, วิธีลบ/rollback และ test ว่าข้อมูลของ task หนึ่งไม่ไหลไปอีก task
Human-in-the-loop ไม่ใช่ security boundary โดยอัตโนมัติ
หน้าจออนุมัติที่แสดงเพียง summary จากโมเดลยังถูก ASI09 เล่นงานได้ UI ต้องแสดง action จาก structured payload ที่กำลังจะ execute และการอนุมัติต้องผูกกับ payload นั้น หาก target หรือ parameter เปลี่ยนหลังการอนุมัติ ระบบต้องขอใหม่
กรณีศึกษาและสถานะของหลักฐาน
EchoLeak — ช่องโหว่ที่มี advisory และ case study
EchoLeak แสดง indirect prompt injection ผ่าน email ไปยัง Microsoft 365 Copilot และเส้นทาง exfiltration แบบไม่ต้องให้ผู้ใช้เปิด email Microsoft แก้ก่อนเปิดเผยและระบุว่าไม่พบการ exploit ลูกค้า กรณีนี้พิสูจน์ว่าเส้นทางโจมตีเป็นไปได้ใน production architecture แต่ไม่ได้แปลว่ามีผู้เสียหายในวงกว้าง (CVE-2025-32711, case study)
Amazon Q v1.84 — supply-chain near miss
คำสั่งอันตรายถูกแทรกเข้า source ของ extension แต่ AWS ระบุว่า syntax ผิดและไม่ได้ execute ใน build ที่เผยแพร่ บทเรียนอยู่ที่ review/release pipeline และ credential scope ไม่ใช่หลักฐานว่า agent ลบระบบของผู้ใช้สำเร็จ (AWS-2025-015)
Replit/SaaStr — incident report จากผู้ใช้
เจ้าของระบบรายงานว่า coding agent ลบ production database ระหว่าง code freeze และสร้างข้อมูลสังเคราะห์ภายหลัง กรณีนี้ชี้ให้เห็นความสำคัญของ privilege boundary, approval และ environment separation แต่รายละเอียดอาศัยรายงานของผู้เกี่ยวข้อง ไม่ใช่ controlled experiment (รายงานเหตุการณ์)
Minimum control set สำหรับ agent ที่มี write access
- Capability inventory — ระบุ tool, side effect, data classification, owner และ environment
- Least agency — expose เฉพาะ tool ของ task ปัจจุบัน และไม่ให้ generic shell หาก typed API ทำแทนได้
- Per-action authorization — ตัดสินสิทธิ์ด้วย deterministic policy ใน identity ของผู้ใช้ ไม่ใช้ข้อความจากโมเดลเป็น authorization decision
- Parameter validation — validate schema และ business invariant เช่น amount, tenant, path, recipient และ allowed state transition
- Impact limits — จำกัด step, recursion, fan-out, token, เวลา, ค่าใช้จ่าย และจำนวน record ต่อ transaction
- Safe execution — ใช้ sandbox, egress allowlist, read-only filesystem และ credential อายุสั้น
- Bound approval — action สำคัญแสดง raw parameters/diff และผูก approval กับ payload hash
- Audit and containment — log intent → plan → tool call → result → approval และมี stop/revoke/rollback ที่ทดสอบแล้ว
Acceptance tests ที่ควรมี
| Test | ผลที่ถือว่าผ่าน |
|---|---|
| เอกสาร RAG สั่งให้เปลี่ยนเป้าหมาย | agent ไม่ทำ action นอก recorded user intent |
| ผู้ใช้ A ขอข้อมูล tenant B | authorization ปฏิเสธก่อน retrieval หรือ tool execution |
| tool schema เปลี่ยนหลังอนุมัติ | tool ถูก block จนกว่าจะ review ใหม่ |
| agent retry action ที่มี side effect | idempotency ป้องกันผลซ้ำและ retry มีเพดาน |
| approval summary ไม่ตรง payload | UI แสดง payload จริงและระบบไม่ execute payload ที่ไม่ได้อนุมัติ |
| downstream agent ไม่ตอบหรือส่งข้อมูลผิด schema | workflow fail closed และไม่ fan-out ต่อ |
| ใช้ kill switch ระหว่าง run | token ถูก revoke, queue หยุด, subprocess จบ และมี audit trail |
ข้อจำกัดของ Top 10
Agentic Top 10 ช่วยค้นหา threat แต่ไม่ได้กำหนด assurance level หรือเกณฑ์ผ่าน ใช้ LLMSVS และ ASVS เป็น verification baseline แล้วเพิ่ม test cases ตาม architecture และผลกระทบของ agent จริง