放权还是失控？Agent 自主时代，我们需要怎样的「可验证授权」？

"Tôm hùm" OpenClaw, vốn im hơi lặng tiếng một thời gian, đã phát hành phiên bản 2.0 vào ngày 30 tháng 8.

Theo tuyên bố chính thức, đây là bản cập nhật lớn nhất trong lịch sử OpenClaw, với tổng cộng hơn 16.000 Pull Request, gần như chạm đến toàn bộ các thành phần sản phẩm như cài đặt, tin nhắn, bộ nhớ, Skills, mô hình, Automations, trình duyệt, ứng dụng gốc, Plugins và cơ chế bảo mật.

Nhưng so với danh sách tính năng đồ sộ và phức tạp này, điều đáng chú ý hơn cả chính là lộ trình phát triển ngày càng rõ ràng đằng sau OpenClaw 2.0: Agent đang ngày càng có khả năng thực sự "tự tay hành động".

Đồng thời, nó cũng đưa ngành công nghiệp vào một thế tiến thoái lưỡng nan về niềm tin không thể tránh khỏi: Khi Agent ngày càng có thể tự quyết định "phải làm như thế nào", chúng ta làm cách nào để đảm bảo rằng mọi thao tác quan trọng của nó đều không vượt qua ranh giới mà người dùng thực sự ủy quyền?

1. Thế lưỡng nan về quyền tự chủ của Agent: Giao toàn quyền, hay xác nhận từng lớp?

Trong năm qua, thay đổi rõ rệt nhất của AI Agent không chỉ là các mô hình nền tảng trở nên thông minh hơn.

Khi hạ tầng như MCP, Skills, Plugins, điều khiển trình duyệt và thực thi mã ngày càng hoàn thiện, Agent bắt đầu sở hữu ngày càng nhiều "tay chân" thực sự có thể tác động đến thế giới bên ngoài, chẳng hạn như sửa đổi thông tin, nhấp vào nút, hoặc trực tiếp điều khiển trình duyệt thông qua computer use (đọc thêm bài viết "Bước ngoặt của Agentic AI đã đến? Khi AI học cách 'tự hành động', làm thế nào để tái cấu trúc ranh giới bảo mật của Web3?").

Nhưng vấn đề lại nằm ngay tại đây. Trong mô hình tương tác hiện tại, chúng ta thường dễ rơi vào hai thái cực.

Một là giao toàn quyền, đưa trực tiếp private key hoặc một Session Key có thời hạn dài và quyền hạn đủ lớn cho Agent, để nó tự phán đoán và thực thi.

Trải nghiệm tự động hóa của mô hình này tất nhiên là tốt nhất, nhưng rủi ro cũng tập trung không kém. Một khi gặp phải prompt injection, trang web độc hại hoặc ô nhiễm môi trường, hoặc bản thân mô hình có sai lệch trong hiểu biết, lỗi có thể lan truyền dọc theo toàn bộ chuỗi thực thi và cuối cùng biến thành các thao tác thực tế (đọc thêm bài viết "Sign không chỉ là ký: Khi AI Agent ký thay bạn, ai vẫn đang nắm quyền kiểm soát?").

Xét cho cùng, trong bối cảnh internet thông thường, điều này có thể chỉ là gửi nhầm một email, xóa nhầm một tệp, nhưng khi lên on-chain, một giao dịch sai lầm lại thường không thể đảo ngược.

Một thái cực khác là hoàn toàn không giao quyền, mỗi thao tác, mỗi lần gọi phụ đều phải bật cửa sổ ký xác nhận, an toàn hơn được nâng cao, nhưng ý nghĩa của tự động hóa cũng giảm đi đáng kể.

Rốt cuộc, khi một Agent giúp người dùng hoàn thành một chiến lược DeFi phức tạp, liên quan đến nhiều bước, nếu tất cả đều yêu cầu người dùng cầm điện thoại lên "Approve" từng cái một, thì người dùng thực chất chỉ chuyển từ việc "tự mình nhấn nút" thành một "máy đóng dấu xác nhận thủ công" thay cho Agent.

Nói cách khác, mức độ tự do ở giữa chính là nguồn gốc giúp Agent tăng hiệu quả, nhưng cũng là nguồn gốc của rủi ro mới.

Từ góc độ này, cốt lõi của vấn đề không nằm ở việc "có nên giao quyền cho Agent hay không", mà nằm ở việc mức độ chi tiết của việc ủy quyền và cơ chế xác minh có tính linh hoạt động hay không, bởi vì quản lý quyền hạn truyền thống là nhị phân (hoặc cho phép, hoặc từ chối), trong khi các nhiệm vụ mà Agent phải đối mặt rõ ràng phức tạp hơn nhiều.

Cũng là một giao dịch, 10 USD và 100.000 USD là khác nhau; tương tác với một giao thức đã sử dụng lâu dài, và đột nhiên ủy quyền cho một hợp đồng lạ, là khác nhau; hoàn thành một Swap mà người dùng yêu cầu rõ ràng, và việc Agent tự quyết định chuyển tài sản sang một chuỗi khác, cũng không cùng mức độ rủi ro.

Vì vậy, Agent càng có thể hành động tự chủ, thì quyền hạn càng không thể chỉ là một công tắc bật tắt đơn giản.

Điều thực sự cần thiết là một cơ chế bảo mật cho phép nó tự do hành động trong ranh giới, và tự động dừng lại khi vượt qua ranh giới đó.

2. Làm thế nào để xây dựng một tuyến phòng thủ "có thể xác minh" cho Agent tự chủ?

Trên thực tế, OpenClaw không hề phớt lờ vấn đề này.

Hiện tại, nó cung cấp cơ chế phân quyền đa lớp, ví dụ như plugin có thể tạm dừng và yêu cầu người dùng xác nhận trước khi thực hiện các thao tác cụ thể. Khi liên quan đến lệnh máy chủ, còn có Exec Approvals và Allowlist độc lập, v.v.

So với việc giao tất cả công cụ và quyền hạn cho Agent cùng một lúc, điều này đã là một bước tiến lớn. Nhưng khi Agent thực sự bước vào các tình huống thanh toán, giao dịch và quản lý tài sản, một vấn đề tinh tế hơn xuất hiện: Cho phép Agent sử dụng một khả năng nào đó, và ủy quyền cho Agent hoàn thành một hành động cụ thể nào đó, thực ra không phải là một chuyện.

Cũng giống như việc cho phép Agent sử dụng trình duyệt không có nghĩa là cho phép nó mua bất cứ thứ gì trên bất kỳ trang web nào; cho phép Agent truy cập email cũng không đồng nghĩa với việc cho phép nó gửi email cho bất kỳ ai dưới danh nghĩa của bạn; tương tự, cho phép Agent gọi ví cũng tuyệt đối không nên đồng nghĩa với việc cho phép nó gửi số tiền bất kỳ đến địa chỉ bất kỳ.

Vì vậy, hệ thống quyền hạn trong kỷ nguyên Agent có thể cần phân biệt hai vấn đề khác nhau. Một là quyền năng lực, tức là Agent có được sử dụng trình duyệt, thiết bị đầu cuối, email hoặc ví hay không? Và một vấn đề khác là ủy quyền hành động cụ thể hơn, như ngay tại thời điểm này, việc nó chuẩn bị thực hiện, rốt cuộc có phải là điều người dùng thực sự cho phép nó làm hay không?

Vậy làm thế nào để Agent có thể tự động hóa đầy đủ trong ranh giới rõ ràng, đồng thời khi thực sự vượt qua ranh giới, trao lại quyền quyết định cho người dùng?

Đây cũng là lý do imToken đang khám phá Sigil. Cốt lõi của nó không phải là thêm một "cửa sổ xác nhận" theo nghĩa truyền thống cho Agent, mà là cố gắng thiết lập một lớp rào chắn an toàn có thể bị giới hạn rõ ràng giữa người dùng và Agent thông qua chữ ký có thể xác minh và kiểm soát quyền hạn chi tiết.

Một trong những nguyên tắc rất quan trọng là "What you see is what you sign", bạn thấy gì, bạn ký cái đó.

Nói một cách đơn giản, người dùng có thể cấp trước cho Agent một phạm vi quyền hạn nhất định, cho phép các hành vi có rủi ro thấp và phù hợp với chiến lược đã định tự động hoàn thành; khi thao tác chạm đến hạn mức tiền, giao thức lạ hoặc các ranh giới quyền hạn quan trọng khác, hệ thống sẽ tạm dừng thực thi và trả lại yêu cầu cụ thể cho người dùng xác nhận.

Quan trọng hơn, sự xác nhận này không nên chỉ là một câu mơ hồ "Agent chuẩn bị thực hiện giao dịch, bạn có đồng ý không?" Người dùng thực sự cần nhìn thấy là các tham số quan trọng thực sự thay đổi trong thao tác này: sử dụng tài sản nào, số tiền là bao nhiêu, đối tượng tương tác là ai, và cuối cùng rốt cuộc chuẩn bị thực hiện điều gì.

Bởi vì chỉ khi nội dung người dùng nhìn thấy, nội dung người dùng ủy quyền và nội dung hệ thống cuối cùng thực thi có thể tương ứng với nhau, thì một lần xác nhận mới thực sự có ý nghĩa.

Xoay quanh điểm này, Sigil cũng cố gắng sử dụng các cơ chế như Passkey, xác thực sinh trắc học, chữ ký một lần, thời hạn hiệu lực ngắn và ràng buộc tham số yêu cầu, để các ủy quyền quan trọng không chỉ có thể được người dùng hiểu mà còn có thể được hệ thống xác minh.

Điều này có nghĩa là, một ủy quyền không chỉ là "có người nhấn xác nhận", mà còn có thể trả lời thêm các câu hỏi như ai đã phê duyệt, đã phê duyệt điều gì, và cuối cùng thực sự được thực thi, có phải là điều đã thấy lúc đó hay không.

Từ góc độ này, điều Sigil thực sự muốn giải quyết không phải là "làm thế nào để Agent làm ít việc hơn".

Ngược lại.

Nó cố gắng giải quyết vấn đề làm thế nào để Agent có thể yên tâm làm nhiều việc hơn trong khi vẫn không lấy đi quyền kiểm soát cuối cùng của người dùng (đọc thêm bài viết "Từ việc mù quáng nhấn 'Yes' đến việc nhìn rõ rồi mới ký: Sigil thêm một lớp rào chắn an toàn cho AI Agent bằng cách nào?").

3. Từ quản lý tài sản đến quản lý Agent

Nếu lùi xa hơn một bước, chúng ta sẽ thấy rằng đây thực sự là một sự thay đổi vai trò mà các ví đang phải đối mặt.

Kể từ khi Ethereum ra đời, ví imToken đã trực tiếp trải qua và chứng kiến hai thế hệ quan trọng: từ kỷ nguyên 1.0 quản lý một private key duy nhất, tiến hóa đến kỷ nguyên 2.0 tối ưu hóa trải nghiệm tương tác thông qua Account Abstraction (AA).

Với sự phổ biến của các Agent tự chủ như OpenClaw 2.0, ví chắc chắn đang bước vào giai đoạn phát triển thế hệ thứ ba, cần tiếp tục giúp người dùng quản lý các Agent có thể tự phán đoán và liên tục hoạt động.

Đây cũng là lý do vì sao các năng lực quản lý private key, ký số, xác thực danh tính và cô lập quyền hạn mà ngành công nghiệp ví tích lũy trong quá khứ có thể có được ý nghĩa mới trong kỷ nguyên Agent.

Bởi vì về bề ngoài, những công nghệ này giải quyết vấn đề "làm thế nào để ký một giao dịch on-chain một cách an toàn", nhưng đằng sau chúng thực sự xử lý một vấn đề phổ biến hơn: làm thế nào để chứng