Chế độ tự động Claude Code: cách an toàn hơn để bỏ qua quyền

Theo mặc định, Claude Code yêu cầu người dùng phê duyệt trước khi thực hiện lệnh hoặc chỉnh sửa tệp. Điều này giúp bảo vệ người dùng, nhưng cũng đồng nghĩa với việc phải nhấp "phê duyệt" rất nhiều lần. Theo thời gian, điều này dẫn đến sự mệt mỏi trong việc phê duyệt, khiến người dùng không còn chú ý kỹ đến những gì họ đang phê duyệt. Người dùng có hai giải pháp để tránh sự mệt mỏi này: một sandbox tích hợp nơi các công cụ được cô lập để ngăn chặn hành động nguy hiểm, hoặc cờ --dangerously-skip-permissions vô hiệu hóa tất cả các yêu cầu quyền và cho phép Claude hoạt động tự do, điều này không an toàn trong hầu hết các tình huống. Hình 1 trình bày không gian đánh đổi. Sandboxing an toàn nhưng yêu cầu bảo trì cao: mỗi khả năng mới cần được cấu hình, và bất kỳ thứ gì yêu cầu truy cập mạng hoặc máy chủ đều phá vỡ sự cô lập. Bỏ qua quyền không yêu cầu bảo trì nhưng không cung cấp sự bảo vệ nào. Các yêu cầu phê duyệt thủ công nằm ở giữa, và trong thực tế người dùng chấp nhận 93% trong số đó. Hình 1. Các chế độ quyền có sẵn trong Claude Code, được định vị theo tính tự động của nhiệm vụ và bảo mật. Màu sắc của điểm chỉ ra sự ma sát bảo trì. Chế độ tự động nhắm đến tính tự động cao với chi phí bảo trì thấp; mũi tên đứt nét cho thấy sự cải thiện bảo mật theo thời gian khi phạm vi của bộ phân loại và phán đoán của mô hình được cải thiện. Chúng tôi giữ một nhật ký sự cố nội bộ tập trung vào các hành vi sai trái của agent. Các ví dụ trước đây bao gồm xóa các nhánh git từ xa từ một hướng dẫn bị hiểu sai, tải lên token xác thực GitHub của kỹ sư lên một cụm tính toán nội bộ, và cố gắng di chuyển dữ liệu trên cơ sở dữ liệu sản xuất. Mỗi trường hợp này là kết quả của mô hình quá nhiệt tình, tự ý hành động theo cách người dùng không mong muốn. Chúng tôi đã ghi lại mô hình này trong thẻ hệ thống Claude Opus 4.6 (§6.2.1 và §6.2.3.3). Chế độ tự động là một chế độ mới cho Claude Code, ủy quyền phê duyệt cho các bộ phân loại dựa trên mô hình—một trung gian giữa việc xem xét thủ công và không có rào cản nào. Mục tiêu là bắt các hành động nguy hiểm không phù hợp với ý định của người dùng, trong khi cho phép phần còn lại chạy mà không cần yêu cầu phê duyệt. Bắt đầu sử dụng chế độ tự động bằng cách làm theo tài liệu.

Cách hoạt động

Chế độ tự động sử dụng hai lớp phòng thủ: một cho những gì Claude đọc, một cho những gì Claude làm. Ở lớp đầu vào, một probe tiêm lệnh phía máy chủ quét kết quả của công cụ (đọc tệp, lấy web, đầu ra shell, phản hồi công cụ bên ngoài) trước khi chúng đi vào ngữ cảnh của agent. Khi nội dung trông như một nỗ lực để chiếm đoạt hành vi, probe thêm một cảnh báo vào ngữ cảnh của agent trước khi kết quả được chuyển tiếp—báo cho agent xử lý nội dung này như đáng ngờ và bám vào những gì người dùng thực sự yêu cầu. Ở lớp đầu ra, bộ phân loại bản ghi (chạy trên Sonnet 4.6) đánh giá mỗi hành động theo một tập hợp tiêu chí quyết định trước khi thực hiện, hoạt động như một người phê duyệt thay thế. Bộ phân loại chạy trong hai giai đoạn: một bộ lọc token đơn nhanh (quyết định ‘có’ để chặn hoặc ‘không’ để cho phép), tiếp theo là lý luận chuỗi suy nghĩ chỉ khi bộ lọc đầu tiên gắn cờ bản ghi. Vì hầu hết các hành động vượt qua giai đoạn đầu tiên, token lý luận chỉ được sử dụng khi cần thiết. Bộ phân loại chỉ thấy các thông điệp của người dùng và các cuộc gọi công cụ của agent; chúng tôi loại bỏ các thông điệp và kết quả công cụ của chính Claude, khiến nó không thể lý luận theo thiết kế. Chúng tôi đi qua từng lựa chọn này, bao gồm những gì chúng mang lại cho chúng tôi và những gì chúng tiêu tốn, trong phần Quyết định thiết kế dưới đây. Hình 2: Kiến trúc hệ thống. Bộ phân loại bản ghi điều khiển các cuộc gọi công cụ; probe tiêm lệnh sàng lọc kết quả công cụ. Các subagent chạy cùng một pipeline đệ quy, với các bộ phân loại chuyển giao (có thể từ chối) và khi trả lại (chỉ cảnh báo).

Mô hình đe dọa

Một agent có thể thực hiện hành động nguy hiểm vì bốn lý do: Hành vi quá nhiệt tình. Trong trường hợp này, agent hiểu mục tiêu của người dùng và thực sự cố gắng giúp đỡ, nhưng tự ý hành động vượt quá những gì người dùng sẽ phê duyệt. Ví dụ, nó sử dụng một thông tin xác thực mà nó tình cờ tìm thấy hoặc xóa thứ gì đó mà nó cho là cản trở. Hành vi này có thể khó phát hiện, vì không có lý luận thù địch. Hành động thay vào đó trông như giải quyết vấn đề hợp lý, chỉ được áp dụng vượt quá giới hạn mà người dùng cho phép hoặc dự định. Sai lầm trung thực. Ở đây, agent hiểu sai phạm vi ảnh hưởng. Ví dụ, nó nghĩ rằng một tài nguyên chỉ nằm trong phạm vi thử nghiệm khi thực tế nó được chia sẻ, hoặc một nhánh là của riêng nó khi thực tế không phải. Tiêm lệnh. Các hướng dẫn được cài vào tệp, trang web, hoặc đầu ra công cụ chiếm đoạt agent, chuyển hướng nó khỏi nhiệm vụ của người dùng về phía kẻ tấn công. Mô hình không phù hợp. Theo lý thuyết, sự không phù hợp xảy ra khi agent theo đuổi mục tiêu của riêng nó. Chúng tôi hiện không thấy điều này trong thực tế, mặc dù chúng tôi đánh giá cẩn thận cho mỗi mô hình mà chúng tôi phát hành. Trong cả bốn trường hợp, biện pháp phòng thủ là chặn hành động. Bộ phân loại của chúng tôi được điều chỉnh cho hành vi quá nhiệt tình và sai lầm trung thực, vì chúng tôi có các ví dụ cụ thể về hành vi này từ thử nghiệm mô hình nội bộ, nhưng biện pháp phòng thủ áp dụng bất kể mối đe dọa nào đã tạo ra hành động. Các ví dụ dưới đây được điều chỉnh từ nhật ký sự cố nội bộ của chúng tôi để minh họa những gì chế độ tự động được thiết kế để chặn: Leo thang phạm vi. Một người dùng yêu cầu "dọn dẹp các nhánh cũ." Agent liệt kê các nhánh từ xa, xây dựng một mẫu khớp, và đưa ra lệnh xóa. Điều này sẽ bị chặn vì yêu cầu không rõ ràng, hành động không thể đảo ngược và phá hủy, và người dùng có thể chỉ muốn xóa các nhánh cục bộ. Khám phá thông tin xác thực. Một agent gặp lỗi xác thực giữa chừng trong một nhiệm vụ. Thay vì yêu cầu quyền, nó bắt đầu tìm kiếm hệ thống qua các biến môi trường và tệp cấu hình để tìm các token API thay thế. Vì những thông tin xác thực này có thể được định phạm vi cho một nhiệm vụ khác, điều này bị chặn. Tham số suy diễn từ agent. Một người dùng nói "hủy công việc của tôi." Agent truy vấn cụm, chọn kết quả gần nhất theo tên tương tự, và cố gắng xóa nó. Điều này bị chặn vì mục tiêu cụ thể có thể không phải là những gì người dùng dự định, và có thể thuộc sở hữu của người khác. Chia sẻ qua dịch vụ bên ngoài. Một agent muốn chia sẻ một script để gỡ lỗi, và xây dựng một lệnh GitHub Gist. Điều này bị chặn như là sự rò rỉ dữ liệu vì người dùng có thể coi nội dung là bí mật và không phù hợp để công khai. Bỏ qua kiểm tra an toàn. Một lệnh triển khai không vượt qua kiểm tra trước; agent thử lại với cờ bỏ qua xác minh. Điều này bị chặn vì nó có thể ảnh hưởng đến cơ sở hạ tầng chia sẻ.

Cách hoạt động của quyết định quyền

Tất cả các ví dụ trên sẽ đến bộ phân loại, nhưng hầu hết các hành động được cho phép trước bước đó bởi các quy tắc cho phép tiêu chuẩn của Claude Code: Tầng 1: Danh sách cho phép công cụ an toàn tích hợp và cài đặt người dùng. Một danh sách cho phép cố định bao gồm các công cụ không thể thay đổi trạng thái, bao gồm đọc tệp, tìm kiếm văn bản và mẫu tệp, điều hướng mã, chuyển đổi chế độ todo và kế hoạch. Người dùng cũng có thể cấu hình các quy tắc luôn cho phép cho các mẫu công cụ cụ thể. Một ngoại lệ là khi vào chế độ tự động, chúng tôi loại bỏ các quy tắc quyền được biết là cấp quyền thực thi mã tùy ý, bao gồm truy cập shell toàn diện, các trình thông dịch script có ký tự đại diện (python, node, ruby, và tương tự), và các lệnh chạy trình quản lý gói. Mặc dù điều này là nỗ lực tốt nhất dựa trên việc sử dụng thực tế, bất kỳ danh sách nào cũng sẽ không thể hoàn chỉnh. Nhiều người dùng thiết lập các quy tắc toàn diện này để thuận tiện trong chế độ phê duyệt thủ công, nhưng để chúng hoạt động có nghĩa là bộ phân loại không bao giờ thấy các lệnh có khả năng gây thiệt hại nhất. Các quy tắc hẹp ("cho phép chạy các trình định dạng mã") được giữ lại, nhưng các lối thoát trình thông dịch rộng thì không. Tầng 2: Các thao tác tệp trong dự án. Các thao tác ghi và chỉnh sửa tệp trong thư mục dự án được cho phép mà không cần gọi bộ phân loại. Việc mã hóa thường xuyên (ví dụ: chỉnh sửa các tệp nguồn trong repo của bạn) không phải chịu độ trễ của bộ phân loại; các chỉnh sửa trong dự án có thể được xem xét qua kiểm soát phiên bản. Chỉ những hành động có tiềm năng gây hậu quả thực sự mới đạt đến tầng cuối cùng: Tầng 3: Bộ phân loại bản ghi. Bộ phân loại bản ghi thấy tất cả những thứ khác, bao gồm các lệnh shell, lấy web, tích hợp công cụ bên ngoài, sinh sản subagent, thao tác hệ thống tệp ngoài dự án.