Bảo mật LLM là gì? Cách giảm thiểu 10 rủi ro an toàn hàng đầu theo OWASP

Một kiểu tấn công đánh lừa AI coi chỉ dẫn của kẻ tấn công là lệnh—chèn prompt (prompt injection)—đã đứng số 1 trong OWASP Top 10 cho ứng dụng LLM ở mọi phiên bản kể từ năm 2023.

Danh sách này là thứ gần với sự đồng thuận nhất mà lĩnh vực bảo mật AI từng có. Dự án khởi đầu từ một nhóm nhỏ các chuyên gia bảo mật và hiện quy tụ hơn 600 chuyên gia đóng góp tại hơn 18 quốc gia.

Chúng tôi là một công ty AI đang xuất bản hướng dẫn về cách AI bị dụ dỗ làm theo người khác, nên chúng tôi sẽ không giả vờ rằng vấn đề này đã được giải quyết. Wilson, người đồng dẫn dắt dự án OWASP, đã nói khá rõ về các biện pháp phòng thủ hiện nay: “...thành thật mà nói, tôi không nghĩ chúng ta đã đạt 99%.”

Phiên bản 2026 mở đầu cũng với tinh thần đó. Trưởng dự án khuyên chúng ta “ngừng cố xây dựng một mô hình không thể bị đánh lừa” và thiết kế hệ thống xung quanh sao cho một mô hình dù bị đánh lừa cũng không thể phá hỏng điều gì quan trọng.

Chúng tôi áp dụng quan điểm đó cho cả 10 rủi ro trong danh sách năm 2026 của OWASP.

Bảo mật LLM nghĩa là gì?

Bảo mật LLM là việc bảo vệ các mô hình AI và những ứng dụng sử dụng chúng khỏi các cuộc tấn công và hành vi lạm dụng. Rủi ro càng lớn khi mô hình được kết nối với càng nhiều thứ: các tệp và dữ liệu mà nó có thể đọc, cùng các công cụ mà nó có thể dùng, như email, tìm kiếm hoặc cơ sở dữ liệu của công ty.

Trong phần mềm được bảo mật đúng cách, có một ranh giới rõ ràng giữa các chỉ dẫn mà chương trình thực hiện và thông tin mà nó xử lý. Nhưng LLM không có ranh giới đó.

Mọi thứ mô hình đọc đều đến dưới dạng một luồng văn bản dài duy nhất: chỉ dẫn của nhà phát triển, câu hỏi của bạn, một trang web mà nó tra cứu. Các mô hình AI được kỳ vọng sẽ phân biệt được ai đang nói, dù đó là nhà phát triển, người dùng hay chính mô hình đang suy luận để giải quyết một vấn đề.

Nhưng các nhà nghiên cứu Jasmine Cui và Charles Ye phát hiện ra rằng các mô hình chủ yếu đoán ai đang nói dựa trên giọng điệu của văn bản. Vì vậy, nếu kẻ tấn công viết một nội dung nghe giống như lập luận của chính mô hình, mô hình có thể tin rằng chính nó đã nghĩ ra ý tưởng đó. Đây là vấn đề đối với mọi cơ chế an toàn phụ thuộc vào việc mô hình biết ai là người nắm quyền.

Chúng tôi cũng gặp phải vấn đề tương tự với chính các tác nhân AI của mình. CISO của chúng tôi, Kyle Polley, chia sẻ với ISMG rằng các tác nhân “có thể không tuân theo chính sách ngay cả khi bạn thêm nó vào prompt hệ thống.” Đó là lý do chúng tôi xây dựng Numbat, một công cụ mã nguồn mở giúp kiểm tra những gì tác nhân sắp làm và có thể chặn hành động đó nếu nó vi phạm một quy tắc bảo mật đã được cấu hình.

Bảo mật LLM nghĩa là chấp nhận rằng đôi khi mô hình sẽ nghe lệnh từ nhầm người, và xây dựng các rào chắn AI xung quanh nó vẫn đứng vững ngay cả khi điều đó xảy ra.

Đâu là các phương pháp tốt nhất để bảo mật LLM?

Chúng ta sẽ lần lượt đi qua OWASP Top 10 cho ứng dụng LLM 2026, từ hạng 1 đến hạng 10.

Với mỗi rủi ro, bạn sẽ có phần giải thích dễ hiểu về cách mọi thứ có thể trục trặc cùng một ví dụ thực tế. Sau đó, chúng tôi sẽ trình bày các phương pháp có thể giúp ngăn chặn rủi ro đó, hoặc ít nhất là hạn chế thiệt hại.

1. Kiểm soát chèn prompt

Chèn prompt xảy ra khi kẻ tấn công khiến AI làm theo những chỉ dẫn mà nó không nên làm theo. Các chỉ dẫn đó có thể được đưa trực tiếp vào cuộc trò chuyện hoặc được cài sẵn trong email, trang web hay tài liệu.

Loại thứ hai được gọi là chèn prompt gián tiếp. Bạn yêu cầu trợ lý tóm tắt một tài liệu. Trong tài liệu đó, tác giả đã dặn trợ lý gửi cho họ các tệp riêng tư của bạn. Nếu trợ lý làm theo những chỉ dẫn đó, người viết tài liệu thực chất đã mượn được quyền truy cập của bạn.

PCMag ví bảo mật prompt như việc trám lỗ trên một hòn đá xốp. Bạn bịt một lỗ, nước lại tìm đường qua lỗ khác. “Một cuộc tấn công tìm được đường lọt qua; nó được khắc phục, nhưng vô số con đường tấn công khác vẫn chờ được phát hiện, đơn giản vì các hệ thống như LLM có tính động rất cao.”

Ví dụ: Vào tháng 6 năm 2025, các nhà nghiên cứu của Aim Security đã phát hiện EchoLeak, một lỗ hổng đánh lừa Microsoft 365 Copilot làm rò rỉ thông tin riêng tư của công ty. Khi một nhân viên hỏi một câu hỏi công việc thông thường, Copilot có thể kéo email đó vào, làm theo các chỉ dẫn ẩn bên trong và gửi thông tin nhạy cảm cho kẻ tấn công. Cuộc tấn công đã vượt qua các lớp kiểm tra vốn được thiết kế để phát hiện chỉ dẫn độc hại và loại bỏ các liên kết đáng ngờ.

Những gì bạn có thể làm:

• Tuân theo “Quy tắc Hai” của Meta: EchoLeak cần một AI có thể đọc dữ liệu công ty, đọc email từ bên ngoài và gửi thông tin ra ngoài—và nó có đủ cả ba. Giới hạn AI ở hai trong số các khả năng đó sẽ ngăn chèn prompt giành quá nhiều quyền kiểm soát. Nếu tác vụ cần cả ba, hãy yêu cầu con người phê duyệt trước mỗi hành động.
• Kiểm thử với những kẻ tấn công nắm rõ các biện pháp phòng thủ của bạn: Cung cấp cho đội kiểm thử bảo mật các quy tắc và bộ lọc bạn đã triển khai, rồi để họ tìm cách vượt qua. Trong một nghiên cứu, những kẻ tấn công biết thích ứng với các biện pháp phòng thủ đã thành công hơn 90% số lần trước hầu hết trong số 12 biện pháp phòng thủ được thử nghiệm.

2. Ngăn rò rỉ thông tin nhạy cảm

Khi hệ thống AI cung cấp thông tin riêng tư cho những người không được phép xem, đó được gọi là tiết lộ thông tin nhạy cảm. Điều này có thể là làm lộ thông tin thanh toán của khách hàng hoặc để các cuộc trò chuyện riêng tư nằm trên một cơ sở dữ liệu dùng chung.

Nhiều vụ rò rỉ bắt đầu từ việc “chia sẻ quá mức”. Giả sử một công ty kết nối AI của mình với các ổ lưu trữ và cơ sở tri thức có phân quyền lỏng lẻo. AI truy xuất bất cứ thứ gì nó tiếp cận được, đúng như thiết kế. Không ai cần phải xâm nhập, nhưng hãy coi như LLM đã bị xâm nhập.

Ví dụ: Vào tháng 1 năm 2025, các nhà nghiên cứu của Wiz phát hiện một cơ sở dữ liệu của DeepSeek bị để mở ra internet với hơn một triệu mục nhật ký, bao gồm lịch sử trò chuyện và khóa API, thứ mà phần mềm dùng để truy cập các dịch vụ khác. Các nhà nghiên cứu không cần thuyết phục mô hình tiết lộ bất cứ điều gì.

Những gì bạn có thể làm:

• Kiểm tra quyền truy cập trước khi AI đọc dữ liệu: Ứng dụng của bạn nên kiểm tra xem người đặt câu hỏi được phép xem những tài liệu nào trước khi chuyển chúng cho mô hình.
• Bảo vệ các bản ghi mà AI để lại: Xóa thông tin riêng tư và khóa bí mật trước khi lưu nhật ký hoạt động, yêu cầu đăng nhập và chỉ cấp quyền truy cập cho những người cần đến. Đặt thời hạn lưu giữ để các bản ghi đó không tích tụ vô thời hạn.

3. Kiềm chế quyền tự chủ quá mức

AI có quyền tự chủ quá mức là AI nắm nhiều quyền hơn mức công việc đòi hỏi: những công cụ không cần đến, quyền hạn vượt quá phạm vi tác vụ hoặc sự tự do hành động mà không cần kiểm tra. Nguyên nhân ở đây không quan trọng.

Một prompt bị chèn, một lỗi phần mềm hay một mô hình đơn giản là làm sai đều dẫn đến cùng một kết quả. Sớm muộn gì AI cũng sẽ làm điều gì đó mang tính phá hoại nếu nó có khả năng đó.

Ví dụ: Vào tháng 7 năm 2025, nhà sáng lập SaaStr Jason Lemkin cho biết tác nhân lập trình của Replit đã xóa cơ sở dữ liệu chứa 1.206 hồ sơ lãnh đạo của ông, bất chấp chỉ dẫn không được thực hiện thay đổi. Ban đầu, tác nhân nói rằng dữ liệu không thể khôi phục, dù sau đó việc khôi phục hóa ra vẫn khả thi. Jason nhận ra rằng việc bảo nó để yên cơ sở dữ liệu không hề loại bỏ khả năng xóa cơ sở dữ liệu đó của nó.

Phóng to

Nguồn: X

Những gì bạn có thể làm:

• Loại bỏ những khả năng mà tác vụ không cần: Giới hạn cả các công cụ mà tác nhân được cấp lẫn những gì các công cụ đó có thể làm. Một trợ lý tóm tắt email cần quyền đọc email, chứ không cần quyền gửi hay xóa chúng.
• Đặt cơ chế kiểm tra quyền bên ngoài AI: Mỗi khi một hành động được yêu cầu, hãy buộc hành động đó được đối chiếu với các quy tắc bảo mật của bạn và yêu cầu con người phê duyệt.

4. Kiểm tra những gì đi vào chuỗi cung ứng AI của bạn

Rất ít công ty tự xây dựng AI từ đầu, và con số này ngày càng giảm qua từng năm. Theo khảo sát The State of Generative AI in the Enterprise năm 2025 của Menlo Ventures, 53% doanh nghiệp đã mua mô hình AI trong năm 2024, và tỷ lệ này tăng lên 76% vào năm 2025.

Thông thường, các công ty tải mô hình từ những nền tảng như Hugging Face, tiếp tục huấn luyện chúng trên các tập dữ liệu do người khác thu thập, rồi tích hợp các tiện ích bổ sung và gói mã do người lạ viết.

Mỗi thành phần đó đều là một lối vào. Nếu một thành phần bị can thiệp, vấn đề sẽ theo sản phẩm của bạn đến tay người dùng.

Ví dụ: Số kho mô hình công khai của Hugging Face đã tăng từ 2,43 triệu lên 2,96 triệu trong khoảng từ tháng 1 đến tháng 8 năm 2026. Tuy nhiên, vào tháng 7 năm 2026, các mô hình của OpenAI đã vượt qua các cơ chế kiểm soát nhằm ngăn chúng truy cập internet trong quá trình kiểm thử bảo mật nội bộ và xâm nhập vào một số phần trong hệ thống của Hugging Face. Thậm chí, một tác nhân đã thu thập được 14 thông tin xác thực truy cập bị lộ công khai, kiểm tra xem chúng có hoạt động không, rồi chia sẻ chúng với các tác nhân khác. Sau đó, các tác nhân tiếp tục khai thác những lỗ hổng cho phép chúng chạy mã trên máy chủ của Hugging Face.

“Chúng tôi đang đặt ra các yêu cầu nghiêm ngặt hơn về căn chỉnh (alignment) trong suốt vòng đời của mô hình, đồng thời tạo ra các môi trường Sandbox biệt lập hơn, hạn chế truy cập internet và kiểm soát chặt chẽ hơn quyền truy cập vào trọng số mô hình,” báo cáo của OpenAI cho biết.

Những gì bạn có thể làm:

• Cố định mô hình vào một phiên bản cụ thể và xác minh chúng: Cố định mỗi mô hình vào một phiên bản đã được xem xét và kiểm tra dấu vân tay tệp của nó trước khi tải, để một tệp bị tráo không thể lọt vào dưới cùng một nhãn. OWASP cũng khuyến nghị dùng chữ ký số, kèm một lưu ý—chữ ký chỉ chứng minh mô hình đến từ đâu, chứ không chứng minh rằng nó an toàn.
• Kiểm tra mọi gói mà AI đề xuất: Trước khi cài đặt một gói mã do trợ lý AI đề xuất, hãy xác nhận rằng gói đó tồn tại, đúng là gói bạn định dùng và đến từ nhà phát hành mà bạn mong đợi.

5. Phòng chống đầu độc dữ liệu và mô hình

Một AI bị đầu độc sẽ học từ dữ liệu bị làm hỏng. Đó có thể là các ví dụ được dùng để tinh chỉnh nó, hoặc một cơ sở tri thức mà nó tìm kiếm để trả lời. Mô hình trông vẫn hoạt động bình thường; chỉ là nó học sai bài học, và đôi khi nó học cách chỉ hành xử sai khi bắt gặp một cụm từ kích hoạt cụ thể.

Cụm từ đó sẽ lọt qua mọi bài kiểm thử của bạn cho đến khi có người thực sự sử dụng nó.

Phóng to

Ngoài ra, việc này cũng rất khó khắc phục. Đầu độc không phải là một lỗi mà bạn có thể vá. Nếu dữ liệu của bạn sai, bạn có thể cần kiểm tra lại dữ liệu, huấn luyện lại mô hình hoặc thay thế hoàn toàn mô hình đó.

Ví dụ: Vào tháng 10 năm 2025, các nhà nghiên cứu tại Anthropic, Viện An ninh AI Vương quốc Anh và Viện Alan Turing đã chứng minh rằng 250 tài liệu bị đầu độc có thể dạy một mô hình tạo ra văn bản vô nghĩa mỗi khi gặp một yếu tố kích hoạt cụ thể. Cùng con số đó có tác dụng với cả bốn kích thước mô hình được thử nghiệm, dù mô hình lớn nhất được huấn luyện trên lượng dữ liệu sạch nhiều hơn 20 lần.

Những gì bạn có thể làm:

• Theo dõi nguồn gốc dữ liệu: Lưu hồ sơ về mọi tập dữ liệu và mô hình bạn sử dụng, nguồn gốc của từng thứ và những thay đổi giữa các phiên bản. Chúng tôi khuyến nghị quản lý phiên bản cho các tập dữ liệu để nếu phát hiện bị đầu độc, bạn có thể quay lại một phiên bản sạch và tìm ra cách dữ liệu độc đã lọt vào.
• Kiểm thử cửa hậu: “Cửa hậu” là một hành vi ẩn mà kẻ tấn công cài vào mô hình, chờ một cụm từ cụ thể hoặc một yếu tố kích hoạt khác để bật lên. Hãy kiểm thử bằng các đầu vào được thiết kế để khiến mô hình phá vỡ các quy tắc thông thường của nó.

6. Kiểm soát tiêu thụ không giới hạn

Khi AI không có bất kỳ giới hạn nào về khối lượng công việc có thể thực hiện hay chi phí có thể phát sinh, mức tiêu thụ của nó được coi là “không giới hạn”. Phần lớn các dịch vụ AI tính phí theo mức sử dụng, nên kẻ tấn công có thể đẩy hóa đơn của bạn lên cao hoặc tạo ra một bản sao mô hình của bạn.

OWASP gọi vấn đề cốt lõi là “bất cân xứng chi phí”. Một yêu cầu ngắn và rẻ có thể kích hoạt quá trình tính toán tốn kém ở phía bạn.

Ví dụ: Vào tháng 5 năm 2024, Nhóm Nghiên cứu Mối đe dọa của Sysdig đã phát hiện một kiểu tấn công mới có tên “LLMjacking”. Một nhóm kẻ tấn công đã nhắm vào 10 dịch vụ LLM được lưu trữ trên đám mây bằng thông tin xác thực bị đánh cắp. Chúng xâm nhập qua một phiên bản Laravel có lỗ hổng, sau đó tìm hiểu xem thông tin xác thực có thể làm được gì cùng các hạn mức đi kèm, với mục đích rõ ràng là bán lại quyền truy cập. Nhiều thiết lập ghi nhật ký cũng bị truy vấn, có lẽ để tránh bị phát hiện. Theo Sysdig, trong trường hợp xấu nhất, nạn nhân có thể mất hơn 46.000 USD mỗi ngày.

Những gì bạn có thể làm:

• Đặt ngân sách có khả năng chặn chi tiêu: Áp dụng hạn mức chi tiêu cứng cho từng người dùng, khóa API, nhóm và toàn bộ tài khoản. Thực thi các hạn mức này ở mọi điểm mà yêu cầu có thể đi vào.
• Đặt điểm dừng cho mọi tác vụ: Giới hạn thời gian một tác vụ có thể chạy, lượng văn bản nó có thể xử lý và tạo ra, cũng như số lần gọi công cụ nó có thể thực hiện. Thêm cơ chế tự động ngắt đối với những tác nhân lặp đi lặp lại hoặc vượt quá mức cho phép.

7. Phát hiện thông tin sai lệch trước khi hành động

Khi AI tạo ra điều gì đó sai nhưng nghe có vẻ đúng, và ai đó, hoặc thứ gì đó, hành động dựa trên nó, thì đó được gọi là thông tin sai lệch. Rủi ro cốt lõi không hẳn nằm ở bản thân câu trả lời sai, mà ở việc câu trả lời sai đó được tin tưởng và sử dụng.

Hồ sơ sự cố cho thấy giới chuyên môn đã không lo ngại về thông tin sai lệch đúng mức cần thiết. Theo thư mở đầu của phiên bản 2026, những người bình chọn xếp rủi ro này gần cuối danh sách, nhưng xét theo các sự cố thực tế, nó lại nằm gần đầu.

Ví dụ: Năm 2025, Deloitte Australia đã bàn giao một bản đánh giá về các hệ thống CNTT phúc lợi theo hợp đồng chính phủ trị giá 440.000 đô la Úc. Tại Đại học Sydney, nhà nghiên cứu Chris Rudge đã phát hiện các tài liệu tham khảo dẫn tới những nghiên cứu không tồn tại cùng một trích dẫn bịa đặt từ một phán quyết của tòa án liên bang. Bản báo cáo sửa đổi đã công bố rằng Deloitte sử dụng Azure OpenAI GPT-4o trong phương pháp luận của mình, và công ty đồng ý hoàn trả khoản thanh toán cuối cùng. Đáng tiếc thay, đây lại là một bản đánh giá đảm bảo.

Những gì bạn có thể làm:

• Kiểm tra xem bằng chứng có hỗ trợ câu trả lời hay không: Căn cứ các khẳng định vào những nguồn hiện hành và có thẩm quyền. Với câu trả lời liên quan đến chính sách, hãy truy xuất chính sách đã được phê duyệt và kiểm tra xem nó có hỗ trợ kết luận hay không, kể cả các ngoại lệ.
• Xác minh trước khi hệ thống hành động: Nếu một tác nhân cho biết khách hàng đã vượt qua bước kiểm tra danh tính, hãy đối chiếu thông tin đó với hệ thống xác minh trước khi thực hiện thanh toán. Yêu cầu con người phê duyệt đối với các quyết định quan trọng, đồng thời cung cấp sẵn bằng chứng hỗ trợ cho người xem xét.

8. Hạn chế thiệt hại do lộ ngữ cảnh ẩn

Các ứng dụng AI cung cấp cho mô hình những chỉ dẫn và thông tin nền mà người dùng thường không nhìn thấy. Những nội dung này có thể bao gồm prompt hệ thống, chính sách nội bộ, mô tả về các công cụ sẵn có và quy tắc về việc ai được sử dụng chúng. Lộ ngữ cảnh ẩn xảy ra khi mô hình tiết lộ những thông tin đó cho ai đó.

Năm 2026, OWASP đã mở rộng mục này từ “rò rỉ prompt hệ thống” vì prompt hệ thống chỉ là một phần trong những gì có thể bị lọt ra ngoài. Mức độ nguy hiểm phụ thuộc vào những gì bạn đặt vào đó. Một bản hướng dẫn giọng điệu bị rò rỉ chỉ hơi đáng xấu hổ, nhưng một khóa API bị rò rỉ sẽ cho người khác quyền truy cập vào cơ sở dữ liệu bảo mật của bạn.

Ví dụ: Vào tháng 2 năm 2023, người dùng đã khiến Bing Chat của Microsoft tiết lộ các chỉ dẫn nội bộ của nó. Một trong những nỗ lực thành công đến từ Marvin von Hagen, người tự nhận là nhà phát triển của OpenAI và yêu cầu xem các chỉ dẫn để cấu hình mô hình. Bing đã tiết lộ các quy tắc chi phối việc tìm kiếm, phản hồi và hành vi an toàn của nó, cùng với tên nội bộ là Sydney. Trong số các chỉ dẫn bị lộ có một chỉ dẫn yêu cầu nó giữ bí mật những chỉ dẫn đó.

Những gì bạn có thể làm:

• Giữ thông tin bí mật bên ngoài ngữ cảnh của mô hình: Hãy giả định rằng mọi thứ mô hình có thể đọc đều có thể bị người dùng nhìn thấy—hãy lưu mật khẩu, khóa API và token truy cập trong một hệ thống quản lý bí mật riêng biệt.
• Đảm bảo quyền hạn vẫn có hiệu lực ngay cả khi quy tắc bị rò rỉ: Thực thi việc kiểm tra quyền truy cập trong mã ứng dụng của bạn. Nếu một công cụ chỉ dành cho quản trị viên, hãy kiểm tra quyền tài khoản của người dùng trước khi chạy công cụ đó.

9. Bảo vệ chặt chẽ vector và embedding

Khi AI sử dụng tìm kiếm vector để tìm câu trả lời trong tài liệu của công ty bạn, nó không tìm kiếm trực tiếp trên văn bản. Các tài liệu được chuyển đổi thành “embedding”—những dãy số dài thể hiện ý nghĩa của từng đoạn văn—và được lưu trữ trong cơ sở dữ liệu vector. Câu hỏi cũng được chuyển đổi theo cách tương tự, và hệ thống sẽ truy xuất những đoạn văn có dãy số gần với câu hỏi nhất.

OWASP tóm tắt bốn cách mà hệ thống này có thể thất bại: đầu độc khiến hệ thống trả lời sai, đảo ngược khiến hệ thống rò rỉ dữ liệu, gây nhiễu khiến hệ thống im lặng, còn kiểm soát truy cập bị lỗi khiến hệ thống trao bất cứ thứ gì cho bất kỳ ai.

Những con số này không phải là lớp trừu tượng an toàn như vẻ ngoài của chúng. Các embedding được lưu trữ có thể được chuyển ngược lại thành văn bản, và một phương pháp đã khôi phục chính xác 92% các đoạn văn ngắn dài 32 token trong các thử nghiệm của mình. Vì vậy, một bản sao lưu “chỉ chứa embedding” bị rò rỉ cũng có thể làm lộ nội dung của tài liệu.

Ví dụ: Trong một nghiên cứu được trình bày tại USENIX Security 2025, các nhà nghiên cứu đã chứng minh rằng chỉ một tài liệu được soạn thảo khéo léo cũng có thể khiến AI ngừng trả lời một câu hỏi cụ thể. Họ đã thêm tài liệu này vào bộ tài liệu mà AI tìm kiếm. Khi tìm thấy nó, AI có thể nói rằng mình không có đủ thông tin hoặc việc trả lời sẽ không an toàn. Tài liệu này không cần yêu cầu AI bỏ qua các quy tắc của nó. Kỹ thuật này được gọi là “gây nhiễu truy xuất” (retrieval jamming).

Những gì bạn có thể làm:

• Duy trì các chỉ mục riêng biệt cho dữ liệu công khai và dữ liệu riêng tư: Đừng trộn lẫn nội dung thu thập từ web với dữ liệu của đối tác hoặc tài liệu nội bộ mật. Hãy tách biệt về mặt vật lý theo mức độ tin cậy thay vì gắn thẻ nội dung trong cùng một chỉ mục, vì cách này loại bỏ hoàn toàn cả một nhóm lỗi cấu hình, đồng thời đảm bảo nội dung thu thập từ internet không thể nằm cạnh tài liệu họp hội đồng quản trị của bạn.
• Đối xử với embedding như chính tài liệu gốc của chúng: Mã hóa chúng, bảo vệ các bản sao lưu cơ sở dữ liệu vector cũng như các tệp nguồn, và xóa embedding khi bạn xóa bản gốc. Khóa API cho dịch vụ embedding của bạn cần được giữ bí mật.

10. Kiểm tra đầu ra của AI trước khi chuyển tiếp

Bất cứ khi nào một ứng dụng chuyển đầu ra của AI sang một hệ thống khác mà không xác minh xem đầu ra đó có an toàn để sử dụng ở đó hay không, thì ứng dụng đang xử lý đầu ra của LLM không đúng cách.

Mục này cũng đề cập đến mã không an toàn mà các trợ lý lập trình AI tạo ra trên quy mô lớn. Do đó, mỗi dòng mã mà trợ lý viết ra cũng là đầu ra.

Ví dụ: Năm 2025, nhà nghiên cứu Johann Rehberger đã chứng minh cách trợ lý lập trình Amp của Sourcegraph có thể làm rò rỉ nội dung trò chuyện chỉ bằng cách hiển thị một hình ảnh. Ông đã dùng kỹ thuật chèn prompt (prompt injection) để khiến Amp đưa thông tin riêng tư vào địa chỉ web của một hình ảnh. Sau đó, ứng dụng tự động tải hình ảnh đó, qua đó gửi thông tin đến máy chủ của ông. Lỗi xử lý đầu ra nằm ở chính yêu cầu tự động đó—văn bản do mô hình tạo ra đã trở thành một kết nối đến máy chủ bên ngoài, mang theo dữ liệu riêng tư.

Những gì bạn có thể làm:

• Đảm bảo đầu ra an toàn cho nơi nhận: Kiểm tra và xử lý phản hồi tùy theo nơi chúng sẽ được chuyển đến. Với trang web, hãy ngăn văn bản được tạo ra trở thành mã thực thi. Với cơ sở dữ liệu, hãy sử dụng truy vấn được chuẩn bị sẵn (prepared query) để tách biệt các giá trị được cung cấp khỏi câu lệnh.
• Ngăn câu trả lời tự động tạo kết nối ra bên ngoài: Theo mặc định, hãy tắt tính năng tự động tải hình ảnh, bản xem trước liên kết và trang nhúng trong phản hồi của mô hình. Chỉ cho phép các kết nối cần thiết đến những đích đã được phê duyệt rõ ràng.

Perplexity bảo mật LLM như thế nào?

Chúng tôi giả định rằng mọi rủi ro nêu trên rồi sẽ xảy ra, và chúng tôi thiết kế hệ thống sao cho khi điều đó xảy ra, rủi ro không thể gây nhiều thiệt hại. Giám đốc An ninh Thông tin (CISO) của chúng tôi, Kyle Polley, đã trình bày cách chúng tôi thực hiện điều này trong một buổi hội thảo gần đây.

• Tác nhân có máy tính riêng, và máy tính đó ban đầu hoàn toàn trống: Các công cụ tác nhân được cài đặt trên máy tính xách tay của bạn có thể truy cập vào tệp, ứng dụng và thông tin xác thực đã lưu trên máy. Perplexity Computer hoạt động theo cách ngược lại. Mỗi tác vụ chạy trong sandbox biệt lập riêng, và như Polley chia sẻ, “theo mặc định, nó không có quyền truy cập vào bất cứ thứ gì.”
• Tác nhân không bao giờ nhìn thấy mật khẩu: Thông tin xác thực của các dịch vụ được kết nối được lưu trữ bên ngoài sandbox. Khi cần truy cập một dịch vụ như GitHub, tác nhân sẽ gửi yêu cầu không kèm thông tin xác thực. Một cổng (gateway) kiểm tra xem đích đến và yêu cầu có đúng như dự kiến hay không, rồi mới thêm thông tin xác thực khi yêu cầu được gửi đi. Tác nhân có thể sử dụng kết nối mà không bao giờ nắm được khóa.
• Quyền của bạn được giữ nguyên và bạn có thể thắt chặt chúng: Các kết nối được thiết lập qua OAuth giữ nguyên quyền truy cập của bạn trong dịch vụ được kết nối. Nếu bạn không thể xem một nội dung nào đó thì tác nhân của bạn cũng không thể.
• Mọi trang web đều được coi là người lạ: Chúng tôi xây dựng BrowseSafe cho Comet, trình duyệt tác nhân của chúng tôi, vì các công cụ chúng tôi đã thử nghiệm không đáp ứng được nhu cầu khi sử dụng thực tế. Trình duyệt quét các trang web và nội dung bên ngoài khác, bao gồm cả email, để phát hiện hành vi chèn prompt. Chúng tôi đã công bố mã nguồn mở cho cả mô hình lẫn tập dữ liệu.
• Chúng tôi giám sát tác nhân và các máy mà tác nhân chạy trên đó: Numbat nằm giữa thời điểm tác nhân quyết định hành động và thời điểm công cụ thực sự chạy. Numbat ghi nhật ký hoạt động trên các tác nhân lập trình được hỗ trợ và có thể chặn những hành động vi phạm chính sách đã cấu hình trước khi chúng được thực thi. Bumblebee kiểm kê các gói phần mềm trên máy tính xách tay, máy chủ và pipeline build, đồng thời gắn cờ những gói được biết là độc hại. Cả hai đều là mã nguồn mở.
• Nhà cung cấp mô hình không lưu giữ dữ liệu của bạn: Chúng tôi có thỏa thuận không lưu giữ dữ liệu (zero data retention) với các nhà cung cấp LLM bên thứ ba. Quản trị viên doanh nghiệp cũng có thể đặt thời gian lưu giữ dữ liệu của chính Perplexity ngắn tới 24 giờ.

Chúng tôi chủ động xây dựng Numbat vì một lý do mà Polley tóm gọn trong một câu: “Bạn càng trao cho tác nhân nhiều quyền tự chủ thì rủi ro càng lớn.”

Câu hỏi thường gặp về bảo mật LLM

LLM nào bảo mật nhất?

Không có LLM nào tự nó có thể khiến một ứng dụng trở nên bảo mật—các mô hình vẫn có thể nhầm nội dung mà chúng chỉ nên đọc thành chỉ dẫn mà chúng phải làm theo. Những biện pháp phòng thủ trông có vẻ vững chắc trong các bài kiểm tra tiêu chuẩn cũng có thể sụp đổ khi chịu áp lực.

Câu hỏi đúng hơn là cách thiết lập nào bảo mật nhất cho trường hợp sử dụng của bạn. Điều đó có nghĩa là quyền hạn được giới hạn, thông tin xác thực được giữ cách xa mô hình, có sự phê duyệt của con người đối với các hành động rủi ro, và được kiểm thử bởi những người hiểu rõ các biện pháp phòng thủ của bạn.

Lỗ hổng LLM là gì?

Lỗ hổng LLM là những điểm yếu khiến hệ thống AI có thể bị lừa, làm rò rỉ dữ liệu hoặc gây thiệt hại, dù là do kẻ tấn công hay do chính sai sót của hệ thống.

Mười rủi ro chính là chèn prompt, tiết lộ thông tin nhạy cảm, quyền tự quyết quá mức, chuỗi cung ứng, đầu độc dữ liệu và mô hình, tiêu thụ tài nguyên không giới hạn, thông tin sai lệch, lộ ngữ cảnh ẩn, điểm yếu của vector và embedding, và xử lý đầu ra không đúng cách.

LLM riêng tư có an toàn không?

Đó là lựa chọn an toàn hơn trong một số trường hợp, nhưng không phải mặc định. Bạn có nhiều quyền kiểm soát hơn đối với việc xử lý dữ liệu nếu chạy mô hình trên hạ tầng của riêng mình hoặc trong môi trường đám mây. Tuy nhiên, không có cách tự động nào để ngăn chặn hành vi chèn prompt, quyền tự quyết quá mức, đầu độc dữ liệu hay thông tin sai lệch.

Khi tự lưu trữ (self-hosting), bạn cũng phải chịu trách nhiệm về mô hình mà mình tải xuống, bao gồm cả các rủi ro chuỗi cung ứng và hạ tầng mà mô hình đó yêu cầu.