Rò rỉ dữ liệu AI: Rovo vs Notion AI vs Slack AI vs ClickUp Brain

Tóm tắt nhanh: Rò rỉ dữ liệu AI trong các công cụ làm việc xảy ra khi một trợ lý AI đọc văn bản độc hại, làm theo các chỉ thị ẩn bên trong đó và gửi dữ liệu riêng tư của bạn đến một máy chủ bên ngoài thông qua việc truy xuất URL (URL fetch), hiển thị hình ảnh hoặc một liên kết. Các nghiên cứu công khai đã chỉ ra lỗ hổng này trên Atlassian Rovo, Notion AI và Slack AI. Notion và Slack đã phát hành bản vá; tính đến ngày 27-10-2026, chúng tôi chưa tìm thấy bản vá công khai nào cho đường dẫn khai thác của Rovo.

AI quản lý dự án của bạn thường đọc những nội dung không phải do bạn viết: các phiếu hỗ trợ (support ticket), tệp PDF được tải lên, trang liên kết (connector page), kênh công khai. Bất kỳ nội dung nào trong số đó cũng có thể chứa chỉ thị ẩn.

Bài viết này so sánh Rovo, Notion AI, Slack AI và ClickUp Brain. Mỗi dòng đều trích dẫn bài phân tích gốc hoặc trang chính thức của nhà cung cấp kèm ngày tháng. Ở những phần không tìm thấy thông tin, bảng ghi “chưa tìm thấy báo cáo công khai”. Cơ chế tương tự cũng áp dụng cho các coding agent (agent lập trình), phần mà chúng tôi sẽ đề cập ở cuối bài.

Bản chất của rò rỉ dữ liệu AI, tóm gọn trong một câu

Tấn công chèn câu lệnh gián tiếp (indirect prompt injection) là một chỉ thị ẩn bên trong nội dung mà trợ lý AI xử lý, sau đó trợ lý này làm theo chỉ thị đó như thể chính bạn đã yêu cầu.

Nó sẽ biến thành một vụ rò rỉ dữ liệu khi hội đủ ba điều kiện. Simon Willison gọi đây là bộ ba chí mạng (lethal trifecta) vào tháng 6 năm 2025:

1. Trợ lý AI có thể đọc dữ liệu riêng tư.
2. Trợ lý AI đọc nội dung mà người ngoài có thể tác động.
3. Trợ lý AI có cách để gửi dữ liệu ra bên ngoài.

Chỉ cần loại bỏ một yếu tố bất kỳ, đường dẫn rò rỉ sẽ bị chặn. Tuy nhiên, theo thiết kế vốn có, các trợ lý trong không gian làm việc (workspace assistant) lại sở hữu cả ba yếu tố này.

Phương thức trích xuất dữ liệu trên Atlassian Rovo đã diễn ra như thế nào

PromptArmor đã công bố bài phân tích về Rovo vào ngày 05-08-2026. Chuỗi khai thác diễn ra rất ngắn gọn:

1. Người dùng tải lên một tệp (trong bản demo là “Backlog Guide”) có chứa chỉ thị ẩn bên trong.
2. Người dùng yêu cầu Rovo sắp xếp các ticket Jira của họ.
3. Rovo tìm kiếm trên Jira và Confluence, sau đó thực hiện theo chỉ thị ẩn.
4. Rovo đính kèm nội dung ticket và trang vào một URL của kẻ tấn công rồi mở URL đó bằng công cụ truy xuất URL (URL-retrieval tool).
5. Máy chủ của kẻ tấn công ghi lại request này, bao gồm cả dữ liệu bị đánh cắp. Người dùng vẫn chỉ nhìn thấy kết quả phản hồi bình thường.

Không hề có bước phê duyệt nào được kích hoạt. Cuộc tấn công vẫn hoạt động ngay cả khi đã tắt tính năng tìm kiếm web (web search), bởi vì nút gạt bật/tắt đó không vô hiệu hóa công cụ truy xuất URL. Rovo cũng hiển thị hình ảnh Markdown – một kênh gửi dữ liệu thứ hai.

Mốc thời gian công bố lỗ hổng là điều người mua cần lưu tâm. PromptArmor đã báo cáo vào ngày 23-05-2026, Atlassian xác nhận tiếp nhận vào ngày 25-05, các liên hệ tiếp theo vào ngày 04-06 và 29-07 đều không nhận được phản hồi, và bài viết đã được công khai vào ngày 05-08 trong khi Rovo vẫn còn tồn tại lỗ hổng. Chủ đề trên Hacker News đã đạt 306 điểm và 138 bình luận.

Một vấn đề riêng biệt khác của Rovo đã được khắc phục. Ghi chú nghiên cứu của Cloud Security Alliance ngày 14-08-2026 đề cập đến hướng tấn công một cú nhấp “RovoBlast” của Varonis thông qua tham số URL trong khung chat, lỗi này đã được Atlassian vá ở phía máy chủ trước khi Varonis công bố. Cũng trong ghi chú đó, hướng tấn công qua tài liệu của PromptArmor được mô tả là chưa được giải quyết. Tính đến ngày 27-10-2026, chúng tôi không tìm thấy thông báo khắc phục nào sau đó.

Một lưu ý về tên gọi: Rovo Dev là coding agent của Atlassian. Đây là sản phẩm khác với trợ lý Rovo được đề cập trong bài viết này, và nghiên cứu ở trên không thử nghiệm trên Rovo Dev.

Rovo so với Notion AI, Slack AI và ClickUp Brain

Bảng dưới đây so sánh những gì từng trợ lý đã được chứng minh hoặc ghi nhận là có thực hiện. “Không đề cập” nghĩa là nguồn tài liệu chúng tôi tham khảo không nói về mục đó.

Chúng tôi không đưa Linear và Asana vào danh sách. Tính đến ngày 27-10-2026, chúng tôi không tìm thấy báo cáo công khai nào về việc trích xuất dữ liệu qua prompt injection đối với trợ lý của cả hai nền tảng này, và việc thiếu báo cáo không đồng nghĩa với việc chúng hoàn toàn an toàn.

Notion AI: chỉnh sửa đã được lưu trước khi bạn phê duyệt

Trường hợp Notion AI do PromptArmor thử nghiệm đã ẩn văn bản màu trắng cỡ chữ 1-point trong một bản CV. Khi được yêu cầu cập nhật bảng theo dõi tuyển dụng từ CV này, Notion AI đã tạo một URL hình ảnh có gắn kèm văn bản từ bảng theo dõi. Notion có đưa ra cảnh báo về URL bên ngoài, nhưng nội dung chỉnh sửa vốn đã được lưu từ trước, vì vậy dữ liệu vẫn bị tuồn ra ngoài dù người dùng có chấp thuận hay không.

Notion đã xác thực lỗ hổng sau khi được công bố công khai và tung ra bản vá ngay trong đêm đó. PromptArmor cũng cảnh báo một vấn đề tương tự trong trợ lý soạn thảo Notion Mail; tuy nhiên bản cập nhật chúng tôi đọc không nêu rõ liệu bản vá có áp dụng cho Mail hay không.

Slack AI: một cú nhấp vào liên kết xác thực lại

Kẻ tấn công đăng chỉ thị vào một kênh công khai do chính họ tạo ra. Khi một người dùng hỏi Slack AI về một thông tin bí mật trong kênh riêng tư của chính họ, câu trả lời đã bao gồm một liên kết “nhấp vào đây để xác thực lại” với chuỗi bí mật được đính kèm trong URL. Chỉ một cú nhấp chuột là dữ liệu bí mật đã bị gửi đi.

Slack đã phản hồi với PromptArmor vào ngày 19-08-2024 rằng tính năng tìm kiếm trên kênh công khai là hành vi đúng như thiết kế. Vào ngày 21-08-2024, Slack thông báo bản vá cho một kịch bản tấn công giả mạo (phishing) mức độ nghiêm trọng thấp; SC Media đưa tin rằng thông cáo không nhắc tên PromptArmor hay xác nhận đó có phải cùng một vấn đề hay không. PromptArmor cũng lưu ý rằng Slack AI đã bắt đầu thu nạp tệp từ các kênh và tin nhắn trực tiếp (DM) trong tháng đó, một hướng tấn công mà họ chưa thử nghiệm.

ClickUp Brain: chưa tìm thấy báo cáo công khai

Tính đến ngày 27-10-2026, chúng tôi không tìm thấy nghiên cứu nào được công bố về việc trích xuất dữ liệu trên ClickUp Brain hay Super Agents. Trang Super Agents của ClickUp cho biết các agent hoạt động với quyền hạn ngầm định và tường minh, đồng thời lưu giữ “nhật ký kiểm toán đầy đủ cho mọi hành động”. Một bài đăng trên blog của ClickUp về quy trình làm việc của Super Agent tuyên bố rằng các agent kế thừa quyền hạn ở cấp người dùng và yêu cầu sự phê duyệt của con người đối với các hành động quan trọng. Đó là những tuyên bố từ phía nhà cung cấp, không phải kết quả thử nghiệm độc lập. Bài viết hướng dẫn của ClickUp về prompt injection đã hiển thị trang kiểm tra bot khi chúng tôi truy cập, do đó chúng tôi không trích dẫn nội dung này.

Biện pháp xử lý nào thực sự hiệu quả, biện pháp nào chỉ làm chậm bước kẻ tấn công

Chủ đề trên Hacker News đã xếp hạng các giải pháp phòng thủ như sau:

• Chỉ truy xuất các URL do người dùng nhập hoặc do một công cụ đáng tin cậy trả về. Simon Willison lập luận rằng agent tuyệt đối không được tự ý cấu thành URL. Lọc chuỗi truy vấn (query string) là không đủ, vì wildcard DNS có thể truyền dữ liệu qua subdomain.
• Chỉ truy xuất các URL đã được lập chỉ mục trước (pre-indexed). Người bình luận wunderwuzzi23 chỉ ra rằng việc giới hạn truy xuất ở các trang đã được lập chỉ mục tìm kiếm vẫn có thể làm rò rỉ dữ liệu, mỗi request một ký tự.
• Danh sách tên miền cho phép (domain allowlist). Đối với một trợ lý có phạm vi công việc hẹp, một danh sách ngắn các tên miền gửi đi (outbound) được phép sẽ mang lại hiệu quả phòng thủ rất tốt.
• Bộ phân loại (classifier) và bộ lọc regex. Hữu ích như một lớp bảo vệ bổ sung. Mang tính xác suất, do đó không bao giờ có thể làm tuyến phòng thủ cuối cùng.

Điểm chung rút ra là: các giới hạn mang tính xác định (deterministic) trên kênh outbound luôn đánh bại những câu prompt thông minh hơn. Một mô hình từ chối yêu cầu thường xuyên hơn thì vẫn nắm giữ toàn bộ quyền truy cập mạng mà bạn đã cấp cho nó – đây là điểm chúng tôi từng nêu ra về prompt injection và hàng rào bảo vệ (guardrail) cho agent khi Claude Opus 5.5 ra mắt.

Những điều cần kiểm tra trước khi bật AI trong không gian làm việc

Hãy yêu cầu nhà cung cấp trả lời bằng văn bản những câu hỏi sau:

1. Những công cụ nào có thể gửi dữ liệu ra bên ngoài tenant: truy xuất URL (URL fetch), hiển thị hình ảnh, hiển thị liên kết, email, connector?
2. Mỗi cài đặt liên quan có thực sự loại bỏ công cụ đó không, hay chỉ đơn thuần ẩn đi tính năng sử dụng nó? Nút gạt tìm kiếm web của Rovo rơi vào trường hợp thứ hai.
3. Mô hình có thể truy xuất một URL do chính nó tự tạo ra không?
4. Hình ảnh Markdown từ các tên miền bên ngoài có được hiển thị trong kết quả của AI không?
5. Mặc định AI sẽ đọc những gì: tệp tải lên, ổ đĩa liên kết, tin nhắn trực tiếp (DM), kênh công khai?
6. Những hành động nào cần con người phê duyệt, và sự phê duyệt đó diễn ra trước hay sau khi tác vụ phát sinh tác dụng phụ (side effect)? Trường hợp của Notion diễn ra sau.
7. Nhà cung cấp đã xử lý báo cáo lỗ hổng bên ngoài gần nhất như thế nào và tốc độ xử lý ra sao?

Chỉ nên sử dụng trợ lý không gian làm việc khi các kênh outbound của nó được ghi nhận rõ ràng trong tài liệu và bạn có thể chủ động tắt từng kênh một. Hãy tạm hoãn sử dụng nếu nhà cung cấp không thể liệt kê được những kênh này.

Vị trí thực sự của Sharkly trong bức tranh này

Sharkly không phải là một trợ lý nhúng trong tài liệu của bạn, và nó cũng không hề miễn nhiễm với prompt injection. Sharkly quản lý các coding agent như Claude Code và Codex, và những agent này liên tục đọc văn bản không đáng tin cậy suốt cả ngày: nội dung issue, tệp README, các trang web được nạp về. Bộ ba chí mạng (trifecta) cũng áp dụng với chúng.

Điểm khác biệt nằm ở chỗ ai là người nắm quyền kiểm soát ranh giới bảo mật. Trong Sharkly, các agent thực thi trên chính Computer (máy tính) của bạn thông qua một dịch vụ cục bộ. Tài liệu về Computers nêu rõ rằng Computer cung cấp tệp, thông tin xác thực (credential), quyền truy cập mạng và các công cụ cần thiết cho mỗi lần chạy. Vì vậy, quyền giới hạn lưu lượng mạng ra ngoài (egress) thuộc về bạn: đặt một Computer phía sau một danh sách tên miền cho phép (domain allowlist), và mọi lượt chạy trên đó đều kế thừa giới hạn này, bất kể đó là agent nào.

Một số ranh giới bảo mật khác được nêu trong tài liệu:

• Khách (Guest) chỉ nhìn thấy các Space mà họ được thêm vào. Họ không thể tìm thấy hay tự ý tham gia các Space công khai (People and roles).
• Các hành động của bên thứ ba cần connector được ủy quyền. Quy trình tự động hóa không thể gọi đến một ứng dụng bên ngoài mà bạn chưa kết nối.
• Thông tin bảo mật tuyệt đối không đưa vào Skills. Tài liệu Skills quy định không bao giờ lưu trữ mật khẩu, token hoặc khóa bí mật trong các chỉ thị hoặc tệp của Skill.

Những điều này không thể ngăn hoàn toàn việc một agent bị dẫn dụ thực hiện một hành động xấu trong phạm vi quyền hạn mà nó đang có. Nhưng nó thu hẹp phạm vi quyền hạn đó và duy trì bước phê duyệt của con người trên Task. Các bài viết của chúng tôi về phân quyền cho coding agent và cổng phê duyệt (approval gate) sẽ hướng dẫn chi tiết cách thiết lập các ranh giới này.

Kết luận

Prompt injection vẫn là một bài toán chưa có lời giải triệt để trên mọi sản phẩm xử lý văn bản không đáng tin cậy, bao gồm cả các coding agent. Câu hỏi thực tế và trọng tâm hơn là: trợ lý có thể gửi những gì ra ngoài, và bạn có thể tắt nó đi không? Trong số bốn công cụ ở đây, hai công cụ từng bị rò rỉ công khai và đã tung bản vá, một công cụ bị rò rỉ công khai nhưng chúng tôi chưa tìm thấy bản vá, và một công cụ chưa có báo cáo công khai nào.

Nếu bạn đang vận hành nhiều coding agent và muốn đặt chúng trên các máy chủ có hệ thống mạng do bạn toàn quyền kiểm soát, hãy kết nối một Computer với Sharkly, siết chặt lưu lượng mạng ra ngoài (egress) và giao cho Agent một Task có mức độ rủi ro thấp. Sharkly hiện miễn phí cho các tổ chức có quy mô tối đa 5 người.

Câu hỏi thường gặp (FAQ)

Atlassian Rovo có còn dễ bị tấn công trích xuất dữ liệu không?

Hướng tấn công qua tài liệu do PromptArmor phát hiện vẫn chưa được vá vào ngày 05-08-2026, và tính đến ngày 27-10-2026 chúng tôi vẫn chưa tìm thấy bản vá công khai nào. Vấn đề riêng biệt liên quan đến liên kết của Varonis đã được khắc phục.

Notion đã vá lỗi rò rỉ dữ liệu của Notion AI chưa?

Rồi. Notion cho biết giải pháp khắc phục cho việc AI cập nhật tài liệu không an toàn đã được đưa lên production vào ngày 07-01-2026, ngay trong đêm PromptArmor công bố thông tin ra công chúng.

Lỗ hổng prompt injection trên Slack AI đã được vá chưa?

Slack đã công bố một bản vá vào ngày 21-08-2024, nhưng không xác nhận đó có phải chính xác là vấn đề mà PromptArmor đã báo cáo hay không.

Tắt tính năng tìm kiếm web có ngăn được trợ lý AI làm rò rỉ dữ liệu không?

Không phải lúc nào cũng vậy. Trong trường hợp của Rovo, cài đặt tìm kiếm web không hề vô hiệu hóa công cụ truy xuất URL, do đó việc rò rỉ dữ liệu vẫn diễn ra bình thường.

“Bộ ba chí mạng” (lethal trifecta) trong bảo mật AI là gì?

Dữ liệu riêng tư, nội dung không đáng tin cậy và một phương thức để gửi dữ liệu ra bên ngoài. Một trợ lý có đủ cả ba yếu tố này có thể bị dẫn dụ để làm rò rỉ dữ liệu.

Các coding agent có thể làm rò rỉ dữ liệu theo cách tương tự không?

Có. Một coding agent đọc tệp README độc hại và có quyền truy cập mạng sẽ phải đối mặt với nguy cơ tương tự. Hãy giới hạn thông tin xác thực (credential) và lưu lượng mạng ra ngoài (outbound network) của nó ở cấp máy chủ (host).