Hiểu rủi ro “Don’t Ask Again” của Claude Code: Khi quy tắc quyền làm lộ bí mật

Claude Code có thể lưu quy tắc cho những thao tác được người dùng chọn “Yes, and don’t ask again” vào tệp .claude/settings.local.json. Cơ chế này giúp giảm số lần hỏi quyền, nhưng nghiên cứu mới của Apiiro cho thấy câu lệnh được lưu có thể chứa mật khẩu, khóa API hoặc token rồi bị đưa lên kho GitHub công khai.

Hộp thoại cấp quyền của Claude Code với lựa chọn không hỏi lại
Hộp thoại quyền của Claude Code cho phép lưu quy tắc theo kho mã. Nguồn: tài liệu Claude Code.

“Don’t Ask Again” thực sự lưu điều gì?

Theo tài liệu chính thức, quyền đọc thường không cần phê duyệt trong thư mục làm việc, trong khi lệnh shell, truy cập web và một số hành động khác có thể yêu cầu xác nhận. Với lệnh Bash hoặc miền WebFetch, lựa chọn không hỏi lại có thể tạo quy tắc tồn tại lâu dài theo từng repository trong .claude/settings.local.json.

Vấn đề không nằm ở bản thân tệp cấu hình, mà ở nội dung câu lệnh được đưa vào quy tắc. Nếu nhà phát triển dán bí mật trực tiếp vào dòng lệnh, toàn bộ chuỗi đó có thể trở thành dữ liệu cấu hình dạng văn bản thuần.

Apiiro phát hiện quy mô phơi lộ ra sao?

Apiiro cho biết đã khảo sát 104.185 bản sao công khai của .claude/settings.local.json trên 103.617 repository. Nhóm nghiên cứu tìm thấy 1.122 tệp chứa 1.379 bí mật riêng biệt; khi mở rộng sang lịch sử commit, cấu hình chia sẻ và transcript của agent, tổng số được báo cáo tăng lên 2.539 bí mật trong 1.994 repository.

Các con số phản ánh dữ liệu mà công cụ dò tìm nhận diện là bí mật; Apiiro lưu ý họ không kiểm tra xem từng thông tin xác thực còn hoạt động hay không. Dù vậy, chỉ riêng việc khóa từng xuất hiện trong lịch sử Git cũng đủ để tổ chức phải coi đó là một sự cố và thực hiện luân chuyển.

Vì sao tệp có chữ “local” vẫn lên GitHub?

Tên tệp dễ tạo cảm giác đây là dữ liệu chỉ tồn tại trên máy cá nhân. Trên thực tế, việc một tệp được commit hay không phụ thuộc vào trạng thái Git, quy tắc bỏ qua, thao tác của người dùng và công cụ tự động. Sao chép dự án, dùng mẫu cấu hình hoặc lệnh thêm toàn bộ tệp có thể khiến dữ liệu cục bộ đi vào commit.

Nguy cơ còn kéo dài sau khi xóa tệp ở phiên bản mới nhất, bởi bí mật có thể vẫn nằm trong commit cũ, nhánh khác, bản fork, bộ nhớ đệm hoặc transcript đã được đồng bộ.

Chuỗi rủi ro đối với nhóm phát triển

Một token bị lộ có thể cho phép đọc mã nguồn riêng tư, truy cập dịch vụ đám mây, registry gói, hệ thống CI/CD hoặc dữ liệu khách hàng, tùy phạm vi quyền. Kẻ tấn công cũng có thể dùng quyền ghi để sửa workflow, chèn mã độc vào bản dựng hoặc đánh cắp thêm thông tin xác thực.

Đây là ví dụ điển hình về rủi ro giao thoa giữa trợ lý lập trình AI, quản lý quyền và vệ sinh bí mật. Agent không nhất thiết tự làm lộ khóa; quy trình lưu phê duyệt đã biến một câu lệnh tiện lợi thành dữ liệu bền vững, rồi Git khuếch đại phạm vi phát tán.

Cách kiểm tra repository an toàn

  • Tìm mọi bản sao của .claude/settings.local.json trong cây làm việc, nhánh, lịch sử commit và các bản fork.
  • Rà soát quy tắc Bash, URL, header và tham số có dạng token, mật khẩu, khóa truy cập hoặc chuỗi kết nối.
  • Dùng công cụ quét bí mật ở máy phát triển, pre-commit, pull request và CI; không chỉ kiểm tra nhánh mặc định.
  • Đối chiếu nhật ký dịch vụ để phát hiện truy cập bất thường bằng thông tin xác thực nghi bị lộ.

Nếu đã phát hiện bí mật, xóa tệp là chưa đủ

Ưu tiên đầu tiên là thu hồi hoặc luân chuyển khóa, vì làm sạch lịch sử Git không vô hiệu hóa bản sao đã bị tải về. Sau đó mới loại bỏ dữ liệu khỏi lịch sử khi phù hợp, thông báo cho chủ sở hữu các bản fork và xác định phạm vi tài nguyên mà khóa từng có thể truy cập.

Tổ chức nên coi dữ liệu đã xuất hiện trong repository công khai là đã bị phơi lộ, ngay cả khi không thấy dấu hiệu khai thác. Với khóa có quyền cao, cần điều tra nhật ký, thay đổi credential phụ thuộc và đánh giá khả năng di chuyển ngang.

Biện pháp phòng ngừa bền vững

Không đặt bí mật trực tiếp trong câu lệnh được lưu làm quy tắc. Thay vào đó, dùng trình quản lý bí mật, biến môi trường được cấp lúc chạy, credential ngắn hạn và quyền tối thiểu. Quy tắc cho phép nên giới hạn theo công cụ, câu lệnh và miền cụ thể; nhóm phát triển cần định kỳ mở mục quản lý permissions để xóa các quyền rộng hoặc không còn dùng.

Trong repository, bổ sung quy tắc bỏ qua phù hợp cho cấu hình cá nhân, nhưng không coi .gitignore là lớp bảo vệ duy nhất. Kiểm soát hiệu quả cần kết hợp đào tạo, secret scanning, bảo vệ nhánh, cảnh báo lịch sử và quy trình luân chuyển khóa nhanh.

Bài học rộng hơn cho AI coding agent

Mỗi quyết định “không hỏi lại” là một thay đổi chính sách có thể tồn tại qua nhiều phiên làm việc. Vì vậy, giao diện tiện lợi phải đi cùng khả năng quan sát, giới hạn phạm vi và đánh giá dữ liệu nhạy cảm trước khi lưu. Với doanh nghiệp, tệp cấu hình và transcript của agent cần được quản trị như mã nguồn và log vận hành: có phân loại, thời hạn lưu, kiểm soát truy cập và giám sát rò rỉ.

VNCyberS tổng hợp từ Apiiro, The Hacker News và tài liệu Claude Code

Liên hệ với chúng tôi

Email: [email protected]
Điện thoại: +84 903260277