Управляемая область

Управляемая область позволяет администратору установить базовый набор конфигурации и секретов, который обычный (не root) пользователь не может переопределить. Она предназначена для развертываний в парках/организациях, где IT-отделу необходимо зафиксировать, например, провайдера модели, общий базовый URL API или security.redact_secrets: true для всех пользователей на машине.

Когда управляемая область присутствует, указанные в ней значения имеют приоритет над ~/.vibeos/config.yaml, ~/.vibeos/.env пользователя и даже над переменными окружения оболочки — но только для тех ключей, которые она фиксирует. Все остальное остается полностью под контролем пользователя.

Отличие от установки, заблокированной менеджером пакетов

Установка, управляемая менеджером пакетов (декларативный дистрибутив / формула), блокирует все изменения конфигурации и требует использования менеджера пакетов. Управляемая область — это отдельный механизм: она внедряет конкретные неизменяемые значения на уровне отдельных ключей, а не блокирует всю конфигурацию целиком. Эти два механизма независимы и могут сосуществовать.

Где она находится

Управляемая область считывается из системной директории, по умолчанию /etc/vibeos:

/etc/vibeos/
├── config.yaml     # управляемый слой конфигурации (имеет приоритет над ~/.vibeos/config.yaml)
└── .env            # управляемый слой переменных окружения (имеет приоритет над ~/.vibeos/.env + оболочка)

Директория и файлы принадлежат root (режим директории 0755, файлов 0644): читать может каждый, записывать — только администратор. Именно эти права доступа к файловой системе являются механизмом принуждения — обычный пользователь может читать управляемые файлы, но не может их редактировать.

Любой из файлов является опциональным. Отсутствие управляемой директории или файла означает «нет управляемой области», и конфигурация разрешается точно так же, как и без этой функции.

Перемещение директории

Расположение можно изменить с помощью переменной окружения VIBEOS_MANAGED_DIR (для контейнеров или развертываний не в /etc). Это параметр пути развертывания/загрузки — как VIBEOS_HOME — устанавливаемый тем же администратором, который владеет управляемыми файлами. Он никогда не сохраняется в какой-либо .env файл VibeOS.

# Указать управляемую область в пользовательской директории (устанавливается IT / развертыванием, а не пользователем)
export VIBEOS_MANAGED_DIR=/opt/org/vibeos-policy

предупреждение

Пользователь, который может установить VIBEOS_MANAGED_DIR, может перенаправить управляемую область в директорию под своим контролем, тем самым обойдя её. В реальном развертывании эта переменная должна быть фиксирована администратором (например, встроена в служебный юнит / образ контейнера), а не оставлена изменяемой пользователем. vibeos doctor сообщает фактическую управляемую директорию, так что перенаправление будет видно.

Приоритет

Для ключей, указанных в управляемом слое, порядок следующий (наивысший приоритет):

Уровень	config.yaml	.env
1	/etc/vibeos/config.yaml (управляемый)	/etc/vibeos/.env (управляемый)
2	~/.vibeos/config.yaml (пользовательский)	~/.vibeos/.env (пользовательский)
3	Встроенные значения по умолчанию	Существующее окружение оболочки

Слияние происходит на уровне листьев: фиксация model.default не замораживает остальную часть model.*. Управляемый config.yaml вида:

model:
  default: org/standard-model

принудительно устанавливает model.default для каждого пользователя, оставляя model.fallback (и все остальные ключи) под контролем пользователя.

Примечание о приоритете

Для фиксируемых ключей управляемая область намеренно имеет приоритет даже над окружением оболочки — иначе она не была бы «управляемой». Это единственное место, где инвертируется обычное правило «переменная окружения переопределяет config.yaml», и применяется оно только к конкретным ключам, указанным в управляемом слое.

Просмотр управляемых значений

vibeos config        # показывает заголовок с указанием управляемого источника + фиксированные ключи
vibeos doctor        # сообщает разрешенную управляемую директорию + количество фиксированных ключей

При попытке изменить управляемое значение VibeOS отказывает и указывает источник:

$ vibeos config set model.default my/model
Невозможно установить 'model.default': он управляется вашим администратором
(/etc/vibeos/config.yaml) и не может быть изменен.

То же самое относится к управляемым секретам — vibeos config set / setup не запишет пользовательское значение для ключа переменной окружения, зафиксированного управляемым .env.

Настройка управляемой области (для администраторов)

sudo mkdir -p /etc/vibeos

# Зафиксировать некоторые значения конфигурации для всех пользователей на этой машине
sudo tee /etc/vibeos/config.yaml >/dev/null <<'YAML'
model:
  provider: nous
security:
  redact_secrets: true
YAML

# Опционально зафиксировать общее, нечувствительное значение переменной окружения
sudo tee /etc/vibeos/.env >/dev/null <<'ENV'
OPENAI_API_BASE=https://inference.example.com/v1
ENV

sudo chmod 0755 /etc/vibeos
sudo chmod 0644 /etc/vibeos/config.yaml /etc/vibeos/.env

Изменения вступают в силу при следующем запуске VibeOS (некорректный управляемый файл логируется с ошибкой и игнорируется — он никогда не блокирует запуск, но администратору следует проверить vibeos doctor, чтобы убедиться, что политика применяется).

Модель безопасности и ограничения (v1)

• Принуждение осуществляется только через права доступа к файловой системе. Если пользователь имеет права на запись в управляемую директорию (или запускает VibeOS от root), управляемая область носит рекомендательный характер.
• Управляемый .env доступен для чтения всем (0644), поэтому любой локальный пользователь может прочитать секреты, переданные через него. Используйте его для общих, нечувствительных значений (базовый URL API организации, значения по умолчанию для функций), а не для высокочувствительных секретов.
• Собственные инструменты агента не имеют жесткой блокировки от управляемого значения переменной окружения. Управляемая переменная окружения применяется при запуске, но ничто не мешает агенту установить другое значение в своем собственном подпроцессе оболочки. v1 — это граница удобства управления для обычного пользователя, а не необходная песочница.

Следующие возможности намеренно выходят за рамки v1 и могут появиться позже:

• Жесткая граница, которую сам агент не может обойти.
• Встроенные управляемые расположения на macOS и Windows (v1 ориентирована в первую очередь на Linux/POSIX).
• Директории фрагментов с подключаемыми файлами (managed.d/) для многоуровневой политики.
• Подписанные / проверяемые на целостность управляемые файлы.
• Доставка через удаленное управление устройствами (MDM).
• Более строгие (групповые) права доступа для управляемых секретов.