ความปลอดภัยของ agent
Agent อ่านข้อความที่คนแปลกหน้าเขียน แล้วลงมือทำด้วยข้อมูลรับรองของคุณ หน้านี้อธิบายกฎสำคัญ รายการ OWASP ทั้งสองรายการประจำปี 2026 เหตุการณ์ที่เกิดขึ้นจนถึงตอนนี้ และมาตรการป้องกันที่ช่วยหยุดเหตุการณ์เหล่านั้นได้
สามองค์ประกอบอันตราย
- เข้าถึงข้อมูลส่วนตัวอีเมล repository ฐานข้อมูล ไฟล์ หรือข้อมูลอื่นใดที่อยู่หลังการยืนยันตัวตนของคุณ
- สัมผัสเนื้อหาที่ไม่น่าเชื่อถือหน้าเว็บ issue คำขอรับการสนับสนุน อีเมลขาเข้า และคำอธิบายเครื่องมือ: ข้อความใดก็ตามที่ผู้โจมตีเขียนได้
- สื่อสารกับภายนอกได้ส่งอีเมล เปิด pull request ดึง URL หรือแสดงภาพจากระยะไกล Simon Willison เรียกองค์ประกอบสามอย่างนี้รวมกันว่า lethal trifecta ในเดือนมิถุนายน 2025
หาก agent ตัวเดียวมีองค์ประกอบครบทั้งสาม ให้ถือว่า prompt injection อาจทำให้มันส่งข้อมูลของคุณให้ผู้โจมตีได้ อย่าหวังว่าโมเดลจะปฏิเสธ แต่ให้ตัดองค์ประกอบอย่างน้อยหนึ่งอย่างออกจาก agent และ session ทุกตัว
เช็กลิสต์ความปลอดภัย
รายการตรวจสอบ 22 ข้อ ครอบคลุมอินพุต เครื่องมือ runtime, MCP, CI และการปฏิบัติงาน ทำเครื่องหมายเมื่อดำเนินการเสร็จ แล้วส่งออกผลเป็นไฟล์ Markdown
บันทึกเหตุการณ์
สำหรับเหตุการณ์ด้านความปลอดภัยของ agent ที่เปิดเผยต่อสาธารณะทุกกรณีนับตั้งแต่เดือนเมษายน 2025: เกิดอะไรขึ้น เหตุใดการโจมตีจึงสำเร็จ และควรปรับเปลี่ยนการตั้งค่าของคุณอย่างไร
เหตุการณ์ล่าสุด
- ยึด session ใน MCP Python SDK และเข้าถึง task ข้าม session
- การอนุมัติ WebFetch อัตโนมัติใน Claude Code เปิดทางให้ส่งข้อมูลออกผ่าน huggingface.co
- Comment and Control: ข้อความใน PR ขโมย secret จาก CI agent
- MCP TypeScript SDK ส่ง response ข้าม client
- ClawHavoc: skill อันตรายหลายร้อยรายการบน ClawHub แพร่ AMOS
OWASP Top 10 สำหรับ Agentic Applications 2026
OWASP GenAI Security Project เผยแพร่รายการนี้เมื่อ 9 ธันวาคม 2568 โดยครอบคลุมความเสี่ยงที่เกิดขึ้นเมื่อโมเดลวางแผน จดจำข้อมูล เรียกใช้เครื่องมือ และทำงานร่วมกับ agent ตัวอื่น
ASI01การชักจูงให้ agent เปลี่ยนเป้าหมายผู้โจมตีเปลี่ยนเป้าหมายที่ agent กำลังทำ โดยมักซ่อนคำสั่งไว้ในเนื้อหาที่ agent อ่าน จากนั้น agent จะดำเนินการตามเป้าหมายของผู้โจมตีโดยใช้ tool และสิทธิ์ของผู้ใช้
ASI02การใช้ tool ในทางที่ผิดและการหาประโยชน์agent ใช้ tool ที่ถูกต้องในทางที่ก่อให้เกิดความเสียหาย เช่น ลบระเบียน ส่งข้อความ หรือเชื่อมการเรียกใช้หลายครั้งเข้าด้วยกัน เพราะถูกชักจูงหรือมีสิทธิ์ใช้ tool เกินกว่าที่งานต้องการ
ASI03การใช้ข้อมูลประจำตัวและสิทธิ์เกินขอบเขตagent ทำงานผ่านข้อมูลรับรอง token ที่ได้รับมอบหมาย และสิทธิ์ที่สืบทอดมา ผู้โจมตีอาศัยข้อมูลประจำตัวเหล่านี้หรือช่องโหว่ระหว่างข้อมูลเหล่านั้นเพื่อยกระดับสิทธิ์หรือปลอมเป็นผู้อื่น
ASI04ช่องโหว่ในห่วงโซ่อุปทานของ agenttool, MCP server, skill, plugin, model และ prompt ที่โหลดระหว่าง build หรือขณะทำงานอาจเป็นอันตรายหรือถูกเจาะระบบได้ เนื่องจาก agent โหลดสิ่งเหล่านี้แบบไดนามิกจำนวนมาก คอมโพเนนต์ที่เป็นอันตรายเพียงชิ้นเดียวจึงส่งผลถึงทุก session ที่ใช้งาน
ASI05การเรียกใช้โค้ดโดยไม่คาดคิด (RCE)agent ที่เขียนและรันโค้ด หรือส่งผลลัพธ์จากโมเดลให้ shell และ interpreter ทำงานต่อ อาจถูกชักจูงให้รันคำสั่งที่ผู้โจมตีเลือกบน host ได้
ASI06การปนเปื้อน memory และ contextผู้โจมตีแทรกข้อเท็จจริงหรือคำสั่งเท็จลงใน memory ของ agent เอกสารที่ดึงมาใช้ หรือ context ที่บันทึกไว้ สิ่งปนเปื้อนนี้จะคงอยู่และส่งผลต่อ session ในภายหลัง แม้ข้อมูลต้นทางจะหายไปแล้ว
ASI07การสื่อสารระหว่าง agent ที่ไม่ปลอดภัยข้อความระหว่าง agent ถูกส่งโดยไม่มีการยืนยันตัวตน การตรวจสอบความถูกต้องครบถ้วน หรือการตรวจสอบเนื้อหาที่เหมาะสม จึงอาจถูกปลอม ส่งซ้ำ หรือแก้ไขเพื่อหลอก agent ที่ได้รับข้อความ
ASI08ความล้มเหลวแบบลูกโซ่ข้อผิดพลาดเพียงจุดเดียว เช่น input ที่ถูกวางยาพิษ ผลลัพธ์จาก tool ที่ผิดพลาด หรือเอเจนต์ที่ถูกเจาะระบบ อาจแพร่กระจายผ่านเอเจนต์ที่เชื่อมต่อกันและขั้นตอนอัตโนมัติได้เร็วกว่าที่คนจะตรวจพบ
ASI09การใช้ประโยชน์จากความไว้วางใจระหว่างมนุษย์กับเอเจนต์เอเจนต์มักสื่อสารอย่างมั่นใจและดูพร้อมให้ความช่วยเหลือ ผู้คนจึงมักอนุมัติสิ่งที่เอเจนต์เสนอ ผู้โจมตีอาศัยความไว้วางใจนี้หลอกให้มนุษย์ยืนยันการกระทำที่เป็นอันตรายหรือเปิดเผยข้อมูล
ASI10เอเจนต์นอกการควบคุมเอเจนต์ที่ถูกเจาะระบบหรือเบี่ยงเบนจากพฤติกรรมที่ตั้งใจไว้จะยังคงทำงานด้วยตัวเอง โดยอยู่นอกขอบเขตและการกำกับดูแลที่กำหนดไว้
OWASP Top 10 สำหรับ LLM Applications 2026
ฉบับนี้เผยแพร่เมื่อ 4 สิงหาคม 2569 และมาแทนรายการปี 2025 Excessive Agency ขยับจากอันดับหกขึ้นมาเป็นอันดับสาม ส่วน System Prompt Leakage เปลี่ยนชื่อเป็น Hidden Context Exposure
LLM01Prompt InjectionInput ทำให้พฤติกรรมของโมเดลเปลี่ยนไปในแบบที่ผู้พัฒนาไม่ได้ตั้งใจ โดยอาจมาจากผู้ใช้โดยตรง หรือมาจากเอกสาร หน้าเว็บ และผลลัพธ์จาก tool ที่โมเดลอ่านโดยอ้อม
LLM02การเปิดเผยข้อมูลอ่อนไหวโมเดลหรือแอปพลิเคชันเปิดเผยข้อมูลส่วนบุคคล ข้อมูลรับรองความถูกต้อง ความลับทางธุรกิจ หรือข้อมูลลับอื่น ๆ ในผลลัพธ์ ซึ่งอาจมาจากข้อมูลฝึกสอน context หรือระบบที่เชื่อมต่ออยู่
LLM03การให้อำนาจเกินจำเป็นแอปพลิเคชันมอบฟังก์ชัน สิทธิ์ หรืออิสระในการทำงานให้โมเดลมากเกินกว่าที่งานต้องใช้ ทำให้ผลลัพธ์ที่ถูกชักจูงหรือผิดพลาดก่อความเสียหายจริงได้ อันดับเพิ่มจากอันดับที่หกในปี 2025 มาเป็นอันดับที่สามในปี 2026
LLM04ห่วงโซ่อุปทานโมเดล ชุดข้อมูล adapter แพ็กเกจ และปลั๊กอินจากบุคคลที่สามอาจถูกดัดแปลงหรือมีช่องโหว่ และนำความเสี่ยงเหล่านั้นมาสู่แอปพลิเคชันของคุณ
LLM05การวางยาพิษข้อมูลและโมเดลผู้โจมตีดัดแปลงข้อมูลสำหรับ pre-training, fine-tuning หรือ embedding เพื่อฝัง backdoor อคติ หรือพฤติกรรมที่ผิดพลาด ซึ่งจะปรากฏให้เห็นในภายหลังเมื่อใช้งานจริง
LLM06การใช้ทรัพยากรอย่างไร้ขีดจำกัดหากไม่มีการจำกัดจำนวนคำขอ ขนาด input หรือการประมวลผล ผู้โจมตีอาจทำให้ค่าใช้จ่ายพุ่งสูง ใช้ทรัพยากรจนหมด หรือคัดลอกโมเดลด้วยการส่งคำขอจำนวนมาก
LLM07ข้อมูลที่บิดเบือนโมเดลสร้างผลลัพธ์ที่เป็นเท็จหรือชวนให้เข้าใจผิด แต่ดูน่าเชื่อถือ จนผู้ใช้หรือระบบปลายทางนำไปใช้โดยไม่ตรวจสอบ
LLM08การเปิดเผย context ที่ซ่อนอยู่เดิมใช้ชื่อ System Prompt Leakage ผู้โจมตีอาจดึง system prompt คำสั่งที่ซ่อนอยู่ และบริบทอื่น ๆ ที่ผู้ใช้ไม่ควรเห็นออกมาได้ ทำให้กฎ ตรรกะ หรือข้อมูลลับที่ระบุไว้ในนั้นถูกเปิดเผย
LLM09จุดอ่อนของเวกเตอร์และ embeddingข้อบกพร่องในวิธีสร้าง จัดเก็บ และดึง embedding เปิดทางให้ผู้โจมตีแทรกเนื้อหา รั่วไหลข้อมูลข้าม tenant หรือกู้คืนข้อความต้นฉบับ โดยระบบ RAG ได้รับผลกระทบมากที่สุด
LLM10การจัดการผลลัพธ์ที่ไม่เหมาะสมผลลัพธ์จากโมเดลถูกส่งไปยังเบราว์เซอร์ shell ฐานข้อมูล หรือคอมโพเนนต์อื่นโดยไม่มีการตรวจสอบหรือเข้ารหัสอย่างเหมาะสม ทำให้เกิดช่องทางสู่ XSS, SQL injection, การเรียกใช้โค้ด และการขโมยข้อมูล
มาตรการป้องกัน
มาตรการป้องกัน 15 ข้อพร้อมลิงก์ไปยังแหล่งที่มา ควรใช้หลายมาตรการร่วมกัน เพราะไม่มีมาตรการใดป้องกันการโจมตีได้ทุกแบบด้วยตัวเอง
ตัดวงจรสามปัจจัยอันตราย
กฎของ Simon Willison: เอเจนต์ที่อ่านข้อมูลส่วนตัวได้ เห็นเนื้อหาที่ไม่น่าเชื่อถือ และส่งข้อมูลออกไปได้ อาจถูกใช้โจมตีคุณผ่านข้อความใดก็ตามที่มันอ่าน ให้ตัดอย่างน้อยหนึ่งในสามปัจจัยนี้ออกจากเอเจนต์หรือเซสชันแต่ละรายการ ตัวอย่างเช่น เอเจนต์ที่คัดแยก issue สาธารณะจะไม่ได้รับข้อมูลลับ ส่วนเอเจนต์ที่เข้าถึงข้อมูลลับจะไม่มีช่องทางส่งข้อมูลออก
จำกัดขอบเขตเอเจนต์หลังได้รับ input ที่ไม่น่าเชื่อถือ
งานวิจัยเกี่ยวกับรูปแบบการออกแบบเพื่อความปลอดภัยของเอเจนต์ชี้กฎหนึ่งข้อ: เมื่อเอเจนต์รับข้อมูลที่ไม่น่าเชื่อถือเข้ามาแล้ว ข้อมูลนั้นต้องไม่สามารถกระตุ้นการกระทำที่มีผลสำคัญได้ รูปแบบที่ใช้ได้แก่ action-selector, plan-then-execute, dual LLM และการลดบริบทให้เหลือเท่าที่จำเป็น เลือกใช้รูปแบบหนึ่งต่อเวิร์กโฟลว์ เช่น กำหนดแผนให้เสร็จก่อนที่เอเจนต์จะอ่านข้อมูลที่ไม่น่าเชื่อถือ
ติดตามการไหลของข้อมูลด้วย CaMeL
CaMeL แยกเอเจนต์ออกเป็นสองส่วน: planner ที่มีสิทธิ์สูงจะเขียนโค้ดจากคำขอของผู้ใช้ ส่วนโมเดลที่ถูกกักกันจะจัดการข้อมูลที่ไม่น่าเชื่อถือ ค่าจากฝั่งที่ถูกกักกันจะมีแท็ก capability กำกับ และระบบจะตรวจสอบแท็กเหล่านั้นตามนโยบายก่อนเรียกใช้ tool ใด ๆ ในบทความวิจัย ระบบนี้ทำงานได้ 77% ของงาน AgentDojo พร้อมความปลอดภัยที่พิสูจน์ได้ เทียบกับ 84% ของเอเจนต์ที่ไม่มีการป้องกัน
ใช้ข้อมูลรับรองสิทธิ์ขั้นต่ำ
กำหนดให้เอเจนต์มีสิทธิ์อ่านอย่างเดียวและจำกัดขอบเขตไว้ที่โปรเจกต์เป็นค่าเริ่มต้น อย่าใช้คีย์ admin หรือ service_role ซึ่งใน Supabase สามารถข้ามการรักษาความปลอดภัยระดับแถวได้ จำกัด token ของ CI และ repository ให้ใช้ได้เฉพาะกับงานเดียวที่ต้องทำ เหตุการณ์ Amazon Q Developer มีต้นตอมาจาก GitHub token ที่กำหนดขอบเขตกว้างเกินไปใน CodeBuild
กำหนดให้อนุมัติก่อนการกระทำที่มีผลสำคัญ
กำหนดให้มีคนยืนยันการเรียก tool ที่เขียน ลบ ส่ง หรือใช้จ่ายข้อมูล และปฏิเสธการทำงานหากไม่มีใครตอบ Supabase แนะนำให้อนุมัติการเรียก MCP tool ด้วยตนเอง ส่วนใน OpenClaw ให้ตั้ง tools.exec.ask เป็น always และคง askFallback ไว้ที่ deny แสดงอาร์กิวเมนต์ทั้งหมดเพื่อให้ผู้ตรวจสอบเห็นสิ่งที่จะทำงานจริง
รันโค้ดและ tool ใน sandbox
รันคำสั่ง shell และโค้ดที่สร้างขึ้นใน container หรือ VM ที่ไม่มีข้อมูลรับรองและมองเห็นเฉพาะ workspace เท่านั้น OpenClaw ปิด sandboxing ไว้เป็นค่าเริ่มต้น และตั้ง tools.exec.security เป็น full บนโฮสต์ gateway ดังนั้นให้เปิด sandboxing ตั้งค่า exec security เป็น deny หรือ allowlist ตั้ง fs.workspaceOnly เป็น true และปิดโหมด elevated ตรวจสอบผลด้วย openclaw sandbox explain
จำกัดการเชื่อมต่อเครือข่ายขาออก
ปฏิเสธทราฟฟิกขาออกจากเอเจนต์และ MCP server เป็นค่าเริ่มต้น แล้วอนุญาตเฉพาะโฮสต์ที่แต่ละตัวจำเป็นต้องใช้ อย่าอนุมัติการดึงข้อมูลจากโฮสต์แบบ multi-tenant ที่ใครก็เผยแพร่ข้อมูลได้โดยอัตโนมัติ เพราะนั่นคือช่องทางที่ทำให้ CVE-2026-54316 ใช้ huggingface.co เพื่อขโมยข้อมูลออกไปได้ เซิร์ฟเวอร์อีเมลควรเชื่อมต่อได้เฉพาะ mail API ของตัวเองเท่านั้น ดังที่แสดงให้เห็นใน postmark-mcp
อย่าเปิด control plane สู่อินเทอร์เน็ต
ผูก agent gateway, dashboard และ debug proxy ไว้กับ loopback และกำหนดให้ใช้ token ที่มีความยาวอย่างน้อย 24 characters เช่น สร้างด้วย openssl rand -hex 32 หากต้องเข้าถึงจากระยะไกล ให้ใช้ SSH tunnel หรือ Tailscale Serve และใช้ Tailscale Funnel เฉพาะเมื่อเปิดใช้ password auth ตั้งเวลาเรียก openclaw security audit --deep เป็นประจำ
ตรวจสอบ audience ของ MCP token
ข้อกำหนดการอนุญาตของ MCP กำหนดให้เซิร์ฟเวอร์ปฏิเสธ access token ที่ไม่ได้ออกให้เซิร์ฟเวอร์นั้น และห้ามส่งต่อ token ของ client ไปยัง upstream API โดยตรง client จะส่ง resource indicator ตาม RFC 8707 เพื่อผูกแต่ละ token กับเซิร์ฟเวอร์เดียว หากเซิร์ฟเวอร์ proxy ไม่มีความยินยอมจาก client แต่ละราย ก็จะกลายเป็น confused deputy
แยก session และ tenant ของ MCP
สร้าง server และ transport instance แยกกันสำหรับแต่ละ session แทนการใช้ instance เดียวร่วมกันระหว่าง client ผูกทุก session และ task เข้ากับ principal ที่ผ่านการยืนยันตัวตนและเป็นผู้สร้าง แล้วตรวจสอบการผูกนี้ในทุก request คำแนะนำด้านความปลอดภัยของ MCP SDK ทั้งสองรายการในปี 2026 มีสาเหตุมาจากการใช้ state ร่วมกันหรือไม่มีการผูก state
ตรวจสอบ skill, plugin และ MCP server
กำหนดเวอร์ชันที่แน่นอน อ่าน diff ก่อนอัปเดตทุกครั้ง และตรวจสอบผลจาก scanner เช่น VirusTotal รวมถึงสถานะการตรวจสอบความปลอดภัยของ ClawHub แฮชคำอธิบาย tool เมื่ออนุมัติเซิร์ฟเวอร์ และแจ้งเตือนเมื่อมีการเปลี่ยนแปลง เพื่อจับการเปลี่ยนแปลงแอบแฝง OpenClaw ไม่มีการบล็อกในตัวขณะติดตั้ง ดังนั้นให้ตั้ง security.installPolicy ด้วยตนเอง
ควบคุมผู้ที่ส่งข้อความถึงเอเจนต์
จำกัดการเข้าถึง DM ให้ใช้ pairing หรือ allowlist กำหนดให้เอเจนต์ต้องถูก mention ก่อนจึงจะทำงานในแชตกลุ่ม และตั้ง session.dmScope เป็น per-channel-peer เพื่อไม่ให้ผู้ส่งแชร์บริบทร่วมกัน ใครก็ตามที่ส่งข้อความถึงเอเจนต์ได้ก็อาจพยายามสั่งให้เอเจนต์ทำงาน ดังนั้นรายชื่อผู้ส่งจึงเป็นส่วนหนึ่งของ attack surface
เก็บ secrets ให้ห่างจาก CI run ที่ไม่น่าเชื่อถือ
อย่าเรียกใช้เอเจนต์ที่มี repository secret ใน workflow ที่บุคคลภายนอกกระตุ้นได้ผ่าน pull request, issue หรือ comment ให้ถือว่าชื่อเรื่อง คำอธิบาย และ comment จากเหตุการณ์เหล่านี้เป็นข้อมูลที่เป็นอันตราย หากขั้นตอนใดจำเป็นต้องใช้ secrets จริง ๆ ให้เรียกใช้หลังจาก maintainer อนุมัติ run แล้วเท่านั้น
ถือว่า output จากโมเดลไม่น่าเชื่อถือ
เข้ารหัสหรือทำความสะอาด output จากโมเดลก่อนแสดงผล และอย่าส่งต่อไปยัง shell, SQL query หรือ browser โดยไม่ตรวจสอบ ปิดกั้นการโหลด markdown image และลิงก์ไปยังโดเมนภายนอกโดยอัตโนมัติ พร้อมตั้งค่า Content Security Policy ให้เข้มงวด EchoLeak ใช้ URL ที่โหลดขึ้นมาเองเพื่อส่งข้อมูลออกไป
ตรวจสอบลายเซ็นของเอเจนต์ แล้วจึงกำหนดสิทธิ์
หากต้องการระบุตัวเอเจนต์ที่เรียกใช้เว็บไซต์หรือ API ของคุณ ให้ตรวจสอบลายเซ็น Web Bot Auth กับคีย์ที่ operator เผยแพร่ไว้ที่ /.well-known/http-message-signatures-directory ChatGPT agent ลงลายเซ็นด้วย Signature-Agent https://chatgpt.com ลายเซ็นที่ถูกต้องบอกได้ว่าใครเป็นผู้ให้บริการเอเจนต์ แต่ไม่ได้บอกว่าผู้ใช้คนใดเป็นผู้ส่งคำขอหรือผู้ใช้นั้นทำอะไรได้บ้าง ดังนั้นให้กำหนดสิทธิ์ของแต่ละ request แยกกัน
คำถามเกี่ยวกับความปลอดภัยของ agent
Prompt injection ใน AI agent คืออะไร
Prompt injection คือข้อความที่โมเดลตีความเป็นคำสั่ง ทั้งที่ได้รับมาในฐานะข้อมูล เช่น ในหน้าเว็บ อีเมล หรือคำอธิบาย tool สำหรับ agent คำสั่งเหล่านี้อาจทำให้เกิดการเรียกใช้ tool ด้วยข้อมูลรับรองของคุณ OWASP จัดให้เป็น LLM01:2026 ส่วน Agent Goal Hijack (ASI01) ครอบคลุมรูปแบบที่เกิดกับ agent
สามประสานอันตรายถึงชีวิตสำหรับ AI agent คืออะไร
เป็นคำที่ Simon Willison ใช้เรียก agent ที่มีทั้งสิทธิ์เข้าถึงข้อมูลส่วนตัว รับเนื้อหาที่ไม่น่าเชื่อถือ และมีช่องทางสื่อสารออกไปภายนอก เมื่อมีครบทั้งสามอย่าง prompt injection ก็อาจอ่านข้อมูลของคุณแล้วส่งออกไปได้ เหตุการณ์ token ของ Supabase MCP รั่วในปี 2025 เป็นกรณีตัวอย่างที่ชัดเจน
จะรักษาความปลอดภัยให้ MCP server ได้อย่างไร
ปฏิเสธ access token ที่ไม่ได้ออกให้กับ server ของคุณ และอย่าส่งต่อ token ของ client ไปยัง API ต้นทาง สร้าง server และ transport instance แยกสำหรับแต่ละ session และผูก session กับ task เข้ากับผู้ใช้ที่ผ่านการยืนยันตัวตนแล้ว ใช้ TypeScript SDK เวอร์ชัน 1.26.0 ขึ้นไป และ Python SDK เวอร์ชัน 1.27.2 ขึ้นไป ซึ่งแก้ปัญหาการรั่วไหลของ response ข้าม client และการยึด session
system prompt ที่ดีกว่าจะหยุด prompt injection ได้ไหม
อย่าพึ่งพาวิธีนี้ งานวิจัยเกี่ยวกับรูปแบบการออกแบบสำหรับ agent ชี้ว่า เมื่อ agent รับข้อมูลที่ไม่น่าเชื่อถือเข้ามาแล้ว ต้องจำกัด agent ไม่ให้ข้อมูลนั้นกระตุ้นการกระทำที่ส่งผลสำคัญได้ CaMeL ซึ่งบังคับใช้ข้อจำกัดนี้ด้วยการติดตาม capability ทำภารกิจ AgentDojo ได้ 77% พร้อมความปลอดภัยที่พิสูจน์ได้ เทียบกับ 84% สำหรับ agent ที่ไม่มีการป้องกัน
OWASP LLM Top 10 กับ Agentic Top 10 ต่างกันอย่างไร
OWASP Top 10 for LLM Applications ซึ่งฉบับปี 2026 เผยแพร่เมื่อ 4 August 2026 ครอบคลุมความเสี่ยงในแอปพลิเคชันทุกประเภทที่สร้างบน language model ส่วน OWASP Top 10 for Agentic Applications ซึ่งเผยแพร่เมื่อ 9 December 2025 ครอบคลุมความเสี่ยงที่เกิดขึ้นเมื่อโมเดลวางแผน ใช้ tool จดจำข้อมูล และสื่อสารกับ agent อื่น ผู้พัฒนา agent ส่วนใหญ่ควรศึกษาเอกสารทั้งสองชุด
การเปิด OpenClaw gateway สู่อินเทอร์เน็ตปลอดภัยไหม
ไม่ปลอดภัย ให้คง gateway.bind ไว้ที่ค่าเริ่มต้นคือ loopback และใช้ SSH tunnel หรือ Tailscale Serve เมื่อต้องการเข้าถึงจากระยะไกล OpenA2A พบ gateway ที่เปิดให้เข้าถึงได้ 192,492 แห่งเมื่อ 1 September 2026 และ CVE-2026-25253 แสดงให้เห็นว่าแม้แต่การติดตั้งที่ใช้ loopback เท่านั้นก็ยังต้องติดตั้งแพตช์โดยเร็ว