OpenClaw 2.0 và Sigil: Xây dựng sự ủy quyền có thể xác minh cho các tác nhân AI tự chủ

Sau một thời gian im lặng, “Cua” OpenClaw đã ra mắt phiên bản 2.0 vào ngày 30 tháng 8.

Theo thông báo chính thức, đây là bản cập nhật lớn nhất trong lịch sử OpenClaw, với hơn 16.000 Pull Request được tích lũy, gần như chạm đến toàn bộ hệ sinh thái sản phẩm bao gồm 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ác cơ chế bảo mật.

Nhưng điều đáng quan tâm hơn so với danh sách chức năng phức tạp này, thực ra là lộ trình phát triển ngày càng rõ ràng đằng sau OpenClaw 2.0: Agent đang trở nên ngày càng có khả năng thực sự “làm việc”.

Đồng thời, nó cũng đưa ngành công nghiệp vào một nghịch lý về niềm tin không thể tránh khỏi: Khi các Agent ngày càng có khả năng tự quyết định “làm thế nào”, chúng ta nên làm thế nào để đảm bảo rằng mỗi thao tác quan trọng của chúng đều không vượt quá ranh giới được người dùng cấp phép thực sự?

Trong năm qua, sự 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 các cơ sở hạ tầng như MCP, Skills, Plugins, điều khiển trình duyệt và thực thi mã ngày càng trở nên trưởng thành, 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, ví dụ 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 Agentic AI đã đến điểm ngoặt? Khi AI học cách “tự hành động”, làm thế nào để tái cấu trúc biên giới bảo mật của Web3?).

Nhưng vấn đề cũng chính xuất hiện ở đây, trong mô hình tương tác hiện tại, thường dễ rơi vào hai cực đoan.

Một cách là trao toàn quyền, trực tiếp giao khóa riêng hoặc một Session Key có hiệu lực dài hạn và quyền hạn đủ lớn cho Agent để nó tự quyết định thực hiện.

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

Sau cùng, trong các bối cảnh internet thông thường, điều này có thể chỉ là gửi nhầm một email hoặc xóa nhầm một tệp tin, nhưng trên chuỗi, một giao dịch sai lầm thường là không thể hoàn tác.

Một cách khác là không cấp quyền nào, mỗi thao tác và mỗi lần gọi con đều hiển thị cửa sổ yêu cầu xác nhận chữ ký; độ an toàn được nâng cao, nhưng ý nghĩa của tự động hóa cũng vì vậy mà giảm đáng kể.

Sau cùng, một Agent giúp người dùng thực hiện một chiến lược DeFi phức tạp, với nhiều bước trung gian; nếu mỗi bước đều yêu cầu người dùng lấy điện thoại nhấn từng cái «Approve», thì thực chất người dùng chỉ đang chuyển từ việc «tự nhấn nút» thành việc liên tục đóng dấu cho Agent – trở thành một «máy kiểm tra dấu tay».

Nói cách khác, mức độ linh hoạt ở giữa vừa là nguồn gốc giúp Agent tăng hiệu suất, vừa là nguồn gốc của những rủi ro mới.

Từ góc độ này, cốt lõi của vấn đề không phải là “có nên trao quyền cho Agent hay không”, mà là mức độ chi tiết của quyền truy cập và cơ chế xác thực có linh hoạt và thích ứng được không, bởi vì quản lý quyền truy cập truyền thống mang tính 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 đô la và 100.000 đô la là khác nhau; tương tác với một giao thức sử dụng lâu dài và cấp quyền đột ngột cho một hợp đồng lạ lẫm cũng khác nhau; thực hiện một giao dịch Swap theo yêu cầu rõ ràng của người dùng và Agent tự ý chuyển tài sản sang một chuỗi khác không cùng mức độ rủi ro.

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

Điều thực sự cần là một cơ chế an toàn cho phép nó hoạt động tự do trong phạm vi giới hạn và tự động dừng lại khi vượt qua ranh giới.

Thực tế, OpenClaw đã không bỏ qua 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 xác nhận từ người dùng trước khi thực hiện các thao tác cụ thể, khi liên quan đến lệnh chủ, còn có các tính năng riêng biệt như Exec Approvals và Allowlist, v.v.

So sánh với việc trao toàn bộ công cụ và quyền hạn cho Agent ngay từ đầu, điều này đã tiến một bước 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 vi hơn xuất hiện: cho phép Agent sử dụng một khả năng nào đó thực ra không giống với việc cấp quyền cho Agent thực hiện một hành động cụ thể nào đó.

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 kỳ 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 dưới danh nghĩa của bạn đến bất kỳ ai; tương tự, việc 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 bất kỳ số tiền nào đến bất kỳ địa chỉ nào.

Vì vậy, hệ thống quyền trong thời đại 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ó thể sử dụng trình duyệt, terminal, email hoặc ví không? Một là quyền hành động cụ thể hơn, ví dụ như tại thời điểm này, hành động mà nó chuẩn bị thực hiện có thực sự được người dùng cho phép hay không?

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

Đây cũng là lý do imToken đang khám phá Sigil. Hạt nhân của nó không phải là thêm một cửa sổ xác nhận truyền thống cho Agent, mà là thử nghiệm xây dựng một hàng rào bảo mật có thể bị ràng buộc 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 tinh vi.

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

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 để tự động thực hiện các hành vi có rủi ro thấp và tuân thủ chiến lược đã định; khi thao tác chạm đến giới hạn số tiền, giao thức mới 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 hiện và chuyển yêu cầu cụ thể về cho người dùng xác nhận.

Quan trọng hơn, xác nhận này không nên chỉ là một câu mơ hồ như “Agent đang chuẩn bị thực hiện giao dịch, bạn có đồng ý không?”, mà người dùng thực sự cầ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 gì, số lượng bao nhiêu, đối tượng tương tác là ai, và cuối cùng sẽ thực hiện chính xác hành động gì.

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

Sigil cũng đã thử sử dụng các cơ chế như Passkey, sinh trắc học, chữ ký một lần, thời hạn ngắn và ràng buộc tham số yêu cầu để đảm bảo rằng các quyền truy cập 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 sự ủy quyền không chỉ là “ai đó đã nhấn xác nhận”, mà còn có thể trả lời thêm ai đã phê duyệt, phê duyệt cái gì, và cuối cùng, hành động thực sự được thực hiện có phải là điều mà lúc đó họ đã thấy 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”.

On the contrary.

Nó cố gắng giải quyết vấn đề làm thế nào để Agent có thể thực hiện nhiều việc hơn một cách an toàn mà 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 vô tư nhấn «Yes» đến việc hiểu rõ trước khi ký: Sigil đã tạo ra hàng rào bảo mật nào cho AI Agent?).

Nếu lùi thêm một bước nữa, bạn sẽ nhận ra đây thực chất cũng là một sự thay đổi vai trò mà ví tiền đang đối mặt.

Kể từ khi Ethereum ra đời, ví imToken đã trực tiếp trải nghiệm và chứng kiến hai thế hệ quan trọng: từ thời kỳ 1.0 quản lý khóa riêng lẻ, tiến hóa sang thời kỳ 2.0 tối ưu hóa trải nghiệm tương tác thông qua tài khoản trừu tượng (AA).

Với sự phổ biến của các Agent tự chủ như OpenClaw 2.0, ví tiền chắc chắn đang bước vào giai đoạn phát triển thứ ba, cần hỗ trợ thêm người dùng trong việc quản lý từng Agent có khả năng tự đưa ra quyết định và hoạt động liên tục.

Đó cũng là lý do tại sao các khả năng quản lý khóa riêng, chữ ký số, xác thực danh tính và phân cách quyền hạn mà ngành ví đã tích lũy trong quá khứ có thể mang ý nghĩa mới trong thời đại Agent.

Vì những công nghệ này về mặt bề ngoài đang giải quyết vấn đề “làm thế nào để ký một giao dịch trên chuỗi một cách an toàn”, nhưng thực chất đang xử lý một vấn đề phổ biến hơn nhiều: làm thế nào để chứng minh một hành động thực sự đã nhận được sự ủy quyền hợp lệ từ một thực thể cụ thể.

Hôm nay, hành động này có thể là chuyển ra 1 ETH. Trong tương lai, nó cũng có thể là gửi một email, chỉnh sửa một tài liệu, sử dụng một danh tính kỹ thuật số, mua một dịch vụ, hoặc cho phép Agent thực hiện liên tục một chiến lược tự động hóa trong vòng một tuần tới.

Những hành vi này không nhất thiết đều xảy ra trên blockchain, nhưng mối quan hệ cơ bản rất tương tự, đó là Agent đang gọi một khả năng thuộc về người dùng với danh nghĩa của người dùng đó.

Do đó, ý nghĩa của Sigil cũng không nhất thiết chỉ giới hạn trong Crypto.

Khi OpenClaw, Hermes và nhiều Agent hơn nữa chạy trên thiết bị cá nhân hoặc môi trường đám mây dần kết nối với email, tin nhắn tức thì, lịch, tệp tin, trình duyệt, terminal và các công cụ thanh toán, câu hỏi “làm thế nào để chứng minh hành động này thực sự được người dùng cấp phép” sẽ trở thành một vấn đề ngày càng phổ biến.

Do đó, Sigil trong tương lai có thể mở rộng từ giao dịch trên chuỗi sang truy cập dữ liệu, sử dụng danh tính, chỉnh sửa tệp, đăng nội dung, mua dịch vụ và các tác vụ tự động hóa.

Nhìn chung, với sự hợp tác giữa imToken và OpenClaw, Sigil cố gắng mang những kinh nghiệm tích lũy trong suốt mười năm qua của imToken trong lĩnh vực tự lưu trữ, ví và chữ ký số vào giai đoạn mới khi các Agent tự chủ bắt đầu bước vào môi trường thực thi thực tế.

Nó không thay thế Agent, cũng không thay thế ví.

Nó đứng giữa hai bên.