Mật mã xác định ai có thể đọc tin nhắn trên đường truyền; kiểm soát truy cập và thiết kế tác tử xác định bên nhận có thể làm gì sau khi đọc.
Tấn công chèn chỉ dẫn (prompt injection) trong ứng dụng nhắn tin xảy ra khi nội dung một tin nhắn tìm cách khiến trợ lý AI bỏ qua các quy tắc chính và thực hiện một yêu cầu không được phép. Mã hóa đầu cuối bảo vệ tin nhắn trên đường truyền; nhưng nếu người dùng đã cho phép bot đọc cuộc trò chuyện hoặc thiết bị bị nhiễm mã độc, mã hóa không thể kiềm chế hành vi của bên nhận có quyền truy cập đó.
Những điểm chính
- Mã hóa đầu cuối ngăn việc đọc tin nhắn trên đường truyền, chứ không ngăn trợ lý ảo lạm dụng văn bản đã giải mã mà nó được phép xem.
- Chèn chỉ dẫn gián tiếp có thể ẩn trong tin nhắn riêng tư, tệp, chú thích hoặc nội dung trích dẫn và bị hiểu thành chỉ dẫn sau khi được xử lý.
- Nguy cơ rò rỉ dữ liệu từ tác tử AI tăng lên khi tác tử đồng thời có quyền truy cập cuộc trò chuyện, bộ nhớ, công cụ bên ngoài và khả năng gửi hoặc thực hiện thao tác.
- Tách dữ liệu khỏi chỉ dẫn, giảm thiểu quyền, yêu cầu con người xác nhận và giới hạn đầu ra là những lớp phòng vệ quan trọng; không lớp nào tự nó bảo đảm an toàn tuyệt đối.
- Theo tài liệu của Livara, trò chuyện trực tiếp và nhóm riêng tư tương thích có trạng thái E2EE đang bật được mã hóa đầu cuối; nhóm cũ không tương thích có thể nằm ngoài phạm vi bảo vệ này. Sự bảo vệ đó không bảo đảm hành vi của trợ lý sau khi nhận văn bản.
Chèn chỉ dẫn trong ứng dụng nhắn tin hoạt động như thế nào?
Chèn chỉ dẫn là việc kẻ tấn công tạo đầu vào khiến mô hình ngôn ngữ tiếp nhận nó như một chỉ dẫn thay vì dữ liệu, từ đó đi chệch chính sách ban đầu. Hướng dẫn của OWASP về chèn chỉ dẫn nêu cả đầu vào trực tiếp lẫn nội dung bên ngoài là những con đường dẫn đến rủi ro này. Trong hệ thống dựa trên tác tử, việc làm lệch câu trả lời còn có thể dẫn đến sử dụng ngoài ý muốn các công cụ đã kết nối.
Trong tấn công trực tiếp, chính người dùng yêu cầu bot bỏ qua các quy tắc trước đó. Trong tấn công gián tiếp, chỉ dẫn độc hại nằm trong nội dung mà trợ lý đọc để làm một việc khác: tin nhắn nhận được, văn bản trích dẫn, chú thích, tài liệu hoặc đầu ra của công cụ. Ở trường hợp thứ hai, kẻ tấn công không cần dùng chung tài khoản với tác tử AI; chỉ cần nội dung của họ lọt vào ngữ cảnh mà tác tử xử lý.
Ví dụ, người dùng yêu cầu trợ lý tóm tắt các tin nhắn mới. Một tin nhắn chứa văn bản giả làm “chỉ dẫn hệ thống”, yêu cầu tác tử dừng tóm tắt, lấy thông tin khác trong ngữ cảnh và gửi đến một đích bên ngoài. Kịch bản này không chắc chắn thành công mà phụ thuộc vào mô hình, thiết kế ứng dụng, quyền truy cập và các biện pháp kiểm soát đầu ra. Tuy nhiên, chỉ riêng khả năng đó đã có ý nghĩa về bảo mật đối với trợ lý có công cụ.
Cần phân biệt việc thao túng câu trả lời của mô hình với tấn công tác tử có khả năng hành động. Một câu trả lời sai có thể gây phiền toái; tác tử được phép gửi tin nhắn, truy xuất tệp hoặc gọi dịch vụ có thể biến chính sự thao túng đó thành việc tiết lộ dữ liệu hay hành động ngoài ý muốn.
Vì sao bảo mật chatbot AI không chỉ phụ thuộc vào mã hóa?
Bảo mật chatbot AI phụ thuộc vào toàn bộ chuỗi tin cậy: ứng dụng nhắn tin, thiết bị, mô hình, bộ nhớ, công cụ, máy chủ của nhà cung cấp và chính sách cấp quyền. Mã hóa đầu cuối chỉ bảo vệ một ranh giới cụ thể: ngăn việc đọc nội dung riêng tư trên đoạn đường giữa người gửi và các bên nhận được phép.
Khi tin nhắn đến thiết bị được phép, nó được giải mã để hiển thị cho người dùng. Nếu trợ lý có quyền truy cập văn bản trên cùng thiết bị hoặc qua một kết nối được cho phép, nó sẽ thấy dữ liệu sau khi giải mã. Xét theo giao thức, bot hoặc ứng dụng có quyền có thể là bên nhận hợp lệ; xét theo người dùng, chính bên nhận đó có thể được trao quá nhiều quyền hạn.
Có thể tóm tắt sự khác biệt như sau: mật mã xác định ai có thể đọc tin nhắn trên đường truyền; kiểm soát truy cập và thiết kế tác tử xác định bên nhận có thể làm gì sau khi đọc. Để hiểu ranh giới thứ nhất, hướng dẫn Mã hóa đầu cuối và những gì nó không bảo vệ giải thích rằng E2EE không phải giải pháp cho mã độc, bên nhận không đáng tin hoặc màn hình bị xâm nhập.
Cụm từ “ứng dụng nhắn tin mã hóa và trí tuệ nhân tạo” cũng không nên tự động được hiểu là an toàn hoặc không an toàn. Một tác tử chạy cục bộ, không có bộ nhớ lâu dài và không có công cụ đầu ra không có cùng mức rủi ro với bot đám mây có quyền truy cập lịch sử, tệp và tài khoản bên ngoài. Kiến trúc và phạm vi quyền quyết định kết quả.
Trợ lý AI truy cập cuộc trò chuyện riêng tư tạo ra rủi ro gì?
Việc trợ lý AI truy cập cuộc trò chuyện riêng tư đưa nội dung trước đây chỉ những người tham gia mới thấy vào một ranh giới tin cậy mới. Rủi ro chính là ngoài việc đọc văn bản, trợ lý còn có thể lưu giữ, kết hợp với dữ liệu khác hoặc đưa nó ra ngoài qua một kênh khác.
Trước khi bật tính năng như vậy, cần trả lời rõ năm câu hỏi:
- Chính xác trợ lý đọc những cuộc trò chuyện, tệp đính kèm và khoảng thời gian nào?
- Việc xử lý diễn ra trên thiết bị hay nội dung được gửi đến một máy chủ khác?
- Nhà cung cấp lưu giữ dữ liệu gì và có dùng dữ liệu đó để huấn luyện không?
- Tác tử có những công cụ nào để gửi tin nhắn, tải tệp lên, tìm kiếm hoặc thực hiện thao tác?
- Mỗi hành động nhạy cảm có cần người dùng xác nhận rõ ràng không?
Quyền “đọc mọi cuộc trò chuyện” cho một tính năng chỉ cần tóm tắt một tin nhắn được chọn là vi phạm nguyên tắc đặc quyền tối thiểu. Nguyên tắc này nghĩa là mỗi thành phần chỉ nhận mức truy cập tối thiểu cần thiết cho nhiệm vụ hiện tại. Quyền giới hạn trong một tin nhắn, một cuộc trò chuyện và một lượt làm giảm phạm vi thiệt hại; tuy vậy, nội dung trong phạm vi đó vẫn có thể mang theo tấn công.
Siêu dữ liệu cũng khác với nội dung. Theo tài liệu của Livara, siêu dữ liệu vận hành như người gửi, đích nhận và thời điểm chuyển phát được lưu để định tuyến và đồng bộ hóa. Hướng dẫn Siêu dữ liệu của ứng dụng nhắn tin và những thông tin chúng tiết lộ giải thích ranh giới này. Ngoài văn bản, trợ lý còn có thể suy luận từ mẫu liên lạc và thời gian giao tiếp; vì vậy, chính sách truy cập phải tính đến cả hai.
Dữ liệu có thể rò rỉ từ tác tử AI qua những con đường nào?
Rò rỉ dữ liệu từ tác tử AI thường xảy ra khi tác tử thấy nội dung mật trong ngữ cảnh và có cách chuyển nó đến một đích khác. Chèn chỉ dẫn tự nó không di chuyển dữ liệu; rò rỉ phụ thuộc vào sự kết hợp giữa đầu vào độc hại, quyền truy cập dữ liệu và một kênh đầu ra.
Tin nhắn hoặc tệp đầu ra
Tác tử có thể đưa thông tin vào câu trả lời, tin nhắn mới, bản nháp, tệp hoặc yêu cầu gửi đến dịch vụ bên ngoài. Nếu hệ thống gửi đầu ra mà không có giới hạn hoặc xác nhận của người dùng, kẻ tấn công có thể tìm cách biến dữ liệu mật thành một dạng có vẻ bình thường.
Bộ nhớ dài hạn
Một số tác tử lưu bản tóm tắt cuộc trò chuyện, tùy chọn hoặc kết quả trước đó để dùng về sau. Chỉ dẫn độc hại có thể tìm cách đưa dữ liệu vào bộ nhớ hoặc truy xuất dữ liệu đó trong một phiên khác. Thời gian lưu ngắn, tách biệt người dùng và khả năng xem, xóa bộ nhớ giúp giảm rủi ro nhưng không loại bỏ lỗi của mô hình.
Gọi công cụ
Tác tử có công cụ có thể tìm kiếm, đọc tệp hoặc thực hiện những thao tác được phép khác. Đọc tệp, gửi tin nhắn và gửi yêu cầu mạng phải có quyền riêng biệt. Ngay cả việc tự động hiển thị liên kết hoặc tải tài nguyên bên ngoài trong đầu ra cũng có thể tạo đường đưa dữ liệu ra ngoài; chỉ không có nút “Gửi” là chưa đủ.
Thiết bị bị nhiễm mã độc
Mã độc có đủ quyền truy cập có thể thấy văn bản hiển thị, thông báo, bộ nhớ ứng dụng hoặc dữ liệu người dùng nhập. Trong tình huống này, kẻ tấn công không nhất thiết phải phá mã hóa mà đi vòng qua nó ở điểm cuối. Bảo vệ hệ điều hành, cập nhật, kiểm soát truy cập và kiểm tra ứng dụng đã cài là các phần của phòng vệ, không phải tính năng của giao thức nhắn tin.
Mật mã của Livara có giới hạn gì trước mối đe dọa này?
Trong tài liệu bảo mật của Livara, LVR1 được mô tả dành cho trò chuyện trực tiếp và LGS1 dành cho nhóm riêng tư tương thích. Nhóm cũ không tương thích có thể được xác định rõ là nằm ngoài E2EE; cần kiểm tra trạng thái của chính cuộc trò chuyện đó. Các kênh công khai cũng không thuộc phạm vi trò chuyện riêng tư E2EE.
Ngay cả trong cuộc trò chuyện E2EE, nếu người dùng cung cấp văn bản đã giải mã cho trợ lý, mã hóa tin nhắn không kiểm soát mục đích xử lý tiếp theo. Kiểm tra số an toàn cũng nhằm xác minh khóa của người liên hệ, chứ không phát hiện chỉ dẫn độc hại trong văn bản của họ. Bài viết này nói về một nhóm rủi ro chung và không xác nhận sự tồn tại hay độ an toàn của một tích hợp AI cụ thể trong Livara.
Đây là hình minh họa khái niệm, không phải kiến trúc Livara đã được xác minh; những ổ khóa trong hình không chứng minh rằng trợ lý không thể truy cập văn bản được chọn.
Kiến trúc nào hạn chế chèn chỉ dẫn trong ứng dụng nhắn tin?
Kiến trúc an toàn phải xem tin nhắn nhận được là dữ liệu không đáng tin cậy, ngay cả khi đến từ người liên hệ quen biết và nằm trong cuộc trò chuyện mã hóa. Mã hóa tăng cường tính xác thực của đường truyền, nhưng không chứng minh rằng nội dung của người gửi vô hại khi được thực thi tự động.
Tách dữ liệu khỏi chỉ dẫn
Ứng dụng phải giữ chỉ dẫn cố định của nhà phát triển, yêu cầu rõ ràng của người dùng và nội dung đọc từ cuộc trò chuyện ở các lớp riêng biệt. Cảnh báo của NCSC về chèn chỉ dẫn nhấn mạnh rằng không nên coi vấn đề này giống SQL injection với một giải pháp dứt điểm tương tự. Gắn nhãn nội dung là “dữ liệu không đáng tin cậy” có ích, nhưng mô hình ngôn ngữ không phải lúc nào cũng tuân thủ ranh giới ngữ nghĩa đó một cách chính xác; vì vậy, sự tách biệt phải đi kèm kiểm soát bên ngoài mô hình.
Giảm quyền hạn của tác tử
Tác tử tóm tắt không cần khả năng tự động gửi tin nhắn hay đọc mọi tệp. Công cụ phải có danh sách cho phép, phạm vi hẹp, thông tin xác thực riêng và thời hạn ngắn. Quyền dùng một lần cho nội dung được chọn tốt hơn quyền truy cập thường trực, vì giảm cả khả năng truy cập ngoài ý muốn lẫn phạm vi rò rỉ.
Kiểm tra đầu ra tại cổng kiểm soát xác định
Mô hình không nên tự đưa ra quyết định cuối cùng về việc gửi dữ liệu nhạy cảm. Một lớp không sinh nội dung có thể kiểm tra đích nhận, loại dữ liệu, lượng đầu ra và thao tác được yêu cầu theo các quy tắc xác định. Quy tắc về cấu trúc và danh sách đích được phép phải được thực thi bên ngoài mô hình; việc nhận diện ngữ nghĩa của mọi thông tin mật vẫn có thể sai. Cũng cần ghi nhật ký sự kiện tối thiểu, cảnh báo và khả năng dừng.
Yêu cầu con người xác nhận hành động nhạy cảm
Đọc bản nháp không giống gửi bản nháp đó. Gửi tin nhắn, chia sẻ tệp, thêm thành viên, thay đổi cài đặt tài khoản hoặc chuyển dữ liệu đến dịch vụ bên ngoài phải có bản xem trước rõ ràng và sự xác nhận sau khi đã hiểu đầy đủ. Các yêu cầu xác nhận mơ hồ hoặc quá thường xuyên sẽ biến thành thói quen bấm nút; giao diện phải thể hiện chính xác dữ liệu, đích nhận và hệ quả.
Chạy tác tử trong môi trường bị giới hạn
Cách ly tiến trình, mặc định ngắt quyền truy cập mạng, lưu trữ tạm thời và thông tin xác thực có phạm vi hẹp giúp giới hạn tác động khi xảy ra lỗi. Những biện pháp này không loại bỏ chèn chỉ dẫn; chúng ngăn một câu trả lời bị làm lệch trực tiếp biến thành quyền truy cập rộng.
Người dùng và quản trị viên nên làm gì để bảo vệ chatbot AI?
Người dùng nên xem mỗi kết nối AI là một bên nhận mới của dữ liệu riêng tư. Quản trị viên cũng phải kiểm tra luồng dữ liệu và thao tác của tác tử trước khi triển khai, đồng thời giám sát khi vận hành.
Đối với sử dụng cá nhân:
- Chỉ chọn tin nhắn hoặc tệp cần thiết; không cấp quyền truy cập toàn bộ lịch sử.
- Kiểm tra nơi xử lý, thời hạn lưu giữ, việc sử dụng để huấn luyện và cách xóa dữ liệu.
- Giữ chức năng tự động gửi tin nhắn hoặc tệp ở trạng thái tắt, trừ khi có nhu cầu rõ ràng.
- Cập nhật thiết bị, trình duyệt và ứng dụng, đồng thời rà soát các quyền nhạy cảm.
Đối với tổ chức:
- Xây dựng một mô hình đe dọa bao quát riêng từng trường hợp: người gửi ác ý, thành viên nhóm không trung thành, dịch vụ mô hình, công cụ bên ngoài và thiết bị nhiễm mã độc.
- Ghi lại các lần gọi công cụ, thay đổi quyền, đích đầu ra và xác nhận của người dùng với lượng dữ liệu nhạy cảm tối thiểu cần thiết.
- Thử nghiệm đầu vào đối kháng trong tin nhắn, tài liệu, văn bản trích dẫn, ảnh chứa chữ và nội dung được truy xuất.
- Đặt giới hạn thao tác, tần suất yêu cầu, các đích được phép và cơ chế ngắt khẩn cấp cho từng tác tử.
- Mặc định dừng an toàn: nếu chính sách không rõ ràng, tác tử phải dừng thay vì phỏng đoán.
Không danh sách nào tạo ra sự an toàn tuyệt đối. Kết quả phụ thuộc vào cách triển khai, mô hình, cài đặt, hành vi người dùng và sự phát triển của phương thức tấn công. Mục tiêu của phòng vệ tốt là giảm quyền hạn, làm lộ rõ sai lệch và giới hạn thiệt hại.
Ứng dụng nhắn tin mã hóa và AI có thể cùng an toàn không?
Có, ứng dụng nhắn tin mã hóa và AI có thể hoạt động cùng nhau với rủi ro được kiểm soát, với điều kiện trợ lý có quyền truy cập tối thiểu và không thực hiện hành động nhạy cảm khi chưa có xác nhận. Tuy nhiên, kết nối bất kỳ mô hình nào với nội dung riêng tư đều tạo ra ranh giới tin cậy mới và không nên bị che khuất dưới nhãn E2EE.
Thiết kế ít rủi ro hơn giữ việc xử lý trên thiết bị ở mức tối đa có thể, giới hạn ngữ cảnh trong phần người dùng chủ động chọn, duy trì bộ nhớ ngắn hạn và tách riêng công cụ đầu ra. Xử lý cục bộ cũng không phải bảo đảm tuyệt đối: thiết bị bị nhiễm mã độc, mô hình không an toàn hoặc quyền quá rộng vẫn tạo rủi ro.
Người dùng phải có thể hiểu dữ liệu nào được đưa vào mô hình, mô hình chạy ở đâu, lưu giữ thông tin bao lâu và có thể làm gì. Nếu sản phẩm không trả lời rõ những câu hỏi này, không nên suy ra kết luận chắc chắn về bảo mật từ những cụm từ như “AI riêng tư”.
Tài liệu giao thức hoặc việc mã băm của ứng dụng khớp nhau không phải là kiểm thử bảo mật của trợ lý được kết nối. Trước khi bật kết nối, hãy kiểm tra riêng quyền và đường đi dữ liệu của chính tính năng đó. Kết quả của một lần thử thành công cũng không tự nó bao quát mọi đầu vào trong tương lai.
Câu hỏi thường gặp
Mã hóa đầu cuối có ngăn chặn chèn chỉ dẫn không?
Không. Mã hóa đầu cuối che giấu tin nhắn khỏi các bên trung gian giữa người gửi và các bên nhận được phép. Nếu bot được cấp quyền, ứng dụng trên thiết bị hoặc mã độc truy cập được văn bản đã giải mã, chúng có thể xử lý nó. Hạn chế chèn chỉ dẫn đòi hỏi giới hạn quyền, công cụ, bộ nhớ và đầu ra của tác tử.
Dùng AI tóm tắt cuộc trò chuyện riêng tư có nguy hiểm không?
Rủi ro phụ thuộc vào kiến trúc. Tóm tắt cục bộ một tin nhắn được chọn, không có bộ nhớ và công cụ đầu ra, có phạm vi rủi ro nhỏ hơn bot đám mây được truy cập thường trực mọi cuộc trò chuyện. Trước khi dùng, hãy kiểm tra nơi xử lý, việc lưu giữ dữ liệu, phạm vi quyền và khả năng tự động gửi.
Tin nhắn từ người liên hệ quen biết có thể chứa chèn chỉ dẫn không?
Có. Tin vào danh tính người gửi không đồng nghĩa với tin vào mọi nội dung của họ; tài khoản có thể đã bị chiếm đoạt hoặc họ vô tình chuyển tiếp văn bản độc hại. Mọi nội dung tác tử đọc phải được xem là dữ liệu không đáng tin cậy, ngay cả trong cuộc trò chuyện đã xác thực và mã hóa.
LVR1 và LGS1 có che giấu thông tin khỏi trợ lý AI không?
Trong các cuộc trò chuyện thực sự được bảo vệ bằng LVR1 hoặc LGS1 với trạng thái E2EE đang bật, mục đích của những giao thức này là che giấu nội dung khỏi bên trung gian không có khóa. Nếu người dùng hoặc ứng dụng cho phép trợ lý đọc tin nhắn đã giải mã, những giao thức này không chặn quyền truy cập được cho phép đó. Vì vậy, bảo mật của trợ lý phải được đánh giá tách biệt với bảo mật truyền tin nhắn.
Bước đầu tiên để giảm rò rỉ dữ liệu từ tác tử AI là gì?
Trước tiên, thu hẹp phạm vi truy cập của tác tử: chỉ tin nhắn được chọn, chỉ trong lượt đó và không có khả năng tự động gửi. Sau đó, bổ sung bản xem trước và xác nhận của con người cho thao tác nhạy cảm, giới hạn đích đầu ra và ghi nhật ký các lần gọi công cụ. Các lớp này giảm rủi ro nhưng không tạo ra bảo đảm tuyệt đối.
