Ngày 26 tháng 8 năm 2026, Anthropic công bố Claude in Chrome đã được cung cấp rộng rãi cho các gói trả phí và ra mắt trình duyệt tích hợp trong Claude Cowork. Các công cụ này có thể đọc trang, di chuyển giữa các tab, nhập văn bản và điền biểu mẫu với mức độ tự chủ cao hơn. Chúng giúp truy cập các cổng nội bộ hoặc cũ không có API, nhưng đồng thời cũng làm dịch chuyển ranh giới bảo mật: nội dung của một trang trở thành một chỉ dẫn có khả năng độc hại, nằm ngay cạnh một phiên đã xác thực.
Điểm cần nhớ: tác nhân trình duyệt không bao giờ được ngầm thừa hưởng mọi quyền của người dùng. Cần cô lập môi trường, giới hạn miền và tài khoản, phân loại hành động theo rủi ro, yêu cầu xác nhận đối với tác động nhạy cảm, ghi nhật ký quyết định và kiểm tra kết quả. Các cơ chế bảo vệ của mô hình làm giảm rủi ro prompt injection, nhưng không loại bỏ được rủi ro này.
1. Trình duyệt trở thành môi trường thực thi
Các thế hệ trợ lý đầu tiên chỉ trả lời câu hỏi. Giờ đây, một tác nhân trình duyệt có thể quan sát trạng thái của trang, quyết định chuỗi bước và thao tác trong một ứng dụng. Vì vậy, nó tương tự một người dùng tự động có khả năng suy luận.
Sự phát triển này hữu ích với những hệ thống không cung cấp API hoặc trình kết nối: cổng thông tin nhà cung cấp, giao diện quản trị cũ, CRM chuyên ngành hoặc bảng điều khiển nội bộ. Tác nhân có thể thu thập dữ liệu, chuẩn bị nội dung nhập, đi qua nhiều màn hình và trả kết quả trong cùng cuộc trò chuyện.
Tuy nhiên, tự động hóa truyền thống tuân theo một kịch bản được viết sẵn. Tác nhân chọn đường đi dựa trên nội dung hiển thị. Tính linh hoạt cũng chính là bề mặt tấn công: thông tin gặp trong quá trình thực hiện có thể làm thay đổi kế hoạch.
Vì vậy, cần xem trình duyệt như một runtime nhạy cảm, có chính sách truy cập, môi trường cô lập, dấu vết, giới hạn tài nguyên và cơ chế dừng. Việc thêm một tiện ích vào trình duyệt làm việc mà không xem xét lại các yếu tố này tương đương với triển khai một robot phần mềm mới có quyền của nhân viên, nhưng thiếu cơ chế quản trị phù hợp.
2. Phân biệt trình duyệt cá nhân và trình duyệt cô lập
Hai thông báo của Anthropic minh họa cho hai mô hình khác nhau.
Một tiện ích như Claude in Chrome hoạt động trong ngữ cảnh của trình duyệt đang được sử dụng. Nó tận dụng các phiên đang mở và có thể can thiệp vào trang hiển thị. Sự gần gũi này giúp các tác vụ hằng ngày thuận tiện hơn, nhưng làm tăng tác động tiềm ẩn của sai sót: tác nhân có thể gặp email, CRM và khu vực quản trị trong cùng một phiên.
Trình duyệt tích hợp trong Cowork tách biệt với trình duyệt cá nhân. Theo Anthropic, mặc định nó không truy cập các tab, dấu trang hoặc mật khẩu của người dùng. Kết nối có thể được nhập theo từng trang web, còn một số nhóm nhạy cảm như ngân hàng, email hoặc SSO bị loại trừ trừ khi người dùng chủ động chọn.
Đối với doanh nghiệp, cô lập nên là chế độ mặc định. Hãy tạo một hồ sơ riêng, không đồng bộ trình duyệt, sử dụng kho bí mật tách biệt và các tài khoản dịch vụ bị giới hạn. Trình duyệt cá nhân vẫn có thể hữu ích cho hỗ trợ ponctuelle dưới sự giám sát, nhưng không nên trở thành nền tảng của tự động hóa định kỳ.
Lựa chọn phụ thuộc vào nhu cầu: hỗ trợ một người trên trang họ đang nhìn thấy hay giao một tác vụ cho môi trường được kiểm soát. Nhầm lẫn hai cách sử dụng này sẽ khiến các phiên bị phơi nhiễm không cần thiết.
3. Vì sao prompt injection làm thay đổi mối đe dọa
Trong một kiểu injection cổ điển, kẻ tấn công cố khiến ứng dụng thực thi một lệnh. Với prompt injection, kẻ tấn công đặt chỉ dẫn trong một trang, email, tài liệu hoặc trường dữ liệu để tác động đến mô hình đang đọc chúng.
Nội dung độc hại có thể hiển thị rõ, kín đáo hoặc được lồng trong dữ liệu hợp lệ. Ví dụ, người dùng yêu cầu tổng hợp các yêu cầu của khách hàng; một trong các tin nhắn chứa chỉ dẫn yêu cầu tác nhân mở màn hình khác và truyền thông tin đi. Đối với mô hình, yêu cầu của người dùng và văn bản trên trang thuộc cùng ngữ cảnh làm việc, trừ khi kiến trúc áp đặt sự phân tách rõ ràng.
Anthropic mô tả các bộ dò phân tích nội dung và một bộ phân loại kiểm tra các hành động dự kiến so với yêu cầu ban đầu. Nhà cung cấp cũng nói rõ rằng các biện pháp này không thể loại bỏ rủi ro và khuyến nghị bắt đầu với các trang web đáng tin cậy.
Sự thận trọng này cần định hướng thiết kế. Không có điểm số chống chịu nào do nhà cung cấp đưa ra có thể bao quát ứng dụng, cách diễn đạt, tích hợp và quyền của bạn. Prompt injection là vấn đề của cả hệ thống: mô hình, công cụ, phiên, dữ liệu, chính sách và kiểm soát của con người phải được thiết kế cùng nhau.
4. Áp dụng nguyên tắc đặc quyền tối thiểu cho các phiên web
Biện pháp bảo vệ đầu tiên là giảm các quyền mà tác nhân có thể truy cập.
Hãy dùng một tài khoản riêng khi ứng dụng cho phép. Loại bỏ vai trò quản trị, chức năng xuất dữ liệu toàn cục, quản lý người dùng và các chức năng tài chính nếu tác vụ không cần đến chúng. Ưu tiên phạm vi dữ liệu giới hạn trong nhóm hoặc hồ sơ đang được xử lý.
Tiếp theo, hãy xác định danh sách miền được phép. Một tác vụ trên CRM không nên có khả năng mở tùy ý một dịch vụ chia sẻ tệp. Kiểm soát chuyển hướng, miền con và tải xuống, vì một trang được phê duyệt có thể chứa liên kết đến nguồn không được phê duyệt.
Đồng thời, giới hạn các luồng mạng của trình duyệt cô lập. Lưu lượng đi ra có thể đi qua proxy ghi nhật ký đích đến và chặn các nhóm bị cấm. Tệp tải xuống phải được phân tích và lưu trong vùng tạm thời, không tự động thực thi.
Không được sao chép bí mật vào prompt hoặc tệp cấu hình mà mô hình có thể đọc. Hãy dùng cơ chế xác thực do trình duyệt quản lý hoặc một kho cung cấp phiên mà không tiết lộ giá trị thô. Nếu hồ sơ bị xâm phạm, cần có khả năng xoay vòng bí mật nhanh chóng.
Cách tiếp cận này tiếp nối các nguyên tắc trong bài viết của chúng tôi về tác nhân AI zero-trust, việc ký các thao tác ghi và cô lập mã được tạo: mọi khả năng đều phải được cấp phép rõ ràng và có thể kiểm chứng.
5. Kiểm soát hành động, không chỉ câu trả lời
Một tác nhân có thể đưa ra câu trả lời đúng nhưng vẫn thực hiện một hành động không mong muốn. Vì vậy, chính sách phải được áp dụng ngay tại thời điểm hành động.
Hãy phân loại thao tác thành bốn mức. Việc đọc các trang công khai có thể tự động. Việc chuẩn bị biểu mẫu hoặc bản nháp có thể được cho phép mà không gửi đi. Một thay đổi có thể hoàn tác, chẳng hạn thêm ghi chú nội bộ, cần được kiểm tra nội dung và đối tượng đích. Một hành động bên ngoài hoặc khó hoàn tác—gửi email, thay đổi quyền, xóa, đặt hàng, thanh toán hoặc xuất bản—phải có xác nhận rõ ràng và mới được đưa ra.
Xác nhận phải trình bày các yếu tố cụ thể: miền, tài khoản, đối tượng bị thay đổi, giá trị hiện tại, giá trị mới và hệ quả. Câu hỏi chung chung như “tiếp tục?” không giúp người dùng phát hiện sự lệch hướng.
Sau khi được xác nhận, tác nhân chỉ được thực hiện hành động đã được phê duyệt. Nó không được lợi dụng xác nhận đó để thêm các bước khác. Công cụ có thể áp đặt schema nghiêm ngặt, danh sách trường được phép và giới hạn khối lượng.
Với quy trình nhạy cảm, hãy tách khâu chuẩn bị và thực thi. Tác nhân chuẩn bị giao dịch; một dịch vụ xác định hoặc một người kiểm tra quy tắc nghiệp vụ và thực hiện thao tác ghi.
6. Ghi nhật ký, kiểm tra và chuẩn bị khả năng hoàn tác
Khả năng truy vết không nên chỉ giới hạn ở video của phiên làm việc. Hãy ghi lại danh tính người yêu cầu, tác vụ ban đầu, mô hình và phiên bản, các miền đã truy cập, công cụ đã gọi, quyết định của chính sách, các lần xác nhận, đối tượng đã thay đổi và kết quả quan sát được.
Tuy nhiên, tránh ghi nhật ký các bí mật hoặc dữ liệu cá nhân không cần thiết. Ảnh chụp màn hình và nội dung trang phải tuân theo thời hạn lưu giữ, kiểm soát truy cập và mục đích đã xác định.
Sau mỗi thao tác ghi, tác nhân phải đọc lại trạng thái kết quả. Việc nhấp vào một nút không chứng minh rằng thay đổi đã được lưu. Hãy kiểm tra thông báo xác nhận, giá trị đã lưu hoặc mã giao dịch. Với một lô, hãy đối chiếu số lượng phần tử dự kiến và đã xử lý.
Hãy chuẩn bị cơ chế hủy: dùng bản nháp thay vì xuất bản trực tiếp, thùng rác thay vì xóa vĩnh viễn, giao dịch idempotent, lưu lại phiên bản trước hoặc nhật ký cho phép phát lại thao tác ngược. Một số thao tác như email đã gửi hoặc thanh toán không thực sự có thể hoàn tác; chúng phải nằm sau mức kiểm soát nghiêm ngặt nhất.
7. Kiểm thử tác nhân như một hệ thống không tất định
Các bài kiểm thử chức năng thông thường là chưa đủ. Tác nhân có thể chọn những lộ trình khác nhau cho cùng một yêu cầu và phản ứng với cách diễn đạt bất ngờ.
Hãy xây dựng bộ đánh giá gồm các tác vụ bình thường, tình huống mơ hồ, lỗi xác thực, chuyển hướng, trang chậm và nội dung cố gắng điều hướng tác nhân. Kiểm tra rằng nó dừng lại khi thiếu thông tin, yêu cầu xác nhận đúng lúc và không mở rộng phạm vi.
Thêm các trường hợp prompt injection phù hợp với ứng dụng của bạn nhưng không để lộ dữ liệu thật: chỉ dẫn trong mô tả ticket, tên tệp, trường CRM, email hoặc trang tài liệu. Đo tỷ lệ chặn, đồng thời đo cả các kết quả dương tính giả cản trở công việc hợp lệ.
Kiểm thử mỗi phiên bản mô hình mới và mỗi thay đổi chính sách. Một cải thiện chung của mô hình có thể làm thay đổi cách nó diễn giải chỉ dẫn, xu hướng yêu cầu xác nhận hoặc cách sử dụng công cụ.
Cuối cùng, hãy thực hiện một giai đoạn quan sát ở chế độ chỉ đọc. So sánh các quyết định tác nhân đề xuất với hành động của nhân viên trước khi cho phép thao tác ghi.
8. Triển khai theo nhóm mục đích sử dụng
Hãy bắt đầu với các tác vụ ít tác động: thu thập thông tin công khai, kiểm tra trạng thái, chuẩn bị báo cáo hoặc nhập bản nháp trong môi trường kiểm thử.
Giai đoạn thứ hai có thể bao gồm các cổng nội bộ với tài khoản giới hạn và hành động có thể hoàn tác. Duy trì xác thực của con người và đo thời gian thực sự tiết kiệm được, bao gồm cả việc rà soát và sửa lỗi.
Các mục đích sử dụng liên quan đến email, dữ liệu nhạy cảm, thay đổi quyền, đơn hàng hoặc tài chính phải nằm trong phạm vi tách biệt. Hãy yêu cầu phân tích rủi ro, một chủ sở hữu nghiệp vụ, một người phụ trách kỹ thuật, nhật ký có thể khai thác và kế hoạch xử lý sự cố.
Đồng thời, hãy xác định các loại trừ: miền không được phép, nhóm dữ liệu, khung thời gian, khối lượng và những hành động tác nhân sẽ không bao giờ thực hiện. Một danh sách rõ ràng bảo vệ tốt hơn một prompt chung chung yêu cầu “thận trọng”.
Việc mở rộng quy mô phải dựa trên bằng chứng: tỷ lệ hoàn thành tác vụ, lỗi đã xác nhận, can thiệp của con người, sự cố chính sách, chi phí và mức độ hài lòng của người dùng. Tính tự chủ là một cấp độ dịch vụ phải đạt được, không phải một tùy chọn bật trên toàn hệ thống.
Kết luận
Tác nhân trình duyệt giúp tự động hóa những ứng dụng mà các tích hợp truyền thống bỏ lại. Khả năng sử dụng các phiên hiện có và diễn giải các trang động mang lại giá trị thực, nhưng cũng đưa dữ liệu không đáng tin cậy đến gần các hành động đã xác thực hơn.
Bảo mật phải được xây dựng xoay quanh mô hình: trình duyệt cô lập, quyền tối thiểu, miền được phép, chính sách hành động, xác nhận có đủ thông tin, kiểm tra kết quả và ghi nhật ký. Partitech hỗ trợ thiết kế các kiến trúc tác nhân này, xác định biện pháp bảo vệ và triển khai các thử nghiệm có thể đo lường trước khi nhân rộng.