0.4.11
Поиск по документации… ⌘K
13 · Руководство пользователя

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

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

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

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

  1. Sandbox — изоляция выполнения. Команды AstraCode не могут писать туда, куда не должны.
  2. Approvals — запросы вашего разрешения на рискованное.
  3. Secrets — шифрование ваших API-ключей.

Sandbox: что AstraCode может и не может делать

Три режима:

read-only

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

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

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

Но даже в проекте защищены: - .git/ — никогда. - .astracode/ — никогда. - .agents/ — никогда.

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

danger-full-access

Отключает sandbox. AstraCode может делать что угодно: писать в /etc, удалять /usr, ходить в любые сети.

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

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

В status line — workspace-write / read-only / danger-full-access.

Или:

text
/status

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

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

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

После — перезапуск AstraCode.

Approvals: когда вас спросят

Политики:

untrusted

Каждое действие требует подтверждения. Очень безопасно, очень медленно. Подходит, если не доверяете модели вообще.

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

Модель сама решает, когда спросить вас. Большинство безопасных команд (чтение файлов) выполняется автоматически, остальное — через approval-диалог. Дефолт для интерактивных запусков.

granular

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

never

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

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

Как сменить

text
/approvals

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

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

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

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

Или вручную:

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

Approval-диалог: что вы видите

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

text
─────────────────────────────────────────
  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
─────────────────────────────────────────

Что выбрать

Клавиша Решение Когда
y Allow once Безопасно, но именно в этот раз
a Allow always (for session) Безопасно, и я доверяю это в текущей сессии
p Approve for prefix Доверяю все команды с таким же префиксом (правило сохраняется на сессию)
d Deny Не выполнять, но продолжить разговор
n / Esc Decline Отклонить запрос
o Open thread Открыть ветку/контекст действия для разбора
c Cancel Отменить диалог

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

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

Когда AstraCode отправляет ваш код в LLM (для генерации/анализа): - HTTPS к провайдеру (TLS). - Authorization через Bearer-токен. - Кастомные CA — ASTRACODE_CA_CERTIFICATE.

Внимание: содержимое запросов попадает на серверы провайдера (OpenAI / Anthropic). Их политики хранения данных — на их сайтах.

Если работаете с конфиденциальным кодом — рассмотрите: - Локальный LLM (vLLM, llama.cpp, Ollama). - On-prem provider вашей компании.

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

Audit log

Approval-решения и эскалации логируются AstraCode. Лог-файл:

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

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

Полезно если хотите аудитировать, что AstraCode делал на вашей системе.

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

shell_environment_policy

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

toml
[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 в конфиге.

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

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

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

Даже в workspace-write или danger-full-access есть системные защиты:

  • .git/ — не пишется (защита git-истории).
  • .astracode/ — не пишется (защита настроек AstraCode).
  • .agents/ — не пишется (legacy от codex).

Это «hard» защиты — sandbox их применит даже если approval разрешит.

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

Sandbox и approvals — defense in depth, не абсолютная защита. Они НЕ спасают от:

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

Для критичных систем — запускайте AstraCode на изолированной машине или в контейнере.

Threat model

От чего AstraCode защищает:

✓ Случайное rm -rf / от модели.
✓ Утечка API-ключей через child-процессы.
✓ Запись в .git без подтверждения.
✓ Сетевые запросы из sandbox в network_access = false.
✓ Перезапись настроек AstraCode.

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

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

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

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

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

AstraCode сделал что-то нежелательное

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

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

bash
# Стереть секреты
rm -rf ~/.astracode/secrets

# Стереть rollouts (могут содержать промпты)
rm -rf ~/.astracode/sessions

# Стереть память
rm -rf ~/.astracode/memories

И отзовите API-ключи у провайдеров (через их dashboards).

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

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