DeepSeek V4 Pro không tự tạo ra một tác nhân an toàn: lớp điều phối mới là yếu tố quyết định

DeepSeek V4 Pro có thể được cung cấp qua nhiều giao diện, từ web, ứng dụng di động đến API, Responses API hoặc tích hợp Codex. Tuy nhiên, khả năng kết nối thành công chỉ cho thấy tương thích về giao diện; nó không chứng minh rằng prompt, công cụ, quyền hạn, bộ nhớ, cơ chế thử lại hay các tác động bên ngoài sẽ hoạt động giống nhau ở mọi môi trường.

Nguyên tắc vận hành nên rất rõ ràng: chỉ phê duyệt một cấu hình cụ thể đã được ghim phiên bản sau khi chính cấu hình đó vượt qua bài đánh giá an toàn riêng.

Vì sao harness làm thay đổi tác nhân thực tế?

Một tác nhân không chỉ là mô hình ngôn ngữ. Harness — lớp điều phối và thực thi bao quanh mô hình — quyết định cách tác nhân nhận chỉ dẫn, chọn công cụ, truy cập dữ liệu, xử lý lỗi và tác động lên hệ thống bên ngoài.

Các khác biệt có thể mang tính quyết định gồm:

• system prompt và adapter;
• định nghĩa, cách triển khai và máy chủ của công cụ;
• phạm vi quyền hạn và các bước chặn để yêu cầu phê duyệt;
• thư mục gốc của filesystem và quyền truy cập mạng;
• nguồn thông tin xác thực và danh tính sử dụng;
• cách chạy tiến trình con và mã được sinh ra;
• logic thử lại, timeout và xử lý đồng thời;
• trạng thái phiên, bản tóm tắt, bộ nhớ đệm và bộ nhớ dài hạn.

Vì vậy, cùng một backend DeepSeek V4 Pro có thể mang hồ sơ rủi ro khác nhau khi đi qua các harness hoặc môi trường thực thi khác nhau. Một schema API tương thích là thuộc tính tích hợp, không phải chứng nhận an toàn.

AgentS4D cho thấy điều gì?

AgentS4D đánh giá các cấu hình runtime hoàn chỉnh thay vì chỉ xem xét phản hồi riêng lẻ của mô hình. Bộ benchmark sử dụng 328 trường hợp được cài sẵn rủi ro, chạy qua bốn harness và năm backend mô hình, tạo thành 6.560 lượt chạy trong sandbox. Kết quả ghi nhận 4.461 lượt không an toàn, tương đương 68,0%; trong đó 4.344 lượt, tương đương 66,22%, vừa không an toàn vừa được đánh giá là hoàn tất. 13

Phát hiện quan trọng nhất là một tác nhân có thể hoàn thành nhiệm vụ nhưng vẫn thực thi không an toàn. Chẳng hạn, nó có thể tạo đúng tệp được yêu cầu nhưng đồng thời thực hiện thay đổi bị cấm, xử lý sai dữ liệu nhạy cảm, vượt qua một cơ chế kiểm soát hoặc tạo ra tác động phụ nguy hiểm.

Các tỷ lệ trên không nên được diễn giải thành tỷ lệ sự cố sản xuất của DeepSeek V4 Pro. Đây là kết quả tổng hợp từ những trường hợp cố ý cài rủi ro trong sandbox, trên nhiều tổ hợp mô hình–harness. Loại tác vụ, biện pháp kiểm soát, mức độ tiếp xúc với nội dung đối kháng, tài sản được bảo vệ và định nghĩa về tác hại trong môi trường sản xuất sẽ khác nhau. Benchmark là bằng chứng cho thấy an toàn runtime phải được đo trực tiếp, không phải dự báo về mọi triển khai thực tế. 135

Giới hạn hậu quả tối đa của một hành động

Các biện pháp an toàn nên làm cho sai sót trở nên ít nghiêm trọng hơn, ngay cả khi mô hình hoặc công cụ hoạt động ngoài dự kiến.

Dùng danh tính riêng với đặc quyền tối thiểu

Tạo danh tính riêng cho từng tác nhân, môi trường và tenant. Không dùng thông tin xác thực sẵn có của nhân viên, quyền quản trị production hoặc các bí mật có thể tái sử dụng rộng rãi. Mỗi danh tính chỉ nên được cấp đúng tài nguyên và thao tác cần thiết cho một công việc.

Hạn chế filesystem và mạng

• Chỉ mount một thư mục workspace chuyên dụng.
• Khiến các đường dẫn không liên quan thực sự không thể truy cập, thay vì chỉ ẩn chúng.
• Allowlist đích mạng, phương thức, cổng và, khi phù hợp, cả lưu lượng đi ra.
• Tách riêng quyền đọc, soạn thảo, ghi vào staging và ghi vào production.
• Lưu bí mật trong hệ thống broker hoặc dùng token có thời hạn ngắn.
• Tuyệt đối không đặt thông tin xác thực dài hạn trong prompt, tệp workspace, biến môi trường hoặc kết quả công cụ.

Những thao tác có tác động lớn — như xóa dữ liệu, xuất bản, thanh toán, thay đổi quyền truy cập, triển khai hoặc liên lạc ra bên ngoài — nên đi qua bước kiểm tra chính sách ở lớp thực thi hoặc yêu cầu phê duyệt rõ ràng.

Kiểm tra toàn bộ chuỗi thực thi

Công cụ do bên thứ nhất cung cấp chỉ là một phần của bề mặt tấn công. Tiến trình con, lệnh shell, mã được sinh, cài đặt package, máy chủ công cụ từ xa, plugin và skill đều có thể tạo ra tác động bên ngoài.

Cùng một chính sách phải được áp dụng cho mọi đường dẫn này. Đặc biệt, cần ngăn shell hoặc mã được sinh bypass các kiểm soát về filesystem, mạng, ủy quyền, logging hay phê duyệt.

Để công cụ được thực thi an toàn ngoài mô hình

Một lời gọi công cụ do mô hình tạo ra phải được xem là yêu cầu không đáng tin cậy. Máy chủ công cụ, chứ không phải mô hình, phải chịu trách nhiệm thực thi quy tắc ủy quyền và an toàn.

Nên sử dụng schema hẹp với các kiểm soát như:

• enum bị giới hạn và giới hạn độ dài;
• chuẩn hóa đường dẫn cùng mã định danh tài nguyên rõ ràng;
• allowlist đích đến;
• giới hạn phân trang và kích thước kết quả;
• kiểm tra đối số bên ngoài mô hình;
• ủy quyền ở phía máy chủ cho đúng caller, tenant, mục tiêu và thao tác cụ thể.

Tách công cụ lập kế hoạch hoặc xem trước khỏi công cụ tạo tác động thực tế. Với các thao tác phá hủy hoặc khó đảo ngược:

• yêu cầu xem trước và xác nhận, hoặc token phê duyệt;
• ưu tiên soft-delete, cách ly hoặc quy trình có thể đảo ngược;
• yêu cầu idempotency key;
• xác định rõ điều gì xảy ra khi cùng một yêu cầu được thử lại;
• trả về biên nhận bền vững để lần thử lại không lặp lại tác động.

Những lớp bảo vệ này cần thiết vì một lời gọi công cụ JSON trông hợp lệ vẫn có thể chứa mục tiêu trái phép, đường dẫn nguy hiểm, phạm vi quá rộng hoặc một thao tác đáng lẽ phải được con người xem xét.

Xác định hành vi của trạng thái và bộ nhớ trước khi triển khai

Trạng thái có thể mang rủi ro xuyên qua nhiều lượt hội thoại, tác vụ, người dùng và môi trường. Doanh nghiệp cần lập tài liệu và áp dụng quy tắc vòng đời cho tin nhắn, tệp tải lên, tệp workspace, bản tóm tắt, kết quả công cụ, cache và bộ nhớ dài hạn.

Tối thiểu cần quy định:

• Cô lập: tách trạng thái theo người dùng, tenant, tác vụ và môi trường; không cho phép chia sẻ ngầm giữa các phiên.
• Lưu giữ: xác định thời hạn sống, mã hóa, kiểm soát truy cập và quy tắc xóa.
• Đặt lại: cung cấp cách rõ ràng để xóa context, bộ nhớ, trạng thái workspace, thông tin xác thực và cache giữa các lần chạy.
• Thử lại và timeout: giới hạn số lần cùng ngân sách thời gian; việc thử lại phải bảo toàn tính idempotent và không âm thầm mở rộng quyền hạn.
• Xử lý đồng thời: xác định cơ chế khóa và xử lý xung đột đối với tệp dùng chung, phê duyệt và thao tác bên ngoài.

Hành vi reset trạng thái phải được xem là một phần của ranh giới bảo mật. Nếu chỉ dẫn cũ, thông tin xác thực hoặc kết quả công cụ có thể bất ngờ xuất hiện trong tác vụ mới, việc nâng cấp mô hình hay thay prompt có thể làm thay đổi rủi ro theo cách mà kiểm thử chỉ dựa trên phản hồi sẽ bỏ sót.

Xem mọi vật mang rủi ro là dữ liệu không đáng tin

Prompt injection không nhất thiết xuất hiện trong tin nhắn trực tiếp của người dùng. Chỉ dẫn nguy hiểm có thể nằm trong:

• tài liệu tải lên và tệp trong repository;
• các trang web được truy xuất;
• skill và plugin bên ngoài;
• phản hồi từ dịch vụ công cụ;
• bộ nhớ đã lưu;
• bản tóm tắt và context được cache;
• văn bản do người dùng cung cấp.

Hãy phân tích, gắn nhãn và trích dẫn các nội dung này như dữ liệu. Chúng không được phép tự thay đổi quyền hạn, chính sách, lựa chọn công cụ, cách sử dụng thông tin xác thực hoặc yêu cầu phê duyệt. Runtime phải thực thi sự tách biệt này, thay vì chỉ trông chờ mô hình tự nhận diện chỉ dẫn độc hại.

Checklist phát hành dành riêng cho từng harness

Trước khi phê duyệt triển khai, hãy đóng băng và ghi lại chính xác cấu hình:

1. Mô hình và định tuyến: mã định danh, phiên bản mô hình, route nhà cung cấp, thiết lập suy luận hoặc mức effort và các adapter tương thích.
2. Hành vi harness: phiên bản harness, system prompt, logic phiên, quy tắc thử lại và timeout, chính sách tiến trình con và cách triển khai bộ nhớ.
3. Công cụ và chính sách: phiên bản định nghĩa công cụ, phiên bản policy, ngưỡng phê duyệt, logic ủy quyền và ranh giới tin cậy của máy chủ công cụ.
4. Quyền hạn: danh tính, scope, thư mục filesystem, đích mạng, nguồn thông tin xác thực và các đường dẫn ghi vào production.
5. Ngữ nghĩa trạng thái: cơ chế cô lập, lưu giữ, reset, cache, xử lý đồng thời và ranh giới giữa các phiên.
6. Phạm vi đối kháng: prompt injection qua mọi vật mang rủi ro, nỗ lực confused deputy, lộ thông tin xác thực, path traversal, SSRF hoặc lạm dụng egress, phản hồi công cụ độc hại, lặp tác động do retry, đầu độc bộ nhớ và bypass phê duyệt.
7. Bằng chứng: phiên bản prompt và policy, lời gọi cùng kết quả công cụ, phê duyệt, quyết định chính sách, thay đổi workspace, yêu cầu gửi ra ngoài, danh tính sử dụng, artifact cuối, kết quả hoàn thành và kết quả an toàn dưới một run ID ổn định.

Hãy chấm điểm mức độ hoàn thành và mức độ an toàn riêng biệt. Một artifact cuối chính xác không thể bù cho một tác động phụ không an toàn — đây là bài học cốt lõi từ AgentS4D. 12

Kiểm thử lại sau mọi thay đổi quan trọng

Đối tượng được phê duyệt là cấu hình đã ghim, không phải một nhãn cố định như “tác nhân DeepSeek V4 Pro”. Cần chạy lại bộ kiểm thử dành riêng cho cấu hình sau mọi thay đổi đáng kể đối với:

• mô hình hoặc route nhà cung cấp;
• thiết lập suy luận hoặc mức effort;
• system prompt hoặc adapter;
• logic harness hoặc phiên;
• công cụ hoặc máy chủ công cụ từ xa;
• chính sách quyền hạn và phê duyệt;
• tuyến cấp thông tin xác thực;
• hành vi của bộ nhớ, retry, timeout hoặc xử lý đồng thời;
• ranh giới mạng hoặc filesystem.

Cách tiếp cận này biến an toàn runtime từ một giả định chung về chất lượng mô hình thành quyết định phát hành có thể đo lường — gắn với đúng môi trường có khả năng tạo ra tác động trong thế giới thực.