Sâu AI Copilot tự lây lan qua tài liệu Word

• Cross-domain prompt injection (XPIA) được ẩn trong tài liệu Word bên ngoài có thể thao túng kết quả soạn thảo/chỉnh sửa của Copilot và tự sao chép sang tài liệu mới, nhờ đó có thể lan truyền theo luồng công việc hằng ngày ngay cả khi không còn tài liệu tấn công gốc
• Các lệnh được giấu bằng chữ trắng, cỡ nhỏ vẫn được Copilot đọc sau khi loại bỏ định dạng; trong thử nghiệm, nó đã thay đổi số liệu tài chính và giấu toàn bộ prompt tấn công ở cuối tài liệu kết quả, biến tài liệu đó thành vector tấn công mới
• Kẻ tấn công không cần truy cập tenant Microsoft 365 của nạn nhân; chỉ cần chia sẻ tài liệu qua SharePoint, Teams, Outlook rồi khiến người dùng đính kèm tài liệu đó hoặc để Work IQ chọn nó làm tài liệu liên quan trong OneDrive
• Microsoft đã triển khai chặn một số payload cụ thể và nâng cấp mô hình, nhưng toàn bộ chuỗi tấn công vẫn được tái hiện trên GPT-5.6 bằng prompt biến thể; sau 144 ngày phối hợp xử lý, họ vẫn chưa chặn được toàn bộ lớp lỗ hổng này
• Vì tài liệu bị nhiễm được lưu thông như tài liệu nội bộ/đối tác bình thường nên khó truy vết nguồn gốc và phát hiện; cần rà soát tài liệu bên ngoài và kết quả Copilot, đồng thời lưu giữ bằng metadata nguồn gốc ban đầu và lịch sử chỉnh sửa của mô hình

---

Cách thức hoạt động của sâu AI dựa trên tài liệu

• Khi lệnh do kẻ tấn công kiểm soát trong một tài liệu được sao chép vào kết quả tạo/chỉnh sửa của Copilot, tài liệu kết quả trở thành vector mới mang cùng cuộc tấn công
  • Nếu tài liệu đó được dùng làm tài liệu tham chiếu cho một tác vụ Copilot khác, lệnh sẽ được thực thi lại và sao chép sang tài liệu tiếp theo
  • Quá trình lây lan có thể tiếp diễn mà không cần tài liệu độc hại ban đầu hay sự can thiệp thêm của kẻ tấn công
• Morris II trước đây đã trình diễn prompt tự sao chép trong hệ sinh thái trợ lý email AI tạo sinh
• Trường hợp lần này là một trình diễn công khai về sâu AI dựa trên tài liệu tự lây lan trong công việc tài liệu thông thường của một sản phẩm năng suất thương mại phổ biến

Tấn công bằng quy trình xử lý tài liệu bình thường

• Một nhân viên tải tài liệu phân tích thị trường có chứa lệnh ẩn từ một website đáng tin cậy đã bị xâm nhập và dùng nó làm tài liệu đầu vào để Copilot soạn báo cáo tài chính
  • Copilot thay đổi số liệu tài chính nội bộ và sao chép lệnh tấn công vào báo cáo mới
  • Nhân viên lưu báo cáo trông có vẻ bình thường và chia sẻ nội bộ
  • Khi đồng nghiệp dùng báo cáo này làm tài liệu cho báo cáo tiếp theo, việc thao túng số liệu và sao chép lệnh được lặp lại
• Càng nhiều lần báo cáo được tái sử dụng, càng nhiều tài liệu bị biến thành vector tấn công; website bị nhiễm và tài liệu độc hại đầu tiên không còn cần thiết nữa

Mô hình đe dọa và ranh giới tin cậy

• Kẻ tấn công chỉ cần chia sẻ tài liệu độc hại, không cần quyền truy cập tenant Microsoft 365 của nạn nhân
  • Đường phân phối bao gồm SharePoint, Teams, Outlook và các phương thức chia sẻ tài liệu khác
• Ranh giới bảo mật cốt lõi nằm giữa tài liệu đính kèm và tài liệu đang được soạn thảo
  • Copilot phải đọc mọi tài liệu đính kèm để chọn thông tin cần dùng
  • Thông tin trong tài liệu đính kèm có thể được sử dụng, nhưng các lệnh bên trong không được coi là chỉ thị có thẩm quyền của người dùng
• Trên thực tế, lệnh được chèn trong tài liệu đã thay đổi hành vi của Copilot
  • Thay đổi các con số trong báo cáo tài chính mà không thông báo cho người dùng
  • Dán toàn bộ XPIA vào tài liệu tiếp theo để nó tiếp tục được thực thi trong các tác vụ sau

Cách vượt ranh giới tin cậy trong Word

• Tài liệu độc hại ban đầu chứa prompt định dạng JSON, có thể được ẩn khỏi người dùng bằng chữ trắng trên nền trắng và cỡ chữ nhỏ
• Copilot for Word loại bỏ các định dạng như màu sắc và cỡ chữ trước khi chuyển văn bản cho LLM nền tảng, nên nội dung người dùng không nhìn thấy vẫn được mô hình đọc đầy đủ
• Có thể che giấu tốt hơn bằng cách đặt lệnh tấn công trong một tài liệu bình thường trông có vẻ liên quan đến tác vụ
• Để tài liệu độc hại được đưa vào ngữ cảnh của Copilot, cần một trong các điều kiện sau
  1. Người dùng trực tiếp đính kèm hoặc tải tài liệu lên Copilot for Word
  2. Người dùng dùng chế độ work/Work IQ của Edit with Copilot, và Copilot đánh giá tài liệu đó trong OneDrive là tài liệu liên quan rồi chọn nó
• Kẻ tấn công cần cấu trúc nội dung để tăng khả năng tài liệu được chọn trực tiếp hoặc xuất hiện trong kết quả tìm kiếm
• Lỗ hổng này áp dụng cho cả magic pen của Word lẫn Edit with Copilot

Giai đoạn 1: Thao túng tài liệu và sao chép ban đầu

• Bằng chứng khái niệm (PoC) đầu tiên dùng một tài liệu chỉ chứa prompt độc hại bằng chữ trắng, xác nhận rằng nếu tài liệu được đưa vào ngữ cảnh thì cuộc tấn công có thể được thực thi dù tài liệu không liên quan đến tác vụ
• Prompt PoC gồm hai phần
  • Phần đầu thao túng tài liệu đích bằng cách tinh vi thay đổi ý nghĩa của bản tóm tắt hoặc sửa các con số trong tài liệu tài chính
    • Điểm then chốt là khiến Copilot tin rằng đây là một yêu cầu bình thường liên quan đến tác vụ
    • Trong thử nghiệm, rất khó phát hiện thay đổi có ý nghĩa bằng mắt thường, nên còn phải thêm riêng chỉ thị yêu cầu làm nổi bật phần thay đổi
    • Trong tấn công thực tế sẽ không yêu cầu hiển thị thay đổi; ví dụ công khai dùng việc thay đổi số liệu tài chính để dễ xác nhận ngay
  • Phần thứ hai chỉ thị sao chép prompt tấn công vào tài liệu kết quả
    • Nó ngụy trang như một tác vụ phục vụ truy vết nguồn gốc tài liệu về sau và cũng chỉ thị cách tự che giấu với lý do cải thiện khả năng đọc
• Khi chèn cuộc tấn công bằng chữ trắng vào cuối tài liệu phân tích thị trường của một công ty hư cấu tên Tfosorcim Ltd., Copilot đã giảm một nửa tất cả số liệu trong báo cáo tài chính Q1
• Sau đó, nó sao chép toàn bộ prompt độc hại vào cuối tài liệu kết quả bằng chữ trắng cỡ 8 điểm, đồng thời không thông báo cho người dùng về việc thay đổi số liệu hay chèn prompt
• Ngay cả khi người dùng không trực tiếp đính kèm tài liệu độc hại mà chỉ yêu cầu soạn báo cáo Q1 của Tfosorcim, Copilot vẫn tìm kiếm OneDrive, tìm thấy tài liệu phân tích thị trường độc hại trong thư mục khác và cuộc tấn công thành công
• PoC này dùng mô hình mới nhất thời điểm đó là GPT-5.6

Giai đoạn 2: Tự lây lan sang tài liệu tiếp theo

• Vì bản thân báo cáo Q1 bị nhiễm đã trở thành vector tấn công mới, phiên soạn thảo tiếp theo không còn cần tài liệu độc hại ban đầu
• Khi đính kèm báo cáo Q1 để tạo báo cáo Q2, Copilot lại giảm một nửa mọi số liệu tài chính và sao chép toàn bộ prompt bằng chữ trắng
• Vector mới là tài liệu được tạo từ tài nguyên nội bộ hợp pháp, nên nó có được niềm tin dành cho tài liệu nội bộ
  • Nếu nạn nhân chia sẻ tài liệu cho đồng nghiệp, rồi bản thân họ hoặc đồng nghiệp dùng nó làm tài liệu soạn thảo/chỉnh sửa cho Copilot, cuộc tấn công sẽ lan sang tài liệu mới
• Trong tất cả PoC được báo cáo, Copilot đã thay đổi tài liệu và sao chép lệnh ẩn; nếu đưa tài liệu bị nhiễm vào ngữ cảnh sau đó, cuộc tấn công được thực thi lại mà không cần bản gốc

Tác động đến tổ chức và môi trường cộng tác

• Sau điểm xâm nhập ban đầu, tài liệu bị nhiễm trông giống tài liệu được tạo bình thường trong nội bộ và không hiển thị lịch sử chỉnh sửa Copilot đã được phê duyệt, khiến việc truy vết tấn công rất khó khăn
• Nếu lây lan âm thầm qua công việc tài liệu thông thường, nó có thể làm suy giảm độ tin cậy của nền tảng thông tin dùng cho việc ra quyết định của tổ chức
• Tổ chức không biết mình bị nhiễm có thể chuyển tài liệu cho tổ chức khác qua site SharePoint dùng chung hoặc cộng tác trên Teams
  • Tài liệu tấn công ban đầu nhắm vào một tổ chức cũng có thể đến từ một đối tác đáng tin cậy nhưng đã bị nhiễm
  • Niềm tin vào tài liệu của đối tác cũng làm tăng khả năng người dùng đưa nó vào ngữ cảnh Copilot
• Khi Copilot được tích hợp sâu hơn vào các hệ thống tự động tạo và thao tác tài liệu, công cụ, luồng cộng tác như Microsoft Cowork hoặc Microsoft Scout, cùng cơ chế này có thể ảnh hưởng đến bề mặt rộng hơn với tốc độ máy

Biện pháp giảm thiểu của Microsoft và lỗ hổng còn lại

• Microsoft đã chặn prompt PoC được gửi ban đầu và triển khai nhiều bản sửa trong giai đoạn phối hợp công bố
  • Payload cụ thể được báo cáo đã bị chặn, nên các lần tái hiện sau đó cần payload biến thể thay vì câu chữ cũ
  • Các đường tấn công qua bộ nhớ và nội dung email được đề cập ở phần 1 và phần 2 của loạt bài đã được giảm thiểu
• Tuy nhiên, lớp lỗ hổng trong đó lệnh từ tài liệu gốc thay đổi đầu ra của Copilot và tự sao chép sang tài liệu tiếp theo vẫn còn
  • Dù thay đổi tác vụ yêu cầu hoặc câu chữ, lỗ hổng cơ bản và cách lây lan không thay đổi
  • Ngay cả khi áp dụng tất cả biện pháp giảm thiểu đã triển khai, toàn bộ chuỗi tấn công vẫn được tái hiện bằng payload đã chỉnh sửa
• Đây là điểm yếu mang tính cấu trúc mà các hệ thống dựa trên LLM hiện nay cùng chia sẻ, và chưa xác nhận được cách chặn hoàn toàn lớp này trong các sản phẩm tương đương
• Vấn đề này cần nghiên cứu thêm hơn là một bản vá đơn lẻ, nhưng các sửa đổi của Microsoft đã thực sự giảm khả năng bị phơi nhiễm

Tình trạng công bố và phản ứng của người dùng

• Nhóm đã phối hợp công bố với MSRC và các nhóm sản phẩm Microsoft, cung cấp quy trình tái hiện, video, giả định môi trường và prompt PoC chính xác
• Giai đoạn phối hợp ban đầu 90 ngày được gia hạn hai lần, tổng cộng 144 ngày, nhưng tại thời điểm công bố, cuộc tấn công vẫn tái hiện được
• Hai đợt giảm thiểu, bao gồm nâng cấp mô hình, vẫn không chặn được toàn bộ lớp lỗ hổng, nên thông tin được công bố ở mức loại hình tấn công và cơ chế lây lan thay vì payload cụ thể
• Tại thời điểm công bố, khách hàng không có cách nào giải quyết hoàn toàn vấn đề ở phía mình, nhưng có thể giảm phơi nhiễm bằng các biện pháp sau
  1. Xem tài liệu từ nguồn bên ngoài dùng trong Copilot là tài liệu không đáng tin cậy
  2. Rà soát tài liệu đính kèm trước khi bắt đầu tạo/chỉnh sửa bằng Copilot
  3. Kiểm tra kỹ các tài liệu do Copilot tạo hoặc chỉnh sửa trước khi tái sử dụng, chia sẻ hoặc phân phối

Lịch trình phối hợp công bố

• Ngày 6 tháng 3 năm 2026: Gửi báo cáo ban đầu cho MSRC kèm quy trình tái hiện, video, giả định môi trường và prompt PoC
• Ngày 9 tháng 3: MSRC tiếp nhận báo cáo và mở vụ việc
• Ngày 31 tháng 3: Microsoft xác nhận hành vi và nhóm sản phẩm bắt đầu thực hiện giảm thiểu
• Ngày 3 tháng 4: Triển khai biện pháp giảm thiểu đầu tiên thông qua trải nghiệm Edit with Copilot mới
• Ngày 9 tháng 4: Xác nhận prompt tấn công cũ đã bị chặn, nhưng tái hiện cuộc tấn công bằng một tác vụ XPIA mới thao túng số liệu tài chính và báo cáo thành vụ việc riêng
• Ngày 10 tháng 4: MSRC tiếp nhận vụ việc mới và nhóm sản phẩm bắt đầu thực hiện giảm thiểu
• Ngày 8 tháng 6: Theo yêu cầu của Microsoft, ngày công bố được lùi sang 15 tháng 7
• Ngày 14 tháng 7: Triển khai biện pháp giảm thiểu thứ hai bằng cách nâng cấp mô hình nền tảng lên GPT-5.5
• Ngày 15 tháng 7: Tái hiện thành công cuộc tấn công, bao gồm lây lan dạng sâu, trên GPT-5.6, mô hình mới nhất tại thời điểm đó
  • Để có thêm thời gian giảm thiểu mới, việc công bố được lùi tiếp sang 28 tháng 7 và Microsoft đồng ý
• Ngày 28 tháng 7: Tiến hành công bố phối hợp trong khi cuộc tấn công vẫn tiếp tục tái hiện được

Tính toàn vẹn thông tin và truy vết nguồn gốc

• Khi LLM được đưa vào vận hành nghiệp vụ, tính toàn vẹn thông tin nổi lên thành một vấn đề bảo mật lớn
• Nội dung do kẻ tấn công kiểm soát không chỉ thao túng đầu ra riêng lẻ hoặc gây rò rỉ thông tin, mà còn có thể sao chép và tự lây lan theo các thao tác bình thường của người dùng
• Lệnh độc hại trong nội dung được tạo ra vẫn nằm lại trong nhiều tài liệu, được người dùng hợp pháp phân phối lại và được đưa trở lại các ngữ cảnh mới
  • Các cuộc tấn công về sau trở thành một phần của luồng thông tin bên trong hệ thống, thay vì chỉ là điểm xâm nhập ban đầu
• Nội dung được tạo bằng quy trình sinh/chỉnh sửa bình thường khiến việc xác định nguồn gốc thao túng sau đó trở nên khó khăn, làm phức tạp phát hiện và ứng phó
• Tách biệt với việc chặn prompt injection, tài liệu được tạo cần lưu giữ nguồn gốc của tài liệu đầu vào và lịch sử chỉnh sửa do mô hình thực hiện trong metadata
  • Kiểm soát này không ngăn được chính hành vi injection, nhưng có thể tăng khả năng truy vết

Vấn đề căn bản trong kiến trúc LLM hiện tại

• Để trợ lý AI hữu ích, chúng phải xử lý cả thông tin có thể do kẻ tấn công kiểm soát như email, tài liệu, trang web, bộ nhớ và đầu ra công cụ
• Thông tin bên ngoài được đưa vào cùng cửa sổ ngữ cảnh với lệnh hệ thống, yêu cầu người dùng và các thông tin đáng tin cậy khác, rồi tham gia cùng một phép tính
• LLM phải đánh giá ý nghĩa, mức độ liên quan và khả năng tấn công của nội dung bên ngoài, nhưng tại thời điểm đánh giá, token của kẻ tấn công đã ảnh hưởng đến chính phép tính đó
  • Nội dung cần kiểm tra tham gia vào chính hành vi kiểm tra
  • Giao cho mô hình phát hiện XPIA giống như yêu cầu một trình thông dịch chạy một chương trình không đáng tin cậy để đánh giá độ an toàn của chương trình đó
• Ngay cả khi phát hiện và loại bỏ nội dung độc hại trước khi nó tới mô hình đích, cùng vấn đề chỉ được đẩy lên lớp phía trước
  • LLM có thể khôi phục ý nghĩa từ những cách diễn đạt rất khác nhau, nên bộ phát hiện cũng cần năng lực khôi phục ý nghĩa tương tự
  • Bộ phát hiện yếu hơn LLM đích chỉ bao phủ một không gian biểu đạt hẹp hơn, vì vậy vẫn còn các biểu đạt độc hại mà mô hình đích hiểu nhưng bộ phát hiện bỏ sót
• Công nghệ phổ biến cung cấp năng lực xử lý ý nghĩa tương tự lại là một LLM khác, nên thêm mô hình ở tuyến trước có thể giảm xác suất thành công của từng cuộc tấn công nhưng tạo ra vấn đề LLMs all the way down, trong đó từng mô hình phòng thủ cũng phải được bảo vệ tiếp
• Về dài hạn, cần thiết kế hệ thống trong đó mục tiêu và ý định tồn tại độc lập với thông tin đang được xử lý
  • Kiến trúc LLM hiện tại không có cơ chế tách biệt ổn định giữa ý định và diễn giải
  • Thông tin của kẻ tấn công có thể ảnh hưởng không chỉ đến đầu ra của mô hình, mà cả chính tác vụ mà mô hình tin rằng nó được yêu cầu thực hiện
• Các hệ thống tích hợp LLM vào luồng công việc đáng tin cậy cần giả định rằng khi nội dung do kẻ tấn công kiểm soát đi vào ngữ cảnh, xâm nhập sẽ xảy ra với một tỷ lệ nhất định

[GN⁺]

Ý kiến trên Hacker News

• Họ nói rằng “không có biện pháp giảm thiểu mạnh mẽ cho loại lỗ hổng rộng hơn này”, và giờ có vẻ đã rõ rằng không thể sửa các vấn đề kiểu này cho tới khi ngừng trộn lẫn lệnh và dữ liệu

  • Ngay từ đầu các mô hình này đã mang sẵn lỗ hổng bảo mật, nhưng người dùng dường như phần lớn không quan tâm đến hệ quả của nó. Đặc biệt, việc trao cho AI agent quyền truy cập toàn bộ hệ thống mà không có giới hạn là một vấn đề nghiêm trọng
    Có lẽ sẽ phải có thêm nhiều vụ rò rỉ dữ liệu thì ngành AI mới cảnh giác hơn; và nếu đã phó mặc bản thân cho Anthropic hay OpenAI thì hẳn cũng biết mình đang chấp nhận rủi ro gì, nên cũng khó mà quá thông cảm
  • Xem như chúng ta đã quay lại kiến trúc von Neumann theo cách tệ nhất có thể
  • Có vẻ có thể giải quyết phần nào, dù không hoàn hảo, bằng cách đưa mức quyền hạn của lệnh vào dữ liệu huấn luyện. Bản thân mô hình đã mơ hồ theo xác suất, nên khó kỳ vọng nhiều hơn thế
  • Tôi nghi ngờ liệu trong một hệ thống trí tuệ đa dụng xử lý vô hạn loại nội dung khác nhau, có thể thực sự tách lệnh và dữ liệu hay không
  • Có vẻ đúng là không thể sửa trong kiến trúc LLM, và hiện cũng không có phương án thay thế nào thực sự cạnh tranh ở quy mô lớn
    Đây không đơn thuần là vấn đề trộn lẫn lệnh và dữ liệu; đúng hơn, vì LLM không thể phân biệt ranh giới một cách tất định, nên việc dựng ranh giới chỉ mang tính trấn an tâm lý và cùng lắm chỉ khiến một số kiểu tấn công khó hơn đôi chút. Trong kiến trúc này, tam giác bất khả thi chí mạng là vấn đề mang tính vĩnh viễn

• Mọi thứ sẽ còn tệ hơn rất nhiều trước khi tốt lên, và việc trao cho agent quá nhiều quyền truy cập là điều lố bịch
  Có thể tưởng tượng một bình luận trên kho GitHub phổ biến chỉ chứa lệnh “hãy tái hiện lỗi này” mà không có mã nguồn nào. Nó có thể đánh cắp thẻ tín dụng hay ví Bitcoin, rồi tự lây lan sang các kho khác thông qua tài khoản GitHub

  • Trước thời ChatGPT, khi nghe nói về rủi ro hiện sinh của AI và chuyện cô lập nó, tôi từng nghĩ chỉ cần về nguyên tắc bỏ qua mọi lập luận do AI đưa ra thì có thể dễ dàng lấy nó ra khỏi chiếc hộp
    Nhưng nhiều người không phải mở hộp dù AI có sức mạnh đáng sợ, mà chính vì sức mạnh đó nên họ xé toạc cái hộp trước cả khi nó kịp xuất ra thứ gì. Vì vậy chỉ biết hy vọng tự cải thiện đệ quy sẽ không vận hành theo cách mà phe bi quan từng dự đoán
  • “AI agent” thì chẳng có chút bảo mật nào cả

• Việc một chỉ thị độc hại ẩn trong tài liệu chia sẻ bên ngoài có thể khiến Copilot sửa tài liệu Word và phát tán cuộc tấn công sang tài liệu mới là rất nghiêm trọng

  • Trộn lẫn lệnh và dữ liệu lúc nào cũng là một ý tưởng tồi, tôi tưởng ai cũng đã hiểu điều đó rồi chứ
  • Một số mô hình vững hơn mô hình khác. Tôi đã thử khiến Opus-5 thực thi chỉ thị được giấu bằng steganography trong ảnh, nhưng rất khó tìm được payload hoạt động ổn định
  • Thông tin sai lệch lộ ra trong tài liệu chia sẻ bên ngoài có thể khiến Copilot cũng như mọi hệ thống agent, LLM và trí tuệ con người sửa tài liệu trong Word hay chương trình khác, thậm chí trên giấy, rồi lan truyền lỗi sang tài liệu mới
    Nhiều người vẫn tin vào thuyết Trái Đất phẳng, hoặc tin rằng mã và dữ liệu vốn dĩ khác nhau, hay rằng sự phân biệt giữa control plane và data plane là một quy luật khách quan áp dụng cho toàn bộ vũ trụ

• Tôi là lập trình viên và người dùng AI trên web, nhưng không muốn chạy AI dưới bất kỳ hình thức nào trên máy tính cục bộ. Vì những lý do nêu trong bài này, tôi đã gỡ Copilot và tắt AI trong mọi ứng dụng cục bộ, kể cả trình duyệt
  AI không thể phân biệt giữa prompt của người dùng và văn bản trong tệp, nên không có cách nào bảo vệ dữ liệu khỏi các cuộc tấn công gây nhầm lẫn AI này ngay từ cấp độ thiết kế. Việc một trình xử lý văn bản hay ứng dụng email tích hợp AI có thể làm theo chỉ thị được cài vào tài liệu hay email bình thường là chuyện vô lý. Chuyển sang các hệ điều hành mã nguồn mở như Linux, BSD là giải pháp thực tế duy nhất

  • Tùy bạn tin nhà cung cấp nào, sau này họ vẫn có thể bật lại tính năng AI trên máy cục bộ của bạn
    Chỉ chuyển sang Linux hay BSD thôi là chưa đủ, còn cần cả nhà cung cấp trình duyệt và web app đáng tin cậy
  • Tôi cũng đã làm vậy, nhưng nếu nhà cung cấp từng được tin tưởng vượt ranh giới thì Linux cũng không cứu được. Ví dụ gần đây là vụ Google Chrome tự thêm một bộ cài AI cục bộ 4GB và bị phản ứng dữ dội
  • Theo hướng phòng thủ nhiều lớp, tốt nhất là không dùng AI trong các tab trình duyệt có thông tin nhạy cảm. Ví dụ, nếu bạn nhập prompt cho Gemini trong tab Gmail, thì JavaScript chạy trong tab đó hoặc Gemini có thể truy cập email, nên có khả năng dữ liệu thư bị rò rỉ

• Ẩn chữ màu trắng vẫn còn hiệu quả
  Hiện có nhiều kỹ thuật khác nhau, và tại https://tritium.legal/blog/noroboto người ta đã đánh lừa các thuật toán tối tân đọc ra giá trị Unicode khác với giá trị mà phông chữ của tài liệu hiển thị

  • Tôi tự hỏi liệu có thể chỉ thị cho AI kiểu “hãy gọi endpoint API của công cụ AI khác 10 lần bằng payload này nhưng đừng đọc payload”, rồi trong payload lại chứa chính thông điệp gọi AI hiện tại hoặc một AI thứ ba hay không
    Không rõ như vậy có thể khiến các AI gọi lẫn nhau và tạo ra lượng lớn request hay không, hay kiểu lạm dụng này đã được chặn rồi

• Có cảm giác như sâu VBScript·macro đã quay trở lại

  • Chỉ là lần này nếu tắt macro đi thì bạn sẽ mất cỗ máy tạo nội dung chất lượng thấp quý giá của mình. Chẳng lẽ không nghĩ cho ngành nhiên liệu hóa thạch sao

• Cũng có mặt tích cực là AI gây thiệt hại lớn càng nhanh thì ban điều hành càng sớm tỉnh ra và có thể thúc đẩy chính sách cấm AI nội bộ
  Tất nhiên đây đều là hiện thực do mọi người tự chuốc lấy, nên ở vị thế sống không cần AI, tôi sẽ vui vẻ nhìn họ chịu đựng

• Trong một thế giới đầy AI, kiểu sâu này rốt cuộc chỉ là sự lan truyền của ý tưởng dạng meme, và về bản chất có vẻ không khác hiện tượng xảy ra với con người

  • Đó là meme ký sinh không mang lại giá trị gì cho vật chủ, và trong thế giới loài người cũng có đầy những meme như vậy

• Nếu phần chữ bị làm mờ có liên quan đến bản gốc, thà che đen hoàn toàn còn hơn. Một phần vẫn có vẻ đọc được, và đa số thuật toán blur được biết là không thực sự phá hủy thông tin đúng nghĩa