Модель безопасности

Только исходящие соединения

Агент на машине сам открывает WebSocket-соединение к control plane (/agent/ws) с bearer-учётными данными и держит его. Control plane никогда не подключается к машине, входящие порты не нужны, машина может стоять за NAT. Учётные данные агента рождаются на самой машине при enroll по одноразовому токену и хранятся в /etc/nythronix/agent.json (на Windows — %ProgramData%\Nythronix\agent.json) с правами 0600.

Точно так же устроены ИИ-воркеры и супервизор: воркер ходит к control plane по HTTP с узким токеном, супервизор опрашивает control plane и не имеет входящих портов.

Сквозное шифрование SSH через реле

Реле позволяет одному агенту (A) достучаться до loopback-порта другого агента (B) через control plane — например, до sshd на 127.0.0.1:22. Control plane только перекладывает байты между двумя WebSocket-соединениями; аутентификация и шифрование выполняются самим SSH между клиентом и sshd, поэтому control plane не видит содержимого сессии. Реле выключено по умолчанию и включается для каждой машины отдельно (переключатель «Реле» в разделе Агенты); соединяться могут только агенты одной организации.

Агент без root: пользователь nyx-worker и sudo-политика JIT

Команды воркера (cmd.exec) агент выполняет не от себя, а через runuser под непривилегированным пользователем nyx-worker — при условии, что агент запущен от root и пользователь существует. Иначе команда выполняется под uid агента, о чём пишется предупреждение; в разделе Агенты у машины видно, «как» реально выполняются команды и есть ли доступ к docker-сокету. На Windows модели понижения привилегий пока нет.

Когда воркеру действительно нужен root, администратор выдаёт его на время (кнопка Выдать root, 15 минут — 8 часов). Control plane отправляет агенту политику, агент рендерит /etc/sudoers.d/nyx-worker, обязательно проверяет его visudo -cf и подменяет атомарно. По истечении срока грант снимается сервером, а на случай недоступности control plane агент сам держит локальный таймер и удаляет файл в назначенное время. Возможны политики none, list (перечисленные команды) и all. Каждое изменение пишется в аудит как admin.agent.sudo_policy_set.

Allowlist для cmd.exec

Сервер решает, можно ли выполнить команду воркера без человека, по положительному списку: команда запускается автоматически, только если каждая стадия конвейера — это распознанная команда чтения (ls, cat, grep, ps, df, journalctl, systemctl status, docker ps/logs, kubectl get, git log и подобные) и в ней нет перенаправлений, ;, &, подстановок $(...) и обратных кавычек. Для SQL-клиентов допускается встроенный запрос через psql -c / mysql -e, если он не содержит изменяющих ключевых слов. Всё, что не попало в список, — включая обфусцированные команды, docker exec, ssh и чтение секретов (.env, ключи, /etc/shadow, env) — требует подтверждения в канале. Обход этой проверки со стороны воркера невозможен: она выполняется на сервере до пересылки команды агенту.

Локальный override владельца машины

Владелец машины может ограничить, что control plane вправе сделать с ней, независимо от настроек в панели. Файл /etc/nythronix/agent-policy.json читается агентом при старте; control plane его не видит и изменить не может:

{
  "allow_remote_sudo": false,
  "max_sudo_policy": "list",
  "terminal_login_lock": "svc-ops"
}

• allow_remote_sudo: false — любая выдача root из панели отклоняется (отзыв всегда разрешён);
• max_sudo_policy — потолок none < list < all для присланной политики;
• terminal_login_lock — терминалы операторов всегда открываются под этим локальным пользователем.

Отсутствие файла означает отсутствие ограничений; повреждённый файл трактуется в сторону запрета удалённого sudo. Тот же принцип действует для скиллов: агент запускает только те MCP-серверы, что владелец внёс в /etc/nythronix/mcp-catalog.json (см. Скилы через MCP).

Подписанные релизы и проверка при самообновлении

Релизы агента, NX-эндпоинта и CLI подписываются ключом Ed25519 на машине сборки; публичная часть регистрируется на control plane и закрепляется в конфигурации агентов (при enroll — автоматически, при ручной установке — NYTHRONIX_TRUSTED_KEYS). Получив предложение обновления, агент скачивает бандл, сверяет SHA-256 и проверяет подпись манифеста по закреплённым ключам; несовпадение — отказ. Когда доверенных ключей нет, проверяется только SHA-256, и агент пишет об этом предупреждение. Таким образом, даже скомпрометированный control plane не сможет подсунуть машинам чужой бинарник. Подробнее о публикации — в Администрировании.

HITL и аудит для воркеров

Изменяющая команда выполняется лишь после нажатия Подтвердить оператором, у которого есть право на категорию команды (разделение обязанностей через «Апрув: категории»). Подтверждение превращается в одноразовый токен, привязанный к точному тексту команды и конкретной машине, со сроком 10 минут; сервер проверяет его перед выполнением. Токены живут только в памяти процесса: после перезапуска control plane нужно подтвердить заново. Воркер работает с узким токеном, который открывает только его каналы, его память, heartbeat и cmd-exec в его организации — админские и чужие эндпоинты отвечают 401.

Каждая команда на машине записывается в аудит (agent.cmd_exec) до отправки агенту, каждый выполненный MCP-инструмент — как agent.mcp.call, каждое решение оператора — как chat.approval.decided. Подробности — в Воркеры и каналы.

Изоляция воркеров и скиллов

Контейнеры воркеров запускает супервизор по фиксированной спецификации: --cap-drop ALL, no-new-privileges, read-only rootfs с небольшим tmpfs, лимиты памяти и CPU, без монтирования хоста. Ключи LLM внедряет супервизор из своей конфигурации — на control plane их нет. Опциональная изолированная сеть (NYX_WORKER_NETWORK + deploy/host/worker-egress.sh) с SNI-фильтром пропускает трафик воркера только к control plane и LLM. MCP-серверы скиллов работают отдельными подпроцессами под nyx-worker, с возможностью ограничить их выход в сеть списком доменов.

Что хранится на панели, а что нет

Хранится: учётные записи операторов (Argon2-хэши с pepper), учётные данные агентов и NX-эндпоинтов в хэшированном виде, желаемые состояния (sudo-политика, набор скиллов, политика обновлений), каналы, сообщения и память воркеров, релизы и публичные ключи подписи, журнал аудита, заявки на бету.

Не хранится: ключи LLM (у супервизора), приватный ключ подписи релизов (на машине сборки), локальная политика владельца машины и каталог скиллов с командами запуска (на машине), содержимое SSH-сессий через реле, а также токены подтверждения после перезапуска процесса. В SaaS-режиме NX-эндпоинты недоступны и соответствующие API отвечают 404.