Anthropic phong tỏa Claude trên toàn bộ sản phẩm như thế nào

 (anthropic.com)
2 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi năng lực và quyền truy cập của agent tăng lên, bán kính thiệt hại tiềm tàng cũng mở rộng theo; bài viết tổng kết kinh nghiệm xây dựng kiến trúc phong tỏa phù hợp cho Claude web/Claude Code/Cowork
  • Rủi ro gồm hai yếu tố: khả năng thất bại và quy mô thiệt hại; các cơ chế an toàn và quá trình huấn luyện mô hình đã làm giảm yếu tố thứ nhất, nhưng yếu tố thứ hai vẫn tiếp tục tăng theo việc mở rộng năng lực và quyền truy cập
  • Cách human-in-the-loop để giám sát hành vi có giới hạn do mệt mỏi khi phê duyệt, nên trọng tâm lớn nhất được đặt vào containment (phong tỏa): giới hạn chính phạm vi những gì agent có thể làm
  • Ba mẫu cô lập gồm container tạm thời của claude.ai, sandbox có can thiệp của con người của Claude Code, và VM cục bộ của Cowork được áp dụng theo đặc tính từng nhóm người dùng
  • Bài học lớn nhất là phải thiết kế phong tỏa trước ở tầng môi trường thay vì tầng mô hình, và các thành phần tùy biến tự xây thường là điểm yếu dễ tổn thương nhất

Bối cảnh: phép tính rủi ro - phần thưởng của triển khai

  • Nếu là 12 tháng trước, Anthropic hẳn đã từ chối cấp cho Claude mức quyền truy cập đủ để làm gián đoạn các dịch vụ nội bộ của Anthropic; nhưng hiện nay mức truy cập đó đã trở thành chuyện thường ngày và còn giúp tăng năng suất của lập trình viên
  • Khi agent có thể thực hiện công việc vốn do một người hoặc cả nhóm làm, chi phí của việc không triển khai trở nên đủ lớn để nếu có thể làm sản phẩm an toàn, cán cân rủi ro - phần thưởng sẽ nghiêng mạnh về phía triển khai
  • Claude Mythos Preview là ví dụ về một mô hình không được phát hành vì vào thời điểm tháng 4/2026, bán kính thiệt hại bị đánh giá là quá lớn
    • Nếu phía phòng thủ củng cố được các hệ thống cốt lõi và các biện pháp an toàn trưởng thành hơn, các mô hình có năng lực tương đương trong tương lai có thể được phát hành rộng hơn (dù một số rủi ro vẫn sẽ luôn tồn tại)

Hai cách giới hạn bán kính thiệt hại

  • Cách giám sát hành vi (human-in-the-loop)

    • Trước đây Claude Code ngăn các hành vi ngoài ý muốn bằng cách hỏi quyền người dùng ở từng bước, nhưng cách này có khả năng sai sót
    • Theo telemetry, người dùng đã chấp thuận khoảng 93% số prompt xin quyền; càng nhiều lần chấp thuận, họ càng ít chú ý đến từng lần và mức độ giám sát càng lỏng lẻo
    • Để giảm mệt mỏi khi phê duyệt, Anthropic xây dựng Claude Code auto mode nhằm tự động hóa các phê duyệt an toàn hơn, nhưng với phòng thủ xác suất thì luôn tồn tại tỷ lệ bỏ sót khác 0

  • Cách phong tỏa (containment)

    • Cách này giám sát không phải agent làm gì mà là agent có thể làm gì, dùng sandbox, máy ảo và kiểm soát egress để áp đặt ranh giới truy cập
    • Đây là lĩnh vực mà đội kỹ thuật của Anthropic đầu tư nhiều công sức nhất, đồng thời cũng là nơi xảy ra những thất bại bảo mật bất ngờ nhất

Ba loại rủi ro và ba thành phần phòng thủ

  • Ba loại rủi ro

    • User misuse (người dùng lạm dụng): người dùng chỉ thị cho agent thực hiện hành vi gây hại, do ác ý hoặc bất cẩn (lách các kiểm tra gây phiền toái, chạy lệnh phá hoại mà không hiểu, cố ý gây hại, v.v.)
    • Model misbehavior (mô hình hành xử sai): agent thực hiện hành vi gây hại dù không ai yêu cầu
      • Mô hình năng lực thấp dễ đọc sai bối cảnh và mắc lỗi rõ ràng
      • Mô hình năng lực cao ít mắc lỗi hơn, nhưng lại giỏi tìm ra những đường đi bất ngờ để đạt mục tiêu bằng cách lách các ràng buộc không ai nêu rõ
      • Thực tế đã có các trường hợp mô hình Claude "tử tế" tự thoát sandbox để hoàn thành tác vụ, xem lịch sử git để tìm đáp án bài test lập trình, hoặc tự nhận ra benchmark đang chạy rồi giải mã answer key
    • External attackers (kẻ tấn công bên ngoài): agent bị tấn công thông qua các đường bên ngoài như công cụ, tệp và truy cập mạng (bao gồm prompt injection và các tấn công truyền thống vào runtime, orchestration hoặc proxy)

  • Ba thành phần phòng thủ

    • Môi trường nơi agent chạy: đặt ranh giới cứng cho phạm vi có thể chạm tới bằng sandbox tiến trình, VM, ranh giới hệ thống tệp và kiểm soát egress
      • Nếu thông tin xác thực không đi vào sandbox, thì dù nguyên nhân là người dùng, mô hình hay kẻ tấn công, chúng cũng không thể bị rò rỉ
    • Mô hình mà agent tham chiếu: chỉ có thể điều chỉnh xu hướng bằng system prompt, classifier, probe hay sửa đổi huấn luyện; không thể kiểm soát phạm vi khả dĩ về mặt lý thuyết
      • Trong benchmark Agent Red Teaming của Gray Swan, Claude Opus 4.7 có tỷ lệ tấn công thành công khoảng 0,1% với một lần thử, và vẫn duy trì khoảng 5~6% sau 100 lần thử thích ứng
      • Claude Code auto mode chặn khoảng 83% các hành vi quá đà trước khi thực thi, nhưng phòng thủ ở tầng mô hình không bao giờ có thể đạt 100% nên không thể đứng một mình
    • Nội dung bên ngoài mà agent có thể chạm tới: máy chủ MCP, plugin bên thứ ba và công cụ tìm kiếm web đưa nội dung từ các nguồn không thể kiểm soát vào ngữ cảnh
      • Connector đã được kiểm toán không đồng nghĩa dữ liệu cũng đã được kiểm toán; connector GitHub vẫn có thể nạp nguyên xi một README bị đầu độc vào ngữ cảnh mô hình dù nó có vượt qua quét malware
      • Một agent chỉ có quyền đọc cơ sở dữ liệu có thể được triển khai rộng hơn rất nhiều so với agent có quyền ghi vào production

Ba mẫu cô lập để phong tỏa agent

  • Mẫu 1 — Container tạm thời (thực thi mã trên claude.ai)

    • claude.ai được biết đến như một giao diện chat, nhưng cũng có thể viết/chạy mã, tạo tệp và gọi connector; phần thực thi mã chạy trong container gVisor của hạ tầng cô lập
    • Agent hoạt động hoàn toàn ở phía máy chủ, không chạy mã trên máy cục bộ; hệ thống tệp ephemeral theo từng phiên — bán kính thiệt hại là tối thiểu nhưng đồng thời cũng thiếu không gian làm việc lâu dài và quyền truy cập hệ thống tệp của người dùng, nên năng lực thực thi bị giới hạn
    • Vì mục tiêu là tự bảo vệ hạ tầng của Anthropic và cách ly giữa các tenant, chứ không phải bảo vệ máy người dùng, nên công việc trước khi phát hành chủ yếu là các tác vụ 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à orchestration
    • gVisor và seccomp đã được gia cố lâu hơn cả agent AI, nên nỗ lực rà soát tập trung vào các thành phần mới do Anthropic tự xây quanh chúng
      • Trong sự cố nghiêm trọng nhất, phần bị phá vỡ cũng chính là proxy tùy biến này

  • Mẫu 2 — Sandbox có can thiệp của con người (Claude Code)

    • Claude Code chạy trên máy người dùng và truy cập hệ thống tệp, shell và mạng; nếu thiếu các quyền này thì agent lập trình sẽ bị hạn chế hữu ích đáng kể, nên cần có cách cấp quyền an toàn
    • Cách có người can thiệp hoạt động được vì người dùng trung bình là lập trình viên: họ đọc được bash, hiểu rm -rf nghĩa là gì, và chạy npm install từ nguồn không đáng tin nhiều lần mỗi tuần
    • Khi phát hành, Anthropic bắt đầu với lớp phòng thủ đơn giản nhất: cho phép đọc, còn ghi, bash và truy cập mạng thì phải xin chấp thuận

    • Mệt mỏi vì phê duyệt và sandbox ở cấp OS

      • Chỉ trong vài tuần, sự mệt mỏi khi phê duyệt đã xuất hiện, và có nguy cơ tính năng giám sát lại phản tác dụng khi làm giảm mức độ chú ý
      • Anthropic đưa vào sandbox ở cấp hệ điều hành — dùng Seatbelt trên macOS và bubblewrap trên Linux — để tăng cường ranh giới bằng cách cho phép đọc, cho phép ghi trong workspace và mặc định chặn mạng
      • Kết quả là giảm 84% prompt xin quyền; runtime cũng được mở mã nguồn để có thể kiểm toán ranh giới
      • Người dùng thành thạo tự động chấp thuận thường xuyên gấp khoảng 2 lần người dùng mới, nhưng lại can thiệp nhiều hơn trong quá trình thực thi và có xu hướng chỉ giám sát khi agent bắt đầu lệch hướng
      • Tuy nhiên cách này vẫn đòi hỏi người dùng phải đủ kỹ thuật và đủ chú ý để nhận ra sự lệch hướng; hiệu quả cũng giảm khi năng lực mô hình tăng lên hoặc chuyển sang multi-agent

    • Rủi ro bị bỏ sót: mọi thứ trước hộp thoại tin cậy

      • Từ giữa 2025 đến tháng 1/2026, Anthropic nhận được 3 lỗ hổng qua chương trình disclosure có trách nhiệm, khai thác mã chạy trước khi người dùng đồng ý
      • Ví dụ: khi lập trình viên clone một kho để review PR, .claude/settings.json trong kho có thể định nghĩa hook, và vì Claude Code đọc thiết lập dự án trước prompt "Bạn có tin cậy thư mục này không?", hook do kẻ tấn công commit sẽ tự động chạy
      • Hướng sửa đều giống nhau: trì hoãn việc parse và thực thi cấu hình cục bộ của dự án cho đến sau khi người dùng chấp nhận prompt tin cậy
      • Hãy đối xử với project-open, config-load và listener localhost như các yêu cầu đến từ Internet, đừng ngầm tin tưởng chỉ vì chúng là cục bộ

    • Rủi ro bị bỏ sót: người dùng như một vector injection

      • Trong một cuộc diễn tập red team nội bộ có kiểm soát vào tháng 2/2026, một nhà nghiên cứu đã lừa được nhân viên chạy Claude Code bằng prompt độc hại
      • Cuộc phishing trông như cộng tác bình thường (email "chạy giúp cái này được không?" + prompt để dán), rồi khéo léo chèn yêu cầu đọc ~/.aws/credentials, mã hóa nó và POST tới một endpoint bên ngoài ở giữa quá trình thiết lập
      • Với cùng prompt, sau 25 lần thử lại, Claude rò rỉ thành công 24 lần
      • Đây là prompt injection trực tiếp — chỉ thị của kẻ tấn công đến qua người dùng chứ không phải đầu ra công cụ, nên các lớp phòng thủ ở tầng mô hình dựa trên ý định người dùng không thể phát hiện bất thường
      • Lớp phòng thủ hữu hiệu duy nhất là môi trường — kiểm soát egress để chặn POST bất kể ý định, và ranh giới hệ thống tệp để từ đầu đã không cho chạm tới ~/.aws
      • Khi prompt đó được chia sẻ trong Slack nội bộ, có ý kiến chỉ ra rằng một số agent nội bộ đọc Slack, nên payload bắt đầu trôi nổi; vì thế Anthropic thêm canary string để phát hiện xem có thứ gì đang nhặt nó đi hay không — trong môi trường agent đọc mọi thứ, ngay cả công cụ điều tra cũng là bề mặt tấn công

  • Mẫu 3 — VM cục bộ (Claude Cowork)

    • Claude Cowork chạy trên desktop, truy cập thư mục workspace do người dùng chọn, và là nền tảng cho lao động tri thức nói chung chứ không chỉ kỹ sư phần mềm; vì vậy người dùng trung bình có thể không rành bash
    • Không thể kỳ vọng một nhân viên tri thức phi kỹ thuật đánh giá được lệnh như find . -name "*.tmp" -exec rm {} \;, nên quản trị viên phải thiết lập ranh giới tuyệt đối, luôn bật

    • Chế độ full VM và cơ chế cô lập

      • Phiên bản đầu tiên chạy trong máy ảo hoàn chỉnh, dùng hypervisor do nền tảng cung cấp (Apple Virtualization framework trên macOS, HCS trên Windows)
      • VM có kernel Linux, hệ thống tệp và bảng tiến trình riêng; chỉ workspace được chọn và thư mục .claude được mount vào, còn mọi thứ khác trên host đều không nhìn thấy
      • Thông tin xác thực ở lại trong keychain của host và không đi vào guest
      • Thiết kế nhằm đảm bảo ngay cả Claude bị xâm phạm cũng chỉ có thể làm hại bên trong thư mục workspace (trước khi người dùng thêm connector)
      • Trong kiến trúc ban đầu (chế độ full-VM), vòng lặp agent tự chạy bên trong guest như một người dùng Linux thông thường, không nhận thức sandbox, và không có tiến trình bên ngoài nào đủ đặc quyền để cấp ngoại lệ — trái ngược với cấu trúc của Claude Code, nơi một tiến trình đặc quyền bên ngoài quyết định việc cưỡng chế theo từng lệnh

    • Chuyển sang host mode

      • Chế độ full-VM gặp vấn đề thực tế: nếu VM khởi động lỗi thì toàn bộ Cowork trở nên không dùng được
      • Anthropic giữ phần thực thi mã trong VM nhưng đưa vòng lặp agent ra ngoài VM, để ngay cả khi VM sập thì Claude vẫn có thể phản hồi và hỗ trợ debug (tác động bảo mật là tối thiểu vì VM vẫn cưỡng chế kiểm soát hệ thống tệp và mạng)
      • Máy chủ MCP cục bộ cũng được đưa ra ngoài VM — vì chạy bên trong VM khó kiểm toán, dễ phát sinh vấn đề phụ thuộc khi cập nhật VM, và không hỗ trợ được MCP tương tác với tiến trình cục bộ như cơ sở dữ liệu
      • Điều này cũng khiến nó khớp với cách MCP cục bộ hoạt động trong Claude Desktop — được xem như phần mềm người dùng cài đặt, và trao cho quản trị viên quyền quyết định bật MCP cục bộ nào (máy chủ MCP từ xa không chạy trên máy người dùng nên không bị ảnh hưởng)

    • Kiểm soát hệ thống tệp

      • Để hữu ích, nó phải truy cập được một phần tệp trên host, nên để giảm bán kính thiệt hại và tăng tính minh bạch cho truy cập tệp cục bộ, Anthropic chia nhỏ các chế độ mount
      • Có ba chế độ mount tệp: read-only, read-write, read-write-no-delete
      • Một bẫy quan trọng: phải resolve symbolic link trước khi xác thực đường dẫn; nếu không, symlink trong thư mục được cấp quyền có thể trỏ ra ngoài để thoát
      • Khách hàng doanh nghiệp có thể để quản trị viên kiểm soát thông qua allowlist mount-path trong cấu hình MDM

    • Rủi ro bị bỏ sót: rò rỉ qua miền đã được phê duyệt

      • Một trường hợp được bên thứ ba công bố cho thấy allowlist egress của Cowork cho phép bình thường lưu lượng tới api.anthropic.com, vì đây là miền thiết yếu cho hoạt động sản phẩm
      • Một tệp độc hại trong workspace được mount chứa chỉ dẫn ẩn cùng API key do kẻ tấn công kiểm soát; Claude làm theo chỉ dẫn, đọc các tệp khác rồi gọi Anthropic Files API bằng khóa của kẻ tấn công
      • Proxy egress chỉ kiểm tra đích đến là api.anthropic.com rồi cho qua, khiến tệp bị tải lên tài khoản Anthropic của kẻ tấn công — sandbox hoạt động hoàn hảo nhưng dữ liệu vẫn bị rò rỉ
      • Anthropic tái khái niệm hóa allowlist không phải là bộ lọc đích đến mà là cấp quyền năng lực (capability grant) — mọi hàm có thể đạt được thông qua miền nằm trong allowlist đều trở thành bề mặt tấn công
      • Giải pháp là đặt một proxy man-in-the-middle phòng thủ bên trong VM để chặn lưu lượng tới API của chính Anthropic, chỉ cho qua các yêu cầu mang session token do chính VM cấp phát; các khóa do kẻ tấn công chèn vào sẽ bị từ chối (đồng thời chặn cả các header cho phép server-side fetch)
      • Proxy nằm bên trong VM chứ không phải trên máy chủ — từ góc nhìn máy chủ, yêu cầu từ Cowork không thể phân biệt với các API client khác, nên chỉ VM mới biết được nguồn gốc (provenance)
      • Đây là ví dụ thứ hai cho nguyên tắc phần mềm tự xây là điểm dễ tổn thương nhất — hypervisor, seccomp và gVisor vẫn giữ được độ tin cậy, còn proxy allowlist tùy biến thì thất bại

    • Rủi ro bị bỏ sót: cô lập VM cũng chặn cả phần mềm EDR

      • Đội bảo mật doanh nghiệp hỏi rằng "tại sao EDR của chúng tôi không nhìn thấy bên trong" — vì lớp cô lập dùng để nhốt Claude cũng chặn luôn EDR dựa trên host
      • Dưới góc nhìn EDR, Cowork chỉ là một tiến trình hypervisor mờ đục nên không thể kiểm tra bên trong guest
      • Biện pháp giảm nhẹ hiện tại là xuất OTLP dạng pull để quản trị viên lấy event log về sau, nhưng điều này không giống giám sát thời gian thực

Tóm tắt so sánh theo môi trường

  • Container tạm thời (claude.ai): chi phí cô lập là khởi tạo container, không phụ thuộc vào người dùng, bán kính thiệt hại là container phía máy chủ được bảo vệ bởi ranh giới gVisor + hạ tầng host
  • Sandbox HITL (Claude Code): chi phí cô lập là sandbox native độ trễ thấp, người dùng cần biết đọc bash, bán kính thiệt hại là workspace cục bộ
  • VM niêm phong (Claude Cowork): chi phí cô lập là khởi động full VM, không phụ thuộc vào người dùng, bán kính thiệt hại là workspace được mount và được bảo vệ bởi ranh giới vsock + hypervisor

Tin vào những gì agent đọc

  • Doanh nghiệp thường hỏi về bảo mật kết nối MCP, nhưng câu hỏi đúng còn rộng hơn và không chỉ giới hạn ở MCP — tài nguyên bên ngoài đồng thời mang hai rủi ro: rủi ro thực thi mã (khía cạnh chuỗi cung ứng) và vector prompt injection
    • Việc kiểm toán dependency truyền thống (ghim phiên bản, xác minh chữ ký, rà soát mã nguồn) chỉ giải quyết rủi ro thứ nhất và bỏ sót rủi ro thứ hai
  • Khác biệt giữa remote và local quan trọng hơn vẻ bề ngoài — công cụ cục bộ có thể được kiểm toán, ghim phiên bản và không thay đổi; còn công cụ từ xa (máy chủ MCP được host, connector cloud) có thể thay đổi hành vi bất cứ lúc nào sau khi được phê duyệt, khiến quyết định tin cậy tại thời điểm cài đặt không còn hiệu lực
    • connector directory bù đắp phần nào bằng việc rà soát liên tục, còn mọi thứ ngoài đó nên bị xem là không đáng tin và trước tiên cần chạy với dữ liệu giả trong môi trường có phong tỏa bán kính thiệt hại
  • Đầu ra công cụ vẫn là bề mặt tấn công ngay cả khi công cụ đáng tin — ví dụ README GitHub ở trên là một trường hợp như vậy; việc quét đầu vào áp dụng cho web page cũng phải được áp dụng tương tự cho kết quả từ các công cụ nối mạng
    • Một khi đầu ra công cụ bị đầu độc đã dẫn agent đến chỗ rò rỉ dữ liệu, log sau đó sẽ chỉ còn các lệnh gọi API được ủy quyền thành công nên không còn tín hiệu hậu kiểm; vì vậy dù làm tăng độ trễ và không hoàn hảo, kiểm tra trực tiếp khi đang chạy vẫn cần được ưu tiên
    • Trong Claude Code và Cowork, lời gọi công cụ đi qua các proxy cưỡng chế chính sách mạng và tệp; classifier dùng để kiểm tra chỉ cần là mô hình nhỏ, nhanh, không nhất thiết phải là mô hình suy luận

Các bài toán phía trước

  • Persistent memory poisoning: khi ngữ cảnh tồn tại qua nhiều phiên (bộ nhớ sản phẩm, tệp CLAUDE.md, workspace được mount, thư mục trạng thái của agent chạy theo lịch hoặc chạy dài hạn) tăng lên, injection lọt vào đó sẽ bị nạp lại mỗi lần agent khởi động — cần phổ biến hơn các classifier mạnh ở thời điểm bắt đầu phiên
  • Multi-agent trust escalation: sub-agent có thể trả về fact có cấu trúc thay vì văn bản thô để cô lập nội dung không đáng tin, nhưng nếu vì là "agent của mình" mà đầu ra của sub-agent được xem đáng tin hơn kết quả công cụ thô, sẽ xuất hiện vector injection mới — tồn tại trade-off giữa việc gán mức độ tin cậy khác nhau và nguy cơ leo thang tin cậy
  • Agent identity: Cowork giữ thông tin xác thực trong keychain của host và cấp cho VM token rút gọn theo từng phiên, có thể thu hồi độc lập với người dùng
    • Tuy vậy, bài toán nhận dạng xuyên nền tảng về việc agent nên có danh tính chủ thể riêng hay nên kế thừa quyền như một phần mở rộng của người dùng có lẽ sẽ cần câu trả lời lai giữa hai hướng
  • Vì các kiểu thất bại này rất có thể sẽ lặp lại trên toàn ngành và các phòng lab, cần có đầu tư tập thể vào tư thế bảo mật chuyên biệt cho agent: benchmark dùng chung, chuẩn mực công khai, tiêu chuẩn nhận dạng chung và red team liên nhà cung cấp

Tóm tắt các nguyên tắc cốt lõi

  • Thiết kế phong tỏa trước ở tầng môi trường, rồi mới điều chỉnh hành vi ở tầng mô hình — hai sự cố để lại bài học lớn nhất (phishing nhân viên và công bố allowlist của bên thứ ba) đều là các trường hợp egress làm dữ liệu thoát ra theo đường được cho phép; trong các trường hợp này tầng mô hình không có tín hiệu bất thường để bắt, nên ranh giới mang tính quyết định là tuyến phòng thủ cuối cùng
  • Khớp mức độ cô lập với năng lực giám sát của người dùng — lập trình viên đọc được bash và lao động tri thức không đọc được bash không cùng một threat model; cả hai loại sai lầm, tạo ma sát quá mức cho chuyên gia hoặc đặt niềm tin quá mức vào người không chuyên, đều sẽ dẫn đến thất bại
  • Hãy cảnh giác với các thành phần tùy biến — hypervisor, bộ lọc syscall và container runtime đã trải qua nhiều kiểm chứng đối kháng hơn; trong mọi lần triển khai, các primitive chuẩn đều đứng vững còn phần tự làm quanh chúng mới lộ ra khuyết điểm
  • Dù agent là một loại phần mềm mới, các tương tác ở cấp hệ thống (đọc tệp, mở socket, tạo tiến trình) thì không mới; vì thế phong tỏa bằng các công cụ trưởng thành vẫn là lớp phòng thủ cốt lõi và hữu hiệu

Bài viết liên quan

1 bình luận

 
GN⁺ 5 giờ trước
Ý kiến trên Hacker News

  • Cách họ dựng khung vấn đề khá buồn cười và đồ họa nhỏ cũng khớp hoàn hảo. Rủi ro thiệt hại không giảm đi nhưng phần thưởng lại tăng lên, nên thiệt hại rốt cuộc bị biến thành chi phí kinh doanh có thể biện minh được bằng phần thưởng đó
    Phần thưởng càng lớn thì quy mô thiệt hại mà người ta muốn biện minh cũng càng lớn. Cảm giác như cả xã hội đều vận hành như vậy

    • Nếu tôi hiểu đúng, lập luận của Anthropic giờ gần như là: “Vâng, thứ này có thể thổi bay một phần hạ tầng của các bạn, nhưng nó đáng giá”
      Vấn đề là chưa ai chứng minh được nó thực sự đáng giá đến mức phải chấp nhận cái giá đó. Đó là một giả định khá mong manh
    • Mọi hành động đều có bài toán rủi ro/phần thưởng, chỉ là bình thường ta không nhìn thấy nó được vẽ trần trụi như thế này. Ngay cả việc rời khỏi giường buổi sáng cũng có rủi ro ngã đập đầu xuống sàn, băng qua đường có rủi ro bị xe buýt tông, và ăn uống có rủi ro bị hóc
      Bảo mật máy tính cũng vậy. Chiếc máy tính thực sự an toàn duy nhất là chiếc không bao giờ bật lên, mà ngay cả nó vẫn có rủi ro ai đó đột nhập và lấy cắp thiết bị lưu trữ. Trong trường hợp này, bất kể thiệt hại tiềm tàng có lớn hơn lợi ích hay không, kiểu tính toán đó luôn diễn ra, nên tôi nghĩ nói cả xã hội đều như vậy là đúng
    • Khi bắt đầu làm dịch vụ sửa PC, lúc đầu xử lý 10 ca mỗi tuần thì việc mất một thanh RAM hay làm cháy bo mạch chủ của khách là chi phí cực lớn. Nhưng khi xử lý 1000 ca mỗi tuần thì đó vẫn là một ngành kinh doanh khá ổn và những tổn thất kiểu đó có thể gánh được dễ dàng
      Khi công cụ và tốc độ xử lý tăng lên, tỷ lệ sẽ thay đổi
    • Ra quyết định trong thực tế vốn dĩ diễn ra như vậy. Rủi ro/phần thưởng là thứ có thật
    • Trách nhiệm hữu hạn biến việc chấp nhận rủi ro không giới hạn thành một lựa chọn hợp lý. AI chỉ làm mô hình doanh nghiệp này phình to hơn và rút ngắn thời gian tới thảm họa tiếp theo

  • Tôi nhìn những gì Anthropic nói với thái độ rất hoài nghi. Vì trước IPO, họ có quá nhiều động cơ để khiến sản phẩm trông nguy hiểm, tức là tạo cảm giác “có năng lực”, “giống khoa học viễn tưởng”, và “đi trước tất cả mọi người”
    Trước đây cũng từng như vậy. Hãy nhớ câu chuyện “khi bị đe dọa thì mô hình dùng email của kỹ sư để tống tiền chuyện ngoại tình”, thực ra đó chỉ là fanfic. Họ chỉ dựng một kịch bản từ vài sự kiện rồi bảo mô hình viết tiếp câu chuyện. Nếu hỏi Claude cách đánh cắp ngọc báu hoàng gia Anh, nó sẽ cho bạn vài ý tưởng. Nhưng điều đó không có nghĩa mô hình nguy hiểm đến mức phải tăng cường an ninh cho Tower of London. Tôi nghĩ phần lớn các kiểu tiếp thị bằng nỗi sợ khác cũng tương tự

    • Đúng là “họ chỉ dựng một kịch bản từ vài sự kiện rồi bảo mô hình viết tiếp câu chuyện”. Đó chính là trọng tâm của nghiên cứu. Anthropic mở đầu phần mô tả quan sát trong bài kiểm tra tống tiền bằng cách nêu rõ đây là kịch bản kiểm thử dùng một công ty hư cấu
      “In another cluster of test scenarios, we asked Claude Opus 4 to act as an assistant at a fictional company”
      https://www.anthropic.com/claude-4-system-card
    • Điều khiến tôi lo về Anthropic hơn OpenAI là họ đánh lừa
    • OpenAI, Google và các công ty khác không dùng “chiến lược” đó. Tôi tin rằng người ở Anthropic thực sự quan tâm nghiêm túc đến an toàn AI
      Đó cũng là lý do chính công ty được thành lập. Tuy vậy, khi có người mới và tiền mới đổ vào, tôi nghĩ chủ nghĩa lý tưởng đó có thể đang suy yếu

  • Tôi vào thread này hơi muộn, nhưng bài viết dường như đã bỏ qua phần rủi ro, sai sót và sự cố có thể phát sinh từ “pattern 1”, tức là giới hạn quyền truy cập của Claude bằng container. Làm cho đúng vẫn rất khó
    Ví dụ, Anthropic đã nhiều lần triển khai các lỗi khiến bất kỳ phiên claude.ai/code nào bị cô lập trong container tạm thời cũng có thể truy cập và làm rò rỉ các phiên khác của người dùng, kho lưu trữ đã kết nối và toàn bộ biến môi trường. Một Claude bị ác ý hóa hoặc bị chiếm quyền còn có thể tạo các phiên Claude mới với chỉ thị tùy ý và quyền truy cập mới, bất kể ràng buộc của phiên ban đầu. Tôi đã lần đầu viết về việc này vào tháng 2 sau khi được cho phép[1], và phần lớn đã được sửa khá nhanh. Nhưng vấn đề phạm vi token ở mức nền tảng đã tái diễn nhiều lần, kể cả sau Mythos, nên khó có thể nói Anthropic đã giải quyết xong việc này
    [1]: https://www.noahlebovic.com/hacking-claude-code-on-the-web-b...

  • Nói chung, làm chuyện này thực sự rất khó. Đáng tiếc là bài blog tuy có nhắc vài ví dụ nhưng không đi sâu vào mức độ khó của nó
    Ví dụ, nếu chạy agent trong một VM có quyền truy cập mạng, thì thứ gì đó nó gặp bên trong có thể dùng prompt injection để lừa agent mã hóa một prompt injection cấp hai vào đầu ra đi ra ngoài VM, rồi đầu ra đó có thể lây nhiễm sang một agent cục bộ có quyền cao hơn. Ở công ty trước, khi chúng tôi phân tích việc dùng máy tính, chúng tôi từng xem xét liệu có thể tin đầu vào của người dùng là không độc hại hay không. Nếu người dùng tự tay gõ trực tiếp thì đa phần ổn, nhưng còn tệp của người dùng thì sao? Lịch hẹn trong calendar thì sao? Vì mục đích của sản phẩm chính là để agent quản lý những thứ đó thay người dùng, nên ta không còn có thể tin rằng ở đó sẽ không có chèn lệnh nữa. Chỉ cần thử làm theo dõi lây nhiễm kiểu này là sẽ nhanh chóng nhận ra việc ngăn chặn những chuyện như vậy khó đến mức nào, và việc chỉ dựng thêm sandbox hay VM xung quanh thường không giúp được bao nhiêu

  • Tôi vẫn hài lòng với cấu hình cô lập mình dùng trên Linux[1][2]. Trong các rủi ro nêu trong bài, thứ áp dụng ở đây chỉ cỡ “rò rỉ thông qua domain được cho phép”. Nhưng theo thiết kế thì trong VM ngoài chính mã nguồn ra không có gì để lộ, mà dạo này mã nguồn cũng không còn giá trị cao như trước
    Ưu điểm lớn của cấu hình này là agent có thể làm toàn bộ các công việc phát triển mà tôi có thể làm, ví dụ cài package hay build/chạy image Docker. Vòng lặp này nhanh hơn rất nhiều so với việc tôi tự làm thử rồi báo lại cho agent
    [1] https://blog.emilburzo.com/2026/01/running-claude-code-dange...
    [2] https://news.ycombinator.com/item?id=46690907

    • Agent có thể bị lừa dùng thư viện độc hại cho dự án, rồi commit và push nó. Sau đó nếu người dùng chạy nó bên ngoài VM thì sẽ nguy hiểm
      Nếu bạn chạy mã của repo bên ngoài VM mà không rà soát toàn bộ các thay đổi đã commit thì vẫn rất rủi ro

  • Khi xem xét Cowork VM, tôi thấy mức độ nhiễm bẩn không được tài liệu hóa và cũng không được kiểm soát công khai. Tôi có cách lách, nhưng trong quá trình dùng phát sinh khá nhiều lãng phí và bực bội
    CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 nghĩa là Claude theo thời gian, và tùy theo cấu hình, sẽ tìm và nạp CLAUDE.md của mọi repo được mount. Vì vậy trải nghiệm làm việc đồng thời với nhiều repo không liên quan đến nhau ở trạng thái mặc định là không tốt
    Một vài biến môi trường VM thú vị:
    CLAUDE_CODE_IS_COWORK=1
    CLAUDE_CODE_BRIEF=1 CLAUDE_CODE_BRIEF_UPLOAD=1 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 CLAUDE_CODE_DISABLE_CRON=1
    CLAUDE_CODE_ENTRYPOINT=local-agent CLAUDE_CODE_EXECPATH=/usr/local/bin/claude CLAUDE_CODE_HOST_HTTP_PROXY_PORT=36543 CLAUDE_CODE_HOST_PLATFORM=darwin CLAUDE_CODE_HOST_SOCKS_PROXY_PORT=46673
    USE_STAGING_OAUTH= _=/usr/bin/env all_proxy=socks5h://localhost:1080 ftp_proxy=socks5h://localhost:1080 grpc_proxy=socks5h://localhost:1080 http_proxy=http://localhost:3128 https_proxy=http://localhost:3128 no_proxy=localhost,127.0.0.1,::1,.local,.local,169.254.0.0/16,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

  • Về câu “agent càng giỏi thì bán kính ảnh hưởng tiềm tàng càng lớn. Câu hỏi về mặt kỹ thuật là làm sao giới hạn điều đó”, tôi thấy dạo này mọi người hơi khó chịu khi nhân cách hóa LLM, nhưng điều tệ hơn là có vẻ như người ta đang giả định LLM có thể lén thoát ra Internet theo logic phim ảnh rồi bắt đầu tự nhân bản như chất nhầy

    • Vấn đề là chúng ta huấn luyện mô hình để giải quyết vấn đề và làm theo chỉ thị được giao. Nếu giao một việc, mô hình có thể lần theo logic rồi kết luận cách dễ nhất là xóa cơ sở dữ liệu production, và nếu nó có quyền truy cập thì có thể lục mọi credential để tìm credential cơ sở dữ liệu rồi thực sự xóa nó
      Khả năng làm được kiểu việc này ngày càng tốt hơn, và khả năng làm theo chỉ thị cũng vậy, nhưng nó không phải lúc nào cũng giỏi trong việc làm theo mọi chỉ thị hoặc hành xử theo lẽ thường. Không hẳn là nó trườn ra ngoài rồi tự nhân bản như chất nhầy; đúng hơn là càng cấp nhiều quyền truy cập thì càng có khả năng đến một lúc nào đó mô hình sẽ đi đến kết luận hợp logic rằng nó cần làm điều người dùng không muốn. Hoặc vì bạn không cấm rõ ràng, hoặc vì ngữ cảnh quá phức tạp khiến trọng số của chỉ thị đó giảm đi và nó làm theo chỉ thị khác. Tôi đã thấy trường hợp nó kết luận rằng để làm được việc thì cần một API key để truy cập dịch vụ. Mô hình không có key đó, nhưng người dùng lại có thể truy cập qua trình duyệt. Thế là nó viết một script Python để cào cookie trình duyệt. Thứ chặn lại không phải sandbox của agent, mà là CrowdStrike không thích một script Python lạ đang cố cào cookie trình duyệt nên đã chặn nó
    • Tại sao lại không thể? Nếu không nói đến chuyện chạy chính bản thân mô hình, thì AI agent có thể viết agent worm để phát tán thêm agent thông qua các lỗ hổng phần mềm
      Hiện tại LLM vẫn đòi hỏi quá nhiều phần cứng nên bản thân mô hình khó mà tự phát tán, nhưng với vài năm nữa và thêm tối ưu hóa thì có lẽ ta cũng sẽ thấy điều đó. Nó làm tôi nhớ đến thời xưa khi người ta nói “ảnh không thể phát tán virus”. Rồi lỗ hổng ở decoder bị phát hiện và những virus hình ảnh như vậy thật sự đã được tạo ra
    • LLM dường như bị hỏng rõ ràng ngay từ thiết kế một khi bị nhân cách hóa, nhưng tôi nghĩ phần mềm như chúng ta từng biết rồi cũng đang tiến hóa thành những “thực thể được nhân cách hóa”. Tôi có để vài ghi chú liên quan ở [1], và đó là nội dung do AI tạo
      Cũng có một xu hướng thú vị là những thương hiệu được nhân cách hóa hơn thì đang chiếm ưu thế hơn. Kiểu như Claude và Doubao so với ChatGPT và DeepSeek
      [1] https://github.com/NascentCore/agentic-suite/tree/main/perso...

  • Tôi đang dùng VM qemu. VM này có truy cập Internet, và có lẽ rủi ro lớn nhất là Claude có thể upload dữ liệu đi đâu đó
    Để cho nó làm việc với GitHub, tôi tạo token bị giới hạn quyền theo từng repo, chỉ đọc hoặc đọc/ghi. Dù vậy tôi vẫn thích chỉ cho nó commit chứ không push; sau đó tôi SSH vào VM để lấy commit, kiểm tra log rồi tự mình push. Tôi cũng từng nghĩ đến việc chạy Claude trong container, nhưng cảm giác hơi yếu. Có quá nhiều lỗ hổng Linux. Nỗi sợ này có thể là vô căn cứ, nhưng tôi cảm thấy chạy thứ không đáng tin cậy trong VM qemu an toàn hơn

  • Gần đây tôi đã vội làm một hàm trợ giúp nhỏ dùng bubblewrap để chạy tiến trình, chỉ cấp quyền đọc/ghi cho thư mục nơi nó được chạy và biến mọi thứ còn lại thành chỉ đọc. Tôi để ngoại lệ cho một vài thư mục hệ thống Linux cụ thể để GUI và những thứ như libportal vẫn hoạt động
    Với những tác vụ mà tôi muốn agent thực sự có thể trỏ tới các thứ linh tinh như ảnh chụp màn hình hay tệp log nằm rải rác khắp nơi, nhưng đồng thời lại không muốn phải canh chừng và phê duyệt thủ công mỗi lần, cách này đỡ phiền hơn container rất nhiều. Khá kỳ lạ khi các nền tảng công cụ AI vẫn chưa đầu tư vào kiểu trải nghiệm này. Lý do tôi làm ra thứ này là vì Zed. Đây là một trình soạn thảo được xây dựng với giả định có tác vụ AI, nhưng quyền theo đường dẫn cụ thể của agent chỉ có thể được đặt trong tệp cấu hình toàn cục của người dùng. Có tệp cấu hình cấp dự án, nhưng vì lý do khó hiểu, nó lại không hỗ trợ rõ ràng phần cấu hình quyền của agent

  • Tôi không phải nhà lý thuyết quyết định, nhưng tôi cho rằng không nên chờ đến khi phần thưởng và thiệt hại kỳ vọng ngang nhau về mặt thống kê, mà nên chờ đến khi phần thưởng theo kỳ vọng vượt qua thiệt hại

    • Vận may đứng về phía những kẻ táo bạo