Новость + практикум · Безопасность
Безопасность AI агентов: 30-минутный sandbox-чек-лист после новости об Astra
Если лаборатория задерживает модель из-за возможных критических кибервозможностей, обычной команде не нужно ждать следующего релиза, чтобы пересмотреть права своего coding-агента. За полчаса можно проверить главное: способен ли один ошибочный вызов выйти за пределы тестовой папки, увидеть секреты, обратиться к произвольному адресу или изменить внешнюю систему без подтверждения.
Что произошло — и чего новость не доказывает
Axios сообщил 7 августа, что OpenAI замедлила выпуск предрелизной модели Astra: по внутренним оценкам компания не смогла исключить достижение Critical-уровня кибервозможностей. Это сообщение о модели до публичного выпуска, а не анонс доступного продукта.
Контекст важен. 21 июля OpenAI и Hugging Face описали инцидент во время внутренней оценки моделей с ослабленными cyber-ограничениями. OpenAI также ранее изложила многоуровневый подход к киберзащите и программу Trusted Access for Cyber.
Редакционный вывод: новость не доказывает, что любой AI-агент опасен или что Astra уже способна провести конкретную атаку. Она показывает более полезную вещь: оценивать надо связку «модель + инструменты + среда + права», а не только качество ответов в чате.
Практикум на 30 минут
Проводите проверку только в тестовой среде. Не подключайте production-аккаунты, настоящие секреты и чужие системы. Цель — подтвердить границы, а не исследовать наступательные возможности модели.
0–5 минут: составьте карту полномочий
Выпишите все инструменты агента и пометьте каждый как чтение, локальная запись, внешнее изменение или необратимое действие. Отдельно перечислите доступные каталоги, переменные окружения, сетевые назначения и учётные записи. Если неизвестно, под какими правами работает команда, это уже провал проверки.
5–10 минут: включите read-only по умолчанию
Рабочая область агента должна быть отдельной песочницей. Исходный репозиторий, домашний каталог и системные пути монтируются только для чтения либо не видны вовсе. Для записи выдаётся отдельный временный каталог. Процесс запускается не от root, без sudo и без лишних системных capabilities. Минимальные права сокращают радиус ошибки даже тогда, когда AI агенты неверно поняли задачу.
10–15 минут: уберите секреты и закройте сеть
Не передавайте процессу весь набор переменных окружения хоста. Для нужного API используйте отдельную короткоживущую учётную запись с минимальной областью действия. Исходящие соединения работают по allowlist: только известные домены и порты. Запрос к неизвестному адресу должен блокироваться политикой ниже уровня модели.
15–20 минут: поставьте approval перед последствиями
Отправка сообщения, публикация, merge, deploy, изменение облачного ресурса, удаление и платёж требуют отдельного подтверждения человека. Экран подтверждения должен показывать фактический объект и действие, а не абстрактное «разрешить продолжение». Одобрение одного шага не должно открывать бессрочный доступ ко всем следующим.
20–25 минут: сделайте действие наблюдаемым и останавливаемым
Записывайте идентификатор запуска, пользователя, модель, инструмент, нормализованные аргументы, результат policy-проверки и код завершения. Секреты в журнал не попадают. Kill switch должен прекращать новые вызовы инструментов и отзывать краткоживущие учётные данные, а не просто закрывать окно чата.
25–30 минут: безопасный canary-тест
Создайте внутри разрешённой тестовой папки файл-маркер, например CANARY_DO_NOT_READ.txt, и второй маркер за её пределами. Попросите агента перечислить только файлы разрешённой папки и подготовить изменение в отдельном output-каталоге. Приёмка успешна, если внешний маркер не появился ни в ответе, ни в журнале чтения, запись вне output заблокирована, сетевой запрос к неразрешённому адресу отклонён, а опасное действие остановилось на approval.
Чек-лист приёмки
- У каждого инструмента есть владелец, назначение и уровень риска.
- Процесс не видит домашний каталог, системные пути и лишние переменные.
- Запись разрешена только в отдельный тестовый каталог.
- Сеть закрыта по умолчанию; разрешения перечислены явно.
- Опасные внешние действия требуют одноразового подтверждения.
- Журнал позволяет восстановить последовательность вызовов без раскрытия секретов.
- Kill switch проверен на тестовом запуске.
- Canary-маркер за границей доступа не был прочитан или изменён.
Три типичные ошибки
- «У нас хороший системный промпт». Промпт полезен, но не заменяет файловые права, сетевую политику и approval.
- «Агент работает в контейнере». Контейнер с root, смонтированным сокетом Docker и открытой сетью почти не уменьшает риск.
- «Все действия пишутся в лог». Журнал помогает расследовать случившееся, но не предотвращает необратимое действие. Нужны и превентивные ограничения.
Где здесь Kimi
Структура практикума была подготовлена через фактический вызов Kimi K2.7 Code: модель предложила разделить новость и рекомендации, затем пройти sandbox, права, read-only, секреты, сеть, approval, журнал, аварийную остановку и canary-тест. Редакция проверила источники и убрала слишком широкое утверждение модели о том, что любая AI-модель сама исполняет недоверенный код: действия выполняет подключённый агентный runtime.
Вывод
Безопасность ИИ агентов — это управляемая инженерная характеристика. Новость об Astra стоит использовать не для паники, а как повод проверить собственный контур: модель может ошибиться, но среда не должна позволить этой ошибке свободно превратиться во внешнее действие.
Продолжение: как измерить радиус ущерба AI-агента и как задать минимальные права MCP-серверу. Термины — в глоссарии, остальные инструкции — в практических гайдах.