AGIMA описала on-prem-контур для корпоративных AI-агентов: два гейта, имперсонация, аудит
В блоге AGIMA на Хабре разобрана архитектура корпоративного контура для AI-агентов: агент не ходит во внутренние системы напрямую, а действует через LLM Gateway и MCP Gateway с правами конкретного сотрудника — секреты остаются в Vault, модель их не видит, каждое обращение попадает в аудит. Честно отмечено, какие части — цель, а не работающая функция.
Что произошло
27 октября в блоге AGIMA на Хабре разработчик Назар Башинский описал архитектуру on-prem-контура, через который компания проводит корпоративных AI-агентов. Сотрудник пишет агенту в Mattermost (бот на Codex App Server), дальше запрос проходит инфраструктурный слой: LLM Gateway маршрутизирует обращения к моделям и держит ключи, лимиты, логи и DLP-проверки, а MCP Gateway — единственная точка доступа к внутренним системам (Jira, 1С, финансовые сервисы). Вызовы выполняются с правами конкретного пользователя через имперсонацию: если у сотрудника нет доступа к системе, его не будет и у агента.
Секреты лежат в Vault, вход — через корпоративный SSO; гейт берёт токен нужной системы в момент вызова, поэтому учётные данные не попадают в контекст модели. Каждый шаг фиксируется в аудите: инициатор, применённые политики, источники, результат. Для интерфейса компанию не устраивали готовые харнессы: тестировали OpenClaw и Hermes, но выбрали чистый Codex — по их опыту, меньше багов и гибче настройка, а бот в мессенджере, который знает автора, удобен для имперсонации.
Авторы разделяют цель и текущее состояние: не каждый гейт реализован во всех сценариях, подтверждение человеком критичных операций на запись — целевая возможность, а не работающая функция. 152-ФЗ назван частью проверки, но не заменой юридического и ИБ-ревью. Границу назвали прямо: контур не остановит сотрудника, который вручную скопирует данные в личный AI-сервис — это зона MDM и блокировки внешних сервисов.
Почему это важно
Для команды, которая заводит агентов в корпоративные системы, это готовый чек-лист границ, применимый на любом этапе, где агент трогает прод-данные: от кода до эксплуатации. Главный риск в такой схеме сформулирован не как «модель ошиблась», а как «агент получил доступ без понятных границ» — и снят инфраструктурой, а не промптом: права агента равны правам сотрудника, секреты физически не доходят до модели, каждое обращение идёт через единую точку и остаётся в журнале. Разделение двух гейтов (LLM и MCP) — полезный шаблон: языковой слой и слой доступа к инструментам меняются независимо, интерфейс заменяем. Ценность разбора ещё и в честных пометках: где-то гейт уже работает, где-то это только архитектурный принцип — редкость для корпоративных описаний.
Что с этим делать
- Инвентаризируйте текущий доступ агентов к внутренним системам: где работает общая сервисная учётка и где токены попадают в контекст модели.
- Разделите LLM Gateway и шлюз доступа к инструментам; секреты держите в хранилище с SSO и выдавайте в момент вызова.
- Проводите действия агента от имени конкретного сотрудника с его правами и пишите в аудит инициатора, политики, источники и результат.
- Не ждите от контура защиты от ручного выноса данных человеком — это отдельные меры: MDM, блокировка внешних AI-сервисов, сигналы аномалий.