SkyClaw добавляет зашифрованную настройку API-ключей через чат для ИИ-агентов.

SkyClaw представляет метод безопасной настройки API-ключей через чат-интерфейсы без их раскрытия LLM или мессенджерам. Система решает проблему неудобства традиционных самодостаточных агентов, которые требуют доступа по SSH, редактирования конфигурационных файлов и перезапуска служб для смены ключей.

Как это работает

Решение имеет два уровня безопасности:

• Уровень 1 — Системный перехват: Ключевые команды (/addkey, /keys, /removekey) и зашифрованные блоки (начинающиеся с enc:v1:) перехватываются в main.rs до того, как сообщения достигнут агента. Rust-процесс расшифровывает, проверяет и сохраняет в хранилище, полностью исключая LLM из операций с учетными данными.
• Уровень 2 — OTK-шифрование: Использует фрагменты URL (#), которые никогда не отправляются на серверы согласно RFC 3986. Процесс: бот отправляет setup.page/#one-time-256bit-key, браузер локально шифрует API-ключ с помощью AES-256-GCM через WebCrypto, пользователь вставляет зашифрованный блок обратно в чат, бот расшифровывает на системном уровне, сохраняет, а затем уничтожает одноразовый ключ.

Результаты безопасности

• Мессенджеры видят только зашифрованный текст (бесполезный без OTK)
• LLM ничего не видит (перехватывается до цикла агента)
• GitHub Pages видит только GET /setup
• Работает на любой платформе, которая отправляет/получает текст

Сравнение с другими проектами

Источник выявляет ограничения текущих решений:

• OpenClaw: Использует конфигурационные файлы, переменные окружения, CLI-мастер, опциональные внешние менеджеры секретов. Проблема GitHub #11829 гласит: "OpenClaw в настоящее время имеет несколько векторов, через которые API-ключи могут попасть к LLM или быть раскрыты в чате." Проблема #19137 документирует утечку API-ключей через config.get в JSONL-файлы транскриптов сессий.
• OpenFang (Rust): Использует переменные окружения, указанные в config.toml (api_key_env = "ANTHROPIC_API_KEY"), CLI-мастер инициализации, интерфейс панели управления. Имеет сильную безопасность при хранении с Zeroizing<String> и хранилищем учетных данных AES-256-GCM, но не имеет безопасного получения ключей из чата.
• NanoClaw: Использует переменные окружения ANTHROPIC_API_KEY или CLAUDE_CODE_OAUTH_TOKEN, установленные во время навыка /setup. В режиме Docker Sandbox система на основе прокси заменяет контрольные значения, но все еще нет зашифрованной передачи ключей через мессенджеры.
• PicoClaw: Использует ~/.picoclaw/config.json с переопределением переменных окружения (PICOCLAW_PROVIDERS_*). Проблема #972 документирует утечку учетных данных суб-агентов, когда логика самовосстановления читает config.json и выводит сырые API-ключи в журналы чатов.

Фундаментальная проблема, как указано в проблеме OpenClaw #7916: "ключи должны быть в открытом тексте для работы [системы]." Внешние менеджеры секретов откладывают раскрытие открытого текста до времени выполнения, но никто не шифрует передачу.

Технические детали

Фрагменты URL работают, потому что согласно RFC 3986, # и все после него никогда не отправляются на сервер в HTTP-запросах, не включаются в заголовок Referer, не логируются CDN/прокси/веб-серверами и обрабатываются полностью на стороне клиента. GitHub Pages получает GET /setup без какого-либо знания об OTK.

Обработчик сообщений в main.rs имеет строгий порядок приоритетов: ключевые команды и зашифрованные блоки сопоставляются первыми и возвращаются немедленно, никогда не передаваясь агенту. LLM получает только сообщения, прошедшие все проверки. На стороне вывода каждый исходящий сообщение оборачивается в SecretCensorChannel.