Как обеспечить периметр безопасности AI-агента без опоры на system prompt

«Не удаляй прод» в system prompt — это не защита. Ограничение работает, когда модель физически не дотягивается до файлов и шелла: без прямого API к хосту, с изоляцией, фильтром команд и аудитом. Пример — enterprise-code-bastion.

Как обеспечить периметр безопасности AI-агента без опоры на system prompt

Чтобы вокруг AI-агента был периметр безопасности, одного system prompt мало. Модель не должна физически дотягиваться до файлов и шелла: штатные tools выключены, наружу только MCP, исполнение в Docker на пару «проект + задача», фильтр команд до запуска, audit trail. Ниже — рабочий референс и где схема ломается.

«НЕ УДАЛЯЙ НИЧЕГО С ПРОДА» в системном промпте — записка на холодильнике роботу с кувалдой. Модель текст прочитает. Даже поймёт. А потом решит, что rm по контексту уместен, и выполнит. Не из злости. Текст в промпте она не обязана соблюдать так, как firewall обязан дропать пакет.

Контроль держится на том, куда модель физически не дотягивается: API, токены, изоляция, фильтр операций. Пока всё работает, это легко спутать с «хорошим system prompt». Разница проявляется один раз — обычно уже поздно и дорого.

Почему «хороший system prompt» не проходит согласование у безопасника

Финтех, госсектор, крупный IT не пускают агента к кодовой базе: blast radius одной кривой команды — репозиторий, секреты, инфраструктура. «Доверьтесь, мы написали хороший system prompt» на комитете ИБ проходит как wish-list. Control plane от этого не появляется.

От любого подрядчика enterprise и так ждёт least privilege, изоляцию, полный аудит, воспроизводимость. AI-агента часто пускают без этого пакета — «модель же умная». Умность поверхность атаки не сужает. Меняет форму сбоя: вместо упавшего скрипта — уверенный rm посреди «разумного» плана.

Рабочий бастион

Я собрал рабочий референс такого контура — enterprise-code-bastion: лаунчер сессий, MCP-сервер с secureBash, реестр сессий. Агента режем архитектурой — штатные инструменты выключены, любое действие идёт через фильтрующего посредника в песочнице.

На практике:

  1. Единица работы — «проект + задача». Под пару поднимается свой Docker, в него смонтирован только этот проект. Соседние сессии его не видят.
  2. Claude без штатных tools. --tools "": ни Read, ни Write, ни Bash из коробки. На хосте сам по себе агент ничего не читает и не запускает.
  3. Наружу один канал — MCP (Model Context Protocol) по HTTP. Нужен файл или шелл — просит сервер. Сам не может.
  4. Фильтр до исполнения. В проде команду перед запуском смотрит детерминированная логика или отдельная LLM-модель-фильтр (часто оба слоя). Деструктивное отсекается до docker exec.
  5. Исполнение только в контейнере сессии. Прошла фильтр — docker exec в sandbox, не на хост. Ответ возвращается модели.
  6. Аудит. Запросы в logs/mcp.log (JSON Lines), сессии в sessions.csv. Для комплаенса это входной билет, не «nice to have».

В демо-репозитории для наглядности всё на одной машине: и файлы проекта, и MCP-сервер. В проде их разносят: код лежит на одном хосте, MCP-guard — на другом. Тогда даже если Claude каким-то образом снова получит Bash или Read, до файлов проекта у него всё равно нет пути — они физически в другом месте. Упрощение в репе намеренное.

Методика, таблица контролей, команды запуска — в howto: Enterprise-бастион для кода.

Где это ломается

  • Gate из одной LLM. У фильтра своя поверхность prompt-injection. Жёсткая гарантия требует детерминированный allowlist рядом с моделью — иначе доверие просто переехало с одной модели на другую.
  • secureBash всё равно гоняет команды внутри контейнера. Изоляция = насколько закалён sandbox (non-privileged, egress, лимиты). Сломанный контейнер — всё ещё blast radius: хост снаружи может уцелеть, а всё, что крутилось в sandbox, уже под ударом.
  • Плоский sessions.csv. Для демо упрощённо показан append-only журнал. На масштабе организации нужны session store, RBAC и workflow согласований.

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

Для кого

Для CISO, CTO, Head of AI и архитекторов, которым нужно пустить Claude (или аналог) к коду и пройти security review. Это не туториал «завести агента за вечер». Claude рассуждает и предлагает план, но за пределы разрешения не выходит: нет прямых tools, нет прямого доступа к дереву проекта, каждая команда проверяется и крутится в песочнице.

Ещё один контур — разделение постановки задачи и исполнения (наблюдаемый shared state, git как audit): Как контролировать то, что делают AI-агенты. Бастион закрывает периметр доступа, split — прозрачность работы. Обычно нужны оба.

Итог

System prompt всё равно пишите — без него агент хуже думает. Но когда модель решит, что rm уместен, останется только то, что вы встроили в архитектуру. Если там пусто, промпт уже никого не спасёт.

Репозиторий: github.com/dobryakov/enterprise-code-bastion

Howto: dobryakov.com/howto/enterprise-code-bastion.html

Рядом по теме: book-as-context для предметного контекста и онбординг скиллов, если ассистент обрастает пакетами поведения.