SkyClaw Adiciona Configuração de Chave de API Baseada em Chat Criptografado para Agentes de IA

O SkyClaw introduz um método para configurar chaves de API de forma segura por meio de interfaces de chat sem expô-las aos LLMs ou às plataformas de mensagens. O sistema aborda o atrito no fluxo de trabalho dos agentes auto-hospedados tradicionais, que exigem acesso SSH, edição de arquivos de configuração e reinicialização de serviços para alterar chaves.

Como Funciona

A solução possui duas camadas de segurança:

• Camada 1 — Interceptação do sistema: Comandos de chave (/addkey, /keys, /removekey) e blobs criptografados (iniciando com enc:v1:) são capturados em main.rs antes que as mensagens cheguem ao agente. O processo em Rust descriptografa, valida e salva no cofre, mantendo o LLM completamente fora das operações de credenciais.
• Camada 2 — Criptografia OTK (chave única): Usa fragmentos de URL (#) que nunca são enviados aos servidores, conforme o RFC 3986. O fluxo: o bot envia setup.page/#one-time-256bit-key, o navegador criptografa a chave de API localmente usando AES-256-GCM com WebCrypto, o usuário cola o blob criptografado de volta no chat, o bot descriptografa na camada do sistema e salva, depois destrói a chave única.

Resultados de Segurança

• As plataformas de mensagens veem apenas texto cifrado (inútil sem a OTK)
• O LLM não vê nada (interceptado antes do loop do agente)
• O GitHub Pages vê apenas GET /setup
• Funciona em qualquer plataforma que envia/recebe texto

Comparação com Outros Projetos

A fonte identifica limitações nas soluções atuais:

• OpenClaw: Usa arquivos de configuração, variáveis de ambiente, assistente de linha de comando, gerenciadores de segredos externos opcionais. A issue #11829 do GitHub afirma: "O OpenClaw atualmente tem múltiplos vetores onde as chaves de API podem vazar para o LLM ou serem expostas no chat." A issue #19137 documenta config.get vazando chaves de API para arquivos JSONL de transcrição de sessão.
• OpenFang (Rust): Usa variáveis de ambiente referenciadas em config.toml (api_key_env = "ANTHROPIC_API_KEY"), assistente de inicialização CLI, interface de painel. Tem forte segurança em repouso com Zeroizing<String> e cofre de credenciais AES-256-GCM, mas sem ingestão segura de chaves a partir do chat.
• NanoClaw: Usa variáveis de ambiente ANTHROPIC_API_KEY ou CLAUDE_CODE_OAUTH_TOKEN definidas durante a habilidade /setup. No modo Docker Sandbox, o sistema baseado em proxy substitui valores sentinela, mas ainda sem trânsito criptografado de chaves por mensagens.
• PicoClaw: Usa ~/.picoclaw/config.json com substituições por variáveis de ambiente (PICOCLAW_PROVIDERS_*). A issue #972 documenta vazamento de credenciais de subagente quando a lógica de autocuração lê o config.json e ecoa chaves de API brutas nos logs de chat.

O problema fundamental, como afirma a issue #7916 do OpenClaw: "as chaves devem estar em texto puro para [o sistema] operar." Gerenciadores de segredos externos adiam a exposição em texto puro para o tempo de execução, mas ninguém criptografa o trânsito.

Detalhes Técnicos

Os fragmentos de URL funcionam porque, conforme o RFC 3986, o # e tudo depois dele nunca são enviados ao servidor em requisições HTTP, não são incluídos no cabeçalho Referer, não são registrados por CDNs/proxies/servidores web e são processados inteiramente no lado do cliente. O GitHub Pages recebe GET /setup sem nenhum conhecimento da OTK.

O manipulador de mensagens em main.rs tem uma ordem de prioridade estrita: comandos de chave e blobs criptografados são correspondidos primeiro e retornam imediatamente, nunca passando para o agente. O LLM só recebe mensagens que passam em todas as verificações. No lado da saída, um SecretCensorChannel envolve cada mensagem de saída.