Bốn cách triển khai AI Agent an toàn hơn

Người lao động tri thức ngày càng tích hợp các tác nhân AI vào quy trình làm việc của họ. Các tác nhân hoạt động như “đồng nghiệp kỹ thuật số” mang lại lợi ích rõ ràng. Ví dụ, chúng có thể xem xét báo cáo lỗi, thực hiện và kiểm tra bản sửa lỗi, đẩy bản vá, và thông báo cho con người để xem xét. Bằng cách xử lý các nhiệm vụ thường ngày, các tác nhân có tiềm năng mang lại lợi ích năng suất lớn. Mặt khác, kết nối mô hình ngôn ngữ lớn (LLM) với các công cụ trực tiếp và dữ liệu doanh nghiệp thông qua khung tác nhân có nguy cơ biến trợ thủ hữu ích thành phần mềm đặc quyền với bề mặt tấn công chưa được hiểu rõ.

Trong sáu tháng qua, Nhóm Đỏ AI NVIDIA đã đánh giá nhiều tác nhân AI—từ các công cụ mã hóa tương tác đơn giản đến trợ lý kỹ thuật số tự động luôn bật. Khi một tác nhân được chứng minh là có thể khai thác, chúng tôi thường thấy các chế độ thất bại chính giống nhau, bất kể framework hay khung được sử dụng, bao gồm:

• Thiếu kiểm soát truy cập đối với tác nhân.
• Công cụ tác nhân cho phép thực thi mã tùy ý.
• Không có kiểm soát mạng ra.
• Bí mật được tiết lộ cho agent dưới dạng văn bản thuần.

Trong bài viết này, chúng tôi kiểm tra các chế độ thất bại này và mô tả các kiểm soát thành công dưới áp lực thù địch. Trong khi các ví dụ của chúng tôi tập trung vào các agent kết nối chat—phần lớn trong số đó chúng tôi gặp trong đánh giá—các mô hình tổng quát hóa cho bất kỳ agent nào.

Triển khai kiểm soát truy cập agent

Chế độ thất bại phổ biến nhất trong các triển khai AI hiện tại là thiếu kiểm soát truy cập đối với agent. Chúng tôi phát hiện nhiều agent nắm giữ thông tin xác thực cho người dùng cá nhân và có thể truy cập bởi bất kỳ người dùng được ủy quyền nào trong mạng nội bộ. Mặc dù điều này mở đường cho việc lạm dụng thông tin xác thực hợp pháp của các agent, nó cũng thường cho phép chúng tôi thu thập những thông tin xác thực đó và sử dụng chúng ngoài ngữ cảnh dự kiến của agent, như được thể hiện trong các ví dụ sau.

Khuyến nghị:

• Sử dụng kiểm soát truy cập mạnh mẽ như tuyến phòng thủ đầu tiên chống lại hoạt động bất lợi.
• Hạn chế mỗi agent chỉ cho người dùng được ủy quyền rõ ràng; các agent không phản hồi người dùng không được ủy quyền khó kiểm tra hơn đáng kể.
• Khớp quyền của agent với quyền của người dùng gọi nó, theo nguyên tắc đặc quyền tối thiểu.

Hạn chế thực thi mã

Nhiều harness expose một vỏ Bash hoặc công cụ thực thi lệnh. Chúng thường được sử dụng vì tính tổng quát của chúng. Chúng hỗ trợ nhiều nhiệm vụ thông thường, mà không yêu cầu một công cụ riêng biệt cho mỗi chức năng. Tuy nhiên, khi đầu ra của mô hình kiểm soát việc thực thi lệnh, một kẻ tấn công có thể ảnh hưởng đến đầu ra đó—qua đầu vào trực tiếp, hoặc tiêm lời nhắc gián tiếp—có thể chạy lệnh trong môi trường thực thi. Điều này có thể cho phép họ đạt được các kết quả độc hại như đánh cắp dữ liệu hoặc duy trì thực thi trên máy chủ.

Các biện pháp giảm thiểu phổ biến cho rủi ro thực thi lệnh tùy tiện này thường liên quan đến việc sử dụng các agent đánh giá LLM-as-a-judge để chặn các lệnh có hại hoặc độc hại chạy, việc sử dụng danh sách cho phép cho các lệnh chấp nhận được, hoặc đơn giản là tin rằng mô hình “biết tốt hơn.” Tất cả đều cung cấp bảo vệ hạn chế chống lại sự thao túng đối kháng.

Nhiều tác vụ dòng lệnh agentic phổ biến hỗ trợ các quy trình phát triển chung và phát triển dựa trên kiểm thử. Điều này có nghĩa là chúng thường yêu cầu khả năng thực thi các lệnh như pytest hoặc npm install, nghĩa là các mô hình LLM-as-a-judge thường có xu hướng chấp nhận việc thực thi các lệnh này. Tuy nhiên, khi bị ảnh hưởng bởi đầu vào do kẻ tấn công kiểm soát, các lệnh này tương đương với việc thực thi lệnh tùy ý.

Trong một số trường hợp, việc đạt được thực thi mã từ xa đầy đủ (RCE) với shell ngược đơn giản như yêu cầu agent viết và thực thi một tập lệnh Python hoặc cài đặt một gói từ xa, như đã trình bày trong bài viết blog trước đây của chúng tôi về chủ đề này.

Ngay cả khi không có công cụ dòng lệnh, khả năng tương tác với môi trường mà agent đang chạy thông qua các công cụ đọc và ghi tệp cũng thường mở ra các đường dẫn không mong muốn đến thực thi mã và leo thang đặc quyền.

Một kẻ tấn công có thể ghi nội dung vào các tệp hệ thống như ~/.bashrc hoặc ~/.zshrc, hoặc các tệp cấu hình như ~/.gitconfig, hooks.json, MCP.json, hoặc các tệp kỹ năng, có thể đạt được thực thi mã khi một quá trình khác thực thi tệp liên quan, ngay cả khi thực thi dòng lệnh không trực tiếp khả dụng. Các vị trí và tệp mà agent có thể ghi vào phải được kiểm soát nghiêm ngặt và giới hạn ở các vị trí không thể thực thi.

Khuyến nghị:

• Xử lý thực thi mã tùy ý là rủi ro có tác động cao nhất trong một tác tử có thể truy cập.
• Tránh các công cụ dòng lệnh bất cứ khi nào có thể.
• Chặn ghi ra ngoài không gian làm việc không thể thực thi ở cấp độ hệ điều hành.
• Nếu yêu cầu công cụ thực thi dòng lệnh, hãy sử dụng danh sách cho phép nghiêm ngặt với đặc quyền tối thiểu cho các lệnh có thể thực thi, và chạy công cụ trong môi trường thực thi cô lập với các điều khiển truy cập mạng mạnh mẽ, như chúng tôi sẽ chi tiết tiếp theo.
• Hãy thận trọng khi xử lý các đối số hoặc chuỗi như tên tệp, tiêu đề tài liệu, và dữ liệu bên ngoài khác qua dòng lệnh. Đảm bảo rằng chúng được làm sạch và chuẩn hóa trước khi sử dụng để ngăn ngừa các vấn đề như traversal đường dẫn hoặc command injection.

Từ chối truy cập mạng đi theo mặc định

Các kết nối mạng đi cho phép trích xuất dữ liệu và tạo kết nối trực tiếp, như reverse shells và SOCKS, qua đó kẻ tấn công có thể tương tác trực tiếp với môi trường chạy của agent. Khi các điều khiển truy cập mạng đi được thực thi và có đặc quyền tối thiểu phù hợp, chúng tôi chạy tất cả các tương tác của mình qua tiến trình agent, làm chậm tốc độ thực thi và làm cho tác động ít đáng tin cậy hơn. Duy trì trạng thái và căn chỉnh của agent, điều hướng các bộ lọc đầu ra, và khởi động lại và điều khiển các phiên sau khi agent bắt đầu từ chối yêu cầu, tất cả đều thêm gánh nặng vận hành.

Khuyến nghị:

• Áp dụng chính sách từ chối mặc định cho mạng đi ra, với danh sách cho phép ít đặc quyền nhất của các điểm cuối được giới hạn trong tập hợp tối thiểu cần thiết cho các nhiệm vụ mà tác tử dự kiến thực hiện.
• Thực thi các hạn chế này tại mọi ranh giới mạng mà tác tử chạm vào bằng cách sử dụng các điều khiển môi trường không thể truy cập bởi tác tử.

Giữ bí mật ngoài tầm với của tác tử

Các đại lý thường yêu cầu quyền truy cập vào bí mật để thực hiện chức năng dự định: mã thông báo nền tảng, khóa API, mã thông báo truy cập hệ thống kiểm soát phiên bản (VCS), và trong một số trường hợp thậm chí cả mã thông báo làm mới OAuth. Trong khi lời khuyên bảo mật thông thường đề xuất tiêm bí mật dưới dạng biến môi trường trong bộ nhớ để ngăn chúng được ghi vào đĩa, điều này hợp lý khi chỉ code của bạn chạy trong một container.

Khi một đại lý có khả năng thực thi lệnh chia sẻ môi trường đó, ép nó chạy env, printenv, hoặc /proc/self/environ cho phép kiểm tra trực tiếp chúng. Các công cụ dòng lệnh đáng được nhấn mạnh là đặc biệt rủi ro cao. CLIs lưu trữ thông tin xác thực trên đĩa ở các vị trí có thể dự đoán và in chúng trở lại dễ dàng. Chúng tôi đã quan sát thấy mã thông báo trong các kho lưu trữ git, tệp .env, lịch sử bash, tệp .netrc, mã thông báo làm mới OAuth 2.0 và biến môi trường trong môi trường thực thi.

Ngay cả khi chúng tôi không thể thiết lập một shell đảo ngược, chúng tôi thường có thể trích xuất thông tin xác thực qua giao diện trò chuyện. Sử dụng cách tiếp cận “nấu ếch” (xem bên dưới), chúng tôi dẫn dắt các đại lý tiết lộ một số bí mật bị lộ ra bên trong môi trường thực thi của chính họ. Kiểm soát xuất cảnh ngăn chặn trích xuất trực tiếp qua mạng hoặc kiểm tra trực tiếp trong hệ thống tệp, nhưng thông tin xác thực vẫn bị lộ trong môi trường và có thể truy cập bởi LLM, mà đã chuyển chúng cho chúng tôi qua giao diện trò chuyện.

Khuyến nghị:

• Không bao giờ làm cho bí mật cố định có thể truy cập được cho một tác nhân.
• Lưu trữ bí mật trong một trình quản lý bí mật chuyên dụng.
• Truy xuất bí mật theo yêu cầu chỉ trong bộ nhớ của các quy trình yêu cầu chúng.
• Giữ bí mật ngoài cửa sổ ngữ cảnh và môi trường thực thi của tác nhân.
• Khi một nhiệm vụ yêu cầu thông tin xác thực, hãy sử dụng token có thời gian sống ngắn, phạm vi hẹp, và thu hồi token ngay sau khi nhiệm vụ hoàn thành.

Sử dụng điều khiển xác định làm tuyến phòng thủ đầu tiên của bạn

Cố gắng giảm thiểu thường gặp nhất mà chúng tôi gặp phải là một prompt hệ thống yêu cầu mô hình tránh các hành vi rủi ro hoặc nguy hiểm, đôi khi được củng cố bởi một mô hình thứ hai đánh giá đầu vào hoặc đầu ra (mẫu LLM-as-a-judge). Tất cả đều được thực thi bởi một LLM, và kế thừa cùng một hành vi xác suất, không đáng tin cậy của chính LLM đó.

Ba kỹ thuật chung đánh bại đáng tin cậy các loại điều khiển này. Chúng tôi trình bày từng kỹ thuật trên nhiều hệ thống.

Kỹ thuật xã hội tác nhân

Chỉ cần đưa cho agent một ngữ cảnh trong đó các hoạt động độc hại có vẻ hợp pháp đã mang lại hiệu quả đáng kinh ngạc. Chúng tôi thường gợi ý cho agent rằng chúng tôi đang “gỡ lỗi” hoặc là “người dùng quản trị”, sau đó nó thường xuyên tuân theo yêu cầu của chúng tôi. Một agent thậm chí còn đi xa đến mức viết và thực thi một reverse shell cho chúng tôi:

In other cases, it was possible to directly manipulate agent memory and AGENT.md files by instructing the agent to use file editing tools, which also allowed the construction of “debugging” and “authorized user” frames.

Luộc ếch

“Kỹ thuật luộc ếch” (đôi khi được gọi là Crescendo attack) dần dần thúc đẩy đại lý vào hành vi mong muốn qua nhiều tương tác, sử dụng lịch sử hội thoại trước đó để thiết lập độ tin cậy và bản chất vô hại của các yêu cầu. Việc trích xuất bí mật được tiến hành bằng cách cố gắng thực hiện các quy trình công việc có vẻ hợp pháp theo cách gây ra lỗi, và sau đó cuối cùng “phát hiện” rằng nguyên nhân cơ bản của lỗi liên quan đến bí mật, thuyết phục đại lý tiết lộ chúng cho chúng tôi.

Đánh lạc hướng qua các quy trình công việc hợp pháp

Các cuộc tấn công đánh lạc hướng chẳng hạn như cài đặt gói (được mô tả lần đầu trong From Prompts to Pwns tại Black Hat 2025) vẫn cực kỳ hiệu quả. Bằng cách thúc đẩy đại lý thực hiện một hành động có vẻ vô hại nhưng có thực thi mã là hiệu ứng phụ, thường dễ dàng vượt qua bất kỳ sự kháng cự nào từ đại lý.

Các tác nhân mã hóa thường cài đặt thư viện. Tạo một thư viện độc hại như được mô tả trong bài viết này và sau đó yêu cầu tác nhân cài đặt nó thông qua pip install git+https://… có vẻ là một yêu cầu tiêu chuẩn; tuy nhiên, gói bị vũ khí hóa tạo ra thực thi mã tùy ý trong quá trình cài đặt.

Điều khiển được đề xuất

Một phát hiện nhất quán là các biện pháp phòng thủ trong cùng một mặt phẳng kiểm soát với LLM, đặc biệt là các biện pháp phòng thủ dựa trên prompt, thường bị vô hiệu hóa. Các điều khiển phải được thực thi bên ngoài mặt phẳng kiểm soát của mô hình.

Các điều khiển được đề xuất, theo thứ tự quan trọng tương đối, là:

• Sử dụng kiểm soát truy cập trên agent. Chỉ người dùng cụ thể, đã xác thực mới tương tác agent.
• Chạy thực thi lệnh tùy ý chỉ trong sandbox như Docker, NVIDIA OpenShell, hoặc máy ảo. Môi trường tăng cường chống thoát. Không tự cấu hình bằng sửa tệp môi trường/agent.
• Từ chối mặc định thoát mạng dùng danh sách cho phép đặc quyền tối thiểu tài nguyên mạng cụ thể, tại mọi ranh giới agent chạm.
• Không lộ bí mật khi nghỉ hay môi trường. Tiêm bí mật biến môi trường tiêu chuẩn app không-agent, nhưng không an toàn cho workload mã tùy ý. Bí mật lưu trình quản lý bí mật, truy cập theo yêu cầu, giới hạn process. Dùng token broker cung cấp token đặc quyền tối thiểu, tạm thời khi có thể.
• Chỉ cho phép cài đặt gói từ kho lưu trữ gói đã được xác nhận. Chặn cài đặt dựa trên URL và VCS tùy ý theo mặc định.
• Công cụ, MCPs, kỹ năng, v.v. có đặc quyền thấp nhất. Chỉ những công cụ công việc yêu cầu; kiểm tra bất cứ thứ gì thực thi, ghi hoặc truy cập mạng.
• Bộ nhớ liên tục có đặc quyền thấp nhất. Tránh gắn kết khối lượng; nếu không thể, giới hạn phạm vi chặt chẽ và không bao giờ gắn bất cứ thứ gì có thể ghi vào đường dẫn sau đó được thực thi.
• Sử dụng các mô hình gần đây/siêu việt, đặc biệt cho các mẫu LLM-as-a-judge, có thể mạnh mẽ hơn trước sự can thiệp đối kháng.

Kết luận

Kinh nghiệm của Đội Red Team AI của chúng tôi trong việc bảo mật các tác nhân AI nhấn mạnh yêu cầu liên tục về các kiểm soát “cứng” có tính quyết định trong việc bảo vệ các tác nhân AI. Các hệ thống tự động hoàn toàn với thông tin xác thực doanh nghiệp vốn dĩ có rủi ro và phải được bảo mật cẩn thận. Trong khi các mô hình tiên tiến làm cho việc thao túng thù địch trở nên khó khăn hơn, với đủ thời gian và chuyên môn, gần như tất cả chúng vẫn có thể bị phá vỡ.

Các lỗ hổng phổ biến mà chúng tôi quan sát thấy bao gồm: kiểm soát truy cập yếu (cho phép bất kỳ người dùng nào truy cập tác nhân), các công cụ thực thi và ghi tệp tạo cơ hội cho RCE, kiểm soát mạng đi ra không đủ cho phép đánh cắp dữ liệu và reverse shells, và bí mật ở dạng văn bản rõ bên trong môi trường thực thi mà tác nhân có thể truy cập.

Các rào chắn dựa trên prompt, bao gồm mô hình LLM-as-a-judge, không đóng bất kỳ lỗ hổng nào trong số này. Các kiểm soát kiến trúc thì có: kiểm soát truy cập vào tác nhân, hộp cát cứng hóa với quyền truy cập tối thiểu vào dữ liệu doanh nghiệp, kiểm soát mạng đi ra mặc định từ chối, và bí mật được giữ ngoài tầm với của tác nhân. Khi được cấu hình và thực thi đúng cách, các kiểm soát này rất hiệu quả trong việc giảm thiểu lạm dụng thù địch đối với các tác nhân AI.

Để tìm hiểu thêm về việc thiết kế các tác tử bảo mật từ nguyên lý cơ bản, hãy xem “Cách Quản lý Các Tác Tử Tự Trong Nhà Máy AI Doanh Nghiệp” Blog Kỹ thuật, hướng dẫn bạn qua các bước đầu tiên để triển khai Thiết Kế Tham Chiếu Không Gian Tác Tử Bảo Mật.

Để tìm hiểu thêm về bảo mật tác tử, đừng bỏ lỡ bài thuyết trình của NVIDIA tại Black Hat USA: Chi phí Hiệu quả, Riêng tư, Cấp Độ Tiên Phong: Khai Thác Tác Tử AI với Mô Hình OSS Được Tinh Chỉnh

Để đọc thêm từ Nhóm AI Đỏ của NVIDIA, hãy xem các bài viết khác.

____
Bài viết liên quan