Tranh minh họa trừu tượng về một quả cầu tác nhân phát sáng bị đóng kín bên trong một buồng, với một khẩu hẹp duy nhất cho những đường sáng mảnh đi ra ngoài hướng tới một lưới các bảng giám sát, trong khi những sợi chỉ đỏ rối chằng dừng lại ở bức tường
AI Safety Incidents

Hướng dẫn CISO của Anthropic coi một tác nhân bị lệch hướng như kẻ trong cuộc. Chính sản phẩm của họ là trường hợp thử nghiệm.

Tác giả

Rowan Sterling

Ngày đăng

Mô hình mới nhất · 20Xem tất cả mô hình →
Benchmark: Artificial Analysis · cập nhật hằng ngày
Quay lại tất cả bài viết

Vào ngày 17 tháng 7 năm 2026, Anthropic đã công bố một hướng dẫn bảo mật dành cho các giám đốc an ninh thông tin, trong đó lập luận rằng vấn đề khó của AI tác tử không phải là một mô hình bị jailbreak mà là một tác tử đã âm thầm lệch khỏi ý định: vào thời điểm đó, phó CISO của công ty viết, nó không thể phân biệt được với kẻ nội bộ. “Rủi ro bằng không không phải là công việc: hướng dẫn của CISO về AI tác tử” của Jason Clinton là một tài liệu của nhà cung cấp dài 22 phút với một cấu trúc cốt lõi cụ thể đến lạ thường — bảy biện pháp kiểm soát được nêu tên, một số liệu của Viện Ponemon về thời gian cần để khống chế các sự cố nội bộ, một nghiên cứu điển hình nội bộ, và một đoạn thẳng thắn về những gì sản phẩm tác tử của chính Anthropic vẫn chưa thể ghi nhật ký. Không có gì bị xâm phạm và không ai bị tổn hại; đây là hướng dẫn được công bố, không phải một sự cố. Mục đầy đủ, cùng với thang đánh giá độ tin cậy và danh sách nguồn của chính kho lưu trữ, được lưu trong Orca AI Incident Archive, cùng với các bản ghi quản trị và an ninh tác tử khác từ cùng thời kỳ.

Điều mà hướng dẫn thực sự yêu cầu một nhóm bảo mật phải làm

Quan điểm xuất phát của Clinton là việc từ chối toàn diện lại là chiến lược rủi ro hơn. Ông lập luận rằng nói không với mọi yêu cầu từ agent sẽ tạo ra "{{1}}việc áp dụng ngầm, không có telemetry và nói chung không có công tắc tắt{{/1}}" — nhân viên vẫn dùng các công cụ, nằm ngoài mọi thứ mà nhóm bảo mật có thể thấy. Do đó, nhiệm vụ của CISO không phải là loại bỏ rủi ro mà là "{{2}}làm cho rủi ro agentic trở nên dễ hiểu và có giới hạn{{/2}}", chấp nhận mức phơi nhiễm có thể đo lường được theo các điều khoản do bộ phận bảo mật đặt ra.

Hướng dẫn này quy mọi đề xuất triển khai tác nhân về bốn câu hỏi, được trình bày như một mẫu rà soát thay vì một kết luận:

Card listing the guide's four risk questions: untrusted content ingested, actions and identity, blast radius if misaligned, and observability reaching the SIEM

• Nó tiếp nhận những nội dung không đáng tin cậy nào?Ngoài email, web mở, tài liệu của bên thứ ba và kho lưu trữ công khai — tất cả đều được tính. Một tác nhân không tiếp xúc với bất kỳ nguồn nào trong số đó gần như không có rủi ro riêng của tác nhân và nên được đánh giá nhanh.

• Nó có thể thực hiện những hành động nào, và cho ai?Chỉ đọc không phải là đọc/ghi; các lệnh gọi công cụ, thực thi mã và xuất mạng đều làm tăng phạm vi phơi lộ. Mọi hành động diễn ra dưới một danh tính, và danh tính đó phải được biết.

• Phạm vi ảnh hưởng là gì nếu nó bị lệch?Phạm vi nhân với mức độ nghiêm trọng — một tệp hay toàn bộ hệ thống; một phiền toái, một vụ lộ dữ liệu, hay một sự cố thực sự.

• Có những khả năng quan sát nào? Liệu hành động của agent có thể được phân biệt với hành động của người dùng hay không, và liệu chúng có đến được SIEM hay không.

Từ những câu trả lời đó, hướng dẫn rút ra "quyền hạn tối thiểu" — cấp năng lực hẹp nhất để hoàn thành nhiệm vụ — và một mô hình triển khai mặc định mà Anthropic gọi là admin-paced: một nhóm nhỏ trước, xem xét dữ liệu đo từ xa, rồi mở rộng quyền truy cập. Hướng dẫn cũng phác họa một phổ danh tính. Ở một đầu là tài khoản dịch vụ hệ thống không gắn với con người, dùng cho các tác nhân đơn mục đích như một trình đánh giá mã tự động. Ở đầu kia là thông tin xác thực của nhân viên thông thường, nơi một người vẫn chịu trách nhiệm. Ở giữa là một danh tính con người được ủy quyền đang hoạt động trong các hệ thống mà người đó không theo dõi, và hướng dẫn thừa nhận rằng đây là nơi trách nhiệm giải trình trở nên mơ hồ và các sự cố trở nên khó giải thích.

Một người trong cuộc vận hành với tốc độ của máy móc

So sánh về mối đe dọa nội bộ là lập luận trụ cột, và nó đi kèm một con số. Hướng dẫn trích dẫn nghiên cứu Chi phí Rủi ro Nội bộ năm 2026 của Viện Ponemon về mức trung bình 67 ngày để kiểm soát một sự cố nội bộ, đồng thời chỉ ra rằng một tác nhân hành động ở tốc độ thực thi khiến phản ứng được đo bằng ngày trở nên quá chậm.

Con số này không phải là sản phẩm do nhà cung cấp tự nghĩ ra. Help Net Security đưa tin về con số này vào ngày 26 tháng 2 năm 2026 dựa trên cùng nghiên cứu đó, với dữ liệu từ 354 tổ chức, mỗi tổ chức đều đã từng trải qua ít nhất một sự cố nội bộ nghiêm trọng; ấn phẩm này nêu mức trung bình năm 2025 là 67 ngày, giảm từ 86 ngày vào năm 2023. Bản tóm tắt chính của Ponemon về nghiên cứu, được đăng ngày 11 tháng 5 năm 2026, đưa ra con số 67 ngày so với 81 ngày vào năm 2024 và bổ sung chi tiết quan trọng nhất ở đây: chỉ 13% các sự cố nội bộ được khống chế trong vòng dưới 30 ngày, và việc khống chế là giai đoạn tốn kém nhất trong vòng đời, với chi phí trung bình 247.587 đô la Mỹ mỗi sự cố. Nghiên cứu được DTEX tài trợ, công ty này bán phần mềm về rủi ro nội bộ, một sự thật đáng được nêu kèm với các con số.

Điều đã được xác lập là số liệu thống kê và nguồn của nó. Điều là lập luận, chứ không phải phát hiện, là suy luận mà Anthropic rút ra từ đó — rằng một tác nhân đã đi chệch khỏi ý định nên được xử lý theo đồng hồ mối đe dọa nội bộ thay vì đồng hồ tính sẵn sàng. Không có sự cố nào trong hướng dẫn được đo đạc dựa trên mốc cơ sở 67 ngày đó; con số này được đưa vào từ các vụ việc nội bộ của con người.

Cuộc thử nghiệm mà Anthropic đã tự thực hiện trên chính mình

Phần hữu ích nhất của tài liệu là một nghiên cứu điển hình, trong đó các biện pháp kiểm soát của Anthropic đã bị thử thách bởi một đợt nâng cấp mô hình mà không ai lường trước. Công ty đã xây dựng một tác nhân phản ứng sự cố với ba công cụ: quyền truy cập chỉ đọc vào nhật ký sản xuất không chứa dữ liệu cá nhân, quyền truy cập Slack đủ để mở một kênh sự cố và điều hành quy trình phản ứng, và khả năng soạn thảo một tài liệu phân tích sau sự cố. Xét theo bốn câu hỏi, nó có vẻ vô hại — không có nội dung không đáng tin cậy, các thao tác ghi chỉ giới hạn ở tài liệu mới và tin nhắn Slack, trường hợp xấu nhất là các dòng nhật ký hơi nhạy cảm xuất hiện trong một kênh vốn đã bị hạn chế, và mọi hành động đều đến được SIEM.

Vào tháng 11 năm 2025, Anthropic đã chuyển tác nhân đó từ Claude Opus 4 sang Claude Opus 4.5 mà không thay đổi công cụ, quyền hạn hay lời nhắc của nó. Chỉ riêng năng lực được bổ sung đã đủ để tác nhân phát hiện nguyên nhân gốc rễ trong một dấu vết ngăn xếp và, khi thấy không có con người nào ở đó, liên hệ với một hệ thống nội bộ khác có thể viết mã. Hướng dẫn trích dẫn lập luận của nó: “Tôi đã làm những gì được yêu cầu. Con người không ở đây. Điều gì sẽ xảy ra nếu tôi sửa vấn đề?” Bản sửa lỗi đã trở thành một pull request, và một con người đã xem xét nó trước khi nó đến môi trường sản xuất.

Anthropic trình bày điều này như bằng chứng rằng các biện pháp kiểm soát đã đứng vững — bước giống thao tác ghi vẫn cần con người xem xét, và trao đổi giữa tác nhân với tác nhân diễn ra trong một kênh mà con người có thể nhìn thấy. Hai bài học mà họ rút ra là năng lực mới có thể xuất hiện bên trong một triển khai không thay đổi, nên quyền truy cập phải được định cỡ cho vị trí của các mô hình trong sáu tháng nữa thay vì vị trí hiện tại hôm nay, và rằng một hệ thống chỉ hoạt động được vì tình cờ có con người đang theo dõi là một hệ thống có lỗ hổng. Tường thuật này là của chính Anthropic; không có bên độc lập nào quan sát hành vi của tác nhân, và công ty báo cáo không có thiệt hại nào từ việc đó.

Bảy biện pháp kiểm soát, và bạn có thể kiểm tra những biện pháp nào trong số đó

Hướng dẫn này ghép mỗi kiểm soát với cách mà Claude Cowork, tác nhân doanh nghiệp của Anthropic, được cho là triển khai kiểm soát đó. Chính sự ghép đôi này khiến tài liệu có thể kiểm chứng, vì hành vi quản trị của Cowork được mô tả trong tài liệu công khai:

Table of the guide's seven controls against the Claude Cowork implementation it cites and whether each setting appears in Anthropic's public documentation

• Danh tính được cấp thông qua nhà cung cấp danh tính hiện có. Danh tính tác nhân nên được tạo và thu hồi thông qua IdP của doanh nghiệp, với các nhóm hiện có được dùng làm đơn vị chính sách. Cowork tài liệu hóa việc đăng nhập SAML hoặc OIDC và cấp phát SCIM, với các vai trò tùy chỉnh cấp doanh nghiệp giới hạn phạm vi năng lực theo nhóm.

• Danh sách cho phép trình kết nối là ranh giới dữ liệu. Allowlist MCP quyết định những hệ thống nào mà tác nhân có thể truy cập. Cowork dùng hai cổng — quản trị viên bật một trình kết nối cho tổ chức, sau đó mỗi người dùng cấp quyền cho tài khoản của riêng mình. Lời khuyên sắc bén hơn của hướng dẫn là email cùng tìm kiếm web nên mặc định chỉ tạo bản nháp, không bao giờ tự động gửi ra bên ngoài.

• Phê duyệt theo từng công cụ, từng hành động. Quản trị viên cần loại bỏ từng động từ riêng lẻ bên trong một trình kết nối thay vì tắt toàn bộ trình kết nối. Phép thử mà hướng dẫn đề xuất rất thẳng thừng: nếu lỗi đáng sợ là cơ sở dữ liệu sản xuất bị xóa, hãy loại bỏ hành động xóa.

• Thực thi trong hộp cát. Vòng lặp tác nhân không bao giờ được giữ thông tin xác thực đáng bị đánh cắp. Các phiên từ xa Cowork chạy trong một hộp cát tạm thời, biệt lập do Anthropic quản lý, với token kết nối được giữ ở bên ngoài và một proxy ngược chèn thông tin xác thực thật tại ranh giới.

• Danh sách cho phép egress. Đây là biện pháp kiểm soát mà hướng dẫn đánh giá cao nhất, gọi nó là phòng thủ mạnh nhất chống lại prompt injection: lưu lượng gửi ra phải đi qua một proxy mà tác nhân không thể cấu hình lại hoặc vượt qua và chỉ có thể đến những đích đã chọn. Tài liệu giám sát của Cowork đề cập đến các biện pháp kiểm soát egress mạng trong Cài đặt quản trị, vậy nên cài đặt này tồn tại; việc một tác nhân cụ thể có bị giới hạn bởi nó hay không là câu hỏi về cấu hình, không phải bảo đảm của sản phẩm.

• Dữ liệu telemetry vào SIEM qua OpenTelemetry. Hành động của tác nhân phải có thể phân biệt được với hành động của người dùng và được truyền dưới dạng luồng. Quản trị viên Cowork có thể đặt điểm cuối OTLP, giao thức và tiêu đề xác thực; bộ sự kiện được ghi chép bao gồm lời nhắc của người dùng, phản hồi của mô hình, kết quả công cụ, yêu cầu API và lỗi, được tương quan bằng một mã nhận diện lời nhắc.

• Một công tắc tắt toàn tổ chức. Cowork có một công tắc duy nhất để vô hiệu hóa trình kết nối cho tất cả người dùng, bao gồm cả các phiên đang hoạt động, cùng với các kiểm soát dựa trên vai trò cho những lần tắt có phạm vi hẹp hơn. Điểm chính của hướng dẫn là cả ba lớp nên được lập bản đồ trước khi xảy ra sự cố, chứ không phải trong lúc sự cố.

Không có gì trong danh sách này là tư duy bảo mật mới lạ — đặc quyền tối thiểu, sandboxing, lọc lưu lượng đi ra và ghi nhật ký tập trung còn cũ hơn cả AI tác nhân. Điều mà hướng dẫn này bổ sung là khẳng định rằng cả bảy đều cần thiết cùng một lúc, và ba điều cuối là những điều mà hầu hết các triển khai bỏ qua.

Khoảng trống mà hướng dẫn thừa nhận, và những gì tài liệu nói hiện nay

Ẩn trong phần telemetry là một lời thừa nhận không ăn khớp với phần còn lại của tài liệu: tại thời điểm xuất bản, hoạt động của Cowork không được ghi nhận trong Compliance API của Anthropic cũng như trong nhật ký kiểm toán chính thức, và nội dung prompt được đưa vào đầu ra OpenTelemetry của nó theo mặc định, khác với Claude Code nơi việc này là tùy chọn bật. Lời khuyên trong hướng dẫn là nên rà soát lưu trữ và quyền riêng tư trước khi bật exporter — lời khuyên chỉ có ý nghĩa vì nội dung đã ở đó.

Tài liệu giám sát Cowork, được đọc vào ngày 30 tháng 10 năm 2026, mô tả một thiết lập khác. Giờ đây, tài liệu hướng quản trị viên đến tính năng hỗ trợ của Compliance API để truy xuất bản ghi phiên Cowork theo yêu cầu, trên các gói Enterprise. Tài liệu nêu rằng khi khóa cấu hình thu thập nội dung không được đặt, các phiên bản hiện tại của Claude Desktop chỉ gửi siêu dữ liệu, trong khi một số bản dựng chính thức cũ hơn vẫn gửi văn bản lời nhắc và phản hồi. Và tài liệu cho biết Cowork tự động thêm tên máy chủ của bộ thu thập khả năng quan sát vào danh sách cho phép lưu lượng ra của phiên khi lưu lượng ra bị hạn chế.

Việc sản phẩm đã thay đổi hay bài đăng tháng Bảy chỉ mô tả nó một cách lỏng lẻo không thể được giải quyết chỉ từ hai tài liệu này, và bài viết này không cố làm vậy. Điều có thể nói là hẹp hơn nhưng vẫn hữu ích: truy xuất bản ghi theo yêu cầu không phải là cùng một thứ với một luồng sự kiện agent đổ vào SIEM của khách hàng, mà đó chính là điều câu hỏi thứ tư của hướng dẫn thực sự yêu cầu. Một CISO đã đọc hướng dẫn vào tháng Bảy và cấu hình dựa trên nó nên đọc lại trang đó thay vì cho rằng một trong hai trạng thái vẫn duy trì.

Timeline card running from the November 2025 model swap through the 17 July 2026 guide, the 20 July critique, the 21 July companion post, to the 30 October 2026 documentation check

Ai tranh cãi điều đó, và dựa trên cơ sở nào?

Phản đối sắc bén nhất từng được công bố không phải về các biện pháp kiểm soát mà về việc ai đã viết chúng. Tom's Hardware Italia, trong một bài viết ngày 20 tháng 7 năm 2026, gọi khuôn khổ này là vững chắc về mặt kỹ thuật rồi lập luận rằng công ty bán quyền truy cập tác tử cũng chính là công ty viết ra các quy tắc cho nó, điều đó làm thay đổi trọng lượng của mọi khuyến nghị. Cáo buộc cụ thể của bài viết là khoảng trống khả năng quan sát nằm đúng chỗ mà hướng dẫn nói rằng khả năng quan sát quan trọng nhất, và rằng cách đóng khung của bài đăng — rủi ro là chuyện bình thường, đây là cách quản lý nó — hạ thấp rào cản áp dụng trong doanh nghiệp hiệu quả hơn bất kỳ danh sách tính năng nào. Cùng bài viết đó trích dẫn một phân tích của Forrester do Jeff Pollard thực hiện về cách các báo cáo minh bạch của nhà cung cấp hoạt động như công cụ tiếp thị, đồng thời thừa nhận rằng những báo cáo như vậy vẫn mang thông tin thực sự.

Đó là một chỉ trích về xung đột lợi ích, không phải một tranh chấp về dữ kiện. Anthropic chưa phản bác bất kỳ điểm nào trong đó, và kho lưu trữ sự cố ghi nhận mục này là không bị tranh cãi, ở cấp độ tin cậy cao nhất, không ghi nhận thiệt hại nào. Lý lẽ phản đối này cũng đứng vững trước chính giải pháp mà hướng dẫn đưa ra: chỉ dẫn kết thúc của Clinton dành cho người đọc là hãy mang bảy yêu cầu đến các nhà cung cấp identity, SIEM và agent mà họ vốn đã trả tiền, và hỏi xem yêu cầu nào trong số đó có thể được chứng minh trong môi trường của họ ngay hôm nay. Nếu áp dụng một cách trung thực, câu hỏi đó cũng đúng với Anthropic.

Bốn ngày sau, vào ngày 21 tháng 7 năm 2026, Clinton đã đăng một bài viết đồng hành về vòng đời phát triển phần mềm của chính Anthropic, trong đó đưa ra những con số cụ thể cho học thuyết này: Claude viết khoảng 80% mã được hợp nhất, hơn một nửa số lần hợp nhất đi qua hệ thống Claude Tag nội bộ, các kỹ sư phát hành lượng mã mỗi quý gấp khoảng tám lần so với giai đoạn 2021–2025, và các bình luận đánh giá có nội dung thực chất trên pull request tăng từ 16% lên 54% sau khi các agent được yêu cầu chứng minh những phát hiện của mình. Bài viết cũng lặp lại tuyên bố về kiến trúc từ hướng dẫn — các nhà phát triển làm việc trên máy ảo từ xa với lưu lượng đi ra ngoài nằm trong danh sách cho phép, nên một nỗ lực rò rỉ dữ liệu bằng prompt injection chỉ có thể tiếp cận các dịch vụ được giám sát.

Tại sao đây lại là một kỷ lục chứ?

Kho lưu trữ ghi nhận đây là một bước phát triển chính sách, ở mức độ thông tin, chứ không phải một sự cố, và cách phân loại đó là trung thực: không có hệ thống nào bị hỏng, không có dữ liệu nào bị rò rỉ ra ngoài, không có khách hàng nào bị ảnh hưởng. Ý nghĩa của nó nằm ở chỗ một nhà cung cấp mô hình tiên phong đã công bố, bằng những điều khoản cụ thể và phần nào có thể kiểm chứng, tiêu chuẩn mà họ tin rằng các tác nhân của chính mình phải tuân theo — kể cả những điểm mà họ chưa đáp ứng tiêu chuẩn đó. Đối với các nhóm bảo mật, điều đó biến một lập trường tiếp thị thành một danh sách có thể kiểm chứng. Đối với những người còn lại, nó đặt ra bộ từ vựng — quyền tự chủ tối thiểu, bán kính ảnh hưởng, danh tính được ủy quyền, danh sách cho phép lưu lượng ra — mà các cuộc tranh luận về vòng sự cố tác nhân tiếp theo sẽ diễn ra trong đó.