13. Безопасность

Астра ИИ [КОД] даёт AI доступ к вашему коду и системе. Без защиты — это рискованно: модель может ошибиться, запустить плохую команду, переписать важный файл. Поэтому встроена многоуровневая модель безопасности.

Этот документ — что это значит для вас как пользователя: что вы видите, что делать, когда что-то спрашивает.

Три уровня защиты

1. Песочница — изоляция выполнения. Команды Астра ИИ [КОД] не могут писать туда, куда не должны.
2. Подтверждения — запросы вашего разрешения на рискованное.
3. Credentials и окружение — защищённое хранение managed-сессии и фильтрация секретов из shell.

Песочница: что Астра ИИ [КОД] может и не может делать

Три режима:

read-only

Самый строгий. Астра ИИ [КОД] может читать любые файлы, но писать — никуда. Сеть отключена. - Полезно: проанализировать код, дать рекомендации, без побочных эффектов. - Команды типа cargo build или git commit не сработают — нет записи.

workspace-write (по умолчанию, рекомендуется)

Средний. Читать — везде. Писать — только в: - Рабочую директорию проекта. - /tmp и $TMPDIR.

Стандартная restricted-политика дополнительно исключает из записи служебные пути верхнего уровня: - .git/; - .astracode/; - .agents/.

Это защита по умолчанию для песочницы в режиме restricted, а не безусловная системная гарантия. Явное правило записи может её переопределить; в danger-full-access она не действует.

Сеть — отдельный флаг: network_access = false по умолчанию (рекомендуется).

danger-full-access

Отключает песочницу. Астра ИИ [КОД] может делать что угодно: писать в /etc, удалять /usr, ходить в любые сети.

Не используйте, кроме экстраординарных случаев. И не подтверждайте Allow always на опасное.

Где увидеть текущий режим

В строке состояния — workspace-write / read-only / danger-full-access.

Или:

/status

Сменить режим

# ~/.astracode/config.toml
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
writable_roots = ["/home/me/work"]
network_access = false

После — перезапуск Астра ИИ [КОД].

Подтверждения: когда вас спросят

Политики:

untrusted

Известные безопасные команды, которые только читают файлы, могут выполняться автоматически. Остальные действия требуют подтверждения. Режим безопаснее, но заметно медленнее стандартного.

on-request (по умолчанию, рекомендуется)

Действия, разрешённые текущей песочницей, обычно выполняются автоматически. Модель запрашивает подтверждение, когда ей нужны дополнительные права — например, запись вне рабочей области или доступ к сети. Это режим по умолчанию для интерактивных запусков.

granular

Отдельная политика (approval_policy = "granular"), а не подрежим untrusted. Тонкая настройка по категориям команд: разрешаете/запрещаете целые классы действий вместо поштучного подтверждения.

never

Никогда не спрашивает — модели полностью развязаны руки. Подходит для неинтерактивных/скриптовых запусков. Failures сразу возвращаются модели без эскалации к вам.

on-failure (авто-апрув в песочнице, эскалация при сбое) помечен DEPRECATED и не используется по умолчанию. Для интерактивной работы выбирайте on-request, для скриптов — never.

Как сменить

/approvals

(/approvals — это алиас /permissions; обе команды работают и открывают один и тот же экран.)

Появится список пресетов:

• Read Only (read-only) — только чтение; правки требуют подтверждения. Политика on-request.
• Default (auto) — чтение и правка файлов в рабочей области, запуск команд; правки вне рабочей области требуют подтверждения. Политика on-request. (Это же иногда называют «Agent mode» — отдельного пресета с таким именем нет.)
• Full Access (full-access) — правки вне рабочей области без вопросов. Политика never. Требует дополнительного confirmation.

«Auto-review» — не отдельный пресет, а сочетание: любая политика + approvals_reviewer = "guardian_subagent" (алиас auto_review), когда запросы подтверждения (эскалации из песочницы, сеть, MCP) дополнительно ревьюит subagent.

Или вручную:

approval_policy = "on-request"
approvals_reviewer = "user"     # user — спрашивают вас; guardian_subagent — subagent-ревьюер (алиас auto_review также принимается)

Диалог подтверждения: что вы видите

Когда требуется ваше разрешение:

─────────────────────────────────────────
  Tool wants to: run a shell command
  --------------------------------------
  Command: cargo test --workspace
  Workdir: /home/me/work/myproject

  [y] allow once   [a] allow always   [p] approve for prefix
  [d] deny         [n]/Esc decline    [o] open thread   [c] cancel
─────────────────────────────────────────

Что выбрать

Allow always создаёт правило на текущую сессию — следующие такие же запросы не спросят. Approve for prefix сохраняет правило по префиксу команды (например, для cargo test ...). Не подтверждайте эти варианты на рискованных действиях.

Шифрование передаваемых данных

Когда Астра ИИ [КОД] отправляет код модели для генерации или анализа, запрос идёт через управляемую инфраструктуру AstraHub по HTTPS. Доступ к моделям и правила обработки данных определяет организация.

Внимание: фрагменты кода, которые требуются модели, покидают локальный процесс Астра ИИ [КОД]. Для конфиденциальных репозиториев соблюдайте корпоративную политику и уточняйте у администратора AstraHub допустимые модели и режимы хранения данных.

См. 06-model-and-providers.md.

Audit log

Решения о подтверждении и эскалации логируются Астра ИИ [КОД]. Лог-файл:

~/.astracode/log/astracode-tui.log

Там можно найти записи о том, какие действия были разрешены/отклонены и какие запросы эскалировались. Конкретный формат строк лога зависит от версии и может меняться — ориентируйтесь на общий поток записей о подтверждениях и эскалациях, а не на фиксированный шаблон строки.

Полезно если хотите аудитировать, что Астра ИИ [КОД] делал на вашей системе.

Дополнительные защиты

shell_environment_policy

Фильтрация переменных среды для команд:

[shell_environment_policy]
inherit = "core"                       # core | all | none
ignore_default_excludes = false        # false → автоматически фильтровать *KEY*/*SECRET*/*TOKEN*
exclude = ["AWS_*", "*_API_KEY", "GITHUB_TOKEN"]
set = { CI = "1" }                     # явно задать переменные
include_only = ["PATH", "HOME", "USER"]  # оставить только совпадающее

Защищает от случайной утечки секретов из вашей shell в команды, которые модель запускает. inherit выбирает стартовый набор (core — только базовые вроде HOME/PATH/USER; all — всё; none — ничего), дальше работают exclude/include_only/set.

/sandbox-add-read-dir

Если в текущей сессии модели нужен доступ к директории вне обычной зоны (например, для чтения чего-то из /opt):

Только для Windows. На macOS/Linux команда недоступна (/help её не показывает). Там расширяйте зону через writable_roots/sandbox_workspace_write в конфиге.

/sandbox-add-read-dir /opt/proprietary-data

Только на эту сессию. Не сохраняется.

Защищённые пути

В стандартной restricted-политике workspace-write служебные директории верхнего уровня .git/, .astracode/ и .agents/ исключаются из доступных для записи путей.

Это правило действует только пока активна песочница в режиме restricted и не задано более явное разрешение на запись. В danger-full-access песочница отключена, поэтому эти пути не имеют отдельной hard-защиты. Подтверждение также не превращает их в безусловно защищённые системные области.

strict_workspace — жёсткая граница рабочей области

Опциональный fail-closed режим: strict_workspace = true в config.toml или флаг --strict-workspace. В отличие от режимов песочницы выше, здесь корень рабочей области фиксируется один раз при старте — и логический путь, и то, во что он реально резолвится на диске. Если путь недоступен или не резолвится — Астра ИИ [КОД] откажется запускаться.

Требует managed permission profile и доступную песочницу ОС — если платформенная песочница недоступна, включить режим нельзя.

Что меняется: - писать во временные директории и в root памяти вне зафиксированной рабочей области нельзя — эти пути убираются из эффективной политики; - переопределить permission profile или политику песочницы на уровне хода нельзя; - смена рабочей директории за пределы зафиксированного root'а отклоняется; - для git worktree общий .git (HEAD, index, config, hooks, метаданные соседних worktree) защищён — доступна только собственная директория метаданных текущего worktree; родительский checkout вне границы; - локальные stdio MCP-серверы запускаются только если их cwd — внутри зафиксированного root'а.

Command hooks (см. Хуки команд) и legacy notify — исключение: это доверенный policy-код, а не инструменты агента в песочнице, поэтому PreToolUse по-прежнему может применять политику, а SessionEnd — писать во внешние системы за пределами рабочей области.

Граница проверяется по пути: новый symlink, ведущий за пределы рабочей области, будет отклонён. Но hardlink, который уже существовал и внутри, и снаружи до включения режима, — это тот же inode, и гарантия strict_workspace на него не распространяется.

Что НЕ защищено

Песочница и подтверждения — defense in depth, не абсолютная защита. Они НЕ спасают от:

• Социальной инженерии — если вы жмёте Allow always подряд, ничего не поможет.
• Логически правильных, но нежелательных действий — модель может сделать «правильную» правку, которая ломает вам что-то непредвиденно.
• Уязвимости в bwrap/seatbelt — они активно патчатся, но zero-day возможны.
• Компрометации модельного сервиса — вредоносный ответ может содержать инъекции.

Для критичных систем — запускайте Астра ИИ [КОД] на изолированной машине или в контейнере.

Threat model

От чего Астра ИИ [КОД] защищает:

✓ Случайное rm -rf / от модели.
✓ Случайная передача многих секретов окружения в child-процессы при стандартной фильтрации. ✓ Блокировка записи в .git при стандартной restricted-политике. ✓ Сетевые запросы из песочницы в network_access = false.
✓ Блокировка перезаписи настроек Астра ИИ [КОД] при стандартной restricted-политике.

От чего НЕ защищает:

✗ Сознательно вредоносная модель.
✗ Эксплойты провайдеров песочницы.
✗ Атаки по сторонним каналам (timing, кэширование).
✗ Социальная инженерия в диалогах подтверждения.

Хорошие привычки

✓ workspace-write + on-request — для повседневной работы.
✓ /approvals перед опасным проектом.
✓ network_access = false если задача без сети.
✓ Не жмите Allow always на всё подряд — читайте диалог.
✓ /sandbox-add-read-dir (Windows) для разовых исключений вместо смены глобального режима.
✓ Проверьте корпоративный способ восстановления доступа перед переустановкой OS. ✗ Не отключайте песочницу в чужих проектах.
✗ Не запускайте astracode от root — большие потери при ошибке.
✗ Не делитесь rollout'ами без просмотра — там ваши промпты и код.

Если что-то пошло не так

Астра ИИ [КОД] выполнила нежелательное действие

• Если изменился файл — git diff покажет. git checkout -- <file> откатит.
• Если запустилась долгая команда — Ctrl-C остановит её.
• Если уже committed — git reset HEAD~1 (если не запушено).

Подозреваете компрометацию

1. Остановите текущий ход и выйдите из Астра ИИ [КОД].
2. Выполните astracode logout, чтобы удалить локальную managed-сессию.
3. Сообщите администратору AstraHub время и обстоятельства инцидента, чтобы при необходимости отозвать корпоративную сессию.
4. Перед удалением локальных сессий или памяти сохраните нужные логи и согласуйте очистку с владельцем данных.

Дополнительно

• /help approvals — справка про режимы подтверждения.
• /help sandbox-add-read-dir — справка по дополнительным правам.