Nguyên mẫu dsh-superagent của DeepSeek chạy lệnh với quyền người dùng hệ điều hành

DeepSeek vừa công bố dsh-superagent, một nguyên mẫu nghiên cứu được cấp phép MIT cho một agent lập trình tích hợp với GitHub và Feishu để tạo ra các pull request. Được phát hành vào đầu tháng 11 năm 2026, công cụ này được thiết kế để tự động hóa các nhiệm vụ phát triển phần mềm bằng cách lắng nghe các chuỗi trò chuyện và trực tiếp thực hiện thay đổi mã trong kho lưu trữ (repository). Mặc dù hứa hẹn giảm bớt gánh nặng giám sát của con người, mô hình thực thi của nó lại cấp cho agent quyền truy cập đáng kể ở cấp độ hệ thống, đòi hỏi các nhà phát triển lựa chọn chạy nó phải tuân thủ nghiêm ngặt quy trình bảo mật vận hành.

Điều gì đã xảy ra

Kho lưu trữ mới mô tả một agent lập trình chủ động, giới hạn phạm vi hoạt động trong một repository GitHub duy nhất. Khi một người dùng được ủy quyền trực tiếp yêu cầu agent hoặc phản hồi lại một ticket hiện có, hệ thống sẽ tạo ra một đơn vị công việc gọi là Ticket. Sau đó, nó xử lý yêu cầu trong một phiên làm việc và thư mục riêng biệt, cuối cùng trả lời lại chuỗi hội thoại ban đầu với kết quả, chẳng hạn như một pull request hoặc yêu cầu làm rõ thêm. Quá trình thiết lập cũng được tự động hóa, hướng dẫn người vận hành cấu hình thông qua một loạt câu hỏi dựa trên tệp SETUP.md.

DeepSeek dán nhãn rõ ràng bản phát hành này là một nguyên mẫu nghiên cứu, lưu ý rằng nó khác biệt đáng kể so với phiên bản sản xuất nội bộ của họ. Tài liệu nhấn mạnh nguyên tắc tối thiểu hóa sự can thiệp của con người trong khi tối đa hóa giá trị đầu ra. Agent xác nhận đã nhận yêu cầu, giữ im lặng trong quá trình thực thi và chỉ tương tác trở lại khi có kết quả sẵn sàng, cần đưa ra quyết định hoặc gặp vấn đề gây chặn. Một bảng điều khiển web cung cấp khả năng hiển thị đối với các mục cần xem xét bởi con người, đảm bảo người vận hành có thể theo dõi tiến độ mà không cần liên tục kiểm tra thủ công.

Cách thức hoạt động

Lõi của hệ thống nằm ở mô hình ủy quyền và thực thi, phân biệt giữa các yêu cầu tường minh, ngữ cảnh suy luận và đầu vào bị bỏ qua. Mỗi tin nhắn đến được gán một mức độ ưu tiên. Yêu cầu tường minh chỉ xảy ra khi một người được phép trực tiếp nhắc đến agent hoặc tiếp tục một chuỗi hội thoại liên quan đến một Ticket đang hoạt động. Yêu cầu suy luận đến từ những người dùng không nằm trong danh sách nhưng đang phản hồi lại một Ticket, hoặc từ các bot nằm trong một allowlist (danh sách trắng) cụ thể. Tất cả các đầu vào khác, bao gồm tin nhắn từ những người dùng không nằm trong danh sách mà không nhắc đến agent, đều bị bỏ qua theo mặc định. Cấu trúc này ngăn chặn nhiễu ngẫu nhiên hoặc các tác nhân trái phép kích hoạt quy trình làm việc.

Công việc chủ động, hay các nhiệm vụ không ai yêu cầu rõ ràng, đòi hỏi phải có một quy tắc được viết ra và phụ thuộc vào cài đặt chế độ chấp nhận (accept mode). Trong chế độ observe (quan sát), vốn là mặc định, agent đánh giá các nhiệm vụ tiềm năng và ghi lại những gì nó sẽ làm mà không thực thi bất kỳ điều gì. Trong chế độ auto (tự động), các đánh giá tích cực sẽ kích hoạt việc thực thi ngay lập tức. Mỗi Ticket được chấp nhận đều mang theo một Mandate (Ủy quyền), một bản ghi về lý do tại sao nó được cho phép, bao gồm quy tắc, người gửi và phiên bản chính sách. Mandate này có thể bị thu hồi nếu một người đưa ra lệnh dừng hoặc nếu một bước kiểm tra an toàn thất bại, đảm bảo rằng các quyền hạn là linh hoạt và có thể đảo ngược.

Quan trọng hơn, môi trường thực thi chạy các lệnh mà không cần phê duyệt dưới tư cách là người dùng hệ điều hành của người vận hành. Mỗi Ticket có một phiên worker và thư mục riêng biệt, nhưng tiến trình nền tảng thừa hưởng đặc quyền của tài khoản người dùng đang chạy agent. Điều này có nghĩa là agent có quyền truy cập vào các khóa SSH, thông tin đăng nhập đám mây và các repository khác khả dụng cho người dùng đó. Các lệnh shell chuyển sang chạy ngầm sau năm giây, và các job nền bị giết sau ba mươi phút, nhưng mức độ truy cập ban đầu rất rộng. Như tài liệu nêu rõ: "Các phiên Executor chạy lệnh mà không cần phê duyệt dưới tư cách là người dùng OS của người vận hành."

Chi tiết chính

• Giấy phép và trạng thái: Dự án được cấp phép MIT và được dán nhãn là nguyên mẫu nghiên cứu, khác biệt so với các công cụ nội bộ của DeepSeek.
• Đặc quyền thực thi: Các phiên Worker chạy lệnh shell dưới tư cách là người dùng OS của người vận hành, thừa hưởng tất cả các quyền hạn cục bộ và thông tin đăng nhập.
• Mức độ ủy quyền: Các yêu cầu được phân loại thành tường minh, suy luận hoặc không được chấp nhận, với các mặc định nghiêm ngặt bỏ qua những người dùng không nằm trong danh sách.
• Chế độ chủ động: Chế độ observe mặc định ghi lại các hành động dự kiến mà không thực thi chúng, trong khi chế độ auto thực hiện công việc một cách tự động.
• Hệ thống Mandate: Mỗi nhiệm vụ có một bản ghi quyền hạn có thể thu hồi, kiểm tra đối chiếu với các chính sách hiện hành trước khi tiếp tục công việc đang tạm dừng.
• Cô lập đầu vào: Tin nhắn và bình luận chỉ đóng vai trò là dữ liệu đầu vào và không thể thay đổi cấu trúc quyền hạn, giúp giảm thiểu một số rủi ro từ prompt injection.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và trưởng nhóm kỹ thuật, nguyên mẫu này làm nổi bật một căng thẳng then chốt trong thiết kế AI agent: sự tiện lợi so với bảo mật. Khả năng tự động hóa các pull request và xử lý các nhiệm vụ lập trình thường nhật rất hấp dẫn, nhưng quyết định chạy lệnh dưới tư cách người dùng host (máy chủ) lại đưa ra rủi ro đáng kể. Nếu một kẻ tấn công chiếm quyền kiểm soát giao diện chat hoặc khai thác lỗ hổng trong logic của agent, chúng có thể thực thi các lệnh tùy ý với cùng đặc quyền như nhà phát triển đang chạy dịch vụ. Điều này bao gồm việc truy cập vào các biến môi trường nhạy cảm, khóa SSH và hệ thống tệp cục bộ.

Sự khác biệt giữa nguyên mẫu nghiên cứu và phiên bản nội bộ của DeepSeek gợi ý rằng công ty có thể đã triển khai các biện pháp bảo vệ bổ sung trong môi trường sản xuất mà không có ở đây. Các nhà phát triển thử nghiệm mã này phải giả định rằng mô hình bảo mật là tối giản. Trách nhiệm cô lập agent hoàn toàn thuộc về người vận hành. Điều này chuyển gánh nặng bảo mật từ nhà cung cấp nền tảng sang từng cá nhân đội ngũ, đòi hỏi hiểu biết sâu sắc về quản trị hệ thống và nguyên tắc đặc quyền tối thiểu (least-privilege).

Bạn có thể làm gì

• Chạy agent trên một máy ảo chuyên dụng hoặc container không có quyền truy cập vào khóa SSH cá nhân hoặc thông tin đăng nhập đám mây.
• Tạo một người dùng hệ điều hành riêng biệt với đặc quyền hạn chế dành riêng cho việc chạy các tiến trình agent.
• Giới hạn phạm vi token GitHub mà agent sử dụng chỉ ở mức đọc và ghi cho repository đích duy nhất.
• Giữ chế độ accept ở mức observe lúc ban đầu, xem xét tất cả các hành động được đề xuất trước khi chuyển sang chế độ auto.
• Hạn chế danh sách người dùng được phép chỉ gồm các thành viên đáng tin cậy trong đội ngũ và để chế độ nhắc đến người dùng không nằm trong danh sách ở mức ignore (bỏ qua).
• Đọc kỹ các tệp tài liệu docs/000, docs/002 và docs/003 trước khi thực thi script thiết lập.