Безопасность
У VibeOS defense-in-depth: несколько независимых границ. На этой странице — все они: от approval опасных команд до изоляции контейнера и авторизации пользователей в мессенджерах.
Обзор
Семь слоёв:
- Авторизация пользователя — кто может писать агенту (allowlists, DM pairing)
- Одобрение опасных команд — human-in-the-loop перед деструктивными операциями
- Изоляция контейнера — Docker / Singularity / Modal с hardened-настройками
- Фильтрация credentials MCP — изоляция env для MCP-подпроцессов
- Сканирование контекстных файлов — детект prompt injection в файлах проекта
- Межсессионная изоляция — сессии не видят данные друг друга; пути cron hardened против path traversal
- Санитизация ввода —
cwdв terminal backends проверяется по allowlist, чтобы не допустить shell injection
Одобрение опасных команд
Перед выполнением команды VibeOS сверяет её с curated-списком опасных паттернов. При совпадении нужно явное одобрение пользователя.
Режимы одобрения
Три режима через approvals.mode в ~/.vibeos/config.yaml:
approvals:
mode: manual # manual | smart | off
timeout: 60 # seconds to wait for user response (default: 60)
cron_mode: deny # deny | approve — what cron jobs do when they hit a dangerous command
mcp_reload_confirm: true # /reload-mcp asks before invalidating the MCP tool cache
destructive_slash_confirm: true # /clear, /new, /reset, /undo prompt before discarding state
Полный комплект ключей:
| Ключ | По умолчанию | Что он контролирует |
|---|---|---|
mode | manual | Политика одобрения опасных команд оболочки — см. таблицу ниже. |
timeout | 60 | Секунды, в течение которых VibeOS ожидает ответа об утверждении, прежде чем истечет время ожидания. |
cron_mode | deny | Как задания cron ведут себя бездумно, когда вызывают опасную командную строку. deny блокирует команду (агент должен найти другой путь); approve автоматически одобряет все в контексте cron. |
mcp_reload_confirm | true | Если это правда, /reload-mcp запрашивает перед пересборкой набора инструментов MCP. Перестроение делает недействительным кэш приглашений поставщика (схемы инструментов находятся в системном приглашении), поэтому следующее сообщение повторно отправляет полные входные токены. Пользователи, которые нажимают Всегда одобрять, меняют этот ключ на false. |
destructive_slash_confirm | true | Если установлено значение true, деструктивные команды сеанса (/clear, /new, /reset, /undo) выдают запрос перед отменой состояния разговора. Диалоговое окно с тремя опциями (Однократное одобрение/Всегда утверждать/Отмена), направляемое через встроенные кнопки «да/нет» в Telegram, Discord и Slack; резервный текст в другом месте. Пользователи, которые нажимают Всегда одобрять, меняют этот ключ на false. TUI использует собственное модальное наложение (настройте VIBEOS_TUI_NO_CONFIRM=1, чтобы отключить его). |
| Режим | Поведение |
|---|---|
| ручной (по умолчанию) | Всегда запрашивать у пользователя подтверждение опасных команд |
| умный | Используйте вспомогательный LLM для оценки риска. Команды с низким уровнем риска (например, python -c "print('hello')") утверждаются автоматически. Действительно опасные команды автоматически отклоняются. Сомнительные случаи переходят к подсказке вручную. |
| выкл. | Отключите все проверки одобрения — это эквивалентно запуску с --yolo. Все команды выполняются без подсказок. |
Настройка approvals.mode: off отключает все подсказки безопасности. Используйте только в доверенных средах (CI/CD, контейнеры и т. д.).
Режим ЙОЛО
Режим YOLO обходит все запросы на одобрение опасных команд для текущего сеанса. Его можно активировать тремя способами:
- Флаг CLI: начать сеанс с помощью
vibeos --yoloилиvibeos chat --yolo. - Slash-команда:
/yoloв сессии включает или выключает режим. - Переменная среды: установите
VIBEOS_YOLO_MODE=1.
Команда /yolo представляет собой переключатель — каждое использование включает или выключает режим:
> /yolo
⚡ YOLO mode ON — all commands auto-approved. Use with caution.
> /yolo
⚠ YOLO mode OFF — dangerous commands will require approval.
Режим YOLO доступен как в сеансах CLI, так и в сеансах шлюза. Внутри он устанавливает переменную среды VIBEOS_YOLO_MODE, которая проверяется перед каждым выполнением команды.
Когда YOLO активен, VibeOS показывает два постоянных визуальных напоминания, поэтому трудно забыть, что запросы на одобрение игнорируются:
- Красная строка-баннер в начале сеанса, когда YOLO уже активен:
⚠ YOLO mode — all approval prompts bypassed. Скрывается, когда YOLO выключен, поэтому баннер по умолчанию остается незагроможденным. - Фрагмент
⚠ YOLOв строке состояния на всех уровнях ширины, обновляемый в реальном времени при включении или выключении YOLO (рендеринг форматированного текста и резервный вариант простого текста).
Режим YOLO отключает все проверки безопасности опасных команд для сеанса — кроме жесткого черного списка (см. ниже). Используйте только в том случае, если вы полностью доверяете генерируемым командам (например, хорошо проверенным сценариям автоматизации в одноразовых средах).
Для деструктивных сеансовых slash-команд (/clear, /new / /reset, /undo, /quit --delete — /exit --delete — псевдоним), интерфейс командной строки также запрашивает подтверждение перед их запуском. См. Команды слэша — запросы подтверждения для деструктивных команд.
Жесткий черный список (всегда на этаже)
Некоторые команды настолько катастрофичны — необратимые очистки файловой системы, форк-бомбы, прямая запись на блочные устройства — что VibeOS отказывается запускать их независимо от:
--yolo//yoloвключеноapprovals.mode: off- Задания Cron выполняются в безголовом режиме
approve. – Пользователь явно нажимает «разрешить всегда».
Черный список находится этажом ниже --yolo. Он срабатывает до того, как уровень утверждения увидит команду, и флаг переопределения отсутствует. Рассматриваемые на данный момент шаблоны (не исчерпывающие; синхронизируются с tools/approval.py::UNRECOVERABLE_BLOCKLIST):
| Узор | Почему это жестко |
|---|---|
rm -rf / и очевидные варианты | Очищает корень файловой системы |
rm -rf --no-preserve-root / | Явный вариант «да, я имею в виду root» |
:(){ :|:& };: (бомба-вилка) | Привязывает хост до перезагрузки |
mkfs.* на смонтированном корневом устройстве | Форматирует живую систему |
dd if=/dev/zero of=/dev/sd* | Обнуляет физический диск |
Передача ненадежных URL-адресов в sh на верхнем уровне rootfs | Вектор атаки с удаленным выполнением кода слишком широк, чтобы его можно было одобрить |
Если вы попадете в черный список, вызов инструмента вернет агенту пояснительную ошибку, и ничего не запустится. Если законному рабочему процессу требуется одна из этих команд (например, вы являетесь оператором конвейера очистки и переустановки), запустите ее вне агента.
Тайм-аут одобрения
При появлении опасной командной строки у пользователя есть настраиваемое время для ответа. Если в течение таймаута не получен ответ, команда по умолчанию отклонена (закрытие при сбое).
Настройте таймаут в ~/.vibeos/config.yaml:
approvals:
timeout: 60 # seconds (default: 60)
Что вызывает одобрение
Следующие шаблоны вызывают запросы на одобрение (определенные в tools/approval.py):
| Узор | Описание |
|---|---|
rm -r / rm --recursive | Рекурсивное удаление |
rm ... / | Удалить в корневом пути |
chmod 777/666 / o+w / a+w | Разрешения на запись для всех/других |
chmod --recursive с небезопасной завивкой | Рекурсивный мир/записываемый другими (длинный флаг) |
chown -R root / chown --recursive root | Рекурсивное управление root |
mkfs | Формат файловой системы |
dd if= | Копия диска |
> /dev/sd | Записать на блокировку устройства |
DROP TABLE/DATABASE | SQL ПАДЕНИЕ |
DELETE FROM (без ГДЕ) | SQL DELETE без WHERE |
TRUNCATE TABLE | SQL УСЕЧЕНИЕ |
> /etc/ | Перезаписать конфигурацию системы |
systemctl stop/restart/disable/mask | Остановить/перезапустить/отключить системные службы |
kill -9 -1 | Убить все процессы |
pkill -9 | Принудительное уничтожение процессов |
| Выкройки вилочных бомб | Вилочные бомбы |
bash -c / sh -c / zsh -c / ksh -c | Выполнение команд оболочки с помощью флага -c (включая комбинированные флаги, такие как -lc) |
python -e / perl -e / ruby -e / node -c | Выполнение скрипта через флаг -e/-c |
curl ... | sh / wget ... | sh | Перенаправить удаленный контент в оболочку |
bash <(curl ...) / sh <(wget ...) | Выполнить удаленный скрипт через подстановку процесса |
От tee до /etc/, ~/.ssh/, ~/.vibeos/.env | Перезаписать конфиденциальный файл через тройник |
> / >> до /etc/, ~/.ssh/, ~/.vibeos/.env | Перезаписать конфиденциальный файл с помощью перенаправления |
xargs rm | xargs с rm |
find -exec rm / find -delete | Находка с разрушительными действиями |
От cp/mv/install до /etc/ | Скопировать/переместить файл в конфигурацию системы |
sed -i / sed --in-place на /etc/ | Редактирование конфигурации системы на месте |
pkill/killall VibeOS/шлюз | Предотвращение самоликвидации |
gateway run с &/disown/nohup/setsid | Предотвращает запуск шлюза за пределами диспетчера служб |
Обход контейнера: при работе в серверных модулях docker, singularity, modal или daytona проверки опасных команд пропускаются, поскольку контейнер сам по себе является границей безопасности. Деструктивные команды внутри контейнера не могут нанести вред хосту.
Поток утверждения (CLI)
В интерактивном интерфейсе командной строки опасные команды отображают встроенный запрос на одобрение:
⚠️ DANGEROUS COMMAND: recursive delete
rm -rf /tmp/old-project
[o]nce | [s]ession | [a]lways | [d]eny
Choice [o/s/a/D]:
Четыре варианта:
- once — разрешить это однократное выполнение
- session — разрешить этот шаблон до конца сеанса.
- всегда — добавить в постоянный белый список (сохраняется в
config.yaml) - deny (по умолчанию) — заблокировать команду
Поток утверждения (шлюз/обмен сообщениями)
На платформах обмена сообщениями агент отправляет в чат детали опасной команды и ждет ответа пользователя:
– Ответьте да, да, одобрить, ок или идти, чтобы одобрить. – Чтобы отклонить, ответьте нет, n, отклонить или отменить.
Переменная среды VIBEOS_EXEC_ASK=1 автоматически устанавливается при запуске шлюза.
Постоянный белый список
Команды, одобренные с помощью «всегда», сохраняются в ~/.vibeos/config.yaml:
# Permanently allowed dangerous command patterns
command_allowlist:
- rm
- systemctl
Эти шаблоны загружаются при запуске и автоматически одобряются во всех последующих сеансах.
Используйте vibeos config edit, чтобы просмотреть шаблоны или удалить их из постоянного белого списка.
Авторизация пользователя (шлюз)
При запуске шлюза обмена сообщениями VibeOS контролирует, кто может взаимодействовать с ботом, через многоуровневую систему авторизации.
Порядок проверки авторизации
Метод _is_user_authorized() проверяет в следующем порядке:
- Флаг разрешения всех событий для каждой платформы (например,
DISCORD_ALLOW_ALL_USERS=true) - Список одобренных сопряжений DM (пользователи, одобренные с помощью кодов сопряжения)
- Списки разрешений для конкретной платформы (например,
TELEGRAM_ALLOWED_USERS=12345,67890) - Глобальный белый список (
GATEWAY_ALLOWED_USERS=12345,67890) - Глобальное разрешение (
GATEWAY_ALLOW_ALL_USERS=true) - По умолчанию: запретить
Белые списки платформы
Установите разрешенные идентификаторы пользователей в виде значений, разделенных запятыми, в ~/.vibeos/.env:
# Platform-specific allowlists
TELEGRAM_ALLOWED_USERS=123456789,987654321
DISCORD_ALLOWED_USERS=111222333444555666
WHATSAPP_ALLOWED_USERS=15551234567
SLACK_ALLOWED_USERS=U01ABC123
# Cross-platform allowlist (checked for all platforms)
GATEWAY_ALLOWED_USERS=123456789
# Per-platform allow-all (use with caution)
DISCORD_ALLOW_ALL_USERS=true
# Global allow-all (use with extreme caution)
GATEWAY_ALLOW_ALL_USERS=true
Если списки разрешенных не настроены и параметр GATEWAY_ALLOW_ALL_USERS не установлен, все пользователи запрещены. Шлюз регистрирует предупреждение при запуске:
No user allowlists configured. All unauthorized users will be denied.
Set GATEWAY_ALLOW_ALL_USERS=true in ~/.vibeos/.env to allow open access,
or configure platform allowlists (e.g., TELEGRAM_ALLOWED_USERS=your_id).
Система сопряжения DM
Для более гибкой авторизации VibeOS включает систему сопряжения на основе кода. Вместо того, чтобы заранее требовать идентификаторы пользователей, неизвестные пользователи получают одноразовый код сопряжения, который владелец бота утверждает через CLI.
Как это работает:
- Неизвестный пользователь отправляет боту в Директ
- Бот отвечает 8-значным кодом сопряжения.
- Владелец бота запускает
vibeos pairing approve <platform><code>` в CLI. - Пользователь навсегда одобрен для этой платформы.
Управляйте обработкой неавторизованных прямых сообщений в ~/.vibeos/config.yaml:
unauthorized_dm_behavior: pair
whatsapp:
unauthorized_dm_behavior: ignore
pairиспользуется по умолчанию для платформ DM в стиле чата. Неавторизованные DM получают ответ с кодом сопряжения.ignoreавтоматически отбрасывает неавторизованные DM.- По умолчанию для электронной почты используется
ignore, если не установленplatforms.email.unauthorized_dm_behavior: pair, поскольку входящие почтовые ящики могут содержать несвязанную непрочитанную почту. - Разделы платформы переопределяют глобальные настройки по умолчанию, поэтому вы можете продолжать соединение с Telegram, сохраняя молчание WhatsApp.
Функции безопасности (на основе рекомендаций OWASP + NIST SP 800-63-4):
| Особенность | Подробности |
|---|---|
| Формат кода | 8-значный из 32-значного однозначного алфавита (без 0/O/1/I) |
| Случайность | Криптографический (secrets.choice()) |
| Код ТТЛ | Срок действия 1 час |
| Ограничение скорости | 1 запрос на пользователя за 10 минут |
| Ожидаемый лимит | Максимум 3 ожидающих кода на платформу |
| Локаут | 5 неудачных попыток одобрения → блокировка на 1 час |
| Безопасность файлов | chmod 0600 во всех файлах данных сопряжения |
| Ведение журнала | Коды никогда не выводятся на стандартный вывод |
Сопряжение команд CLI:
# List pending and approved users
vibeos pairing list
# Approve a pairing code
vibeos pairing approve telegram ABC12DEF
# Revoke a user's access
vibeos pairing revoke telegram 123456789
# Clear all pending codes
vibeos pairing clear-pending
Хранение: Данные о сопряжении хранятся в ~/.vibeos/pairing/ с файлами JSON для каждой платформы:
{platform}-pending.json— ожидающие запросы на сопряжение{platform}-approved.json— одобренные пользователи_rate_limits.json— ограничение скорости и отслеживание блокировки
Изоляция контейнера
При использовании серверной части терминала docker VibeOS применяет строгие меры безопасности к каждому контейнеру.
Флаги безопасности Docker
Каждый контейнер запускается со следующими флагами (определенными в tools/environments/docker.py):
_BASE_SECURITY_ARGS = [
"--cap-drop", "ALL", # Drop ALL Linux capabilities
"--cap-add", "DAC_OVERRIDE", # Root can write to bind-mounted dirs
"--cap-add", "CHOWN", # Package managers need file ownership
"--cap-add", "FOWNER", # Package managers need file ownership
"--security-opt", "no-new-privileges", # Block privilege escalation
"--pids-limit", "256", # Limit process count
"--tmpfs", "/tmp:rw,nosuid,size=512m", # Size-limited /tmp
"--tmpfs", "/var/tmp:rw,noexec,nosuid,size=256m", # No-exec /var/tmp
]
SETUID/SETGID нет в базовом списке — они добавляются условно, когда контейнер запускается от имени пользователя root и точка инициализации/входа должна отказаться от привилегий (путь сброса привилегий s6). Они пропускаются, если контейнер уже запущен как --user без полномочий root. /run tmpfs также отделяется от базового списка и монтируется для каждого образа (закрепленный noexec по умолчанию, exec только для изображений с наложением s6, которые выполняются из /run).
Ограничения ресурсов
Ресурсы контейнера настраиваются в ~/.vibeos/config.yaml:
terminal:
backend: docker
docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
docker_forward_env: [] # Explicit allowlist only; empty keeps secrets out of the container
container_cpu: 1 # CPU cores
container_memory: 5120 # MB (default 5GB)
container_disk: 51200 # MB (default 50GB, requires overlay2 on XFS)
container_persistent: true # Persist filesystem across sessions
Сохранение файловой системы
- Постоянный режим (
container_persistent: true): привязка монтирует/workspaceи/rootиз~/.vibeos/sandboxes/docker/<task_id>/. - Эфемерный режим (
container_persistent: false): в качестве рабочей области используется tmpfs — при очистке все теряется.
Для развертывания рабочего шлюза используйте серверную часть docker, modal или daytona, чтобы изолировать команды агента от вашей хост-системы. Это полностью устраняет необходимость в одобрении опасного командования.
Если вы добавите имена в terminal.docker_forward_env, эти переменные намеренно вводятся в контейнер для команд терминала. Это полезно для учетных данных, специфичных для задачи, таких как GITHUB_TOKEN, но это также означает, что код, выполняющийся в контейнере, может прочитать и извлечь их.
Сравнение безопасности серверной части терминала
| Бэкэнд | Изоляция | Опасная проверка CMD | Лучшее для |
|---|---|---|---|
| местный | Нет — работает на хосте | ✅ Да | Развитие, доверенные пользователи |
| тсс | Удаленная машина | ✅ Да | Запуск на отдельном сервере |
| докер | Контейнер | ❌ Пропущено (контейнер является границей) | Производственный шлюз |
| необычность | Контейнер | ❌ Пропущено | среды HPC |
| модальный | Облачная песочница | ❌ Пропущено | Масштабируемая изоляция облака |
| дайтона | Облачная песочница | ❌ Пропущено | Постоянные облачные рабочие пространства |
Передача переменной среды
И execute_code, и terminal удаляют конфиденциальные переменные среды из дочерних процессов, чтобы предотвратить кражу учетных данных с помощью кода, сгенерированного LLM. Однако навыки, которые объявляют required_environment_variables, законно нуждаются в доступе к этим переменным.
Как это работает
Два механизма позволяют определенным переменным проходить через фильтры песочницы:
1. Передача на уровне навыка (автоматически)
Когда навык загружается (через skill_view или команду /skill) и объявляет required_environment_variables, любая из тех переменных, которые фактически установлены в среде, автоматически регистрируется как сквозная. Отсутствующие переменные (все еще находящиеся в состоянии, необходимом для установки) не регистрируются.
# In a skill's SKILL.md frontmatter
required_environment_variables:
- name: TENOR_API_KEY
prompt: Tenor API key
help: Get a key from https://developers.google.com/tenor
После загрузки этого навыка TENOR_API_KEY передается на execute_code, terminal (локальный) и удаленные серверные части (Docker, Modal) — ручная настройка не требуется.
До версии 0.5.1 forward_env в Docker была отдельной системой от прохождения навыков. Теперь они объединены — переменные окружения, объявленные навыками, автоматически пересылаются в контейнеры Docker и модальные песочницы без необходимости добавлять их в docker_forward_env вручную.
2. Передача на основе конфигурации (вручную)
Для переменных окружения, не объявленных каким-либо навыком, добавьте их в terminal.env_passthrough в config.yaml:
terminal:
env_passthrough:
- MY_CUSTOM_KEY
- ANOTHER_TOKEN
Передача файла учетных данных (токены OAuth и т. д.)
Некоторым навыкам нужны файлы (а не только переменные окружения) в песочнице — например, Google Workspace хранит токены OAuth как google_token.json в VIBEOS_HOME активного профиля. Навыки объявляют это во вступительной части:
required_credential_files:
- path: google_token.json
description: Google OAuth2 token (created by setup script)
- path: google_client_secret.json
description: Google OAuth2 client credentials
При загрузке VibeOS проверяет, существуют ли эти файлы в VIBEOS_HOME активного профиля, и регистрирует их для монтирования:
- Docker: монтирование привязки только для чтения (
-v host:container:ro) - Модальный: монтируется при создании песочницы + синхронизируется перед каждой командой (обрабатывает настройку OAuth в середине сеанса).
- Локально: никаких действий не требуется (файлы уже доступны).
Вы также можете перечислить файлы учетных данных вручную в config.yaml:
terminal:
credential_files:
- google_token.json
- my_custom_oauth_token.json
Пути указаны относительно ~/.vibeos/. Файлы монтируются в /root/.vibeos/ внутри контейнера. Этот список читается tools/credential_files.py (terminal.credential_files) — он находится в блоке terminal:, но загружается модулем credential-files, а не базовым сервером терминала, поэтому он не является частью связанного снимка DEFAULT_CONFIG.
Что фильтрует каждая песочница
| Песочница | Фильтр по умолчанию | Переопределение проходного режима |
|---|---|---|
| execute_code | Блокирует переменные, содержащие KEY, TOKEN, SECRET, PASSWORD, CREDENTIAL, PASSWD, AUTH в имени; разрешает только переменные с безопасным префиксом через | ✅ Вары Passthrough обходят обе проверки |
| терминал (локальный) | Блокирует явные переменные инфраструктуры VibeOS (ключи поставщика, токены шлюза, ключи API инструментов) | ✅ Вары Passthrough обходят черный список |
| терминал (Докер) | По умолчанию нет переменных окружения хоста | ✅ Проходные переменные + docker_forward_env, пересылаемые через -e |
| терминал (модальный режим) | По умолчанию нет хост-окружения/файлов | ✅ Файлы учетных данных смонтированы; передача env через синхронизацию |
| MCP | Блокирует все, кроме безопасных системных переменных + явно настроенных env | ❌ Не влияет на транзитную передачу (вместо этого используйте конфигурацию MCP env) |
Вопросы безопасности
- Транзит влияет только на те переменные, которые вы или ваши навыки явно объявляете — состояние безопасности по умолчанию не меняется для произвольного кода, сгенерированного LLM.
- Файлы учетных данных монтируются только для чтения в контейнеры Docker.
- Skills Guard сканирует содержимое навыков на предмет подозрительных шаблонов доступа к среде перед установкой.
- Отсутствующие/неустановленные переменные никогда не регистрируются (вы не можете слить то, чего не существует)
- Секреты инфраструктуры VibeOS (ключи API провайдера, токены шлюза) никогда не следует добавлять в
env_passthrough— у них есть специальные механизмы.
Обработка учетных данных MCP
Подпроцессы сервера MCP (Model Context Protocol) получают фильтрованную среду для предотвращения случайной утечки учетных данных.
Переменные безопасной среды
Только эти переменные передаются от хоста к подпроцессам MCP stdio:
PATH, HOME, USER, LANG, LC_ALL, TERM, SHELL, TMPDIR
Плюс любые переменные XDG_*. Все остальные переменные среды (ключи API, токены, секреты) удалены.
Переменные, явно определенные в конфигурации env сервера MCP, передаются через:
mcp_servers:
github:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_..." # Only this is passed
Редактирование учетных данных
Сообщения об ошибках от инструментов MCP обрабатываются перед возвратом в LLM. Следующие шаблоны заменяются на [REDACTED]:
- PAT GitHub (
ghp_...) - Клавиши в стиле OpenAI (
sk-...) - Токены на предъявителя
- параметры
token=,key=,API_KEY=,password=,secret=
Политика доступа к веб-сайту
Вы можете ограничить доступ агента к веб-сайтам с помощью веб-инструментов и инструментов браузера. Это полезно для предотвращения доступа агента к внутренним службам, панелям администратора или другим конфиденциальным URL-адресам.
# In ~/.vibeos/config.yaml
security:
website_blocklist:
enabled: true
domains:
- "*.internal.company.com"
- "admin.example.com"
shared_files:
- "/etc/vibeos/blocked-sites.txt"
При запросе заблокированного URL-адреса инструмент возвращает ошибку, объясняющую, что домен заблокирован политикой. Черный список применяется к web_search, web_extract, browser_navigate и всем инструментам с поддержкой URL.
Подробную информацию см. в разделе Черный список веб-сайтов в руководстве по настройке.
SSRF-защита
Все инструменты с поддержкой URL-адресов (веб-поиск, веб-извлечение, Vision, браузер) проверяют URL-адреса перед их получением, чтобы предотвратить атаки подделки запросов на стороне сервера (SSRF). К заблокированным адресам относятся:
- Частные сети (RFC 1918):
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16. - Петля:
127.0.0.0/8,::1 - Локальная ссылка:
169.254.0.0/16(включая метаданные облака в169.254.169.254) - CGNAT/общее адресное пространство (RFC 6598):
100.64.0.0/10(Tailscale, WireGuard VPN) - Имена хостов метаданных облака:
metadata.google.internal,metadata.goog. - Зарезервированные, многоадресные и неуказанные адреса
Защита SSRF всегда активна при использовании с выходом в Интернет, а сбои DNS рассматриваются как заблокированные (закрытые при сбое). Цепочки перенаправления повторно проверяются на каждом прыжке, чтобы предотвратить обходы на основе перенаправления.
Намеренное разрешение частных URL-адресов
Некоторым установкам законно необходим доступ к частному/внутреннему URL-адресу — домашние сети, которые разрешают home.arpa в пространство RFC 1918, конечные точки Ollama/llama.cpp только для локальной сети, внутренние вики-сайты, отладка облачных метаданных и тому подобное. В таких случаях предусмотрен глобальный отказ:
security:
allow_private_urls: true # default: false
При включении веб-инструменты, браузер, выборка URL-адресов Vision и загрузка мультимедиа через шлюз больше не отклоняют RFC 1918/loopback/link-local/CGNAT/адреса облачных метаданных. Это преднамеренная граница доверия — включайте ее только на компьютерах, где агент, запускающий произвольные URL-адреса, введенные из подсказки, в локальной сети, представляет собой приемлемый риск. Общедоступные шлюзы должны его отключить.
Защита подстроки хоста (которая блокирует похожие трюки домена Unicode, даже если базовый IP-адрес является общедоступным) остается включенным независимо от этого параметра.
Тирит Предварительное сканирование безопасности
VibeOS интегрирует tirith для сканирования команд на уровне содержимого перед выполнением. Тирит обнаруживает угрозы, которые пропускает только сопоставление с образцом:
- Подмена URL-адреса омографа (атаки на интернациональные домены)
- Шаблоны конвейер-интерпретатор (
curl | bash,wget | sh) - Атаки с терминальными инъекциями
Тирит автоматически устанавливается из выпусков GitHub при первом использовании с проверкой контрольной суммы SHA-256 (и проверкой происхождения cosign, если cosign доступен).
# In ~/.vibeos/config.yaml
security:
tirith_enabled: true # Enable/disable tirith scanning (default: true)
tirith_path: "tirith" # Path to tirith binary (default: PATH lookup)
tirith_timeout: 5 # Subprocess timeout in seconds
tirith_fail_open: true # Allow execution when tirith is unavailable (default: true)
Если tirith_fail_open равен true (по умолчанию), команды выполняются, если tirith не установлен или истекло время ожидания. Установите false в средах с высоким уровнем безопасности, чтобы блокировать команды, когда тирит недоступен.
Тирит поставляет готовые двоичные файлы для Linux (x86_64/aarch64) и macOS (x86_64/arm64). На платформах без предварительно созданного двоичного файла (Windows и т. д.) тирит автоматически пропускается — средства защиты сопоставления с образцом все еще работают, а интерфейс командной строки не отображает баннер «недоступно». Чтобы использовать тирит в Windows, запустите VibeOS под WSL.
Вердикт Тирита интегрируется с потоком одобрения: безопасные команды проходят, в то время как как подозрительные, так и заблокированные команды вызывают одобрение пользователя с полным выводом тирита (серьезность, заголовок, описание, более безопасные альтернативы). Пользователи могут одобрить или отклонить — по умолчанию выбран вариант «Отклонить», чтобы обеспечить безопасность автоматических сценариев.
Защита от внедрения контекстного файла
Файлы контекста (AGENTS.md, .cursorrules, SOUL.md) сканируются на предмет внедрения подсказки перед включением в системную подсказку. Сканер проверяет:
- Инструкции по игнорированию/игнорированию предыдущих инструкций.
- Скрытые HTML-комментарии с подозрительными ключевыми словами.
- Попытки прочитать секреты (
.env,credentials,.netrc) - Эксфильтрация учетных данных через
curl. - Невидимые символы Юникода (пробелы нулевой ширины, двунаправленные переопределения)
Заблокированные файлы показывают предупреждение:
[BLOCKED: AGENTS.md contained potential prompt injection (prompt_injection). Content not loaded.]
Лучшие практики для производственного развертывания
Контрольный список развертывания шлюза
- Установите явные списки разрешенных — никогда не используйте
GATEWAY_ALLOW_ALL_USERS=trueв рабочей среде. - Использовать серверную часть контейнера — установите
terminal.backend: dockerв config.yaml. - Ограничить ограничения ресурсов — установите соответствующие ограничения на ЦП, память и диск.
- Надежное хранение секретов — храните ключи API в
~/.vibeos/.envс соответствующими правами доступа к файлам. - Включить сопряжение DM — по возможности используйте коды сопряжения вместо жесткого кодирования идентификаторов пользователей.
- Просмотр списка разрешенных команд — периодически проверяйте
command_allowlistв config.yaml. - Установить
terminal.cwd— не разрешать агенту работать из конфиденциальных каталогов. - Запускать от имени пользователя без полномочий root — никогда не запускайте шлюз от имени пользователя root.
- Отслеживать журналы — проверьте
~/.vibeos/logs/на предмет попыток несанкционированного доступа. - Обновляйте — регулярно запускайте
vibeos updateдля получения обновлений безопасности.
Защита ключей API
# Set proper permissions on the .env file
chmod 600 ~/.vibeos/.env
# Keep separate keys for different services
# Never commit .env files to version control
Сетевая изоляция
Для максимальной безопасности запустите шлюз на отдельном компьютере или виртуальной машине. Установите terminal.backend: ssh в config.yaml, затем укажите сведения о хосте через переменные среды в ~/.vibeos/.env:
# ~/.vibeos/config.yaml
terminal:
backend: ssh
# ~/.vibeos/.env
TERMINAL_SSH_HOST=agent-worker.local
TERMINAL_SSH_USER=vibeos
TERMINAL_SSH_KEY=~/.ssh/vibeos_agent_key
Детали подключения SSH хранятся в .env (а не config.yaml), поэтому они не возвращаются и не передаются вместе с экспортом профиля. Благодаря этому соединения шлюза для обмена сообщениями отделены от выполнения команд агента.
Консультативная проверка цепочки поставок
VibeOS поставляется со встроенным консультативным сканером, который помечает пакеты Python в активной версии, соответствующие тщательно подобранному каталогу известных скомпрометированных версий (черви цепочки поставок, такие как отравление mistralai 2.4.6 в мае 2026 года). Реализация находится в vibeos_cli/security_advisories.py.
Как это работает:
- Баннер запуска CLI. Если какие-либо рекомендации совпадают, выводится однострочное предупреждение с указателем на
vibeos doctorдля полного исправления. vibeos doctor. Отображает каждую активную рекомендацию с указанием особенностей версии и 2–4-шаговыми инструкциями по исправлению.- Запуск шлюза. Зарегистрировано в
gateway.log; первое интерактивное сообщение получает короткий баннер оператора.
Каждая рекомендация имеет стабильный идентификатор. После того, как вы прочитали и приняли меры, вы можете отклонить это навсегда:
vibeos doctor --ack <advisory-id>
Подтверждение сохраняется в config.security.acked_advisories и выдерживает перезапуск. Старые рекомендации намеренно не удаляются из каталога — если оставить их на месте, новые установки будут предупреждены об исторически зараженных версиях, которые все еще могут кэшироваться в частном зеркале.
Сама проверка доступна только в стандартной библиотеке и запускается с одного поиска importlib.metadata.version() для каждой рекомендации, поэтому ее можно безопасно запускать при каждом запуске.
Отложенная установка дополнительных зависимостей
Многие функции (Mistral TTS, ElevenLabs, Honcho Memory, Bedrock, Slack, Matrix и т. д.) зависят от пакетов Python, которые нужны не каждому пользователю. VibeOS устанавливает их лениво при первом использовании, а не сразу в vibeos-agent[all]. Реализация находится в tools/lazy_deps.py.
Компромисс, который это исправляет:
- Хрупкость. Когда транзитивная зависимость одного дополнения становится недоступной в PyPI (помещена в карантин на наличие вредоносного ПО, выдернута, сломана загрузка), все решение
[all]завершится сбоем, и новые установки автоматически вернутся на урезанный уровень, потеряв одновременно более 10 несвязанных дополнений. Отложенная установка изолирует каждый бэкэнд, поэтому один отравленный отдел не может нарушить несвязанные функции. - Раздувание. Пользователь, который общается только с одним провайдером, больше не получает сотни пакетов, которые он никогда не будет импортировать.
Как это работает:
- Серверный модуль вызывает
ensure("feature.name")в начале пути первого импорта. - Если deps отсутствуют,
ensureпроверяетsecurity.allow_lazy_installsвconfig.yaml(по умолчаниюtrue) и запускаетpip installв области venv для спецификаций из разрешенного списка. - Если установка не удалась или пользователь отключил отложенную установку, вызов вызывает
FeatureUnavailableс фактическим stderr pip и указателем наvibeos tools.
Гарантии безопасности, предусмотренные tools/lazy_deps.py:
| Гарантия | Что это значит |
|---|---|
| Только для Venv | Устанавливает целевой sys.executable в активном венве — никогда не системный Python |
| PyPI только по имени | Спецификации принимают синтаксис "package>=1.0,<2". Никаких --index-url, git+https:// или файлов: путей — вредоносный config.yaml не может перенаправить установку |
| Белый список | По этому пути можно установить только те спецификации, которые отображаются на карте LAZY_DEPS в дереве. Опечатка в имени функции НЕ получает семантики «установить что-либо» |
| Отказаться | Установите security.allow_lazy_installs: false, чтобы полностью отключить установку во время выполнения. Полезно для сетей с ограниченным доступом или строгих мер безопасности |
| Никаких повторных попыток | Сбои проявляются как FeatureUnavailable — нет кэширования плохого состояния, нет повторных попыток |
Чтобы отключить установку во время выполнения:
# ~/.vibeos/config.yaml
security:
allow_lazy_installs: false
Если этот параметр отключен, бэкенды, которым требуются дополнительные deps, будут предлагать пользователю запустить установку вручную (pip install …) или выбрать другой бэкенд через vibeos tools.