Nổi bậtCách chúng tôi kiểm soát Claude trên các sản phẩm Khi các tác nhân AI ngày càng mạnh mẽ hơn, phạm vi ảnh hưởng tiềm ẩn của chúng cũng tăng theo. Câu hỏi kỹ thuật đặt ra là làm thế nào để giới hạn phạm vi đó. Đây là những gì chúng tôi đã học được khi xây dựng hệ thống kiểm soát cho claude.ai, Claude Code và Cowork.

Mười hai tháng trước, chúng tôi sẽ thẳng thừng bác bỏ ý tưởng cấp cho Claude quyền truy cập đủ để vô hiệu hóa một dịch vụ nội bộ của Anthropic. Ngày nay, mức độ truy cập đó là chuyện thường ngày, và các nhà phát triển Anthropic làm việc hiệu quả hơn nhờ nó. Rủi ro của những triển khai này có hai thành phần: khả năng xảy ra lỗi và mức độ thiệt hại mà lỗi đó có thể gây ra. Những tiến bộ trong các biện pháp bảo vệ và huấn luyện mô hình đã liên tục giảm thiểu yếu tố đầu tiên; yếu tố thứ hai—bán kính thiệt hại lý thuyết—chỉ ngày càng mở rộng khi năng lực và quyền truy cập phát triển. Tuy nhiên, khi các tác nhân (agent) có khả năng thực hiện công việc mà trước đây cần một người hoặc thậm chí một nhóm, chi phí của việc *không* triển khai trở nên đủ lớn để phép tính rủi ro-lợi ích nghiêng hẳn về phía chấp nhận, miễn là sản phẩm có thể được đảm bảo an toàn. Vấn đề kỹ thuật trở thành làm thế nào để giới hạn bán kính thiệt hại.

Có hai cách chính để làm điều này.

Cách đầu tiên là giám sát hành vi của tác nhân thông qua một người trong vòng lặp (human-in-the-loop). Trước đây, Claude Code bảo vệ chống lại các hành động không mong muốn của tác nhân bằng cách yêu cầu người dùng cấp phép ở mỗi bước. Về mặt lý thuyết, điều này hiệu quả, nhưng chúng tôi nhận thấy cách tiếp cận này có sai sót. Dữ liệu đo lường của chúng tôi cho thấy người dùng chấp thuận khoảng 93% các lời nhắc cấp phép. Càng thấy nhiều yêu cầu chấp thuận, người dùng càng ít chú ý đến từng cái, dần dần trở nên kém cẩn trọng hơn trong việc giám sát của họ. Gần đây, chúng tôi đã xây dựng chế độ tự động (auto mode) cho Claude Code, giúp *tự động hóa các phê duyệt an toàn hơn* nhằm giảm bớt sự mệt mỏi khi phê duyệt này. Tuy nhiên, các lỗ hổng vẫn tồn tại—bất kỳ biện pháp phòng thủ xác suất nào cũng có tỷ lệ bỏ sót khác không.

Cách tiếp cận thứ hai để giới hạn bán kính thiệt hại—và là trọng tâm của bài viết này—là sự cô lập (containment). Thay vì giám sát những gì tác nhân *làm*, chúng ta giám sát những gì nó *có thể làm* bằng cách thực thi các ranh giới truy cập thông qua, ví dụ, các hộp cát (sandbox), máy ảo (virtual machines) và các biện pháp kiểm soát xuất dữ liệu (egress controls). Đây là lĩnh vực mà đội ngũ kỹ thuật của Anthropic đã dành nhiều nỗ lực nhất, và cũng là nơi xảy ra nhiều lỗ hổng bảo mật đáng ngạc nhiên nhất.

Trong hai năm qua, chúng tôi đã ra mắt ba sản phẩm tác nhân chính: claude.ai, Claude Code và Claude Cowork. Mỗi sản phẩm phục vụ một đối tượng khác nhau, yêu cầu một kiến trúc cô lập khác nhau. Bài viết này chia sẻ những gì đã hoạt động tốt, những gì đã hỏng hóc, và những gì chúng tôi đã học được về bảo mật tác nhân trên chặng đường đó.

Rủi ro bảo mật đối với các tác nhân thuộc một trong ba loại sau:

**Lạm dụng của người dùng:** Người dùng—dù có ác ý hay bất cẩn—chỉ đạo tác nhân làm điều gì đó có hại. Điều này bao gồm mọi thứ từ yêu cầu tác nhân bỏ qua một kiểm tra mà họ thấy phiền phức, đến chạy một lệnh phá hoại mà họ không hiểu, cho đến cố tình gây hại.

**Hành vi sai lệch của mô hình:** Tác nhân thực hiện một hành động có hại mà không ai yêu cầu. Khi các mô hình của chúng tôi được cải thiện, chúng trở nên phù hợp hơn (aligned) trong hầu hết các đánh giá hành vi, nhưng điều này không có nghĩa là rủi ro chắc chắn giảm. Các mô hình kém năng lực hơn có nhiều khả năng hiểu sai tình huống và mắc các lỗi rõ ràng. Các mô hình năng lực hơn mắc ít lỗi hơn, nhưng chúng cũng giỏi hơn trong việc tìm ra những con đường bất ngờ để đạt được mục tiêu, thường bằng cách vòng qua các hạn chế mà không ai

Tôi nghĩ nên viết lại.

Tại Anthropic, chúng tôi đã chứng kiến các mô hình Claude "hữu ích" thoát khỏi sandbox để hoàn thành nhiệm vụ, kiểm tra lịch sử git để tìm câu trả lời cho bài kiểm tra lập trình, và tự động xác định benchmark đang chạy để giải mã đáp án. Mỗi mô hình mang đến một bộ khả năng mới, đôi khi được sử dụng theo những cách không ngờ tới.

**Kẻ tấn công bên ngoài:** Tác nhân bị tấn công thông qua các vectơ bên ngoài như công cụ, tệp tin hoặc truy cập mạng. Danh mục này bao gồm cả prompt injection và các cuộc tấn công thông thường vào runtime, lớp điều phối hoặc proxy của tác nhân.

Khi xây dựng hệ thống ngăn chặn và phòng thủ, chúng tôi áp dụng các biện pháp bảo vệ cho ba thành phần chính:

**Môi trường nơi tác nhân hoạt động.** Chúng tôi giới hạn vị trí và cách thức tác nhân có thể hành động bằng sandbox tiến trình, máy ảo, ranh giới hệ thống tệp và kiểm soát lưu lượng ra. Mục tiêu là thiết lập một ranh giới cứng về những gì tác nhân có thể tiếp cận. Ví dụ, nếu thông tin xác thực không bao giờ vào sandbox, chúng không thể bị đánh cắp, bất kể nguyên nhân là do người dùng, mô hình tìm ra "con đường sáng tạo" hay kẻ tấn công.

Một ranh giới chặt chẽ cũng có nghĩa là bạn có thể nới lỏng giám sát. Devcontainer tham chiếu của Claude Code tồn tại chính xác để tác nhân có thể chạy mà không cần giám sát, không cần phê duyệt từng hành động.

**Mô hình mà tác nhân tham vấn.** Các cơ chế ở đây bao gồm system prompt, bộ phân loại, đầu dò và các sửa đổi huấn luyện. Vì các mô hình có tính xác suất, những cơ chế này chỉ định hình xu hướng hành động của tác nhân, chứ không phải những gì nó có khả năng làm về mặt lý thuyết.

Các biện pháp phòng thủ này rất mạnh. Trên benchmark Agent Red Teaming của Gray Swan, kiểm tra khả năng chống prompt injection, Claude Opus 4.7 giữ tỷ lệ tấn công thành công ở mức khoảng 0,1% cho các lần thử đơn lẻ và khoảng 5–6% sau 100 lần thử thích ứng. Chế độ tự động của Claude Code phát hiện khoảng 83% hành vi quá khích trước khi chúng được thực thi. Tuy nhiên, ngay cả với các biện pháp phòng thủ tốt nhất, bảo vệ ở lớp mô hình sẽ không bao giờ đạt hiệu quả 100%, đó là lý do tại sao nó không thể đứng một mình.

**Nội dung bên ngoài mà tác nhân có thể tiếp cận.** Máy chủ MCP, plugin của bên thứ ba và công cụ tìm kiếm web đều đưa nội dung vào ngữ cảnh của tác nhân từ các nguồn bạn không kiểm soát. Một kết nối đã được kiểm toán không giống với dữ liệu đã được kiểm toán—ví dụ, một kết nối GitHub có thể tải trực tiếp một README độc hại vào ngữ cảnh của mô hình mặc dù đã vượt qua kiểm tra phần mềm độc hại. Giới hạn chi tiết quyền của công cụ có thể giúp giới hạn bán kính tác động. Ví dụ, một tác nhân có quyền truy cập chỉ đọc vào cơ sở dữ liệu có thể được triển khai rộng rãi hơn nhiều so với tác nhân có quyền ghi vào môi trường sản xuất.

Các biện pháp phòng thủ nên chồng chéo và bổ sung cho nhau. Khi các biện pháp phòng thủ môi trường không khả dụng, lớp mô hình phải bù đắp (đây chính xác là mục đích của chế độ tự động trong Claude Code). Ở cấp độ cục bộ, môi trường và các biện pháp phòng thủ mô hình có thể bảo vệ chống lại đầu ra công cụ độc hại, nhưng các biện pháp phòng thủ có thể được thêm vào ở cấp cao hơn bằng cách giới hạn khả năng và quyền truy cập của công cụ.

Tập trung vào lớp môi trường, chúng tôi mô tả ba mẫu cách ly và cách chúng được điều chỉnh cho từng nền tảng Claude—

claude.ai, Claude Code và Cowork. Chúng tôi đã dần dần đạt đến từng thiết kế sau khi tìm ra sự cân bằng giữa khả năng cần có từ agent và mức độ can thiệp cần thiết từ người dùng.

Dù được biết đến nhiều nhất như một giao diện trò chuyện, claude.ai cũng viết và chạy mã, tạo tệp và gọi các connector. Khi Claude chạy mã bên trong claude.ai, nó thực hiện điều đó trong một container gVisor trên cơ sở hạ tầng biệt lập. Agent hoàn toàn hoạt động phía máy chủ; không có mã nào chạy trên máy cục bộ, và hệ thống tệp là tạm thời (theo từng phiên). Bán kính ảnh hưởng là tối thiểu, nhưng giới hạn về những gì Claude có thể làm cũng thấp—không có không gian làm việc liên tục và không có quyền truy cập vào hệ thống tệp của người dùng.

Điều này cũng khiến claude.ai phải tuân theo một mô hình bảo mật truyền thống hơn. Chúng tôi không bảo vệ máy của người dùng khỏi các agent; chúng tôi bảo vệ cơ sở hạ tầng của chính mình và từng tenant khỏi nhau. Công việc tiền ra mắt của chúng tôi cho claude.ai chủ yếu là các công việc bảo mật truyền thống như cấu hình mạng, xác thực dịch vụ nội bộ và điều phối.

Công việc đó đã củng cố bài học lâu đời nhất về bảo mật: lớp yếu nhất là lớp do chính bạn xây dựng. gVisor và seccomp đã được củng cố chống lại các đối thủ có nguồn lực dồi dào trong thời gian dài hơn nhiều so với sự tồn tại của AI agent, vì vậy nỗ lực đánh giá tập trung vào các phần mới hơn mà chúng tôi xây dựng xung quanh chúng. Chúng tôi sẽ quay lại vấn đề này sau, vì proxy tùy chỉnh của chúng tôi cũng là phần đã bị hỏng trong sự cố nghiêm trọng nhất của chúng tôi.

Claude Code chạy trên máy của người dùng và có quyền truy cập vào hệ thống tệp, shell và mạng của họ. Nếu không có điều này, các agent lập trình sẽ có hữu ích hạn chế, vì vậy điều bắt buộc là phải tìm cách cấp quyền truy cập đó một cách an toàn.

Một cách tiếp cận là dựa vào con người trong vòng lặp. Đây chỉ là một giải pháp khả thi cho Claude Code vì người dùng trung bình là nhà phát triển quen thuộc với môi trường lập trình: họ có thể đọc bash, họ hiểu rm -rf làm gì, và họ đã chạy npm install từ các nguồn không đáng tin cậy vài lần mỗi tuần. Tất cả điều đó có nghĩa là khi một hộp thoại "cho phép điều này" bật lên,