OpenClaw 2.0 y Sigil: Construyendo autorización verificable para agentes de IA autónomos

Tras un período de inactividad, «OpenClaw» lanzó la versión 2.0 el 30 de agosto.

Según la versión oficial, esta es la actualización más grande en la historia de OpenClaw, con más de 16,000 Pull Requests acumulados, que abarcan casi toda la pila del producto, incluyendo instalación, mensajes, memoria, Skills, modelos, Automations, navegador, aplicaciones nativas, Plugins y mecanismos de seguridad.

Pero más allá de esta extensa lista de funciones, lo que realmente merece atención es la línea de evolución cada vez más clara detrás de OpenClaw 2.0: los Agentes están volviéndose cada vez más capaces de «hacer cosas» realmente.

Al mismo tiempo, también lleva a la industria a un dilema de confianza inevitable: cuando los Agentes sean cada vez más capaces de decidir de forma autónoma «cómo hacerlo», ¿cómo podemos asegurar que cada operación clave no cruce los límites de la autorización real del usuario?

En el último año, el cambio más notable en los AI Agentes no ha sido solo que los modelos subyacentes se hayan vuelto más inteligentes.

A medida que la infraestructura, como MCP, Skills, Plugins, control de navegadores y ejecución de código, madura, los Agentes comienzan a adquirir cada vez más «extremidades» capaces de influir realmente en el mundo exterior, como modificar información, hacer clic en botones o controlar directamente el navegador mediante computer use (lectura adicional: ¿Ha llegado el punto de inflexión del Agentic AI? Cuando la IA aprende a «actuar por sí misma», ¿cómo redefinir los límites de seguridad de Web3?).

Pero el problema justamente surge aquí, ya que bajo los patrones de interacción actuales, a menudo se cae en dos extremos.

Una opción es otorgar plenos poderes, entregando directamente la clave privada o una Session Key de larga duración con suficientes permisos al agente para que decida y ejecute por sí mismo.

La experiencia automatizada de este modelo es, por supuesto, la mejor, pero el riesgo también está muy concentrado: si se produce una inyección de indicaciones, una página web maliciosa o contaminación del entorno, o si el modelo presenta sesgos en su comprensión, los errores podrían propagarse por toda la cadena de ejecución y terminar convirtiéndose en operaciones reales (lectura adicional: Sign no solo firma: cuando un AI Agent firma por ti, ¿quién tiene el control?).

Después de todo, en escenarios normales de internet, esto podría ser solo enviar un correo electrónico equivocado o eliminar un archivo incorrecto, pero en la cadena, una transacción errónea a menudo es irreversible.

La otra opción es no delegar ningún permiso; cada operación y cada llamada secundaria muestra una ventana de firma para solicitar confirmación, lo que aumenta la seguridad, pero reduce significativamente el valor de la automatización.

Después de todo, un agente que ayuda a un usuario a ejecutar una estrategia DeFi compleja implica múltiples pasos; si cada uno requiere que el usuario tome su teléfono para «aprobar» manualmente, el usuario en realidad solo pasa de ser alguien que «presiona botones» a convertirse en una «máquina humana de sello» que aprueba continuamente para el agente.

En otras palabras, la flexibilidad intermedia es tanto la fuente de eficiencia del Agente como una nueva fuente de riesgo.

Desde este punto de vista, el núcleo del problema no radica en «si se debe otorgar poder al Agente», sino en si la granularidad del permiso y los mecanismos de verificación son dinámicos y flexibles, ya que la gestión de permisos tradicional es binaria (ya sea permitir o rechazar), mientras que las tareas que enfrenta el Agente son claramente mucho más complejas.

Es la misma transacción, pero $10 y $100,000 son diferentes; interactuar con un protocolo de uso prolongado es distinto a autorizar repentinamente un contrato desconocido; completar un Swap que el usuario solicitó explícitamente no tiene el mismo nivel de riesgo que un agente que decide por sí mismo transferir los activos a otra cadena.

Por lo tanto, cuanto más autónomo sea el agente, más complejo debe ser el control de permisos, y no puede ser simplemente un interruptor simple.

Lo que realmente se necesita es un mecanismo de seguridad que le permita moverse libremente dentro de los límites y detenerse automáticamente al cruzarlos.

De hecho, OpenClaw no ha ignorado este problema.

Actualmente ofrece un mecanismo de permisos múltiples, por ejemplo, los plugins pueden pausar y solicitar confirmación del usuario antes de ejecutar operaciones específicas; cuando se tratan comandos del host, existen además aprobaciones independientes de ejecución y listas permitidas, entre otros.

En comparación con entregar todos los instrumentos y permisos al Agente de una vez, esto representa un gran avance. Pero cuando el Agente realmente entre en escenarios de pagos, operaciones y gestión de activos, surge un problema más fino: permitir que el Agente utilice una capacidad no es lo mismo que autorizarlo para realizar una acción específica.

Permitir que el Agente use un navegador no significa permitirle comprar cualquier cosa en cualquier sitio web; permitir que el Agente acceda al correo electrónico no equivale a permitirle enviar correos a cualquier persona en tu nombre; de la misma manera, permitir que el Agente invoque una billetera tampoco debería equivaler a permitirle enviar cualquier cantidad a cualquier dirección.

Por lo tanto, el sistema de permisos en la era de los Agentes podría necesitar distinguir dos problemas diferentes. Uno es el permiso de capacidad: ¿puede el Agente usar el navegador, la terminal, el correo electrónico o la billetera? El otro es una autorización de acción más específica: ¿es realmente esto lo que el usuario le ha permitido hacer en este momento?

¿Cómo se puede permitir que el agente se automatice plenamente dentro de límites claros, mientras se vuelve a entregar la decisión al usuario cuando realmente cruce esos límites?

Esta es también la razón por la que imToken está explorando Sigil. Su núcleo no consiste en añadir al Agente una «ventana de confirmación» tradicional, sino en intentar establecer una barrera de seguridad claramente delimitada entre el usuario y el Agente mediante firmas verificables y control de permisos granular.

Uno de los principios más importantes es «What you see is what you sign»: lo que ves, eso es lo que firmas.

En términos sencillos, los usuarios pueden otorgar previamente al agente ciertos permisos para que acciones de bajo riesgo y alineadas con la estrategia establecida se completen automáticamente; cuando una operación alcance límites de monto, protocolos desconocidos u otros límites de permisos clave, se pausará la ejecución y se devolverá la solicitud específica al usuario para su confirmación.

Más importante aún, esta confirmación no debería ser simplemente una vaga frase como «El agente está listo para ejecutar la operación, ¿está de acuerdo?»; lo que los usuarios realmente necesitan ver son los parámetros clave que cambiarán en esta operación: qué activos se utilizarán, cuál es la cantidad, quién es el objeto de la interacción y qué se ejecutará finalmente.

Solo tiene sentido una confirmación cuando el contenido que ve el usuario, el contenido autorizado por el usuario y el contenido final ejecutado por el sistema coinciden.

Sigil también ha intentado utilizar mecanismos como Passkey, biometría, firma única, validez breve y vinculación de parámetros de solicitud, para que la autorización clave no solo sea comprensible para el usuario, sino también verificable por el sistema.

Esto significa que una autorización no es solo «alguien hizo clic en confirmar», sino que también puede responder quién aprobó, qué aprobó, y si lo que realmente se ejecutó fue exactamente lo que se vio en ese momento.

Desde este punto de vista, lo que Sigil realmente quiere resolver no es «cómo hacer que el Agente haga menos cosas».

Quite the contrary.

Intenta abordar cómo permitir que el agente haga más cosas con confianza sin quitarle al usuario el control final (lectura adicional: De marcar ciegamente «Sí» a comprender antes de firmar: ¿Cómo Sigil añade un sistema de seguridad para los agentes de IA?).

Si se aleja un poco más la perspectiva, se puede ver que esto también representa un cambio de rol que las billeteras están experimentando.

Desde el nacimiento de Ethereum, la billetera imToken ha vivido y presenciado dos generaciones clave: desde la era 1.0, que gestionaba claves privadas únicas, hasta la era 2.0, que optimiza la experiencia de interacción mediante la abstracción de cuentas (AA).

Con la popularización de agentes autónomos como OpenClaw 2.0, las billeteras sin duda están entrando en su tercera generación de evolución, necesitando ayudar aún más a los usuarios a gestionar agentes que toman decisiones autónomas y funcionan de forma continua.

Por eso, las capacidades acumuladas en el pasado por la industria de billeteras en la gestión de claves privadas, firmas digitales, autenticación de identidad e aislamiento de permisos podrían adquirir un nuevo significado en la era de los Agentes.

Porque estas tecnologías, en apariencia, resuelven la pregunta de «cómo firmar de forma segura una transacción en cadena», en realidad abordan un problema más general: cómo demostrar que una acción ha recibido realmente la autorización de un sujeto.

Hoy, esta acción podría ser transferir 1 ETH. En el futuro, también podría ser enviar un correo electrónico, modificar un archivo, utilizar una identidad digital, comprar un servicio o permitir que un Agente ejecute continuamente un conjunto de estrategias automatizadas durante la próxima semana.

Estas acciones no necesariamente ocurren todas en la blockchain, pero la relación subyacente es muy similar: el agente está invocando una capacidad que pertenece al usuario en nombre del usuario.

Por lo tanto, el significado de Sigil tampoco necesariamente se limita a Crypto.

Cuando OpenClaw, Hermes y otros Agentes que se ejecutan en dispositivos personales o entornos en la nube se conecten gradualmente a correo electrónico, mensajería instantánea, calendarios, archivos, navegadores, terminales y herramientas de pago, la pregunta «¿cómo demostrar que esta acción fue realmente autorizada por el usuario?» se volverá cada vez más común.

Por lo tanto, Sigil también podría extenderse en el futuro a la acceso a datos, uso de identidad, modificación de archivos, publicación de contenido, compra de servicios y tareas automatizadas.

En general, como una exploración conjunta de imToken y OpenClaw, Sigil busca llevar la experiencia acumulada por imToken durante los últimos diez años en autoservicio, billeteras y firmas digitales a una nueva etapa en la que los Agentes autónomos comienzan a entrar en entornos de ejecución reales.

No reemplaza al agente ni sustituye la billetera.

Se encuentra entre ambos.