Sandboxing for Agents в 2026: как ограничить blast radius, а не просто изолировать процесс

Короткая версия

У хорошего agent sandbox в 2026 обычно есть пять границ:

1. Filesystem boundary
2. Network boundary
3. Secrets boundary
4. Action boundary
5. Audit boundary

Что особенно важно

• ephemeral environment на один run или короткую сессию;
• read/write allow-list по путям;
• domain allow-list и blocked egress по умолчанию;
• отдельные approval gates для side effects;
• snapshots и trace logging без утечки чувствительных данных.

Что важнее для agent sandbox: просто контейнер или policy поверх файлов, сети и side effects?

1. Sandbox нужен для ограничения blast radius

Когда агент работает с реальными инструментами, ошибка проявляется не только как плохой ответ. Она может означать:

• удалённый файл;
• испорченный state в CRM;
• утечку секретов;
• скачивание вредного артефакта;
• запуск команды на не той машине;
• переход на опасный домен.

Поэтому sandbox полезно проектировать вокруг вопроса:

какой максимальный ущерб возможен, если агент ошибётся на этом шаге?

Именно этот вопрос задаёт реальные границы среды.

2. Filesystem boundary: не весь диск является рабочей областью

Одна из самых недооценённых границ.

Практический baseline:

• явный writable workspace;
• read-only mounts для reference data;
• запрет на доступ к ~, системным путям и credential directories;
• отдельная папка для downloads / generated artifacts;
• cleanup после завершения run.

Это особенно важно для coding agents. Если агент может свободно ходить по всему хосту, любой shell step получает непропорционально большую власть.

3. Network boundary: default deny обычно сильнее default allow

Большинство агентных задач не требует unrestricted internet.

Полезные режимы:

• только внутренние API и package mirrors;
• allow-list доменов для browser agent;
• полностью offline run для локального анализа;
• раздельные network profiles для research и commit paths.

Именно network boundary часто отделяет harmless experiment от настоящего security incident.

4. Secrets boundary: модель не должна видеть всё, что видит система

Секреты полезно делить на три класса:

• вообще недоступные агенту;
• доступные только executor layer;
• временно выдаваемые под конкретный step.

Плохие практики:

• хранить ключи в visible environment variables без ограничения scope;
• писать токены в shell history или traces;
• монтировать полный .ssh или cloud credentials в sandbox.

Хорошие практики:

• short-lived credentials;
• one-tool-one-secret mapping;
• redact-before-log;
• separate machine identity for automation.

5. Action boundary: propose и commit должны быть разведены

Даже в сильном sandbox есть опасные действия:

• git push;
• внешний POST в production API;
• отправка email;
• удаление файла;
• подтверждение платежа;
• publish/deploy.

Именно поэтому sandboxing тесно связан с:

• approval layer;
• idempotency;
• command allow-lists;
• explicit commit points.

Сам sandbox не заменяет этих слоёв, но делает их enforceable.

6. Audit boundary: наблюдаемость без лишней утечки

Полезно логировать:

• command/action;
• files touched;
• domains visited;
• step outcomes;
• human approvals;
• artifact IDs.

Но опасно логировать без фильтра:

• raw secrets;
• полные database dumps;
• private attachments;
• весь desktop screenshot stream без retention policy.

Нужен компромисс: достаточно данных для incident review, но не бесконечное складирование sensitive material.

7. Что особенно часто ломают команды

Reused long-lived sandboxes

Старый state переезжает между run-ами и делает поведение непредсказуемым.

Shared credentials

Все агенты и все разработчики фактически работают от одного identity.

Sandbox без policy layer

Есть контейнер, но нет allow-lists, no-go commands и approval boundaries.

Logging everything

У incident review есть всё, кроме privacy discipline.

No cleanup

Файлы, токены и скачанные артефакты живут дольше, чем нужно.

8. Какие метрики полезны

Минимальный sandbox dashboard обычно включает:

• blocked action rate;
• approval-required rate;
• denied network request rate;
• files touched outside intended workspace;
• secrets redaction incidents;
• stale sandbox reuse rate.

Если таких сигналов нет, команда обычно узнаёт о слабой изоляции уже после инцидента.

Минимальная sandbox policy

sandbox:
  filesystem:
    writable_paths:
      - /workspace
      - /tmp/agent-downloads
    read_only_paths:
      - /reference
    deny_paths:
      - /Users
      - /etc
      - /var/run/secrets
  network:
    allow_domains:
      - docs.internal.example
      - api.internal.example
      - registry.npmjs.org
  actions:
    blocked_commands:
      - rm -rf /
      - git push
      - curl * | sh
    approval_required:
      - external_post
      - payment_action
      - browser_submit

Practical run model

1. Create ephemeral sandbox
2. Mount minimal workspace
3. Inject short-lived scoped credentials
4. Execute bounded run
5. Pause on dangerous step
6. Export audit artifacts
7. Destroy sandbox

Практический совет: хороший sandbox должен отвечать не только на вопрос "где агент запущен", но и на вопрос "что он физически не может сделать даже при плохом решении модели".