Bạn giao cho một agent lập trình một việc nhỏ: sửa một test đang fail. Hai mươi phút sau, nó đã viết lại ba file chẳng liên quan, chạy migration database lên bất kỳ DATABASE_URL nào mà nó tìm thấy trong shell của bạn, và force-push lên một nhánh mà người khác đang dùng. Không có gì trong prompt yêu cầu những việc đó. Agent được toàn quyền trên máy, nên nó đã dùng trọn quyền đó.
Quyền hạn là cách bạn quyết định trước những gì một agent được phép chạm vào. Quyền hạn của agent lập trình là một quy tắc quy định agent cụ thể được tiếp cận những file, lệnh, thông tin xác thực và repository nào trong một lượt chạy, và ở đâu thì con người phải can thiệp. Làm đúng, một agent đi chệch kịch bản sẽ thất bại an toàn bên trong chiếc hộp do bạn vạch ra. Làm sai, chỉ một lượt chạy tồi là đủ để chạm tới production.
Bài viết này đi qua từng tầng của mô hình phân quyền, gọi tên kiểu thất bại ở mỗi bước, và kết thúc bằng một danh sách kiểm tra bạn có thể áp dụng ngay hôm nay. Nội dung dùng Sharkly để cụ thể hóa từng tầng, bởi nhiệm vụ của Sharkly là đứng trên các agent lập trình của bạn và nắm phạm vi này tại một chỗ. Bạn đã có agent lập trình. Sharkly biến chúng thành một đội, mà một đội thì cần luật về việc ai được phép làm gì.
Ba tầng chứa quyền hạn của một agent
Quyền hạn của một agent lập trình không phải là một cài đặt duy nhất. Chúng nằm ở ba nơi, và một lỗ hổng ở bất kỳ nơi nào cũng vô hiệu hóa hai nơi còn lại.
- Runtime quyết định agent được gọi những công cụ nào: đọc file, sửa file, chạy lệnh shell, truy cập mạng. Đây là Claude Code, Codex, Gemini CLI, hay bất kỳ agent nào thực thi công việc.
- Cái máy quyết định những công cụ đó chạm được tới đâu: thư mục nào, thông tin xác thực nào, biến môi trường nào, mạng nào. Một Computer trong Sharkly “cung cấp hệ điều hành, file, thông tin xác thực, quyền truy cập mạng và các công cụ mà một Agent cần”, nên cái máy mới chính là phạm vi ảnh hưởng thực sự.
- Tác vụ quyết định ranh giới của ý định: lượt chạy này được giới hạn trong repository nào, agent được đặt những trạng thái nào, và điểm mà con người chấp nhận kết quả.
Có một ranh giới cần nói cho rõ: quyền hạn không phải là cổng phê duyệt. Quyền hạn là những gì agent có thể làm. Cổng phê duyệt là nơi con người quyết định. Bạn cần cả hai. Quyền hạn chặt mà không có cổng nghĩa là không ai kiểm tra kết quả. Có cổng nhưng quyền hạn lỏng lẻo nghĩa là thiệt hại đã xảy ra từ trước khi có ai đó nhìn vào.
Bước 1: Giới hạn công cụ của runtime
Hãy bắt đầu từ nơi agent hành động. Hầu hết agent lập trình đều có sẵn một hệ thống phân quyền: danh sách cho phép và danh sách từ chối các công cụ, kèm một prompt hỏi trước khi bất cứ thứ gì mang tính phá hoại được chạy. Ví dụ, Claude Code cho phép bạn cho phép hoặc từ chối từng công cụ cụ thể và sẽ hỏi trước khi chạy lệnh shell; tên cài đặt chính xác khác nhau tùy runtime và thay đổi liên tục, nên hãy đọc tài liệu hiện hành của agent thay vì tin vào đoạn snippet bạn tìm thấy năm ngoái.
Mặc định an toàn là thoáng với thao tác đọc và chặt chẽ với thao tác ghi. Hãy để agent đọc repo, chạy test, typecheck và build mà không cần hỏi. Còn việc sửa file và chạy lệnh shell thì phải qua một prompt hoặc một danh sách cho phép rõ ràng.
Kiểu thất bại này có tên, và đó chính là thứ ai cũng chọn khi bị deadline dí: chế độ bỏ qua tất cả. Runtime nào cũng có một flag tắt hết mọi prompt, và nó rất tiện cho một phiên có người giám sát. Nguy hiểm nằm ở việc để nó bật trong một lượt chạy không người trông. Một agent không bao giờ phải hỏi, đang làm theo một kế hoạch hóa ra lại sai, sẽ vui vẻ xóa đúng thứ mà nó hiểu nhầm. Hãy dùng chế độ tự động chấp nhận khi bạn đang ngồi nhìn. Và tắt nó đi khi bạn rời khỏi máy.
Bước 2: Giới hạn phạm vi của cái máy và thông tin xác thực
Danh sách công cụ của runtime trở nên vô nghĩa nếu cái máy giao hết mọi thứ cho agent. Một agent được phép chạy lệnh shell trên chiếc máy bạn dùng hằng ngày có thể đọc mọi SSH key, mọi file .env và mọi thông tin xác thực mà chính tài khoản đăng nhập của bạn chạm tới được. Kiểu thất bại này rất âm thầm: chẳng có gì trông sai cho tới khi agent dùng một key production mà lẽ ra nó không bao giờ được thấy.
Có hai động thái giúp thu hẹp phạm vi ảnh hưởng. Thứ nhất, hãy chạy agent ở một nơi đã được giới hạn thay vì trên chiếc laptop nơi bạn cất những bí mật thật. Sharkly đăng ký một Computer bằng token cài đặt dùng một lần, có thời hạn ngắn và chỉ dùng được đúng một lần, và tài liệu nói thẳng: đừng đưa token đó vào image, script, Task hay comment có thể tái sử dụng. Dù Computer là container, server hay một chiếc máy dự phòng, tầm với của agent chính là tầm với của môi trường đó, không phải của bạn. Nếu bạn muốn agent làm việc trong lúc mình offline, hãy chạy chúng trên một Computer từ xa thay vì trên chiếc laptop đang mở.
Thứ hai, chỉ giao những gì một lượt chạy cần. Môi trường của một lượt chạy Sharkly được lắp ghép từ cấu hình tường minh: các repository được gắn, biến môi trường, liên kết secret và thư mục làm việc. Hãy gắn repository cho một Agent khi nó cần phạm vi code hẹp hơn mặc định của Space, để một Agent frontend không bao giờ checkout service billing. Giữ mỗi lượt chạy trong worktree riêng biệt — đó là khác biệt giữa việc một chỉnh sửa tồi nằm gọn trong một checkout và việc hai agent làm hỏng cùng một working tree. Nguyên tắc chung áp dụng cho mọi trường: chỉ nhập cấu hình mà sản phẩm yêu cầu, và tuyệt đối không dán mật khẩu hay token vào những trường hay lệnh khởi động không liên quan.
Bước 3: Giới hạn phạm vi tác vụ và để việc merge cho con người
Tầng cuối cùng là ý định. Ngay cả một agent được sandbox đúng cách với thông tin xác thực đã giới hạn vẫn có thể làm sai việc: tự đánh dấu tác vụ của mình là đã xong, đẩy một thay đổi làm dở dang lên nhánh dùng chung, hoặc tự quyết rằng một PR đã sẵn sàng merge.
Đây chính là chỗ thuộc về hợp đồng giữa người và agent. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, trao quyền và chấp nhận kết quả. Tự động hóa dừng lại ở nơi cần đến phán đoán của tập thể. Một agent nên được phép mở draft PR và đính kèm kết quả test; nhưng không được phép phê duyệt PR đó hay merge vào nhánh được bảo vệ của bạn. Bảo vệ nhánh trên host và con người review trên tác vụ là hai ổ khóa giữ nguyên ranh giới đó.
Trong Sharkly, chính tác vụ mang giới hạn này. Một Workflow thuộc loại Task sẽ giới hạn những trạng thái mà Agent được chọn, nên Agent không thể âm thầm đưa công việc sang trạng thái “Done” hay “Released” vốn thuộc quyền con người. Khi Agent cần một quyết định, nó để tác vụ ở trạng thái chờ con người review hoặc chờ phản hồi, và điều đó hiện lên trong Inbox để người phụ trách chấp nhận, yêu cầu chỉnh sửa hoặc giao lại. Việc thực thi, điểm nghẽn, kết quả và cả phần review đều quay về một tác vụ duy nhất thay vì tản mát khắp năm cái terminal.
Đây cũng là điểm mà cách làm tự chế bắt đầu hết khả năng mở rộng. Một agent, một repo, một kỹ sư cẩn thận: bạn có thể ghi nhớ toàn bộ mô hình phân quyền trong đầu. Thêm agent thứ hai, thứ ba, thêm repository và một đồng đội nữa, thì “mỗi agent được phép làm gì ở đây” trở thành câu hỏi không ai trả lời nổi từ trí nhớ. Một bảng tác vụ biến những quy tắc đó thành cấu hình dùng chung, có thể kiểm tra: ai giao việc, lượt chạy có phạm vi nào, bằng chứng nào được trả về, và ai đã chấp nhận. Đó chính là tầng quản lý nằm trên các agent lập trình của bạn. Bạn có thể tự dựng nó bằng worktree, thông tin xác thực đã giới hạn và bảo vệ nhánh, hoặc chạy các agent lập trình hiện có qua Sharkly và quản lý quyền hạn, tác vụ cùng việc review ở một nơi.
Danh sách kiểm tra quyền hạn bạn có thể áp dụng ngay hôm nay
Hãy điểm qua danh sách này với mọi agent mà bạn cho phép chạm vào repository thật:
- Runtime: cho phép đọc và chạy test mà không cần hỏi; sửa file và lệnh shell phải qua cổng kiểm soát; tắt chế độ bỏ qua tất cả với những lượt chạy không người trông.
- Cái máy: agent chạy trên một Computer đã được giới hạn, không phải máy bạn dùng hằng ngày; token cài đặt và truy cập chỉ dùng một lần và không bao giờ bị commit.
- Thông tin xác thực: chỉ những biến môi trường và liên kết secret mà lượt chạy này cần, không dán gì vào những trường không liên quan.
- Phạm vi repository: agent chỉ được gắn với những repo mà công việc của nó đòi hỏi, không phải mọi repo trong Space.
- Cô lập: mỗi lượt chạy có worktree riêng để một thay đổi tồi không thể làm hỏng checkout dùng chung.
- Phạm vi tác vụ: agent có thể đặt các trạng thái đang làm việc nhưng không thể đưa tác vụ sang trạng thái đã chấp nhận hoặc đã phát hành vốn thuộc quyền con người.
- Việc merge: bảo vệ nhánh cùng con người review dựa trên bằng chứng ở cấp tác vụ là rào chắn giữa PR của agent và nhánh main.
Nếu có dòng nào còn lỏng lẻo, hãy siết lại trước lượt chạy kế tiếp, chứ đừng đợi đến sau sự cố mới hiểu vì sao nó quan trọng.
Câu hỏi thường gặp
Quyền hạn của agent lập trình khác gì cổng phê duyệt? Quyền hạn xác định những gì một agent về mặt kỹ thuật có thể làm: nó chạm tới được những file, lệnh và thông tin xác thực nào. Cổng phê duyệt là điểm mà con người quyết định có chấp nhận những gì agent đã làm hay không. Bạn cần cả hai, vì quyền hạn chặt vẫn còn những việc mà con người nên phê duyệt, còn cổng phê duyệt chẳng ích gì nếu agent vốn đã có quyền gây thiệt hại.
Có nên cho agent lập trình tự merge PR của chính nó không? Không, mặc định là không. Hãy để agent mở draft PR và đính kèm kết quả kiểm chứng, rồi giao việc merge cho con người hoặc một bước review bắt buộc. Lý do nằm ở hợp đồng giữa người và agent: agent thực thi và báo cáo, con người chấp nhận và phát hành. Điều này vẫn đúng kể cả với các quy trình human-in-the-loop nơi agent làm phần lớn công việc.
Chạy agent với mọi prompt xin quyền đều tắt có an toàn không? Chỉ an toàn khi bạn đang ngồi nhìn. Chế độ tự động chấp nhận hữu ích cho một phiên có người giám sát, nơi bạn có thể dừng một bước sai. Với những lượt chạy không người trông hoặc chạy qua đêm, hãy giữ prompt hoặc một danh sách cho phép, và đặt agent trên một máy đã được giới hạn để sai sót vẫn nằm trong tầm kiểm soát.
