SkyClaw Agrega Configuración de Clave API Basada en Chat Encriptado para Agentes de IA

SkyClaw introduce un método para configurar de forma segura las claves API a través de interfaces de chat sin exponerlas a los LLM o plataformas de mensajería. El sistema aborda la fricción en el flujo de trabajo de los agentes autoalojados tradicionales que requieren acceso SSH, edición de archivos de configuración y reinicios de servicio para cambiar las claves.

Cómo funciona

La solución tiene dos capas de seguridad:

• Capa 1 — Interceptación del sistema: Los comandos de claves (/addkey, /keys, /removekey) y los blobs cifrados (que comienzan con enc:v1:) se capturan en main.rs antes de que los mensajes lleguen al agente. El proceso Rust descifra, valida y guarda en la bóveda, manteniendo al LLM completamente fuera de las operaciones de credenciales.
• Capa 2 — Cifrado OTK: Utiliza fragmentos de URL (#) que nunca se envían a los servidores según RFC 3986. El flujo: el bot envía setup.page/#one-time-256bit-key, el navegador cifra la clave API localmente usando AES-256-GCM con WebCrypto, el usuario pega el blob cifrado de vuelta en el chat, el bot lo descifra en la capa del sistema y lo guarda, luego destruye la clave única.

Resultados de seguridad

• Las plataformas de mensajería solo ven texto cifrado (inútil sin OTK)
• El LLM no ve nada (interceptado antes del bucle del agente)
• GitHub Pages solo ve GET /setup
• Funciona en cualquier plataforma que envíe/reciba texto

Comparación con otros proyectos

La fuente identifica limitaciones en las soluciones actuales:

• OpenClaw: Utiliza archivos de configuración, variables de entorno, asistente CLI, gestores de secretos externos opcionales. El issue #11829 de GitHub afirma: "OpenClaw actualmente tiene múltiples vectores donde las claves API pueden filtrarse al LLM o exponerse en el chat". El issue #19137 documenta que config.get filtra claves API en archivos JSONL de transcripción de sesiones.
• OpenFang (Rust): Utiliza variables de entorno referenciadas en config.toml (api_key_env = "ANTHROPIC_API_KEY"), asistente de inicialización CLI, interfaz de panel de control. Tiene una fuerte seguridad en reposo con Zeroizing<String> y bóveda de credenciales AES-256-GCM, pero no tiene ingesta segura de claves desde el chat.
• NanoClaw: Utiliza variables de entorno ANTHROPIC_API_KEY o CLAUDE_CODE_OAUTH_TOKEN configuradas durante la habilidad /setup. En el modo Docker Sandbox, el sistema basado en proxy sustituye valores centinela, pero aún no hay tránsito cifrado de claves a través de mensajería.
• PicoClaw: Utiliza ~/.picoclaw/config.json con anulaciones de variables de entorno (PICOCLAW_PROVIDERS_*). El issue #972 documenta la filtración de credenciales de subagentes cuando la lógica de autocuración lee config.json y hace eco de claves API sin procesar en los registros de chat.

El problema fundamental, como afirma el issue #7916 de OpenClaw: "las claves deben estar en texto plano para que [el sistema] opere". Los gestores de secretos externos posponen la exposición en texto plano al tiempo de ejecución, pero nadie cifra el tránsito.

Detalles técnicos

Los fragmentos de URL funcionan porque según RFC 3986, # y todo lo que sigue nunca se envía al servidor en solicitudes HTTP, no se incluye en el encabezado Referer, no es registrado por CDN/proxies/servidores web, y se procesa completamente en el lado del cliente. GitHub Pages recibe GET /setup sin ningún conocimiento del OTK.

El manejador de mensajes en main.rs tiene un orden de prioridad estricto: los comandos de claves y los blobs cifrados se emparejan primero y regresan inmediatamente, nunca pasando al agente. El LLM solo recibe mensajes que pasan todas las verificaciones. En el lado de salida, un SecretCensorChannel envuelve cada mensaje saliente.