放权还是失控？Agent 自主时代，我们需要怎样的「可验证授权」？
- 核心观点：OpenClaw 2.0 发布标志 AI Agent 从辅助工具向自主执行体演进，但其“动手做事”的能力提升带来授权边界难题；文章提出通过可验证签名和细粒度权限（如 Sigil）构建动态安全护栏，确保 Agent 在用户授权范围内自主行动。
- 关键要素：
- OpenClaw 2.0 为迄今最大规模更新，超 1.6 万个 Pull Request，覆盖安装、记忆、Skills、安全等全栈功能，体现 Agent 自主行动能力显著增强。
- 当前授权模式存在两难：全盘放权（如交付私钥）风险高，易受提示词注入或模型偏差影响；层层确认则削弱自动化价值，使 Agent 沦为低效执行工具。
- 权限管理需从二元制（允许/拒绝）转向动态弹性策略，结合金额、协议陌生度和操作类型分级授权，如 10 美元与 10 万美元交易不应同等对待。
- 核心区分“能力权限”（能否使用工具）与“行动授权”（具体操作是否被允许）；允许调用钱包不等于授权任意金额转账至任意地址。
- Sigil 作为探索方案，遵循“所见即所签”原则，通过 Passkey、生物识别和请求参数绑定，让用户确认时可见具体资产、金额及交互对象。
- 钱包角色正从管理私钥（1.0）和优化交互（2.0）演进至管理自主 Agent（3.0），需要证明任何代用户行动的真实授权来源。
OpenClaw หรือที่รู้จักกันในชื่อเล่นว่า "ล็อบสเตอร์" ที่เงียบหายไปสักพัก ได้เปิดตัวเวอร์ชัน 2.0 เมื่อวันที่ 30 สิงหาคม
ตามคำกล่าวอย่างเป็นทางการ นี่คือการอัปเดตครั้งใหญ่ที่สุดในประวัติศาสตร์ของ OpenClaw โดยมี Pull Request รวมกันกว่า 16,000 รายการ ครอบคลุมเกือบทั้งผลิตภัณฑ์ทั้งหมด ตั้งแต่วิธีการติดตั้ง ข้อความ ความทรงจำ ทักษะ (Skills) โมเดล ระบบอัตโนมัติ (Automations) เบราว์เซอร์ แอปพลิเคชันเนทีฟ ปลั๊กอิน (Plugins) ไปจนถึงกลไกความปลอดภัย
แต่เมื่อเทียบกับรายการฟีเจอร์อันซับซ้อนเหล่านี้ สิ่งที่น่าสนใจกว่าคือเส้นทางการพัฒนาที่ชัดเจนขึ้นเรื่อยๆ เบื้องหลัง OpenClaw 2.0: Agent กำลังมีความสามารถในการ "ลงมือทำสิ่งต่างๆ" ได้จริงมากขึ้นเรื่อยๆ
ในขณะเดียวกัน มันก็ได้นำอุตสาหกรรมไปสู่ภาวะกลilemmasด้านความไว้วางใจที่หลีกเลี่ยงไม่ได้: เมื่อ Agent สามารถตัดสินใจได้เองมากขึ้นเรื่อยๆ ว่า "จะทำอย่างไร" เราจะมั่นใจได้อย่างไรว่าทุกการดำเนินการที่สำคัญของมัน จะไม่ข้ามขอบเขตที่ผู้ใช้ได้อนุญาตไว้จริงๆ?
หนึ่ง ภาวะilemmasสองทางของอิสระในการตัดสินใจของ Agent: ปล่อยอิสระทั้งหมด หรือต้องยืนยันทุกขั้นตอน?
ในช่วงปีที่ผ่านมา การเปลี่ยนแปลงที่ชัดเจนที่สุดของ AI Agent ไม่ได้มีเพียงแค่โมเดลพื้นฐานที่ฉลาดขึ้นเท่านั้น
เมื่อโครงสร้างพื้นฐานต่างๆ เช่น MCP, Skills, Plugins, การควบคุมเบราว์เซอร์ และการเรียกใช้โค้ด ค่อยๆ เติบโตเต็มที่ Agent เริ่มมี "มือและเท้า" ที่สามารถส่งผลกระทบต่อโลกภายนอกได้จริงมากขึ้นเรื่อยๆ เช่น การแก้ไขข้อมูล การคลิกปุ่ม หรือการควบคุมเบราว์เซอร์โดยตรงผ่าน computer use (อ่านเพิ่มเติมได้ในบทความ "ถึงจุดเปลี่ยนของ Agentic AI แล้วหรือยัง? เมื่อ AI เรียนรู้ที่จะ "ลงมือทำเอง" เราจะสร้างขอบเขตความปลอดภัยของ Web3 ขึ้นมาใหม่ได้อย่างไร?")
แต่ปัญหาก็อยู่ตรงนี้พอดี ภายใต้กระบวนทัศน์การโต้ตอบในปัจจุบัน เรามักจะตกอยู่ในสองขั้วสุดขั้วได้ง่าย
ขั้วหนึ่งคือการปล่อยอิสระทั้งหมด กล่าวคือ มอบคีย์ส่วนตัว หรือ Session Key ที่มีอายุยาวนานและมีสิทธิ์กว้างขวางเพียงพอให้กับ Agent โดยตรง เพื่อให้มันตัดสินใจและดำเนินการได้เอง
ประสบการณ์อัตโนมัติในโหมดนี้ย่อมดีที่สุด แต่ความเสี่ยงก็กระจุกตัวอยู่มากพอๆ กัน เมื่อเผชิญกับการโจมตีแบบ prompt injection, เว็บไซต์ที่เป็นอันตราย หรือมลพิษทางสภาพแวดล้อม หรือแม้แต่ตัวโมเดลเองมีความเข้าใจที่คลาดเคลื่อน ข้อผิดพลาดก็อาจส่งต่อกันไปตลอดทั้งสายการดำเนินการ และท้ายที่สุดกลายเป็นการดำเนินการจริง (อ่านเพิ่มเติมได้ในบทความ "Sign ไม่ได้เป็นเพียงแค่การเซ็นชื่อ: เมื่อ AI Agent เซ็นชื่อแทนคุณ ใครยังคงถืออำนาจควบคุมอยู่?")
เพราะในสถานการณ์อินเทอร์เน็ตทั่วไป มันอาจเป็นแค่การส่งอีเมลผิด, ลบไฟล์ผิด แต่เมื่ออยู่บนเชน ธุรกรรมที่ผิดพลาดเพียง一笔เดียวมักจะไม่สามารถย้อนกลับได้
อีกขั้วหนึ่งคือการไม่ปล่อยอิสระเลย ทุกการดำเนินการ ทุกการเรียกใช้ย่อย จะต้องมีหน้าต่างยืนยันการเซ็นชื่อโผล่ขึ้นมาเพื่อขออนุมัติ ความปลอดภัยเพิ่มขึ้น แต่ความหมายของระบบอัตโนมัติก็ลดลงอย่างมากตามไปด้วย
เพราะหาก Agent ช่วยผู้ใช้ทำกลยุทธ์ DeFi ที่ซับซ้อนชุดหนึ่ง ซึ่งมีหลายขั้นตอนเกี่ยวข้อง และทุกขั้นตอนต้องให้ผู้ใช้หยิบโทรศัพท์ขึ้นมา "อนุมัติ" ทีละอัน ผู้ใช้ก็จะกลายเป็นเพียง "เครื่องประทับตราตรวจสอบมนุษย์" ที่คอยประทับตราให้ Agent ไปเรื่อยๆ แทนที่จะเป็นแค่ "กดปุ่มด้วยตัวเอง"
กล่าวอีกนัยหนึ่ง อิสระในระดับกลางนี้ ทั้งเป็นแหล่งที่มาของการเพิ่มประสิทธิภาพของ Agent และเป็นแหล่งที่มาของความเสี่ยงใหม่
จากมุมมองนี้ แก่นแท้ของปัญหาไม่ได้อยู่ที่ "จะปล่อยอิสระให้ Agent หรือไม่" แต่อยู่ที่ว่าความละเอียดของการอนุญาตและกลไกการตรวจสอบมีความยืดหยุ่นแบบไดนามิกหรือไม่ เพราะการจัดการสิทธิ์แบบดั้งเดิมนั้นเป็นแบบสองขั้ว (อนุญาตหรือปฏิเสธ) ในขณะที่งานที่ Agent เผชิญอยู่นั้นซับซ้อนกว่ามาก
เช่นเดียวกันกับการทำธุรกรรม一笔 การทำ 10 ดอลลาร์กับการทำ 100,000 ดอลลาร์นั้นต่างกัน; การโต้ตอบกับโปรโตคอลที่ใช้มานาน กับการอนุญาตสัญญาที่ไม่คุ้นเคยในทันใดนั้นต่างกัน; การทำ Swap ที่ผู้ใช้ร้องขออย่างชัดเจน กับการที่ Agent ตัดสินใจย้ายสินทรัพย์ไปยังอีกเชนหนึ่งด้วยตัวเอง ก็ไม่ได้มีความเสี่ยงในระดับเดียวกัน
ดังนั้น ยิ่ง Agent ลงมือทำได้ด้วยตัวเองมากเท่าไหร่ สิทธิ์ก็ยิ่งไม่สามารถเป็นเพียงสวิตช์เปิดปิดง่ายๆ ได้เท่านั้น
สิ่งที่จำเป็นจริงๆ คือกลไกความปลอดภัยชุดหนึ่งที่ช่วยให้มันสามารถดำเนินการได้อย่างอิสระภายในขอบเขต และหยุดโดยอัตโนมัติเมื่อข้ามขอบเขตออกไป
สอง จะสร้างแนวป้องกันที่ "ตรวจสอบได้" ให้กับ Agent อิสระได้อย่างไร?
อันที่จริง OpenClaw ไม่ได้มองข้ามปัญหานี้
ปัจจุบันมันมีกลไกสิทธิ์หลายชั้นให้เลือกใช้ ตัวอย่างเช่น ปลั๊กอินสามารถหยุดชั่วคราวและขอให้ผู้ใช้ยืนยันก่อนดำเนินการเฉพาะบางอย่าง และเมื่อเกี่ยวข้องกับคำสั่งของโฮสต์ ก็ยังมี Exec Approvals และ Allowlist แยกต่างหาก เป็นต้น
การทำเช่นนี้ถือเป็นก้าวที่ใหญ่กว่าเมื่อเทียบกับการมอบเครื่องมือและสิทธิ์ทั้งหมดให้กับ Agent ในครั้งเดียว แต่เมื่อ Agent เข้าสู่สถานการณ์การชำระเงิน การซื้อขาย และการจัดการสินทรัพย์จริงๆ คำถามที่ละเอียดอ่อนกว่าก็เกิดขึ้น: การอนุญาตให้ Agent ใช้ความสามารถบางอย่าง กับการอนุญาตให้ Agent ทำการดำเนินการเฉพาะบางอย่างนั้น แท้จริงแล้วไม่ใช่เรื่องเดียวกัน
เหมือนกับการอนุญาตให้ Agent ใช้เบราว์เซอร์ ไม่ได้หมายความว่าอนุญาตให้มันซื้อของอะไรก็ได้บนเว็บไซต์ใดก็ได้; การอนุญาตให้ Agent เข้าถึงอีเมล ก็ไม่ได้เท่ากับอนุญาตให้มันส่งอีเมลถึงใครก็ได้ในนามของคุณ; เช่นเดียวกัน การอนุญาตให้ Agent เรียกใช้กระเป๋าเงิน ก็ไม่ควรเท่ากับอนุญาตให้มันส่งจำนวนเงินเท่าใดก็ได้ไปยังที่อยู่ใดก็ได้โดยเด็ดขาด
ดังนั้น ระบบสิทธิ์ในยุคของ Agent อาจต้องแยกแยะคำถามสองข้อที่แตกต่างกัน หนึ่งคือสิทธิ์ด้านความสามารถ กล่าวคือ Agent สามารถใช้เบราว์เซอร์ เทอร์มินัล อีเมล หรือกระเป๋าเงินได้หรือไม่? อีกข้อหนึ่งคือการอนุญาตการดำเนินการที่เฉพาะเจาะจงกว่า กล่าวคือ ในขณะนี้ สิ่งที่มันกำลังเตรียมจะทำนั้น เป็นสิ่งที่ผู้ใช้อนุญาตให้มันทำจริงๆ หรือไม่?
แล้วจะทำให้ Agent ทำงานอัตโนมัติได้อย่างเต็มที่ภายในขอบเขตที่ชัดเจน ในขณะเดียวกันก็ส่งอำนาจการตัดสินใจกลับคืนให้ผู้ใช้ เมื่อมันข้ามขอบเขตจริงๆ ได้อย่างไร?
นี่คือเหตุผลที่ imToken กำลังสำรวจ Sigil แกนหลักของมันไม่ใช่การเพิ่ม "หน้าต่างยืนยัน" แบบดั้งเดิมอีกชั้นหนึ่งให้กับ Agent แต่เป็นการพยายามสร้างรั้วป้องกันความปลอดภัยที่สามารถถูกจำกัดได้อย่างชัดเจนระหว่างผู้ใช้และ Agent ผ่านการเซ็นชื่อที่ตรวจสอบได้และการควบคุมสิทธิ์แบบละเอียด
หลักการสำคัญประการหนึ่งคือ "What you see is what you sign" สิ่งที่คุณเห็นคือสิ่งที่คุณเซ็นชื่อ
พูดง่ายๆ คือ ผู้ใช้สามารถให้สิทธิ์ Agent ไว้ล่วงหน้าในช่วงหนึ่ง เพื่อให้พฤติกรรมที่มีความเสี่ยงต่ำและสอดคล้องกับกลยุทธ์ที่กำหนดไว้เสร็จสมบูรณ์ได้โดยอัตโนมัติ; เมื่อการดำเนินการแตะถึงขีดจำกัดจำนวนเงิน โปรโตคอลที่ไม่คุ้นเคย หรือขอบเขตสิทธิ์ที่สำคัญอื่นๆ มันจะหยุดการทำงานชั่วคราวและส่งคำขอเฉพาะเจาะจงกลับไปให้ผู้ใช้ยืนยัน
ที่สำคัญกว่านั้น การยืนยันนี้ไม่ควรเป็นเพียงประโยคคลุมเครือว่า "Agent เตรียมดำเนินการธุรกรรม คุณตกลงหรือไม่" สิ่งที่ผู้ใช้จำเป็นต้องเห็นจริงๆ คือพารามิเตอร์สำคัญที่เปลี่ยนแปลงจริงในการดำเนินการนี้: ใช้สินทรัพย์อะไร จำนวนเท่าไหร่ โต้ตอบกับใคร และท้ายที่สุดจะดำเนินการอะไรจริงๆ
เพราะว่า只有当เนื้อหาที่ผู้ใช้เห็น เนื้อหาที่ผู้ใช้อนุมัติ และเนื้อหาที่ระบบดำเนินการในที่สุด สามารถสอดคล้องกันได้ การยืนยันครั้งหนึ่งจึงจะมีความหมายอย่างแท้จริง
Sigil รอบประเด็นนี้ ยังพยายามใช้กลไกต่างๆ เช่น Passkey, การยืนยันตัวตนด้วยชีวภาพ, การเซ็นชื่อแบบครั้งเดียว, อายุสั้น และการผูกพารามิเตอร์คำขอ เพื่อให้การอนุญาตที่สำคัญไม่เพียงแต่ผู้ใช้จะเข้าใจได้เท่านั้น แต่ยังสามารถถูกตรวจสอบโดยระบบได้อีกด้วย
ซึ่งหมายความว่า การอนุญาต一份ไม่ใช่แค่ "มีคนคลิกยืนยัน" แต่ยังสามารถตอบคำถามเพิ่มเติมได้อีกว่า ใครเป็นผู้อนุมัติ อนุมัติอะไร และสิ่งที่ดำเนินการจริงในท้ายที่สุด ใช่สิ่งที่เห็นในตอนนั้นหรือไม่
จากมุมมองนี้ สิ่งที่ Sigil ต้องการแก้ไขจริงๆ ไม่ใช่ "จะทำให้ Agent ทำอะไรน้อยลงได้อย่างไร"
ตรงกันข้ามเลย
มันพยายามแก้ไขว่า จะทำให้ Agent สามารถทำสิ่งต่างๆ ได้มากขึ้นอย่างสบายใจ โดยไม่ต้องแย่งอำนาจควบคุมขั้นสุดท้ายจากผู้ใช้ไป (อ่านเพิ่มเติมได้ในบทความ "จากการคลิก "Yes" อย่างไม่ลืมหูลืมตา สู่การมองให้ชัดก่อนเซ็นชื่อ: Sigil เติมรั้วป้องกันความปลอดภัยให้ AI Agent ได้อย่างไร?")
สาม จากการจัดการสินทรัพย์ สู่การจัดการ Agent
หากถอยมุมมองออกไปอีกหนึ่งก้าว จะพบว่าจริงๆ แล้วนี่คือการเปลี่ยนแปลงบทบาทที่กระเป๋าเงินกำลังเผชิญอยู่
นับตั้งแต่การถือกำเนิดของ Ethereum กระเป๋าเงิน imToken ได้ประสบและเป็นสักขีพยานในสองยุคสำคัญด้วยตนเอง: วิวัฒนาการจากยุค 1.0 ที่จัดการคีย์ส่วนตัวเดียว ไปสู่ยุค 2.0 ที่ปรับปรุงประสบการณ์การโต้ตอบผ่าน Account Abstraction (AA)
เมื่อ Agent อิสระเช่น OpenClaw 2.0 แพร่หลายมากขึ้น กระเป๋าเงินกำลังก้าวเข้าสู่ยุคที่สามของการพัฒนาอย่างไม่ต้องสงสัย ซึ่งจำเป็นต้องช่วยให้ผู้ใช้จัดการ Agent ที่จะตัดสินใจเองและทำงานอย่างต่อเนื่อง ทีละตัว
นี่คือเหตุผลว่าทำไมความสามารถด้านการจัดการคีย์ส่วนตัว การเซ็นชื่อดิจิทัล การยืนยันตัวตน และการแยกสิทธิ์ที่อุตสาหกรรมกระเป๋าเงินสะสมไว้ในอดีต อาจได้รับความหมายใหม่ในยุคของ Agent
เพราะเทคโนโลยีเหล่านี้表面上กำลังแก้ปัญหา "จะเซ็นชื่อธุรกรรมบนเชนอย่างปลอดภัยได้อย่างไร" แต่เบื้องหลังมันจัดการกับปัญหาที่普遍กว่า: จะพิสูจน์ได้อย่างไรว่าการดำเนินการหนึ่งๆ ได้รับการอนุญาตอย่างแท้จริงจากหน่วยงานหนึ่ง
วันนี้ การดำเนินการนี้อาจเป็นการโอน 1 ETH ในอนาคต มันอาจเป็นการส่งอีเมล แก้ไขไฟล์ ใช้ตัวตนดิจิทัล ซื้อบริการ หรืออนุญาตให้ Agent ดำเนินกลยุทธ์อัตโนมัติชุดหนึ่งต่อไปในสัปดาห์หน้า
พฤติกรรมเหล่านี้ไม่จำเป็นต้องเกิดขึ้นบนบล็อกเชนทั้งหมด แต่ความสัมพันธ์พื้นฐานนั้นคล้ายคลึงกันมาก นั่นคือ Agent กำลังเรียกใช้ความสามารถที่เป็นของผู้ใช้ ในนามของผู้ใช้
ดังนั้น ความหมายของ Sigil จึงไม่จำเป็นต้องจำกัดอยู่แค่ในโลก Crypto เท่านั้น
เมื่อ OpenClaw, Hermes และ Agent อื่นๆ อีกมากมายที่ทำงานบนอุปกรณ์ส่วนตัวหรือสภาพแวดล้อมคลาวด์ ค่อยๆ เชื่อมต่อกับอีเมล ระบบส่งข้อความโต้ตอบแบบทันที ปฏิทิน ไฟล์ เบราว์เซอร์ เทอร์มินัล และเครื่องมือชำระเงิน "จะพิสูจน์ได้อย่างไรว่าการดำเนินการครั้งนี้ผ่านการอนุญาตจากผู้ใช้จริงๆ" จะกลายเป็นปัญหาที่พบได้บ่อยมากขึ้นเรื่อยๆ
ดังนั้น ในอนาคต Sigil อาจขยายขอบเขตจากธุรกรรมบนเชนไปสู่การเข้าถึงข้อมูล การใช้ตัวตน การแก้ไขไฟล์ การเผยแพร่เนื้อหา การซื้อบริการ และงานอัตโนมัติ
โดยรวมแล้ว ในฐานะความร่วมมือระหว่าง imToken และ OpenClaw Sigil พยายามนำประสบการณ์ที่ imToken สะสมมาในทศวรรษที่ผ่านมาในด้านการดูแลตนเอง (self-custody) กระเป๋าเงิน และการเซ็นชื่อดิจิทัล เข้าสู่ช่วงใหม่ที่ Agent อิสระเริ่มเข้าสู่สภาพแวดล้อมการดำเนินการจริง
มันไม่ได้แทนที่ Agent และไม่ได้แทนที่กระเป๋าเงิน
มันยืนอยู่ระหว่างทั้งสองสิ่งนี้
