ปัญหาข้อมูลรั่วไหลจาก AI: Rovo vs Notion AI vs Slack AI vs ClickUp Brain

สรุปสั้น ๆ: ข้อมูลรั่วไหลผ่าน AI ในเครื่องมือทำงานมักเกิดขึ้นเมื่อผู้ช่วย AI อ่านข้อความที่เป็นอันตราย แล้วปฏิบัติตามคำสั่งที่แอบแฝงอยู่ จากนั้นจึงส่งข้อมูลส่วนตัวของคุณออกไปยังเซิร์ฟเวอร์ภายนอกผ่านการดึงข้อมูลจาก URL (URL fetch), การเรนเดอร์รูปภาพ หรือการคลิกลิงก์ งานวิจัยสาธารณะชี้ให้เห็นช่องโหว่นี้ใน Atlassian Rovo, Notion AI และ Slack AI โดย Notion และ Slack ได้ปล่อยแพตช์แก้ไขแล้ว ส่วนกรณีของ Rovo นั้น จนถึงวันที่ 27 ตุลาคม 2026 เรายังไม่พบการประกาศแก้ไขต่อสาธารณะแต่อย่างใด

AI สำหรับการจัดการโปรเจกต์ของคุณต้องอ่านข้อความที่คุณไม่ได้เป็นคนเขียนอยู่เสมอ ไม่ว่าจะเป็นทิกเก็ตแจ้งปัญหา (support tickets), ไฟล์ PDF ที่อัปโหลดเข้ามา, หน้าเอกสารจากตัวเชื่อมต่อภายนอก (connectors) หรือแม้แต่ในแชนเนลสาธารณะ ซึ่งคอนเทนต์เหล่านี้ล้วนสามารถแฝงคำสั่งอันตรายไว้ได้ทั้งสิ้น

บทความนี้จะเปรียบเทียบระหว่าง Rovo, Notion AI, Slack AI และ ClickUp Brain โดยทุกแถวในตารางจะอ้างอิงจากบทวิเคราะห์หลักหรือหน้าเว็บทางการของผู้ให้บริการพร้อมระบุวันที่ สำหรับจุดใดที่ไม่พบข้อมูล ตารางจะระบุว่า “ไม่พบรายงานสาธารณะ” กลไกเดียวกันนี้ยังเกิดขึ้นกับ coding agent ได้เช่นกัน ซึ่งเราจะอธิบายไว้ในช่วงท้าย

นิยามของการรั่วไหลของข้อมูลผ่าน AI ในหนึ่งประโยค

Indirect prompt injection คือคำสั่งที่ซ่อนอยู่ภายในเนื้อหาที่ผู้ช่วย AI นำไปประมวลผล ซึ่งทำให้ AI ปฏิบัติตามคำสั่งนั้นราวกับว่าคุณเป็นคนสั่งเอง

ปัญหานี้จะกลายเป็นการรั่วไหลของข้อมูล (data leak) เมื่อเกิดเงื่อนไข 3 ประการร่วมกัน ซึ่ง Simon Willison บัญญัติคำเรียกว่า lethal trifecta (สามองค์ประกอบมรณะ) เมื่อเดือนมิถุนายน 2025:

1. ผู้ช่วย AI สามารถเข้าถึงและอ่านข้อมูลส่วนตัวได้
2. ผู้ช่วย AI อ่านเนื้อหาที่บุคคลภายนอกสามารถแทรกแซงหรือกำหนดได้
3. ผู้ช่วย AI มีช่องทางในการส่งข้อมูลออกไปภายนอก

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

เบื้องหลังการลักลอบส่งข้อมูลออกภายนอกของ Atlassian Rovo

PromptArmor ได้เผยแพร่บทวิเคราะห์เกี่ยวกับ Rovo เมื่อวันที่ 5 สิงหาคม 2026 ซึ่งลำดับขั้นของการโจมตีนั้นสั้นมาก:

1. ผู้ใช้อัปโหลดไฟล์ โดยในการสาธิตคือไฟล์ “Backlog Guide” ที่มีคำสั่งแอบแฝงซ่อนอยู่ภายใน
2. ผู้ใช้สั่งให้ Rovo ช่วยจัดระเบียบทิกเก็ตใน Jira
3. Rovo ทำการค้นหาใน Jira และ Confluence จากนั้นจึงปฏิบัติตามคำสั่งที่แอบแฝงมา
4. Rovo แนบเนื้อหาจากทิกเก็ตและหน้าเอกสารต่อท้าย URL ของผู้โจมตี แล้วเปิด URL นั้นด้วยเครื่องมือดึงข้อมูล URL (URL-retrieval tool)
5. เซิร์ฟเวอร์ของผู้โจมตีจะบันทึกคำขอดังกล่าว ซึ่งมีข้อมูลส่วนตัวแนบไปด้วย ในขณะที่ผู้ใช้จะเห็นเพียงผลลัพธ์การทำงานตามปกติ

การทำงานทั้งหมดนี้ไม่มีขั้นตอนขออนุมัติจากผู้ใช้เลยแม้แต่น้อย การโจมตีนี้ยังคงได้ผลแม้จะปิดการค้นหาเว็บ (web search) แล้วก็ตาม เพราะการปิดการค้นหาไม่ได้ปิดการทำงานของเครื่องมือดึงข้อมูล URL นอกจากนี้ Rovo ยังเรนเดอร์รูปภาพแบบ Markdown ซึ่งเป็นอีกหนึ่งช่องทางในการส่งข้อมูลออก

ไทม์ไลน์การเปิดเผยช่องโหว่นี้ถือเป็นเรื่องสำคัญที่ผู้ซื้อควรพิจารณา PromptArmor รายงานปัญหานี้เมื่อวันที่ 23 พฤษภาคม 2026 ทาง Atlassian รับทราบเรื่องเมื่อวันที่ 25 พฤษภาคม แต่การติดตามผลในวันที่ 4 มิถุนายน และ 29 กรกฎาคม กลับไม่มีการตอบกลับ และบทความดังกล่าวก็ได้รับการเผยแพร่สู่สาธารณะเมื่อวันที่ 5 สิงหาคม โดยที่ Rovo ยังคงมีช่องโหว่นี้อยู่ กระทู้บน Hacker News ได้รับคะแนนโหวตถึง 306 คะแนน และมีความคิดเห็น 138 รายการ

อย่างไรก็ตาม มีอีกประเด็นหนึ่งของ Rovo ที่ได้รับการแก้ไขแล้ว โดยบันทึกงานวิจัยของ Cloud Security Alliance ประจำวันที่ 14 สิงหาคม 2026 ได้ระบุถึงช่องทาง “RovoBlast” แบบคลิกเดียวของ Varonis ผ่านพารามิเตอร์ URL ของการแช็ต ซึ่ง Atlassian ได้แก้ไขที่ฝั่งเซิร์ฟเวอร์ก่อนที่ Varonis จะเผยแพร่รายงาน บันทึกฉบับเดียวกันยังระบุด้วยว่าช่องทางการโจมตีผ่านเอกสารที่ PromptArmor รายงานนั้นยังไม่ได้รับการแก้ไข และจากการสืบค้นของเราเมื่อวันที่ 27 ตุลาคม 2026 ก็ยังไม่พบการประกาศแก้ไขเพิ่มเติมในภายหลัง

ข้อสังเกตเรื่องชื่อ: Rovo Dev เป็น coding agent ของ Atlassian ซึ่งเป็นผลิตภัณฑ์คนละตัวกับผู้ช่วย Rovo ในบทความนี้ และงานวิจัยข้างต้นไม่ได้ทำการทดสอบ Rovo Dev แต่อย่างใด

เปรียบเทียบ Rovo vs Notion AI vs Slack AI vs ClickUp Brain

ตารางนี้เปรียบเทียบพฤติกรรมและการทำงานของผู้ช่วยแต่ละตัวตามที่ปรากฏในผลการทดสอบหรือเอกสารทางการ โดยคำว่า “ไม่ได้ระบุไว้” หมายถึงแหล่งข้อมูลที่เราอ้างอิงไม่ได้กล่าวถึงประเด็นในแถวนั้น

เราไม่ได้นำ Linear และ Asana เข้ามาเปรียบเทียบ เนื่องจากการสืบค้นของเราเมื่อวันที่ 27 ตุลาคม 2026 ไม่พบรายงานสาธารณะเกี่ยวกับการลักลอบส่งข้อมูลออกผ่าน prompt injection สำหรับผู้ช่วยของทั้งสองราย ทั้งนี้ การไม่มีรายงานไม่ได้แปลว่าระบบปลอดภัยร้อยเปอร์เซ็นต์เสมอไป

Notion AI: บันทึกการแก้ไขก่อนที่คุณจะได้อนุมัติ

กรณีของ Notion AI ที่ PromptArmor พบนั้น เกิดจากการซ่อนข้อความสีขาวขนาด 1 พอยต์ไว้ในเรซูเม่ เมื่อสั่งให้ Notion AI อัปเดตข้อมูลลงในตารางติดตามการรับสมัครงาน (hiring tracker) จากเรซูเม่นั้น Notion AI ได้สร้าง URL รูปภาพที่มีข้อความจากตารางติดตามแนบไปด้วย แม้ว่า Notion จะแสดงคำเตือนเกี่ยวกับ URL ภายนอก แต่การแก้ไขนั้นถูกบันทึกลงระบบไปแล้ว ข้อมูลจึงรั่วไหลออกไปไม่ว่าผู้ใช้จะกดยอมรับการแก้ไขหรือไม่ก็ตาม

หลังจากมีการเปิดเผยต่อสาธารณะ Notion ได้ตรวจสอบยืนยันปัญหาและปล่อยตัวแก้ไขออกมาในคืนนั้นทันที นอกจากนี้ PromptArmor ยังชี้ให้เห็นปัญหาลักษณะเดียวกันในผู้ช่วยร่างอีเมลของ Notion Mail อีกด้วย อย่างไรก็ตาม ข้อมูลอัปเดตที่เราได้อ่านไม่ได้ระบุว่าการแก้ไขดังกล่าวครอบคลุมถึง Notion Mail ด้วยหรือไม่

Slack AI: เพียงคลิกเดียวที่ลิงก์ “ยืนยันตัวตนใหม่อีกครั้ง”

ผู้โจมตีได้โพสต์คำสั่งไว้ในแชนเนลสาธารณะที่พวกเขาสร้างขึ้น เมื่อมีผู้ใช้สอบถาม Slack AI เกี่ยวกับข้อมูลลับที่อยู่ในแชนเนลส่วนตัวของตนเอง คำตอบที่ได้กลับมีลิงก์ “click here to reauthenticate” (คลิกที่นี่เพื่อยืนยันตัวตนใหม่อีกครั้ง) ซึ่งมีข้อมูลลับแนบไปกับพารามิเตอร์ของ URL เพียงแค่คลิกเดียว ข้อมูลนั้นก็ถูกส่งออกไปยังภายนอกทันที

Slack ชี้แจงกับ PromptArmor เมื่อวันที่ 19 สิงหาคม 2024 ว่าการค้นหาข้อมูลในแชนเนลสาธารณะถือเป็นพฤติกรรมการทำงานตามปกติที่ออกแบบไว้ ต่อมาในวันที่ 21 สิงหาคม 2024 Slack ได้ประกาศแพตช์แก้ไขสำหรับกรณีการฟิชชิงที่มีความรุนแรงระดับต่ำ ทว่า SC Media รายงานว่าในประกาศดังกล่าวไม่ได้ระบุชื่อของ PromptArmor หรือยืนยันว่าเป็นปัญหาเดียวกันหรือไม่ ทั้งนี้ PromptArmor ยังตั้งข้อสังเกตด้วยว่า Slack AI เริ่มนำเข้าไฟล์จากแชนเนลและข้อความส่วนตัว (DM) ในเดือนเดียวกัน ซึ่งเป็นช่องทางที่พวกเขายังไม่ได้ทดสอบ

ClickUp Brain: ไม่พบรายงานสาธารณะ

ณ วันที่ 27 ตุลาคม 2026 เรายังไม่พบงานวิจัยที่ได้รับการเผยแพร่เกี่ยวกับการลักลอบส่งข้อมูลออกใน ClickUp Brain หรือ Super Agents โดยในหน้า Super Agents ของ ClickUp ระบุว่าเอเจนต์ทำงานภายใต้การอนุญาตสิทธิ์ทั้งแบบโดยนัย (implicit) และแบบชัดแจ้ง (explicit) พร้อมทั้งมี “ประวัติการตรวจสอบการทำงานทั้งหมดอย่างละเอียด (full audit trails)” นอกจากนี้ บล็อกโพสต์ของ ClickUp เกี่ยวกับเวิร์กโฟลว์ของ Super Agent ยังระบุด้วยว่าเอเจนต์จะสืบทอดสิทธิ์ในระดับเดียวกับผู้ใช้ และจำเป็นต้องได้รับการอนุมัติจากมนุษย์สำหรับการกระทำที่สำคัญ อย่างไรก็ตาม นี่เป็นเพียงคำกล่าวอ้างของผู้ให้บริการ ไม่ใช่ผลการทดสอบจากภายนอก ส่วนบทความช่วยเหลือของ ClickUp เกี่ยวกับ prompt injection นั้นพบหน้าตรวจสอบบอต ทำให้เราไม่สามารถนำเนื้อหามาอ้างอิงได้

วิธีแก้ปัญหาแบบไหนที่ได้ผลจริง และแบบไหนแค่ช่วยถ่วงเวลาผู้โจมตี

ในกระทู้ Hacker News มีการจัดลำดับมาตรการป้องกันไว้ดังนี้:

• ดึงข้อมูลเฉพาะ URL ที่ผู้ใช้เป็นผู้พิมพ์เอง หรือ URL ที่ได้คืนมาจากเครื่องมือที่เชื่อถือได้เท่านั้น: Simon Willison แย้งว่าเอเจนต์ต้องไม่เป็นฝ่ายสร้าง URL ขึ้นมาเองโดยเด็ดขาด การกรองเฉพาะ query string นั้นไม่เพียงพอ เพราะผู้โจมตีสามารถใช้ wildcard DNS เพื่อส่งข้อมูลผ่าน subdomain ได้
• อนุญาตเฉพาะ URL ที่อยู่ในดัชนีการค้นหา (Pre-indexed URLs): ผู้ใช้ที่ชื่อ wunderwuzzi23 ชี้ให้เห็นว่า แม้จะจำกัดการดึงข้อมูลเฉพาะหน้าที่ผ่านการทำดัชนีของ Search Engine ข้อมูลก็ยังสามารถรั่วไหลออกไปได้อยู่ดี โดยส่งออกทีละหนึ่งตัวอักษรต่อหนึ่งคำขอ
• การใช้ Domain Allowlist: สำหรับผู้ช่วย AI ที่มีขอบเขตงานเฉพาะเจาะจง การจำกัดรายชื่อโดเมนภายนอกที่อนุญาตให้ส่งข้อมูลออกได้อย่างรัดกุมถือเป็นวิธีที่ได้ผลดี
• ตัวจัดประเภท (Classifiers) และตัวกรอง Regex: มีประโยชน์ในฐานะการป้องกันเสริมอีกชั้นหนึ่ง แต่เนื่องจากทำงานบนหลักความน่าจะเป็น จึงไม่สามารถใช้เป็นแนวป้องกันสุดท้ายได้

ข้อสรุปสำคัญร่วมกันคือ: การกำหนดข้อจำกัดอย่างแน่นอนตายตัว (deterministic limits) บนช่องทางการส่งข้อมูลออกภายนอกนั้นมีประสิทธิภาพเหนือกว่าการพยายามเขียนพรอมต์ให้ฉลาดขึ้น โมเดลที่ปฏิเสธคำสั่งอันตรายได้บ่อยขึ้น ก็ยังคงมีสิทธิ์เข้าถึงเครือข่ายตามที่คุณกำหนดให้อยู่ดี ซึ่งเป็นประเด็นเดียวกับที่เราเคยนำเสนอไว้เกี่ยวกับ prompt injection และแนวทางป้องกันเอเจนต์ (agent guardrails) ในช่วงที่ Claude Opus 5.5 เปิดตัว

สิ่งที่ควรตรวจสอบก่อนเปิดใช้งาน AI ในพื้นที่ทำงาน

สิ่งที่คุณควรสอบถามผู้ให้บริการเป็นลายลักษณ์อักษร ได้แก่:

1. มีเครื่องมือใดบ้างที่สามารถส่งข้อมูลออกนอกระบบ (tenant) ได้ ไม่ว่าจะเป็นการดึงข้อมูล URL, การเรนเดอร์รูปภาพ, การแสดงผลลิงก์, อีเมล หรือตัวเชื่อมต่อภายนอก (connectors)
2. การตั้งค่าปิดใช้งานในแต่ละส่วนนั้น เป็นการถอดเครื่องมือดังกล่าวออกไปจริง ๆ หรือเป็นเพียงแค่การซ่อนฟีเจอร์ที่ใช้งานเครื่องมือนั้นไว้เท่านั้น ตัวอย่างเช่น การปิดสวิตช์ค้นหาเว็บของ Rovo ที่เป็นเพียงแค่การซ่อนฟีเจอร์
3. AI สามารถดึงข้อมูลจาก URL ที่ตัวโมเดลสร้างขึ้นมาเองได้หรือไม่
4. มีการเรนเดอร์รูปภาพ Markdown จากโดเมนภายนอกในข้อความตอบกลับของ AI หรือไม่
5. โดยค่าเริ่มต้นแล้ว AI อ่านข้อมูลอะไรบ้าง เช่น ไฟล์ที่อัปโหลด, ไดรฟ์ที่เชื่อมต่อ, ข้อความส่วนตัว (DM) หรือแชนเนลสาธารณะ
6. การกระทำใดบ้างที่ต้องได้รับการอนุมัติจากมนุษย์ และขั้นตอนการอนุมัตินั้นเกิดขึ้นก่อนที่ผลลัพธ์ข้างเคียง (side effect) จะเกิดขึ้นจริงหรือไม่ ตัวอย่างเช่น กรณีของ Notion ที่การอนุมัติเกิดขึ้นหลังจากที่ข้อมูลถูกบันทึกไปแล้ว
7. ผู้ให้บริการจัดการกับรายงานช่องโหว่ภายนอกล่าสุดอย่างไร และแก้ไขได้รวดเร็วเพียงใด

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

บทบาทที่แท้จริงของ Sharkly ในระบบนิเวศนี้

Sharkly ไม่ใช่ผู้ช่วย AI ที่ฝังตัวอยู่ในเอกสารของคุณ และไม่ได้มีภูมิคุ้มกันต่อ prompt injection โดยตรง Sharkly ทำหน้าที่จัดการ coding agent เช่น Claude Code และ Codex ซึ่งเอเจนต์เหล่านี้ต้องอ่านข้อความที่ไม่น่าเชื่อถืออยู่ตลอดทั้งวัน ไม่ว่าจะเป็นเนื้อหาใน issue, ไฟล์ README หรือหน้าเว็บที่ดึงมา และสามองค์ประกอบมรณะ (trifecta) ก็มีผลกับเอเจนต์เหล่านี้เช่นเดียวกัน

สิ่งที่แตกต่างออกไปคือ “ใครเป็นผู้ควบคุมขอบเขตความปลอดภัย” ใน Sharkly นั้น เอเจนต์จะทำงานบน Computers ของคุณเองผ่านบริการภายในเครื่อง ตามที่เอกสารประกอบของ Computers ระบุไว้ว่า Computer จะเป็นตัวจัดเตรียมไฟล์ ข้อมูลประจำตัว สิทธิ์การเข้าถึงเครือข่าย และเครื่องมือต่าง ๆ ที่จำเป็นสำหรับการทำงานในแต่ละรอบ ดังนั้น การจำกัดการส่งข้อมูลออก (egress) จึงอยู่ภายใต้การควบคุมของคุณเอง เพียงกำหนดให้ Computer ทำงานภายใต้ domain allowlist การทำงานทุกอย่างบนเครื่องนั้นก็จะได้รับข้อจำกัดเดียวกัน ไม่ว่าจะรันเอเจนต์ตัวใดก็ตาม

นอกจากนี้ ยังมีขอบเขตความปลอดภัยอื่น ๆ ตามที่ระบุไว้ในเอกสาร:

• ผู้ใช้ประเภท Guest จะมองเห็นเฉพาะ Spaces ที่ถูกเพิ่มเข้าไปเท่านั้น: โดยไม่สามารถค้นพบหรือเข้าร่วมใน public Spaces ได้เอง (People and roles)
• การกระทำกับระบบภายนอกต้องผ่านตัวเชื่อมต่อที่ได้รับอนุญาต: เวิร์กโฟลว์อัตโนมัติจะไม่สามารถเรียกใช้งานแอปภายนอกที่คุณยังไม่ได้เชื่อมต่อไว้ได้
• ไม่เก็บข้อมูลลับไว้ใน Skills: เอกสารประกอบของ Skills ระบุไว้อย่างชัดเจนว่า ห้ามเก็บรหัสผ่าน โทเคน หรือคีย์ลับไว้ในคำสั่งหรือไฟล์ของ Skill โดยเด็ดขาด

มาตรการเหล่านี้อาจไม่ได้ป้องกันไม่ให้เอเจนต์ถูกหลอกให้ทำสิ่งที่ไม่พึงประสงค์ภายใต้สิทธิ์ที่มันมีอยู่ แต่เป็นการจำกัดขอบเขตสิทธิ์นั้นให้แคบลง และกำหนดให้มีขั้นตอนที่มนุษย์ต้องตรวจรับงานบน Task เสมอ บทความของเราเกี่ยวกับสิทธิ์ของ coding agent และจุดตรวจสอบเพื่อขออนุมัติ (approval gates) ได้อธิบายไว้อย่างละเอียดว่าควรขีดเส้นแบ่งสิทธิ์เหล่านี้อย่างไร

บทสรุป

Prompt injection ยังคงเป็นปัญหาที่ยังไม่มีทางแก้เบ็ดเสร็จสำหรับทุกผลิตภัณฑ์ที่ต้องอ่านข้อความจากภายนอก ซึ่งรวมถึง coding agent ด้วย คำถามที่มีประโยชน์มากกว่าจึงเป็นเรื่องที่เจาะจงยิ่งขึ้น นั่นคือ ผู้ช่วย AI ตัวนั้นสามารถส่งข้อมูลอะไรออกไปได้บ้าง และคุณมีสวิตช์ปิดการทำงานนั้นหรือไม่ ในบรรดาเครื่องมือทั้งสี่ตัวที่กล่าวถึงนี้ มีสองตัวที่เคยพบข้อมูลรั่วไหลสู่สาธารณะและได้ปล่อยแพตช์แก้ไขแล้ว มีหนึ่งตัวที่พบข้อมูลรั่วไหลแต่ยังไม่พบการแก้ไข และอีกหนึ่งตัวที่ยังไม่พบรายงานสาธารณะ

หากคุณใช้งาน coding agent หลายตัว และต้องการให้ทำงานบนโฮสต์ที่คุณสามารถควบคุมเครือข่ายได้เอง ลองเชื่อมต่อ Computer เข้ากับ Sharkly พร้อมจำกัดการส่งข้อมูลออก (egress) แล้วมอบหมาย Task ที่มีความเสี่ยงต่ำให้ Agent ดูแล ปัจจุบัน Sharkly เปิดให้ใช้งานได้ฟรีสำหรับองค์กรที่มีขนาดไม่เกิน 5 คน

คำถามที่พบบ่อย (FAQ)

Atlassian Rovo ยังคงมีช่องโหว่เรื่องข้อมูลรั่วไหลอยู่หรือไม่?

ช่องทางการโจมตีผ่านเอกสารที่ PromptArmor รายงานยังไม่ได้รับการแพตช์เมื่อวันที่ 5 สิงหาคม 2026 และเรายังไม่พบการประกาศแก้ไขต่อสาธารณะ ณ วันที่ 27 ตุลาคม 2026 ส่วนประเด็นเรื่องลิงก์ของ Varonis นั้นได้รับการแก้ไขแล้ว

Notion ได้แก้ไขปัญหาข้อมูลรั่วไหลของ Notion AI แล้วหรือยัง?

แก้ไขแล้ว โดย Notion ระบุว่าแนวทางแก้ไขสำหรับการอัปเดตเอกสาร AI ที่ไม่ปลอดภัยได้ถูกนำขึ้นระบบจริงเมื่อวันที่ 7 มกราคม 2026 ซึ่งเป็นคืนเดียวกับที่ PromptArmor เปิดเผยข้อมูลต่อสาธารณะ

Slack AI ได้รับการแพตช์แก้ปัญหา prompt injection แล้วหรือไม่?

Slack ได้ประกาศแพตช์เมื่อวันที่ 21 สิงหาคม 2024 โดยไม่ได้ยืนยันว่าเป็นปัญหาเดียวกันกับที่ PromptArmor รายงานอย่างชัดเจน

การปิดการค้นหาเว็บช่วยป้องกันไม่ให้ผู้ช่วย AI ส่งข้อมูลรั่วไหลได้หรือไม่?

ไม่ได้เสมอไป ในกรณีของ Rovo การปิดการค้นหาเว็บไม่ได้เป็นการถอดเครื่องมือดึงข้อมูล URL ออก ข้อมูลจึงยังสามารถรั่วไหลได้ตามปกติ

Lethal trifecta ในแง่ความปลอดภัยของ AI คืออะไร?

คือการประกอบกันของ 3 สิ่ง ได้แก่ ข้อมูลส่วนบุคคล (private data), เนื้อหาที่ไม่น่าเชื่อถือ (untrusted content) และช่องทางส่งข้อมูลออกสู่ภายนอก (outbound channel) หากผู้ช่วย AI มีครบทั้งสามข้อนี้ ก็สามารถถูกชักจูงให้ทำข้อมูลรั่วไหลได้

Coding agent สามารถทำข้อมูลรั่วไหลด้วยวิธีเดียวกันนี้ได้หรือไม่?

ได้เช่นกัน Coding agent ที่อ่านไฟล์ README ที่แฝงคำสั่งอันตรายและสามารถเข้าถึงเครือข่ายได้ ย่อมเผชิญกับความเสี่ยงแบบเดียวกัน วิธีป้องกันคือควรจำกัดสิทธิ์ข้อมูลประจำตัวและการเชื่อมต่อไปยังเครือข่ายภายนอกในระดับโฮสต์