OpenClaw 2.0 at Sigil: Pagbuo ng Verifiable Authorization para sa Autonomous AI Agents

Matagal nang walang balita ang «Crab» OpenClaw, na naglabas ng bersyon 2.0 noong Agosto 30.

Ayon sa opisyal, ito ang pinakamalaking update sa kasaysayan ng OpenClaw, na may higit sa 16,000 na Pull Request, na tumutok sa buong produkto stack kabilang ang pag-install, mensahe, memorya, Skills, model, Automations, browser, native app, Plugins, at mekanismo ng seguridad.

Ngunit kaysa sa mga malawak na listahan ng mga tampok, mas mahalaga ang mas malinaw na pag-unlad na landas sa likod ng OpenClaw 2.0: ang Agent ay nagsisiging maging mas kaya na talagang «gumawa ng mga gawain».

Samantala, ito ay nagdudulot din ng isang hindi maiiwasang pagkakalito sa pagkakatiwala: Kapag ang Agent ay lalong nakakapagdesisyon nang sarili tungkol sa "paano gawin", paano natin masisiguro na ang bawat mahalagang aksyon nito ay hindi lumabas sa limitasyon ng awtorisasyon ng user?

Sa nakaraang taon, ang pinakamalaking pagbabago sa AI Agent ay hindi lamang ang pagiging mas matalino ng mga pundasyonal na modelo.

Dumating na ang pagkakaroon ng mas maraming tunay na “mga kamay at paa” na makakaapekto sa labas na mundo ng mga Agent, tulad ng pagbabago ng impormasyon, pag-click sa mga buton, o direkting pagkontrol sa browser sa pamamagitan ng computer use (panatilihin ang pagbabasa ng Agentic AI拐点已至？当 AI 学会「自己行动」，如何重构 Web3 的安全边界？).

Ngunit ang problema ay nasa tamang lugar dito, sa ilalim ng kasalukuyang interaksyonal na paraan, madalas na masisira sa dalawang extremo.

Isang paraan ay ang pagbibigay ng buong awtoridad, direktang ibinibigay ang private key o isang Session Key na may matagal na katumpakan at sapat na awtoridad sa Agent, upang ito ay makapagdesisyon at makapagpapatupad nang sarili.

Ang automated experience na ito ay pinakamahusay, ngunit ang panganib ay napakalaki rin; kung sakaling makarating ang prompt injection, masamang webpage, o pollution, o kaya ay may pagkakamali sa pag-unawa ng modelo, maaaring magpalipat ang error sa buong execution chain at maging totoo sa pagkilos (tignan ang karagdagang pagbabasa sa Sign Hindi Lang Signature: Kapag Ang AI Agent Ang Nagpapakasal sa Iyo, Sino Pa Ang May Kontrol?).

Sa katotohanan, sa karaniwang internet scenario, maaari itong maging pagkakamali sa pagpapadala ng isang email o pagtatanggal ng isang file, ngunit sa blockchain, isang maling transaksyon ay kadalasang hindi maaaring balikin.

Ang isa pang paraan ay ang pag-iwas sa pagbigay ng awtoridad, kung saan bawat operasyon at bawat sub-call ay nagpapakita ng window ng pag-approve para sa pag-sign; itinataas nito ang kaligtasan, ngunit malaki ring bumababa ang kahalagahan ng automation.

Sa katotohanan, kung ang isang Agent ay nagtatapos sa isang kumplikadong DeFi strategy para sa isang user, at kailangan ng user na hawakan ang kanyang telepono at i-approve ang bawat hakbang nang magkakasunod, ang user ay naging isang “tao na pagsasapit ng stamp” lamang—hindi na siya ang nagpapatakbo ng sarili niyang mga pindot, kundi nagpapatakbo ng mga pindot para sa Agent.

Sa ibang salita, ang pagkakaroon ng kalayaan sa gitna ay pinagmumulan ng efisyensiya ng Agent, ngunit gayundin ng bagong panganib.

Sa pananaw na ito, ang core ng problema ay hindi kung dapat o hindi dapat bigyan ng awtoridad ang Agent, kundi kung ang antas ng pagpapawalang-bisa at ang mekanismo ng pag-verify ay may dinamikong fleksibilidad, dahil ang tradisyonal na pagmamahalaga ng awtoridad ay binario (o payagan o tanggihan), habang ang mga gawain na kinakaharap ng Agent ay mas kumplikado.

Isang transaksyon lamang, iba ang $10 at $100,000; iba ang pag-interact sa isang protokolo na ginagamit nang matagal at pagpapahintulot biglaan sa isang hindi kilalang kontrata; iba ang pagtapos ng isang Swap na itinaguyod ng user at pagpapasya ng Agent na ilipat ang mga asset sa ibang chain.

Kaya ang mas makapag-act nang malaya ang Agent, hindi na sapat na isang simpleng switch ang pahintulot.

Ang tunay na kailangan ay isang mekanismo ng kaligtasan na magpapahintulot sa ito na malayang mag-act sa loob ng hangganan at tumigil nang awtomatiko kapag lalabas sa hangganan.

Totoo, hindi pinag-iwanan ng OpenClaw ang problema na ito.

Kasalukuyang nagbibigay ito ng maraming antas ng mekanismo ng pahintulot, tulad ng pagpapahinga ng mga plugin bago maisagawa ang partikular na aksyon at hingin ang pahintulot ng user, at mayroon ding hiwalay na Exec Approvals at Allowlist kapag nauugnay sa mga utos ng host.

Mas malaking hakbang ito kaysa magbigay ng lahat ng mga kasangkapan at pahintulot sa Agent nang sabay-sabay. Ngunit kapag talagang pumasok ang Agent sa mga sitwasyon tulad ng pagbabayad, pagtrabaho, at pagpapamahala ng mga asset, lumalabas ang isang mas detalyadong problema: ang pagpapahintulot sa Agent na gamitin ang isang kakayahan ay iba sa pagbibigay ng pahintulot sa Agent na maisagawa ang isang partikular na aksyon.

Tulad ng pagpapahintulot sa Agent na gamitin ang browser ay hindi nangangahulugan na pinapahintulutan itong bumili anumang bagay sa anumang website; ang pagpapahintulot sa Agent na makapasok sa email ay hindi katumbas ng pagpapahintulot sa iyo na magpadala ng anumang mensahe sa anumang tao sa iyong pangalan; parehong ang pagpapahintulot sa Agent na gamitin ang wallet ay hindi dapat katumbas ng pagpapahintulot sa iyo na magpadala ng anumang halaga sa anumang address.

Kaya ang sistema ng mga pahintulot sa panahon ng Agent ay kailangang magkakaiba sa dalawang iba’t ibang tanong. Ang isa ay kapasidad ng pahintulot, kung maaari bang gamitin ng Agent ang browser, terminal, email, o wallet? At ang isa pa ay mas tiyak na pahintulot sa aksyon, tulad ng sa sandaling ito, kung talagang pinapahintulutan ng user ang aksyon na handa niyang gawin?

Paano mapapahintulutan ang Agent na maging lubos na awtomatiko sa malinaw na hangganan, samantalang ibinabalik ang pagdedesisyon sa user kapag talagang lumabas sa hangganan?

Ito rin ang dahilan kung bakit imToken ay tinutuklas ang Sigil. Ang pangunahin nito ay hindi magdagdag ng isang tradisyonal na «popup na pagpapatotoo» para sa Agent, kundi subukan ang pagbuo ng isang malinaw na limitadong seguridad na barrier sa pagitan ng user at Agent gamit ang verifiable signature at granular na pagkontrol ng pahintulot.

Isa sa mga pinakamahalagang prinsipyo ay ang «What you see is what you sign», kung ano ang nakikita mo, iyon ang pipirmahan mo.

Sa simpleng salita, maaaring bigyan ng tiyak na awtoridad ang Agent ng gumagamit upang awtomatikong matapos ang mga gawain na may mababang panganib at sumusunod sa nakatakdang istratehiya; kapag tumutok ang aksyon sa halaga ng pondo, kilalang protokolo, o iba pang mahahalagang hangganan ng awtoridad, i-pause ang proseso at ibalik ang partikular na hiling sa gumagamit para sa pagpapatunay.

Mas mahalaga pa, ang pagkakatotoo na ito ay hindi dapat isang ambigong pahayag na "Handa na ang Agent na isagawa ang transaksyon, sumasang-ayon ka ba?" Ang tunay na kailangan ng user ay makita ang mga mahahalagang parameter na magbabago sa operasyong ito: anong asset ang gagamitin, ilan ang halaga, sino ang kalaban sa interaksyon, at ano talaga ang gagawin.

Dahil sa tanging pagkakataon na ang nilalaman na nakikita ng user, ang nilalaman na pinapahintulutan ng user, at ang nilalaman na huling isinagawa ng sistema ay magkakatugma, ang isang pagkakakilanlan ay may tunay na kahulugan.

Sa paligid nito, sinubukan din ng Sigil ang paggamit ng mga mekanismo tulad ng Passkey, biometrik, isang beses na lagda, maikling panahon ng katotohanan, at pagkakabind ng mga parameter ng hiling, upang masiguro na ang mga kritikal na awtorisasyon ay hindi lamang nauunawaan ng user kundi pati na rin na masusuri ng sistema.

Ibig sabihin nito, ang isang awtorisasyon ay hindi lamang «may nag-click ng confirmation», kundi maaari ring magbigay ng karagdagang impormasyon kung sino ang nag-approve, ano ang na-approve, at kung ang totoo nang isinagawa ay ang bagay na nakita noong panahong iyon.

Sa pananaw na ito, ang tunay na problema na gustong lutasin ng Sigil ay hindi ang “paano gawing mas kaunti ang mga gawain ng Agent.”

Kabaligtaran naman.

Nag-uusap ito sa pagkakaroon ng paraan kung paano papayagan ang Agent na gawin ang higit pa nang walang pagkuha ng huling kontrol ng user (basahin ang karagdagang pagsusuri sa “Paano mula sa pagpindot ng ‘Yes’ nang walang pag-iisip hanggang sa pag-unawa bago mag-sign: Paano ni Sigil inilalagay ang seguridad sa AI Agent?”).

Kung lilikod ka pa ng isang hakbang, makikita mo na ito ay isang pagbabago ng papel na kinakaharap ng wallet.

Simula noong ang Ethereum ay nabuo, ang imToken wallet ay direktang nakakasaksi at nakaranas ng dalawang mahahalagang henerasyon: mula sa panahon ng 1.0 kung saan pinapamahalaan ang isang pribadong key, hanggang sa panahon ng 2.0 na pinapabuti ang user experience sa pamamagitan ng account abstraction (AA).

Kasabay ng paglalaganap ng mga autonomous agent tulad ng OpenClaw 2.0, ang mga wallet ay tiyak na pumasok sa ikatlong henerasyon ng pag-unlad, at kailangan ng karagdagang tulong para sa mga user sa pagpapamahala sa bawat isa sa mga autonomous agent na nakakagawa ng sariling desisyon at gumagana nang patuloy.

Ito ang dahilan kung bakit ang mga kakayahan sa pamamahala ng private key, digital signature, authentication, at isolation ng mga pahintulot na nakumpuni ng industriya ng wallet sa nakaraan, ay maaaring makakuha ng bagong kahalagahan sa panahon ng Agent.

Dahil ang mga teknolohiyang ito ay sa pangkalahatan ay naglalayong lutasin ang tanong na “paano ligtas na i-sign ang isang on-chain transaction,” ang tunay na isyu na tinutugon nito ay mas pangkalahatan: paano patunayan na ang isang aksyon ay may totoong pahintulot mula sa isang partikular na entidad.

Ngayon, ang aksyon na ito ay maaaring isang paglipat ng 1 ETH. Sa hinaharap, maaari itong maging pagpapadala ng isang e-mail, pagbabago ng isang file, paggamit ng isang digital na identity, pagbili ng isang serbisyo, o pagpapahintulot sa Agent na magpatuloy na pagsasagawa ng isang set ng automated na estratehiya sa susunod na linggo.

Hindi lahat ng mga gawaing ito ay nangyayari sa blockchain, ngunit ang pangunahing ugnayan ay napakapareho: ang Agent ay tumatawag ng isang kakayahan na nasa pangalan ng user.

Kaya ang kahulugan ng Sigil ay hindi lamang nakalulokal sa Crypto.

Kapag ang OpenClaw, Hermes, at iba pang Agent na tumatakbo sa mga personal na device o cloud environment ay nagsisambungay sa mga email, instant messaging, kalendaryo, mga file, browser, terminal, at mga kasangkapan sa pagbabayad, ang tanong na “Paano papatunayan na ang aksyong ito ay may pahintulot ng user” ay magiging isang mas karaniwang problema.

Kaya ang Sigil ay maaaring mag-expand sa hinaharap mula sa on-chain trading patungo sa pag-access sa data, paggamit ng identity, pagbabago ng file, pagpapalabas ng kontenido, pagbili ng serbisyo, at automation ng mga gawain.

Sa kabuuan, bilang isang kolaborasyon ng imToken at OpenClaw, ang Sigil ay nagtatangkang dalhin ang mga karanasan ng imToken sa loob ng nakaraang sampung taon sa larangan ng self-custody, wallet, at digital signature patungo sa bagong yugto kung saan ang autonomous Agent ay nagsisimula nang umakyat sa tunay na pagpapatupad.

Hindi ito nagpapalit sa Agent, ni hindi ito nagpapalit sa wallet.

Nakatayo ito sa pagitan ng dalawa.