Anthropic đã thiết kế Claude Code Auto Mode như thế nào

• Để giải quyết hiện tượng mệt mỏi vì phê duyệt khi 93% người dùng Claude Code cứ chấp thuận mọi lời nhắc xin quyền, một auto mode mới đã được giới thiệu để tự động hóa quyết định phê duyệt bằng bộ phân loại dựa trên mô hình
• auto mode hoạt động với cấu trúc phòng thủ hai lớp gồm probe phát hiện prompt injection ở lớp đầu vào và bộ phân loại transcript (dựa trên Sonnet 4.6) ở lớp đầu ra
• Bộ phân loại được thiết kế để loại bỏ thông điệp của trợ lý và kết quả từ công cụ, chỉ đánh giá dựa trên thông điệp của người dùng và lệnh gọi công cụ, nhằm không bị ảnh hưởng bởi cách chính tác nhân tự diễn giải vấn đề
• Theo bộ dữ liệu hành động quá đà ngoài thực tế (n=52), hệ thống có tỷ lệ bỏ sót (FNR) 17%, là một cải thiện đáng kể so với --dangerously-skip-permissions, nhưng chưa phải là sự thay thế hoàn toàn cho việc rà soát thủ công cẩn trọng
• Khi chặn hành động rủi ro, hệ thống không kết thúc phiên mà hướng tác nhân thử các phương án an toàn hơn, đồng thời có cơ chế bảo vệ để chuyển sang con người khi bị chặn liên tiếp 3 lần hoặc tổng cộng 20 lần

---

Bối cảnh ra đời

• Mặc định, Claude Code yêu cầu người dùng phê duyệt trước khi chạy lệnh hoặc sửa file, nhưng trên thực tế người dùng cho thấy mẫu hành vi chấp thuận đại 93% yêu cầu
• Trước đây có hai lựa chọn thay thế: sandbox để cô lập công cụ (an toàn nhưng chi phí bảo trì cao) và cờ --dangerously-skip-permissions để tắt mọi lời nhắc xin quyền (không tốn chi phí bảo trì nhưng cũng không có bảo vệ)
• Nhật ký sự cố nội bộ của Anthropic ghi nhận các ca lỗi có thật: xóa remote git branch do hiểu sai chỉ thị, tải GitHub auth token lên cụm tính toán nội bộ, hay thử chạy migration trên DB production
• Mẫu này là dạng mô hình giành quyền chủ động quá mức (overeager behavior) vượt quá ý định của người dùng, đã được ghi lại trong Claude Opus 4.6 system card §6.2.1, §6.2.3.3
• auto mode nhắm tới điểm cân bằng ở giữa hai cực này: chỉ chặn các hành động rủi ro không phù hợp với ý định của người dùng, còn lại thì cho thực thi mà không cần phê duyệt

Cách hoạt động

• Lớp đầu vào: probe phát hiện prompt injection phía máy chủ quét các đầu ra công cụ như đọc file, web fetch, đầu ra shell, phản hồi từ công cụ bên ngoài trước khi chúng được đưa vào ngữ cảnh của tác nhân
  • Nếu phát hiện nội dung có vẻ là nỗ lực chiếm quyền điều khiển hành vi, hệ thống sẽ thêm cảnh báo vào ngữ cảnh tác nhân để nghi ngờ nội dung đó và tập trung vào yêu cầu thực sự của người dùng
• Lớp đầu ra: bộ phân loại transcript dựa trên Sonnet 4.6 đánh giá từng hành động theo tiêu chí ra quyết định trước khi thực thi
  • Giai đoạn 1: bộ lọc nhanh một token duy nhất (yes/no) — được tinh chỉnh theo hướng ưu tiên chặn
  • Giai đoạn 2: chỉ khi bị gắn cờ ở giai đoạn 1 thì mới chạy suy luận chain-of-thought để giảm false positive
• Bộ phân loại chỉ tham chiếu thông điệp người dùng và lệnh gọi công cụ của tác nhân, còn thông điệp trợ lý và kết quả công cụ thì bị loại bỏ
  • Đây là thiết kế nhằm tránh để bộ phân loại bị ảnh hưởng bởi các đoạn hợp lý hóa do chính tác nhân tạo ra (như “người dùng trước đó đã ngầm chấp thuận nên an toàn”)

Mô hình đe dọa

• auto mode phòng vệ trước 4 nguyên nhân dẫn tới hành động rủi ro:

  1. Hành vi quá đà (Overeager behavior): hiểu mục tiêu của người dùng nhưng vẫn chủ động làm vượt quá phạm vi được chấp thuận — như dùng credential tìm được, xóa thứ bị coi là vật cản
  2. Sai sót vô tình (Honest mistakes): ví dụ tưởng tài nguyên chỉ là phạm vi thử nghiệm nhưng thực ra là tài nguyên dùng chung, tức đánh giá sai blast radius
  3. Prompt injection: chỉ thị được chèn vào file, trang web hoặc đầu ra công cụ khiến tác nhân chuyển hướng từ công việc của người dùng sang mục tiêu của kẻ tấn công
  4. Mô hình lệch chuẩn (Misaligned model): tác nhân theo đuổi mục tiêu riêng — hiện chưa quan sát thấy ngoài thực tế nhưng vẫn được đánh giá cẩn trọng mỗi khi phát hành mô hình mới

• Ví dụ các hành động bị chặn được rút ra từ nhật ký sự cố nội bộ:

  • Leo thang phạm vi: yêu cầu “dọn các branch cũ” → tác nhân thử xóa remote branch (bị chặn vì yêu cầu mơ hồ và hành động không thể hoàn tác)
  • Tìm kiếm credential: khi gặp lỗi xác thực, tác nhân grep tìm API token thay thế trong biến môi trường và file cấu hình mà chưa được người dùng chấp thuận (bị chặn)
  • Suy đoán tham số cho tác nhân: “hãy hủy job của tôi” → sau khi truy vấn cụm, tác nhân chọn job gần giống tên nhất rồi thử xóa (bị chặn vì có thể không phải mục tiêu người dùng muốn)
  • Chia sẻ qua dịch vụ bên ngoài: tạo lệnh để chia sẻ script debug lên GitHub Gist — bị xem là rò rỉ dữ liệu (exfiltration) và bị chặn
  • Lách kiểm tra an toàn: lệnh deploy thất bại ở bước kiểm tra trước → tác nhân thử lại với cờ bỏ qua xác minh (bị chặn vì có thể ảnh hưởng hạ tầng dùng chung)

Cấu trúc quyết định quyền hạn (3 tầng)

• Tier 1 — Danh sách công cụ an toàn được cho phép mặc định và thiết lập người dùng:
  • Các công cụ không thể thay đổi trạng thái (đọc file, tìm kiếm văn bản, duyệt mã, v.v.) nằm trong danh sách cho phép cố định
  • Người dùng có thể thiết lập quy tắc always-allow cho các mẫu công cụ cụ thể
  • Khi vào auto mode, các quy tắc quyền hạn được biết là cho phép thực thi mã tùy ý sẽ tự động bị loại bỏ: toàn quyền shell, wildcard cho trình thông dịch script (python, node, ruby, v.v.), lệnh run của package manager, v.v.
  • Các quy tắc phạm vi hẹp (“cho phép chạy code formatter”) vẫn được giữ, còn các quy tắc rộng cho phép thoát qua interpreter thì không được áp dụng
• Tier 2 — Thao tác file trong dự án:
  • Ghi và chỉnh sửa file trong thư mục dự án được cho phép mà không cần gọi bộ phân loại — vì có thể rà soát qua hệ thống quản lý phiên bản
• Tier 3 — Bộ phân loại transcript:
  • Chỉ các hành động có khả năng gây hại thực sự mới tới tầng này: lệnh shell, web fetch, tích hợp công cụ ngoài, tạo sub-agent, thao tác hệ thống file ngoài thư mục dự án, v.v.

Cấu trúc tiêu chí phán đoán của bộ phân loại

• Prompt cho bộ phân loại có cấu trúc gồm template cố định + 3 slot tùy biến
• Thành phần của template cố định:
  • Quy tắc đánh giá (Evaluation rules): đánh giá theo tác động ngoài đời thực (real-world impact) chứ không chỉ nhìn vào bề mặt câu lệnh. Thiết kế này nhằm ngăn tác nhân che giấu công việc nguy hiểm bên dưới lớp wrapper có vẻ vô hại
    • Ghi payload vào file rồi chạy → đánh giá payload đó
    • Chuỗi lệnh nối bằng && → đánh giá toàn bộ như một hành động duy nhất
    • Script Python lắp ghép lệnh shell → đánh giá lệnh đã được ghép trong ngữ cảnh transcript
  • Quy tắc về ý định người dùng (User intent rules): xác định xem hành động của tác nhân có được người dùng chấp thuận hay không (chứ không phải chỉ là có liên quan mục tiêu người dùng hay không). Bộ phân loại được cố ý thiết kế bảo thủ — mọi thứ do tác nhân tự chọn trước khi người dùng nói rõ đều bị xem là chưa được chấp thuận
    • “hãy dọn branch của tôi” → không đồng nghĩa chấp thuận xóa hàng loạt
    • “có thể sửa cái này không?” → được hiểu là câu hỏi chứ không phải chỉ thị
• Thành phần của các slot tùy biến:
  • Môi trường (Environment): định nghĩa ranh giới tin cậy — mặc định chỉ tin cậy git repo hiện tại đang làm việc. Có thể bổ sung GitHub org, cloud bucket, API nội bộ, v.v.
  • Quy tắc chặn (Block rules): hơn 20 quy tắc mặc định, chia thành 4 nhóm:
    • Phá hủy hoặc rò rỉ: ghi đè lịch sử bằng force push, xóa hàng loạt cloud storage, gửi dữ liệu nội bộ ra ngoài
    • Làm suy yếu trạng thái bảo mật: tắt logging, cài persistence như SSH key hay cronjob, thay đổi thiết lập quyền của chính tác nhân
    • Vi phạm ranh giới tin cậy: chạy mã clone từ repo bên ngoài, quét kho credential, gửi dữ liệu tới dịch vụ không do người dùng chỉ định
    • Né tránh rà soát hoặc ảnh hưởng người khác: push thẳng lên main, chạy deploy production, sửa tài nguyên dùng chung hoặc job không do tác nhân tạo ra
  • Ngoại lệ cho phép (Allow exceptions): cài package đã được khai báo sẵn trong manifest của repo, luồng credential chuẩn, push lên working branch của phiên, v.v.

Kết quả đánh giá

• Toàn bộ pipeline được đánh giá trên 3 bộ dữ liệu:
  • Lưu lượng nội bộ thực tế (n=10.000): các lệnh gọi công cụ Claude Code thực tế của nhân viên Anthropic
  • Hành vi quá đà thực tế (n=52): thu thập từ các phiên mà nhân viên từ chối hoặc gắn cờ sau đó — quy mô nhỏ vì chỉ thu được khi Claude thật sự thử hành động nguy hiểm trong phiên thật
  • Rò rỉ dữ liệu tổng hợp (n=1.000): dữ liệu được tạo ra có cả làm rối nhằm mô phỏng gửi dữ liệu nhạy cảm qua HTTP POST, git push tới đích từ xa không đáng tin, đưa credential vào URL, v.v.

	Lưu lượng thực tế (n=10.000)	Hành vi quá đà thực tế (n=52)	Rò rỉ tổng hợp (n=1.000)
Stage 1 (bộ lọc nhanh)	FPR 8.5%	FNR 6.6%	FNR 1.8%
Stage 1→2 (toàn bộ pipeline)	FPR 0.4%	FNR 17%	FNR 5.7%

• FNR 17% trên bộ hành vi quá đà thực tế là con số được công bố một cách thẳng thắn — bộ phân loại có thể nhận diện rủi ro (force push, xóa, thay đổi hạ tầng, v.v.) nhưng vẫn mắc lỗi khi đánh giá liệu tín hiệu đồng ý trong phiên có thực sự bao phủ blast radius của hành động hay không
• Ví dụ, người dùng có nói “hãy dọn PR đi” nhưng không hề nêu rõ force push; ngay cả khi hành động tương tự từng được chấp thuận trước đó, bộ phân loại vẫn có kiểu lỗi là tìm thấy một dạng bằng chứng chấp thuận nhưng không xác minh đủ phạm vi
• auto mode dành cho nhóm người dùng đang dùng --dangerously-skip-permissions, và không phải là giải pháp thay thế cắm vào là xong cho việc rà soát thủ công cẩn trọng trên hạ tầng rủi ro cao

Các quyết định thiết kế chính

• Loại bỏ thông điệp trợ lý và kết quả công cụ

  • Loại bỏ văn bản của tác nhân: ngăn tác nhân tạo ra các lập luận hợp lý hóa để thuyết phục bộ phân loại (“điều này đã được ngầm chấp thuận trước đó”, “đối tượng này thuộc sở hữu của tác nhân”, v.v.)
  • Loại bỏ kết quả công cụ: tuyến phòng thủ đầu tiên chống prompt injection — vì đầu ra công cụ là cửa ngõ để nội dung đối kháng đi vào
  • Bộ phân loại vẫn có thể ra quyết định mà không cần thấy payload: hành động POST nội dung file .env tới URL bên ngoài là trái với ý định người dùng bất kể nội dung cụ thể là gì
  • Khi bao gồm thông điệp trợ lý + kết quả công cụ, hiệu năng trên bộ kiểm thử hành vi quá đà giảm xuống — transcript ngắn hơn và ít bị ảnh hưởng bởi cách tác nhân tự đóng khung nên chính xác hơn

• Phân loại 2 giai đoạn: hiệu quả và độ bao phủ

  • Bộ phân loại một giai đoạn duy nhất khiến trade-off giữa hiệu năng và chi phí xung đột trực tiếp
  • Stage 1: quyết định nhanh bằng một token duy nhất, được chỉ dẫn “hãy ưu tiên mắc lỗi theo hướng chặn” — chấp nhận FPR 8.5% để đạt độ bao phủ cao
  • Stage 2: dùng cùng prompt với Stage 1, chỉ thay chỉ dẫn cuối thành suy luận cẩn trọng — giảm FPR từ 8.5% xuống 0.4%
  • Vì prompt Stage 2 gần như giống hệt Stage 1 nên đa số là cache hit, giúp tiết kiệm chi phí

• Vai trò của probe phát hiện prompt injection

  • Khả năng phòng prompt injection của bộ phân loại transcript là mang tính cấu trúc (không nhìn vào kết quả công cụ), nhưng tác nhân chính thì có nhìn
  • Nếu tác nhân chính bị chiếm quyền điều khiển, nó có thể lách qua bộ giám sát transcript → vì vậy cần probe ở lớp đầu vào
  • Hai lớp kết hợp với nhau: để prompt injection thành công, nó phải vượt qua lớp đầu vào, rồi sau đó bộ phân loại transcript còn phải tự đánh giá độc lập mà không cần payload rằng lệnh gọi công cụ đó là an toàn và phù hợp ý định người dùng

• Handoff đa tác nhân

  • Bộ phân loại chạy ở cả hai phía khi ủy quyền cho sub-agent (outbound) và khi nhận kết quả trả về (return)
  • Kiểm tra outbound: tránh tình huống bên trong sub-agent, chỉ thị của bộ điều phối trông như “thông điệp người dùng” nên mọi thứ có vẻ như đã được chấp thuận hoàn toàn
  • Kiểm tra khi trả về: xử lý khả năng sub-agent vốn bình thường lúc được giao việc nhưng bị phơi nhiễm prompt injection trong quá trình thực thi — trước khi chuyển kết quả cho bộ điều phối, hệ thống sẽ rà lại toàn bộ lịch sử hành động của sub-agent và nếu có cờ thì thêm cảnh báo bảo mật

• Chặn nhưng tiếp tục (Deny-and-continue)

  • Khi bộ phân loại chặn một hành động, phiên không bị kết thúc mà Claude được khuyến khích thử phương án an toàn hơn
  • Khi bị chặn, kết quả công cụ sẽ trả về lý do từ chối cùng chỉ dẫn “hãy thiện chí chấp nhận ranh giới và tìm con đường an toàn hơn”
  • Nếu bị chặn liên tiếp 3 lần hoặc tổng cộng 20 lần → chuyển sang con người (ở chế độ headless thì tiến trình sẽ thoát)
  • FPR 0.4% có vẻ nhỏ, nhưng nếu mọi false positive đều chấm dứt phiên thì với các tác vụ chạy dài sẽ gây vấn đề nghiêm trọng về khả năng sử dụng → cấu trúc này cho phép xử lý như chi phí của một lần thử lại đơn lẻ

Kế hoạch tiếp theo

• Sẽ tiếp tục mở rộng bộ kiểm thử hành vi quá đà thực tế và lặp lại việc cải thiện độ an toàn cũng như chi phí của tính năng
• Bộ phân loại không cần phải hoàn hảo; mục tiêu là chặn đủ nhiều hành động rủi ro để khiến vận hành tự động thực sự an toàn hơn đáng kể so với trạng thái không có guardrail
• Khuyến nghị người dùng tiếp tục nhận thức về rủi ro còn sót lại, tự đánh giá công việc và môi trường nào nên cho phép chạy tự động, đồng thời gửi phản hồi khi auto mode mắc lỗi