Các Vấn Đề Bảo Mật AI Khó Nhất Hiện Đang Tồn Tại Ngoài Mô Hình

Bản 2026 OWASP Top 10 for LLM Applications cung cấp một góc nhìn quan trọng về mức độ trưởng thành của AI trong môi trường sản xuất. Nó nắm bắt một sự chuyển đổi then chốt: ngành công nghiệp đang vượt ra ngoài môi trường thử nghiệm và đối mặt với những phức tạp của việc tích hợp trong thực tế.

Khi bạn kết nối một mô hình ngôn ngữ lớn (LLM) với các công cụ và quy trình doanh nghiệp, bề mặt nguy cơ cơ bản thay đổi. Các rủi ro liên quan đến quyền hạn và việc sử dụng tài nguyên trở nên khó kiểm soát hơn đáng kể. Đồng thời, các lỗ hổng như xử lý đầu ra không đúng đang dần không còn là mối quan tâm hàng đầu, không phải vì chúng đã được giải quyết, mà vì các vấn đề khác đã chiếm vị trí ưu tiên.

Bảng xếp hạng OWASP Top 10 phản ánh sự tiến triển này. “Excessive Agency” đã leo lên từ vị trí thứ sáu lên thứ ba, trong khi “Unbounded Consumption” tăng lên vị trí thứ sáu. Ngược lại, “Improper Output Handling” đã tụt xuống vị trí thứ mười.

Điều này không làm giảm rủi ro của việc xử lý đầu ra. Nếu phản hồi của LLM tới một shell hoặc cơ sở dữ liệu mà không có quá trình xác thực nghiêm ngặt, các lỗ hổng tiêm mã truyền thống vẫn tồn tại. Tuy nhiên, mô hình đã thay đổi. Trong một hệ thống có tính năng đại lý, phản hồi của mô hình không phải là đích cuối cùng; nó là một đầu vào mang theo quyền hạn. Khi một mô hình nắm giữ thông tin xác thực hoặc tương tác với API, đầu ra của nó trở thành một vector có thể kích hoạt các hành động trên các hệ thống khác nhau.

Thách thức bảo mật không còn chỉ là đánh giá mô hình; mà là xác định ranh giới của những gì xảy ra sau khi suy luận. Kiến trúc của bạn quyết định liệu một hallucination (sự ảo tưởng) chỉ ở dạng văn bản hay biến thành một thay đổi không được phép trong cơ sở dữ liệu.

Bảng Xếp Hạng Phản Ánh Thiệt Hại

OWASP đã khai thác 7.714 sự cố, 75% do sự đồng thuận của cộng đồng và 25% dựa trên dữ liệu thực nghiệm. Cơ sở bằng chứng này buộc phải tái sắp xếp thực sự các ưu tiên.

“Excessive Agency” tăng lên vì thực tế của các môi trường sản xuất đã bắt kịp lý thuyết. Các tổ chức đang đẩy nhanh việc triển khai các khả năng tự động hơn tốc độ họ thiết lập các mặt phẳng kiểm soát cần thiết. Lỗ hổng quan trọng không chỉ là câu trả lời mà mô hình cung cấp, mà còn là ngữ cảnh ủy quyền mà câu trả lời đó được thực thi.

Mặc dù “Improper Output Handling” vẫn là một mối quan tâm, các nhóm DevOps đã trưởng thành trong khả năng bảo vệ các điểm tiêu thụ hạ nguồn thông qua việc xác thực schema và truy vấn có tham số. Đây là những thực tiễn bảo mật ứng dụng đã được thiết lập.

Tuy nhiên, agency là một loại vấn đề khác. Một lời gọi công cụ có thể hợp lệ về cấu trúc nhưng không hợp lệ trong ngữ cảnh. Mô hình có thể gọi một hàm đã được phê duyệt cho một nhiệm vụ không phù hợp hoặc nhắm vào tài nguyên sai. Việc làm sạch tĩnh không thể xác định ý định. Điều này đòi hỏi một cơ chế ủy quyền tinh vi, nhận thức ngữ cảnh mà mô hình không bao giờ nên thực hiện một mình.

Xem Mỗi Công Cụ Như Một Khả Năng Được Tiết Lộ

Nhiều nhóm coi định nghĩa công cụ chỉ là phần tích hợp kỹ thuật. Đây là một lỗi cơ bản và đáng cười. Mỗi công cụ, kết nối hoặc điểm cuối API đều mở rộng phạm vi ảnh hưởng của ứng dụng AI.

Hãy xem xét một đại lý được thiết kế để tóm tắt hộp thư. Nếu triển khai sử dụng một kết nối rộng bao gồm khả năng ghi hoặc xóa, bạn đã đưa vào chức năng quá mức trước khi lời nhắc đầu tiên được xử lý.

Bạn phải thực thi nguyên tắc tối thiểu đặc quyền:

• Hạn chế giao diện: Cung cấp cho đại lý các công cụ chỉ đọc thay vì các kết nối đa năng.
• Ngữ cảnh giới hạn: Thực thi yêu cầu trong danh tính đã được OAuth phân quyền của người dùng.
• Policy Enforcement Points (PEP): Triển khai logic ủy quyền như một middleware bắt buộc giữa mô hình và các hệ thống hạ nguồn. Mọi hành động phải được xác thực theo chính sách trước khi thực thi.
• Human-in-the-loop (HITL): Yêu cầu phê duyệt rõ ràng cho các thao tác khó đảo ngược hoặc có tác động vật chất lớn.

Cách tiếp cận này đòi hỏi sự thay đổi trong quy trình triển khai. Quy trình xem xét của bạn phải mở rộng ra ngoài mô hình để bao gồm các thay đổi trong schema công cụ, danh tính dịch vụ và phạm vi quyền. Một bản cập nhật mô hình có thể trông vô hại, nhưng việc thay đổi ngữ cảnh ủy quyền của một kết nối có thể tạo ra lỗ hổng thảm họa.

Tính khả thi không thể thương lượng. Bạn phải ghi lại việc thực thi công cụ cụ thể, danh tính ủy quyền và thay đổi kết quả trong hệ thống mục tiêu. Chuỗi quản lý này là thiết yếu cho phản ứng sự cố, cho phép bạn can thiệp vào quá trình đang hoạt động và tái tạo dấu vết kiểm toán sau sự cố.

Mỗi Lần Chạy Tự Động Cần Có Một Điểm Dừng Cứng

“Unbounded Consumption” đã bùng nổ vì khối lượng yêu cầu không phải là thước đo đủ cho rủi ro tài nguyên. Một lời nhắc ngắn gọn duy nhất có thể kích hoạt một chuỗi gọi công cụ đệ quy, tiêu tốn tài nguyên. Bộ đo không dừng lại cho đến khi đại lý hoàn thành.

Cảnh báo đơn giản không đủ khi tốc độ thực thi vượt quá khả năng phản hồi của con người. Bạn cần các giới hạn cứng, quyết định được, nằm ngoài tầm kiểm soát của đại lý. Thực hiện các ngưỡng nghiêm ngặt cho việc sử dụng token, thời gian đã trôi, độ sâu đệ quy và chi phí vận hành tích lũy. Nếu một lần thực thi vượt quá các tham số này, hệ thống phải chấm dứt hoặc giảm tốc độ chạy.

Phạm vi hoạt động đòi hỏi mức độ nghiêm ngặt tương tự. Xác định số lượng bản ghi tối đa mà một tác nhân có thể sửa đổi và định nghĩa ranh giới của việc lan truyền nhiệm vụ. Nếu kiến trúc của bạn thiếu cơ chế “dừng” quyết định, bạn về cơ bản đã ủy thác quyền mà không xác định phạm vi của nó.

Xây dựng cho câu trả lời sai

Kỹ thuật hệ thống từ lâu đã dựa vào kiến trúc bền vững để bảo vệ các thành phần vốn không đáng tin cậy. Chúng tôi dự đoán sự cố thành phần và sự không ổn định của mạng; an ninh được xây dựng dựa trên giả định đó, không phải từ ảo tưởng về sự hoàn hảo. Các mô hình ngôn ngữ lớn (LLM) yêu cầu cùng một kỷ luật kiến trúc.

Đừng dựa chiến lược bảo mật của bạn trên giả định mô hình hoàn hảo. Hãy giả định có lỗi, dù là do hiểu lầm vô hại hay khai thác độc hại. Hạn chế khả năng của tác nhân xuống mức tối thiểu cần thiết và duy trì ngữ cảnh ủy quyền người dùng nghiêm ngặt cho mọi cuộc gọi hạ nguồn. Quan trọng là, việc thực thi chính sách phải tồn tại bên ngoài mô hình để ngăn chặn việc tiêm lệnh (prompt injection) hoặc lỗi suy luận vượt qua các kiểm soát của bạn.

Chúng tôi hiện coi Prompt Injection không chỉ là một lỗ hổng mà còn là một quy luật vật lý. Nó sẽ luôn tồn tại ẩn hiện. Thực tế là các mô hình tự chúng không thể là những người quyết định hiệu quả cho các câu hỏi an ninh quan trọng. Trong một dự án tác nhân thực tế mà tôi đang xây dựng, chúng tôi có khoảng 100 bài kiểm tra “đội đỏ” tự động. Chúng tôi đảm bảo vượt qua tất cả chúng. Tuy nhiên, chúng tôi thực hiện điều này bằng cách xây dựng các kiểm soát cứng bên ngoài mô hình. Chúng tôi có thể tắt chúng và xem tỷ lệ đạt/không đạt chỉ cho mô hình. Mô hình cũ nhất, yếu nhất mà chúng tôi kiểm tra thất bại 17% thời gian. Mô hình mới nhất, lớn nhất thất bại 2% thời gian. Tiến bộ lớn, đúng không? Nhưng liệu 98% có đủ tốt khi mỗi lần thất bại đều đồng nghĩa rò rỉ dữ liệu nhạy cảm? Thậm chí không gần tới mức đó.

Các hoạt động có tác động cao phải có khả năng quan sát, kiểm toán và lý tưởng là có thể đảo ngược. Mỗi lần thực thi tự động đòi hỏi các rào cản bất biến nằm ngoài tầm kiểm soát của mô hình.

Bảng xếp hạng năm 2026 thực sự làm sáng tỏ nơi các thất bại AI chuyển sang hậu quả thực tế. Mô hình có thể khởi tạo lỗi, nhưng kiến trúc quyết định phạm vi ảnh hưởng. Đối với AI trong môi trường sản xuất, công việc bảo mật quan trọng nhất diễn ra trong quy trình hậu suy luận.