Bảo mật LLM cho Agentic AI: Injection, Gọi Công Cụ, Lưu Trú Dữ Liệu, HITL và Kiểm Thử

Bảo mật LLM không còn chỉ là chặn các prompt không an toàn. Khi một LLM trở thành một phần của quy trình agentic, nó có thể truy xuất tài liệu, gọi API, cập nhật bản ghi hoặc kích hoạt quy trình kinh doanh. Điều đó thay đổi mô hình bảo mật từ “bảo vệ cuộc trò chuyện” thành “bảo vệ hệ thống hành động xung quanh mô hình”.

Nếu đội ngũ của bạn đang lên kế hoạch triển khai agentic AI trong sản xuất ở quy mô rộng hơn, bảo mật LLM nên được xem là một cổng kiểm soát phát hành, không phải một danh sách kiểm tra cuối cùng. Với các đội ngũ tại EU/US, điều đó có nghĩa là cần suy nghĩ về prompt injection, truy cập công cụ an toàn, lưu trú dữ liệu, khả năng kiểm toán, giám sát của con người, kiểm thử và giám sát sản xuất trước khi ra mắt.

Rủi ro không còn là lý thuyết. AI Index 2025 của Stanford HAI ghi nhận 233 sự cố liên quan đến AI trong năm 2024, mức cao kỷ lục và tăng 56,4% so với năm 2023. Báo cáo Chi phí Vi phạm Dữ liệu 2025 của IBM cũng cho thấy 13% tổ chức báo cáo các vụ vi phạm liên quan đến mô hình hoặc ứng dụng AI; trong số những tổ chức bị xâm phạm, 97% thiếu các biện pháp kiểm soát truy cập AI phù hợp.

Hướng dẫn này phân tích các biện pháp kiểm soát thực tế mà đội ngũ cần có để triển khai các agent vận hành bởi LLM một cách an toàn.

Những Điểm Chính Cần Ghi Nhớ

• Bảo mật LLM bao phủ prompt, công cụ, dữ liệu, nhật ký, con người, nhà cung cấp và giám sát.
• Agentic AI làm tăng rủi ro bảo mật vì nó có thể thực hiện hành động, không chỉ tạo văn bản.
• Prompt injection cần các lớp phòng thủ, không chỉ một system prompt mạnh hơn.
• Gọi công cụ an toàn phụ thuộc vào quyền tối thiểu, xác thực, sandbox và nhật ký kiểm toán.
• Lưu trú dữ liệu phải được thiết kế trong kiến trúc cho các triển khai tại EU/US.
• Kiểm soát HITL nên dựa trên rủi ro, có thể kiểm toán và thực tế về mặt vận hành.
• Kiểm thử và giám sát phải tiếp tục sau khi phát hành sản xuất.

Bảo Mật LLM Có Ý Nghĩa Gì Đối Với Agentic AI

Bảo mật LLM rộng hơn an toàn prompt

Bảo mật LLM là thực hành bảo vệ các hệ thống vận hành bởi LLM khỏi rò rỉ dữ liệu, prompt injection, sử dụng công cụ trái phép, đầu ra không an toàn và lỗi tuân thủ.

Với một chatbot đơn giản, bảo mật có thể tập trung chủ yếu vào prompt, đầu ra và dữ liệu người dùng. Với một hệ thống agentic AI, phạm vi rộng hơn. Hệ thống có thể bao gồm:

• Một mô hình hoặc nhiều mô hình
• System prompt và chính sách
• Pipeline RAG và cơ sở dữ liệu vector
• API và công cụ kinh doanh
• Bộ nhớ hoặc ngữ cảnh phiên
• Nhật ký và hệ thống giám sát
• Quy trình phê duyệt của con người
• Nhà cung cấp mô hình hoặc hạ tầng bên thứ ba

Một ứng dụng LLM an toàn không chỉ là một prompt an toàn. Đó là một kiến trúc an toàn bao quanh mô hình.

Vì sao hệ thống agentic làm tăng mức độ rủi ro

Agentic AI thay đổi hồ sơ rủi ro vì mô hình có thể tác động đến hành động. Thay vì chỉ trả lời một câu hỏi, một agent có thể:

• Tìm kiếm tài liệu nội bộ
• Gọi API CRM
• Cập nhật một phiếu hỗ trợ
• Kích hoạt email
• Tạo mã nguồn
• Phân tích hồ sơ khách hàng
• Chuyển dữ liệu giữa các công cụ
• Đề xuất hoặc thực thi các bước trong quy trình làm việc

Điều đó có nghĩa là một chỉ dẫn xấu, kết quả truy xuất không an toàn, quyền quá rộng hoặc lớp xác thực yếu có thể tạo ra tác động vận hành thực tế. Chế độ thất bại không còn chỉ là “câu trả lời sai”. Nó có thể trở thành “hành động sai đã được thực hiện”.

Mục tiêu bảo mật cho LLM agent trong sản xuất

Đối với LLM agent trong sản xuất, mục tiêu bảo mật nên được xác định rõ ràng. Tối thiểu, các đội ngũ nên hướng đến:

• Ngăn truy cập dữ liệu trái phép
• Ngăn rò rỉ dữ liệu nhạy cảm
• Ngăn sử dụng công cụ không an toàn hoặc trái phép
• Duy trì nhật ký kiểm toán cho các hành động quan trọng
• Áp dụng phê duyệt của con người cho quy trình rủi ro cao
• Phát hiện sớm hành vi bất thường
• Hỗ trợ ứng phó sự cố và rollback
• Giữ cho thay đổi về mô hình, prompt và công cụ có thể truy vết

Những mục tiêu này giúp các đội ngũ bảo mật, sản phẩm và kỹ thuật đánh giá liệu một agent đã sẵn sàng cho sản xuất hay chưa.

Mô Hình Đe Dọa: LLM Agent Thất Bại Ở Đâu Trong Sản Xuất

Mô hình hóa đe dọa cung cấp cho đội ngũ một cách thực tế để hiểu LLM agent có thể thất bại như thế nào trước khi các thất bại đó ảnh hưởng đến khách hàng, nhân viên hoặc dữ liệu chịu quản lý.

Báo cáo năm 2025 của IBM cho thấy 60% sự cố bảo mật liên quan đến AI dẫn đến dữ liệu bị xâm phạm và 31% gây gián đoạn vận hành. Với agentic AI, các con số đó quan trọng vì một agent bị xâm phạm có thể ảnh hưởng đến cả việc lộ thông tin và tính liên tục của quy trình kinh doanh.

Rủi ro bảo mật thông tin

Rủi ro bảo mật thông tin xảy ra khi thông tin nhạy cảm bị lộ cho sai người dùng, công cụ, nhà cung cấp, nhật ký hoặc hệ thống hạ nguồn.

Các ví dụ phổ biến bao gồm:

• PII được đưa vào prompt một cách không cần thiết
• Bí mật hoặc thông tin xác thực xuất hiện trong nhật ký
• Truy xuất RAG làm lộ tài liệu mà người dùng không nên truy cập
• Đầu ra mô hình tiết lộ các chỉ dẫn hệ thống ẩn
• Thiết lập nhà cung cấp lưu giữ prompt nhạy cảm lâu hơn dự kiến
• Dữ liệu nội bộ được gửi đến dịch vụ bên ngoài khi chưa có phê duyệt rõ ràng

Biện pháp kiểm soát thực tế bắt đầu bằng phân loại dữ liệu. Các đội ngũ cần biết agent có thể truy cập dữ liệu nào, dữ liệu đó được xử lý ở đâu và ai có thể xem đầu ra.

Rủi ro toàn vẹn

Rủi ro toàn vẹn xảy ra khi hành vi, suy luận hoặc hành động của agent bị thao túng.

Trong hệ thống LLM, rủi ro toàn vẹn thường xuất hiện dưới dạng prompt injection. Trong hệ thống agentic, nó có thể đi xa hơn:

• Một tài liệu độc hại yêu cầu agent bỏ qua các chỉ dẫn trước đó.
• Phản hồi của công cụ chứa văn bản mà mô hình xem như một lệnh mới.
• Người dùng lừa agent gọi một hàm không được phép.
• Agent sửa đổi một bản ghi dựa trên thông tin chưa được xác minh.
• Kết quả RAG thay đổi đường đi quyết định của agent.

Kiểm soát toàn vẹn nên tập trung vào việc tách biệt chỉ dẫn đáng tin cậy khỏi nội dung không đáng tin cậy, xác thực lệnh gọi công cụ và áp dụng kiểm tra chính sách trước các hành động nhạy cảm.

Rủi ro sẵn sàng và chi phí

LLM agent cũng có thể tạo ra vấn đề về tính sẵn sàng và chi phí. Ví dụ:

• Agent rơi vào vòng lặp lặp lại.
• Lệnh gọi công cụ tăng đột biến bất ngờ.
• Mức sử dụng token vượt ngân sách.
• Sự cố mô hình hoặc nhà cung cấp làm gãy quy trình làm việc.
• Đầu vào sai định dạng gây thử lại liên tục.
• Một bước có độ trễ cao chặn quy trình kinh doanh.

Điều này đôi khi được gọi là “denial of wallet” khi mức sử dụng mô hình quá mức tạo ra chi phí bất ngờ. Agent trong sản xuất cần giới hạn tốc độ, timeout, giới hạn thử lại, kiểm soát ngân sách và cảnh báo.

Rủi ro tuân thủ

Đối với các triển khai tại EU/US, rủi ro tuân thủ thường đến từ cách xử lý dữ liệu không rõ ràng và quản trị yếu.

Ví dụ bao gồm:

• Không có luồng dữ liệu được tài liệu hóa
• Khu vực xử lý không rõ ràng
• Thiết lập lưu giữ yếu cho prompt và nhật ký
• Không có dấu vết kiểm toán cho hành động rủi ro cao
• Không có giám sát của con người cho quy trình nhạy cảm
• Không rà soát nhà cung cấp/đơn vị xử lý phụ
• Không có kế hoạch ứng phó sự cố cho thất bại liên quan đến AI

Các đội ngũ bảo mật và tuân thủ nên rà soát những rủi ro này trước khi ra mắt, không phải sau khi agent đã được nhúng vào quy trình kinh doanh.

Kiểm Soát Prompt Injection và Injection Gián Tiếp

Prompt injection trực tiếp

Prompt injection trực tiếp xảy ra khi người dùng cố ý thao túng chỉ dẫn của mô hình. Người dùng có thể yêu cầu mô hình bỏ qua quy tắc hệ thống, tiết lộ ngữ cảnh ẩn, vượt qua chính sách hoặc thực hiện hành động ngoài phạm vi được phép.

Với chatbot cơ bản, injection trực tiếp có thể dẫn đến câu trả lời không an toàn hoặc không chính xác. Với AI agent, nó có thể dẫn đến lạm dụng công cụ, lộ dữ liệu hoặc thực thi quy trình trái phép.

OWASP liệt kê Prompt Injection là một rủi ro ứng dụng LLM hàng đầu trong OWASP Top 10 for LLM Applications. Đó là lý do kiểm thử injection nên là một phần của quy trình phát hành đối với bất kỳ quy trình LLM nào xử lý dữ liệu nhạy cảm hoặc hành động kinh doanh.

Prompt injection gián tiếp

Prompt injection gián tiếp xảy ra khi chỉ dẫn độc hại được ẩn bên trong nội dung mà agent đọc. Nội dung này có thể đến từ:

• Trang web
• Email
• Tệp tải lên
• PDF
• Phiếu hỗ trợ
• Bản ghi trò chuyện
• Kết quả RAG
• Phản hồi công cụ
• Tài liệu dùng chung

Điều này đặc biệt quan trọng đối với agentic AI vì agent thường tiêu thụ nội dung bên ngoài hoặc bán tin cậy trước khi quyết định việc cần làm tiếp theo.

Vì sao injection gián tiếp nguy hiểm đối với agent

Injection gián tiếp nguy hiểm vì chỉ dẫn độc hại không đến trực tiếp từ người dùng. Nó xuất hiện bên trong dữ liệu mà agent được yêu cầu xử lý.

Ví dụ, một agent có thể đọc một phiếu hỗ trợ chứa chỉ dẫn ẩn yêu cầu nó tiết lộ chính sách nội bộ, thay đổi trường ưu tiên hoặc gọi một công cụ khác. Nếu hệ thống xem nội dung được truy xuất như chỉ dẫn đáng tin cậy, agent có thể làm theo.

Nguyên tắc cốt lõi rất đơn giản: nội dung bên ngoài nên được xem là dữ liệu, không phải thẩm quyền.

Biện pháp phòng thủ

Giảm thiểu prompt injection nên sử dụng các lớp kiểm soát:

• Tách chỉ dẫn hệ thống khỏi nội dung người dùng và công cụ.
• Xem tài liệu được truy xuất là dữ liệu không đáng tin cậy.
• Sử dụng danh sách cho phép công cụ thay vì quyền truy cập công cụ mở.
• Xác thực đối số công cụ ở phía máy chủ.
• Yêu cầu đầu ra có cấu trúc cho lệnh gọi công cụ.
• Bổ sung kiểm tra chính sách trước hành động nhạy cảm.
• Giới hạn quyền của agent theo vai trò và quy trình làm việc.
• Làm sạch hoặc cô lập nội dung bên ngoài trước khi sử dụng.
• Thêm cổng phê duyệt cho hành động có tác động cao.
• Giám sát các mẫu prompt đáng ngờ và các nỗ lực bị chặn.

Không có biện pháp đơn lẻ nào là đủ. Một system prompt mạnh sẽ hữu ích, nhưng không nên là ranh giới bảo mật duy nhất.

Không nên chỉ dựa vào điều gì

Các đội ngũ nên tránh chỉ dựa vào:

• Một system prompt chung kiểu “không được phá vỡ quy tắc”
• Bộ lọc từ khóa
• Rà soát thủ công mà không có nhật ký
• Một thiết lập an toàn mô hình duy nhất
• Tin tưởng toàn bộ nội dung RAG
• Cấp cho agent quyền API rộng
• Giả định rằng người dùng sẽ không thử đầu vào đối kháng

Bảo mật LLM nên giả định rằng prompt, nội dung được truy xuất và đầu ra công cụ đều có thể bị thao túng.

Gọi Công Cụ An Toàn và Quyền Truy Cập Tối Thiểu

Vì sao gọi công cụ thay đổi mô hình bảo mật

Gọi công cụ là một trong những khác biệt lớn nhất giữa chatbot LLM thông thường và hệ thống agentic AI.

Chatbot tạo văn bản. Agent có công cụ có thể tạo ra tác động phụ. Nó có thể tìm kiếm cơ sở dữ liệu, gửi email, cập nhật trường CRM, tạo phiếu hỗ trợ, chạy script hoặc kích hoạt quy trình làm việc nội bộ.

Điều đó có nghĩa là đầu ra mô hình trở thành một hành động hệ thống tiềm năng. Các biện pháp kiểm soát bảo mật cần bảo vệ lớp hành động, không chỉ lớp văn bản.

Rủi ro gọi công cụ phổ biến trong sản xuất

Các rủi ro phổ biến bao gồm:

• Agent gọi một công cụ mà nó không nên truy cập.
• Agent gửi dữ liệu nhạy cảm đến sai công cụ.
• Agent dùng đúng công cụ nhưng với đối số không an toàn.
• Agent lặp lại lệnh gọi công cụ và tạo ra vấn đề chi phí hoặc tính sẵn sàng.
• Phản hồi của công cụ chứa chỉ dẫn độc hại.
• Công cụ có quyền rộng hơn mức quy trình làm việc yêu cầu.
• Bí mật bị lộ cho mô hình thông qua prompt hoặc đầu ra công cụ.
• Một hành động công cụ không thể truy vết về người dùng, agent hoặc phê duyệt.

OWASP cũng nhấn mạnh Excessive Agency là một rủi ro ứng dụng LLM lớn, đặc biệt đối với các hệ thống có thể gọi công cụ hoặc tương tác với hệ thống bên ngoài. Vấn đề này thường bắt nguồn từ chức năng quá mức, quyền quá mức hoặc mức tự chủ quá mức. Điều đó ánh xạ trực tiếp đến các agent sản xuất có quyền truy cập công cụ rộng.

Quyền truy cập tối thiểu cho LLM agent

Quyền tối thiểu có nghĩa là agent chỉ nên có các quyền cần thiết cho một tác vụ cụ thể.

Ví dụ, một agent soạn thảo phản hồi hỗ trợ khách hàng có thể cần quyền đọc lịch sử phiếu hỗ trợ, nhưng có thể không cần quyền hoàn tiền, xóa tài khoản hoặc thay đổi hồ sơ thanh toán. Nếu một hành động có rủi ro cao, agent nên soạn thảo hoặc đề xuất hành động đó, còn con người phê duyệt.

Một mô hình quyền tối thiểu thực tế nên xác định:

• Agent có thể sử dụng công cụ nào
• Thao tác nào được phép
• Phạm vi dữ liệu nào được phép
• Người dùng hoặc vai trò nào có thể kích hoạt quy trình làm việc
• Hành động nào cần phê duyệt
• Hành động nào bị chặn hoàn toàn

Mỗi agent nên có danh tính dịch vụ riêng khi có thể. Tránh cấp cho agent quyền truy cập rộng thông qua thông tin xác thực quản trị dùng chung.

Danh sách cho phép công cụ, phạm vi và kiểm tra chính sách

Agent trong sản xuất không nên lựa chọn từ vô số công cụ. Quyền truy cập công cụ nên được đưa vào danh sách cho phép và giới hạn theo phạm vi.

Các biện pháp hữu ích bao gồm:

• Danh sách cho phép công cụ theo loại agent
• Phạm vi API theo quy trình làm việc
• Giới hạn tốc độ cho từng công cụ
• Kiểm tra chính sách trước khi thực thi
• Tách biệt môi trường dev, staging và production
• Kiểm tra phê duyệt cho thao tác nhạy cảm
• Hành vi từ chối theo mặc định khi ngữ cảnh không rõ ràng

Một lớp chính sách có thể quyết định liệu lệnh gọi công cụ có được phép hay không trước khi hành động diễn ra. Điều này đặc biệt hữu ích với các hành động liên quan đến dữ liệu khách hàng, tác động tài chính, tác động pháp lý, tác động bảo mật hoặc giao tiếp bên ngoài.

Xác thực đối số và xác thực đầu ra

Lệnh gọi công cụ nên sử dụng schema có cấu trúc. Agent không nên truyền đối số tự do tùy ý vào các API nhạy cảm.

Ví dụ:

• ID nên khớp với định dạng dự kiến.
• Số tiền nên nằm trong giới hạn được phê duyệt.
• Người nhận email nên khớp với miền được phép hoặc liên hệ đã xác minh.
• Đường dẫn tệp nên nằm trong các vị trí được phép.
• Lệnh gọi công cụ nên thất bại an toàn khi thiếu trường bắt buộc.

Đầu ra công cụ cũng nên được xử lý cẩn trọng. Phản hồi của công cụ có thể chứa văn bản không đáng tin cậy, dữ liệu sai định dạng hoặc chỉ dẫn bị chèn. Mô hình nên sử dụng đầu ra công cụ như dữ liệu, không phải như một nguồn thẩm quyền mới.

Sandbox cho công cụ rủi ro cao

Một số công cụ cần được cô lập. Ví dụ bao gồm:

• Thực thi mã
• Duyệt web
• Xử lý tệp
• Nạp tài liệu
• Chuyển đổi dữ liệu
• Tự động hóa quy trình làm việc có tác động phụ bên ngoài

Sandbox giúp giới hạn thiệt hại nếu agent hành xử bất ngờ. Tùy theo trường hợp sử dụng, sandbox có thể bao gồm hạn chế mạng, giới hạn hệ thống tệp, timeout thực thi, giới hạn bộ nhớ, thông tin xác thực riêng và môi trường bị hạn chế.

Quản lý bí mật cho quy trình agent

Bí mật không nên được đặt trong prompt, ngữ cảnh mô hình hoặc nhật ký văn bản thuần. Agent chỉ nên truy cập bí mật thông qua các dịch vụ backend an toàn.

Các thực hành tốt bao gồm:

• Lưu bí mật trong trình quản lý bí mật.
• Không đưa thông tin xác thực vào mẫu prompt.
• Che bí mật khỏi nhật ký.
• Xoay vòng thông tin xác thực thường xuyên.
• Sử dụng token ngắn hạn khi có thể.
• Tách thông tin xác thực theo môi trường.
• Tránh để lộ khóa API thô trong đầu ra mô hình hoặc phản hồi công cụ.

Mô hình nên yêu cầu một hành động, nhưng backend nên thực thi ủy quyền và thực hiện thao tác an toàn.

Ghi nhật ký kiểm toán cho lệnh gọi công cụ

Mọi lệnh gọi công cụ quan trọng nên được ghi nhật ký. Nhật ký nên giúp trả lời:

• Người dùng nào đã kích hoạt quy trình làm việc?
• Agent nào đã đưa ra quyết định?
• Công cụ nào đã được gọi?
• Hành động nào đã được yêu cầu?
• Hành động có được phê duyệt không?
• Kết quả là gì?
• Có dữ liệu nhạy cảm nào liên quan không?
• Hành động có bị chặn, thử lại hoặc rollback không?

Đối với môi trường doanh nghiệp EU/US, khả năng kiểm toán thường quan trọng không kém phòng ngừa. Nếu có sự cố, tổ chức cần tái dựng được những gì đã xảy ra.

Lưu Trú Dữ Liệu và Quyền Riêng Tư cho Triển Khai EU/US

Bắt đầu bằng bản đồ dữ liệu

Lưu trú dữ liệu bắt đầu bằng việc hiểu luồng dữ liệu. Trước khi chọn nhà cung cấp mô hình hoặc kiến trúc, các đội ngũ nên lập bản đồ:

• Dữ liệu nào đi vào prompt
• Dữ liệu nào được truy xuất từ hệ thống nội bộ
• Dữ liệu nào được gửi đến nhà cung cấp mô hình
• Dữ liệu nào được nhúng trong cơ sở dữ liệu vector
• Dữ liệu nào được ghi nhật ký
• Dữ liệu được lưu giữ trong bao lâu
• Khu vực nào xử lý hoặc lưu trữ từng thành phần
• Nhà cung cấp hoặc đơn vị xử lý phụ nào tham gia

Không có bản đồ dữ liệu, rà soát bảo mật và tuân thủ sẽ trở thành phỏng đoán.

IBM cũng báo cáo rằng 63% tổ chức bị vi phạm hoặc thiếu chính sách quản trị AI hoặc vẫn đang phát triển chính sách đó. Với các triển khai tại EU/US, khoảng trống quản trị đó thường thể hiện qua luồng dữ liệu không rõ ràng, quyết định lưu giữ yếu, rà soát nhà cung cấp chưa đầy đủ hoặc thiếu kiểm soát quanh shadow AI.

Cân nhắc tại EU

Đối với triển khai tại EU, các đội ngũ thường cần cân nhắc các nguyên tắc quyền riêng tư như giảm thiểu dữ liệu, giới hạn mục đích, kiểm soát truy cập, lưu giữ và rà soát chuyển dữ liệu xuyên biên giới. Nghĩa vụ cụ thể phụ thuộc vào tổ chức, trường hợp sử dụng, loại dữ liệu và cơ sở pháp lý.

Các câu hỏi kiến trúc thực tế bao gồm:

• Có thể giảm thiểu dữ liệu nhạy cảm trước khi xây dựng prompt không?
• Có thể cố định suy luận theo khu vực không?
• Nhật ký có được lưu ở đúng khu vực không?
• Embedding có được xem là nhạy cảm trong trường hợp sử dụng này không?
• Có thể loại trừ dữ liệu khách hàng khỏi việc huấn luyện của nhà cung cấp không?
• Thiết lập xóa và lưu giữ có thể cấu hình không?

Diễn giải pháp lý nên được luật sư đủ năng lực rà soát trước khi công bố hoặc đưa ra quyết định triển khai.

Cân nhắc tại US

Các triển khai tại US có thể liên quan đến các kỳ vọng theo ngành tùy thuộc vào lĩnh vực. Y tế, tài chính, giáo dục, khu vực công và môi trường SaaS doanh nghiệp thường có kỳ vọng nghiêm ngặt hơn về kiểm soát truy cập, nhật ký kiểm toán, lưu giữ và quản lý rủi ro nhà cung cấp.

Ngay cả khi một quy định không đề cập rõ ràng đến LLM, người mua có thể kỳ vọng các biện pháp kiểm soát bảo mật phù hợp với các khung doanh nghiệp như SOC 2 hoặc ISO/IEC 27001.

Mẫu kiến trúc cho hệ thống LLM nhạy cảm với lưu trú dữ liệu

Các mẫu phổ biến bao gồm:

• Endpoint mô hình theo khu vực
• Kho vector theo khu vực
• Kết nối mạng riêng khi có sẵn
• Khóa mã hóa do khách hàng quản lý
• Che dữ liệu trước khi gọi mô hình
• Phát hiện PII trước khi xây dựng prompt
• Môi trường EU và US riêng biệt
• Cửa sổ lưu giữ ngắn cho prompt và đầu ra
• Các tầng ghi nhật ký tách metadata vận hành khỏi nội dung nhạy cảm
• Kiểm soát truy cập đối với embedding và tài liệu được truy xuất

Mục tiêu là giảm chuyển dịch dữ liệu không cần thiết và làm cho chuyển dịch dữ liệu không thể tránh khỏi trở nên hiển thị, được kiểm soát và được tài liệu hóa.

Danh sách kiểm tra thẩm định nhà cung cấp

Trước khi sử dụng nhà cung cấp LLM hoặc nhà cung cấp hạ tầng AI, các đội ngũ nên hỏi:

• Dữ liệu được xử lý ở đâu?
• Dữ liệu được lưu trữ ở đâu?
• Dữ liệu khách hàng có được dùng để huấn luyện không?
• Có những kiểm soát lưu giữ nào?
• Những đơn vị xử lý phụ nào tham gia?
• Có hỗ trợ các kiểm soát bảo mật doanh nghiệp không?
• Có nhật ký kiểm toán không?
• Có thể xóa dữ liệu theo yêu cầu không?
• Có tùy chọn mạng riêng hoặc cố định theo khu vực không?
• Điều gì xảy ra trong quá trình ứng phó sự cố?

Thiết lập của nhà cung cấp có thể thay đổi đáng kể tư thế bảo mật của hệ thống LLM. Chúng nên được rà soát trước khi sử dụng trong sản xuất.

Kiểm Soát HITL: Giám Sát Của Con Người Mà Không Làm Chậm Tốc Độ

HITL nên dựa trên rủi ro

Human-in-the-loop không có nghĩa là mọi hành động của agent đều cần phê duyệt thủ công. Điều đó sẽ khiến hầu hết quy trình quá chậm. Nó cũng không có nghĩa là mọi hành động đều nên được tự động hóa.

Cách tiếp cận đúng là dựa trên rủi ro. Hành động rủi ro thấp có thể được ghi nhật ký và giám sát. Hành động rủi ro trung bình có thể cần lấy mẫu, kiểm tra dựa trên quy tắc hoặc phê duyệt trong một số điều kiện nhất định. Hành động rủi ro cao nên yêu cầu con người rà soát rõ ràng.

Các tầng rủi ro đề xuất

Tầng rủi ro	Ví dụ hành động của agent	Kiểm soát đề xuất
Thấp	Soạn thảo tóm tắt nội bộ	Chỉ ghi nhật ký
Trung bình	Cập nhật trường CRM không trọng yếu	Xác thực dựa trên quy tắc hoặc rà soát lấy mẫu
Cao	Gửi thông điệp hướng đến khách hàng	Yêu cầu phê duyệt của con người
Nghiêm trọng	Thanh toán, xóa tài khoản, hành động có tác động pháp lý/bảo mật	Phê duyệt của con người cộng với kiểm soát thứ cấp

Cấu trúc này cho phép đội ngũ duy trì tốc độ trong khi vẫn kiểm soát các quyết định có tác động cao.

Kiểm soát giúp HITL sẵn sàng cho kiểm toán

Một quy trình HITL hữu ích nên ghi nhận:

• Danh tính người rà soát
• Quyết định phê duyệt hoặc từ chối
• Lý do đưa ra quyết định
• Khuyến nghị ban đầu của agent
• Hành động cuối cùng được thực hiện
• Trạng thái trước/sau khi có liên quan
• Dấu thời gian
• Đường dẫn leo thang
• Tùy chọn rollback

Không có các bản ghi này, HITL có thể hỗ trợ vận hành nhưng không đủ để hỗ trợ kiểm toán hoặc rà soát sự cố.

Khi nào nên thêm kill switch

Kill switch cho phép đội ngũ nhanh chóng dừng một agent hoặc vô hiệu hóa các hành động công cụ cụ thể.

Các đội ngũ nên cân nhắc kill switch cho các trường hợp như:

• Khối lượng gọi công cụ bất ngờ
• Lỗi xác thực lặp lại
• Nỗ lực injection đáng ngờ
• Lộ dữ liệu nhạy cảm
• Chi phí tăng đột biến
• Sự cố mô hình/nhà cung cấp
• Quyết định độ tin cậy thấp lặp lại
• Khiếu nại người dùng hoặc leo thang hỗ trợ bất thường

Kill switch nên được kiểm thử trước khi ra mắt. Nó không nên chỉ tồn tại như một kiểm soát mang tính lý thuyết.

Kiểm Thử và Giám Sát LLM Agent Trước Sản Xuất

QA truyền thống là chưa đủ

QA truyền thống giả định hành vi phần lớn mang tính xác định. LLM agent thì khác. Đầu ra của chúng có thể thay đổi, đường suy luận của chúng có thể thay đổi, và hành động của chúng có thể phụ thuộc vào dữ liệu được truy xuất, phản hồi công cụ, ngữ cảnh người dùng và thiết lập mô hình.

Điều đó có nghĩa là kiểm thử agent cần bao gồm cả đánh giá chức năng và bảo mật. Một quy trình có thể vượt qua kiểm thử happy path nhưng vẫn thất bại trước đầu vào đối kháng, tài liệu bất thường, phản hồi công cụ sai định dạng hoặc các trường hợp ranh giới quyền.

Các loại kiểm thử cốt lõi

Một kế hoạch kiểm thử sẵn sàng cho sản xuất nên bao gồm:

• Kiểm thử hoàn thành tác vụ
• Kiểm thử prompt injection
• Kiểm thử injection gián tiếp
• Kiểm thử quyền công cụ
• Kiểm thử xác thực đối số công cụ
• Kiểm thử rò rỉ dữ liệu
• Kiểm thử truy cập truy xuất RAG
• Kiểm thử quy trình HITL
• Kiểm thử hồi quy
• Kiểm thử chi phí và độ trễ
• Kiểm thử chế độ thất bại
• Kiểm thử rollback và kill switch

Kiểm thử bảo mật nên bao gồm các quy trình kinh doanh thực tế, không chỉ các prompt nhân tạo.

Xây dựng bộ đánh giá

Bộ đánh giá giúp đội ngũ kiểm thử agent một cách nhất quán trước khi phát hành. Nó nên bao gồm:

• Một tập hợp ca kiểm thử có phiên bản
• Kết quả kỳ vọng hoặc tiêu chí chấm điểm
• Ví dụ đối kháng
• Tác vụ người dùng thực tế
• Kịch bản sử dụng công cụ
• Kiểm tra vi phạm chính sách
• Theo dõi hồi quy qua các thay đổi mô hình hoặc prompt
• Báo cáo có thể được các đội ngũ kỹ thuật, bảo mật và sản phẩm rà soát

Bộ đánh giá nên chạy trước các bản phát hành lớn và bất cứ khi nào prompt, công cụ, mô hình, logic truy xuất hoặc quy tắc chính sách thay đổi.

Tín hiệu giám sát cần xác định trước khi ra mắt

Giám sát nên được thiết kế trước khi agent đi vào hoạt động. Các tín hiệu hữu ích bao gồm:

• Tần suất gọi công cụ
• Xác thực thất bại
• Hành động bị chặn
• Tỷ lệ phê duyệt và từ chối HITL
• Thử lại lặp lại
• Bất thường về token và chi phí
• Độ trễ tăng đột biến
• Phát hiện dữ liệu nhạy cảm
• Mẫu prompt đáng ngờ
• Truy cập dữ liệu bất ngờ
• Khiếu nại của người dùng
• Nỗ lực vi phạm chính sách

Những tín hiệu này nên đưa vào cảnh báo, dashboard và quy trình ứng phó sự cố.

Giám sát sản xuất sau khi phát hành

Kiểm thử không kết thúc khi ra mắt. LLM agent có thể trôi lệch khi dữ liệu, công cụ, prompt, mô hình và hành vi người dùng thay đổi.

Góc nhìn vòng đời này phù hợp với NIST AI Risk Management Framework, vốn tổ chức công việc rủi ro AI quanh quản trị, lập bản đồ, đo lường và quản lý. Với LLM agent, điều đó có nghĩa là đội ngũ nên lập bản đồ rủi ro trước triển khai, đo lường hành vi thông qua đánh giá và giám sát, đồng thời quản lý thất bại thông qua cảnh báo, đường dẫn rollback và ứng phó sự cố.

Sau khi phát hành, các đội ngũ nên rà soát:

• Agent có còn đáp ứng mục tiêu hoàn thành tác vụ hay không
• Các chặn bảo mật có đang tăng lên hay không
• Người rà soát HITL có thường xuyên ghi đè agent hay không
• Mẫu chi phí có ổn định hay không
• Người dùng có phát hiện các chế độ thất bại mới hay không
• Bất kỳ thay đổi nào từ mô hình hoặc nhà cung cấp có ảnh hưởng đến hành vi hay không

Giám sát sản xuất biến bảo mật LLM từ một danh sách kiểm tra một lần thành một thực hành vận hành liên tục.

Danh Sách Kiểm Tra Bảo Mật LLM để Triển Khai An Toàn

Kiểm soát kiến trúc

Trước khi ra mắt, hãy xác nhận:

• Luồng dữ liệu đã được lập bản đồ.
• Các lớp dữ liệu nhạy cảm đã được xác định.
• Quyền công cụ đã được tài liệu hóa.
• Kiểm soát truy cập RAG đã được kiểm thử.
• Thiết lập mô hình và nhà cung cấp đã được rà soát.
• Thiết lập khu vực và lưu giữ đã được xác nhận.
• Bí mật được giữ ngoài prompt và nhật ký.
• Các môi trường được tách biệt.

Kiểm soát bảo mật

Xác nhận:

• Phòng thủ prompt injection đã được kiểm thử.
• Các trường hợp injection gián tiếp đã được đưa vào đánh giá.
• Danh sách cho phép công cụ được thực thi.
• Đối số công cụ được xác thực phía máy chủ.
• Đầu ra công cụ được xem là dữ liệu không đáng tin cậy.
• Quyền truy cập tối thiểu được áp dụng.
• Hành động rủi ro cao có cổng kiểm soát.
• Nhật ký kiểm toán được bật.
• Giới hạn tốc độ và timeout được cấu hình.

Kiểm soát tuân thủ

Xác nhận:

• Lưu giữ dữ liệu được tài liệu hóa.
• Rà soát nhà cung cấp/đơn vị xử lý phụ đã hoàn tất.
• Chính sách giám sát của con người được xác định.
• Quy trình rủi ro cao có thể kiểm toán.
• Kiểm soát truy cập dựa trên vai trò.
• Các bước ứng phó sự cố được tài liệu hóa.
• Quy trình xóa và truy cập dữ liệu được hiểu rõ.
• Đội ngũ pháp lý và tuân thủ đã rà soát các yêu cầu liên quan.

Kiểm soát phát hành

Xác nhận:

• Bộ đánh giá đã vượt qua.
• Kiểm thử hồi quy đã hoàn tất.
• Các ca kiểm thử bảo mật đã được rà soát.
• Cảnh báo giám sát đã được cấu hình.
• Đường dẫn rollback đã được kiểm thử.
• Kill switch đã được kiểm thử.
• Chủ sở hữu sau phát hành đã được chỉ định.
• Nhịp rà soát đã được lên lịch.

Một lần ra mắt an toàn không chỉ là một cột mốc kỹ thuật. Đó là một cam kết vận hành.

HDWEBSOFT Giúp Đội Ngũ Bảo Mật Hệ Thống LLM và Agentic AI Như Thế Nào

Triển khai agent vận hành bởi LLM một cách an toàn đòi hỏi cả kỹ thuật AI và tư duy bảo mật. Các đội ngũ cần thiết kế quy trình làm việc, tích hợp công cụ, bảo vệ dữ liệu, kiểm thử hành vi và giám sát hệ thống sản xuất mà không làm chậm tiến độ bàn giao một cách không cần thiết.

HDWEBSOFT giúp các đội ngũ lập kế hoạch, xây dựng và bảo mật hệ thống AI bằng hỗ trợ kỹ thuật thực tiễn. Nếu tổ chức của bạn đang chuẩn bị triển khai LLM hoặc agentic AI, đội ngũ của chúng tôi có thể hỗ trợ thiết kế kiến trúc, triển khai quy trình AI, tích hợp công cụ, rà soát bảo mật và sẵn sàng sản xuất.

Khám phá dịch vụ phát triển AI của chúng tôi để triển khai AI an toàn và dịch vụ an ninh mạng để đánh giá bảo mật, rà soát rủi ro và tăng cường kiểm soát sản xuất.

Kết Luận

Bảo mật LLM không phải là một prompt, một chính sách hay một danh sách kiểm tra. Đối với agentic AI, nó phải bao phủ toàn bộ hệ thống: prompt, dữ liệu được truy xuất, công cụ, quyền, nhật ký, phê duyệt của con người, kiểm thử và giám sát sản xuất.

Những đội ngũ triển khai an toàn sẽ là những đội ngũ xem bảo mật là một phần của kiến trúc ngay từ đầu. Kiểm soát prompt injection, quyền truy cập công cụ tối thiểu, lập kế hoạch lưu trú dữ liệu, quy trình HITL và đánh giá liên tục cùng hoạt động để giảm rủi ro.

Đối với môi trường sản xuất EU/US, mục tiêu không chỉ là làm cho agent hữu ích. Mục tiêu là làm cho nó được kiểm soát, có thể kiểm toán, có khả năng phục hồi và đủ an toàn để vận hành trong các quy trình kinh doanh thực tế.

FAQ

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

Bảo mật LLM là thực hành bảo vệ các hệ thống vận hành bởi LLM khỏi prompt injection, rò rỉ dữ liệu, sử dụng công cụ trái phép, đầu ra không an toàn và các lỗi tuân thủ. Với agentic AI, bảo mật LLM còn bao gồm quyền công cụ, nhật ký kiểm toán, quy trình HITL, kiểm thử và giám sát.

Vì sao bảo mật LLM khó hơn đối với AI agent?

Bảo mật LLM khó hơn đối với AI agent vì agent có thể thực hiện hành động. Chúng có thể truy xuất tài liệu, gọi API, cập nhật hệ thống hoặc kích hoạt quy trình làm việc. Điều đó có nghĩa là bảo mật phải bảo vệ không chỉ đầu ra của mô hình mà cả các công cụ và dữ liệu được kết nối với agent.

Làm thế nào để ngăn prompt injection trong LLM agent?

Ngăn chặn prompt injection đòi hỏi các biện pháp kiểm soát theo nhiều lớp. Các đội ngũ nên tách biệt chỉ dẫn đáng tin cậy khỏi nội dung không đáng tin cậy, xác thực lệnh gọi công cụ, áp dụng quyền truy cập tối thiểu, xem nội dung được truy xuất là dữ liệu, bổ sung kiểm tra chính sách, giám sát các mẫu đáng ngờ và kiểm thử bằng các trường hợp đối kháng.

Prompt injection gián tiếp là gì?

Prompt injection gián tiếp xảy ra khi chỉ dẫn độc hại được ẩn bên trong nội dung mà agent đọc, chẳng hạn như trang web, email, tài liệu, phiếu hỗ trợ, PDF hoặc kết quả RAG. Agent có thể xem nội dung đó như một chỉ dẫn trừ khi hệ thống được thiết kế để cô lập và xác thực nó.

Làm thế nào để bảo mật việc gọi công cụ cho LLM agent?

Gọi công cụ an toàn đòi hỏi quyền truy cập tối thiểu, API theo phạm vi, danh sách cho phép công cụ, schema có cấu trúc, xác thực đối số phía máy chủ, xác thực đầu ra, giới hạn tốc độ, sandbox cho công cụ rủi ro cao, quản lý bí mật và ghi nhật ký kiểm toán cho các hành động công cụ.

Lưu trú dữ liệu ảnh hưởng đến ứng dụng LLM như thế nào?

Lưu trú dữ liệu ảnh hưởng đến nơi prompt, tài liệu được truy xuất, embedding, đầu ra và nhật ký được xử lý và lưu trữ. Các triển khai tại EU/US nên lập bản đồ luồng dữ liệu, rà soát thiết lập nhà cung cấp, cấu hình thời gian lưu giữ và chọn các mẫu kiến trúc phù hợp với yêu cầu quyền riêng tư và tuân thủ.

Các đội ngũ nên kiểm thử điều gì trước khi triển khai LLM agent?

Các đội ngũ nên kiểm thử mức độ hoàn thành tác vụ, khả năng chống prompt injection, kịch bản injection gián tiếp, quyền công cụ, rò rỉ dữ liệu, kiểm soát truy cập RAG, luồng phê duyệt HITL, hành vi hồi quy, cảnh báo giám sát, độ trễ, hành vi chi phí, đường dẫn rollback và hành vi kill switch.