Как мы строим безопасную on-prem AI-платформу для корпоративных AI-агентов

Привет, Хабр! Меня зовут Назар Башинский, я разработчик в AGIMA.

Персональный AI-ассистент может быть удобен для работы с текстом, но корпоративная инфраструктура требует другого уровня контроля. Пользователь может случайно передать модели пароль или токен, а агент — получить слишком широкие права и изменить данные не там, где нужно. В AGIMA мы строим безопасный on-prem-контур для AI-агентов: с проверкой прав, контролируемым доступом к внутренним системам, разделением языкового и инфраструктурного слоев и аудитом действий.

Что строим и что защищаем

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

• может ли агент напрямую обращаться к Jira, 1С, финансовым системам и другим сервисам;

• как отличить чтение данных от критичного действия на запись;

• где сохранить следы запроса, примененных политик и результата;

• как расследовать ошибку и не размножить десятки несвязанных ботов.

Мы строим управляемый корпоративный контур. Пользователь обращается к агенту через привычный интерфейс, но агент не ходит во внутренние системы напрямую. Запрос проходит через проверку прав, политики безопасности, Gateway для моделей, Gateway для корпоративных инструментов, источники данных и аудит. Модель — лишь один компонент на этом пути.

Концептуальная схема управляемого пути запроса

Схема разделяет ответственность: интерфейс и модели можно менять, а ограничения доступа остаются в инфраструктурном слое. Это целевая архитектура, а не обещание, что все интеграции уже работают.

Входная точка контура — корпоративный чат-бот в Mattermost. Технически это Codex App Server, который подключен к Mattermost через коннекторы. Сотрудник пишет боту как обычному коллеге, а все остальное происходит уже в инфраструктурном слое.

К этому решению мы пришли не сразу. Мы тестировали разные харнессы — обвязки, которые превращают модель в агента с инструментами, — в том числе OpenClaw и Hermes. По итогам тестов и исследований чистый Codex без дополнительных обвязок оказался надежнее: в связке с Mattermost у него меньше багов, а настройка гибче.

Есть и архитектурная причина. Бот в мессенджере всегда знает, кто ему пишет, поэтому через него удобно настроить имперсонацию в связке с MCP Gateway: агент действует не от имени общей сервисной учетки, а от имени конкретного сотрудника и с его правами.

Один безопасный путь запроса

Пройдем один обезличенный сценарий — от сообщения сотрудника до результата в корпоративной системе. Чтобы его было проще читать, коротко о ролях слоев:

• интерфейс (Mattermost) принимает сообщение и знает, кто его отправил;

• агент на Codex App Server понимает задачу, выбирает скилл и решает, какие инструменты нужны;

• LLM Gateway отвечает за доступ к языковым моделям, лимиты и DLP-проверки;

• MCP Gateway отвечает за доступ к корпоративным системам от имени пользователя;

• Vault хранит секреты и учетные данные, вход в него — через корпоративный SSO;

• аудит фиксирует каждый шаг, чтобы путь запроса можно было восстановить.

Теперь посмотрим, как запрос проходит через эти слои.

1. Сотрудник пишет корпоративному AI-агенту в Mattermost. Мессенджер здесь только точка входа: его можно заменить, не перестраивая остальной контур.

2. Коннектор передает в Codex App Server сообщение, контекст диалога и идентификатор пользователя. Сам интерфейс не решает, какие данные можно читать: его задача — доставить запрос и не потерять, от чьего имени он пришел.

3. Агент разбирает запрос и определяет, какие инструменты нужны. Но к Jira, 1С, финансовой системе или другому сервису он напрямую не обращается: все такие вызовы проходят через MCP Gateway — единую точку подключения корпоративных инструментов.

4. MCP Gateway сопоставляет запрос с личностью пользователя, его ролью и разрешениями и выполняет обращение через имперсонацию — от имени пользователя и с его реальными правами. Если у сотрудника нет доступа к системе, его не будет и у агента.

5. Учетные данные лежат в Vault, вход в который защищен корпоративным SSO. Gateway берет из него токен нужной системы в момент вызова, поэтому секреты не попадают в контекст модели.

6. Обращения к языковой модели идут через LLM Gateway. DLP проверяет запрос до отправки модели и не выпускает секреты и токены за пределы разрешенного контура.

7. Агент получает только разрешенный контекст. Операции на запись отделены от ответа и проходят отдельный контроль.

8. В журнал аудита (audit trail) попадают инициатор, примененные политики, источники и результат обращения.

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

База корпоративного контекста и два Gateway

Агенту недостаточно подключить набор документов. Ему нужно понимать, какие процессы и правила действуют в компании, какие источники относятся к задаче и кто отвечает за их актуальность. Эту связанную систему знаний можно описывать как корпоративную онтологию — карту сущностей, процессов, ролей и отношений между ними.

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

Так разговор «давайте напишем промпт» превращается в более полезный вопрос: какой шаг процесса мы улучшаем, какие данные нужны, кто владелец, как проверить результат и где человек должен остаться в контуре.

Границы корпоративного контура

On-prem не означает, что достаточно развернуть модель внутри периметра. Важно, какие права, секреты и данные доступны агенту. Соответствие 152-ФЗ — часть проверки, но оно не заменяет юридическое и ИБ-ревью архитектуры.

Принципы контура:

• агент действует только в рамках прав пользователя;

• сервисная учетка не получает безлимитный доступ;

• все обращения к корпоративным системам идут через MCP Gateway и выполняются от имени конкретного пользователя — с его доступами, а не с общими правами бота;

• каждый такой вызов проходит через контролируемый слой и попадает в аудит;

• секреты проверяются до передачи модели;

• повторяемые проверки реализуются кодом.

Архитектура разделяет интерфейс, языковой слой, доступ к инструментам, источники, политики и аудит. Так промпт не становится единственным механизмом безопасности.

Два Gateway с разными задачами

Словом Gateway мы называем контролируемую точку прохождения запроса. Важно не смешивать два разных слоя: LLM Gateway работает с языковыми моделями, а MCP Gateway — с доступом AI-агентов к корпоративным системам.

LLM Gateway. Это единая точка маршрутизации запросов к моделям. Она нужна для управления ключами, расходами и лимитами, централизованных логов, замены модели без переписывания клиентов и подключения общих политик безопасности и DLP.

MCP Gateway. Это слой безопасного доступа к инструментам и внутренним системам. Он связывает идентификатор пользователя с разрешениями и выполняет обращение от его имени, не выдавая языковой модели прямой доступ к токенам и сервисам.

Как это устроено у нас. MCP Gateway работает в связке с корпоративным чат-ботом и подключен к Vault — хранилищу секретов. Авторизация в Vault идет через корпоративный SSO: сотрудник входит под своей учетной записью и указывает учетные данные от рабочих систем, с которыми должен работать агент.

Дальше все происходит без участия модели. Codex App Server передает MCP Gateway токен пользователя. Опираясь на него, Gateway берет из Vault токен нужной системы — например, ERP — и выполняет запрос от имени конкретного сотрудника. Модель не видит ни одного секрета: она получает только результат вызова.

Если собрать все вместе, путь запроса через оба Gateway выглядит так:

1. Получить идентификатор пользователя и контекст его прав.

2. Проверить запрос и применить ограничения безопасности до обращения к модели.

3. Выбрать модель, маршрут, лимиты и правила повторной попытки на стороне LLM Gateway.

4. Передать обращение к корпоративной системе через MCP Gateway только после проверки прав.

5. Не помещать секреты и учетные данные в контекст языковой модели.

6. Отдельно контролировать критичные операции на запись. Подтверждение человеком здесь — целевая возможность, а не функция, которая уже работает во всех сценариях.

7. Записать решение и результат в журнал аудита.

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

DLP и деперсонализация

DLP и деперсонализация решают разные задачи. DLP отвечает на вопрос: можно ли передавать это содержимое дальше? Деперсонализация отвечает на вопрос: как сохранить смысл запроса, не раскрывая чувствительные данные модели или внешнему сервису?

Например, имя сотрудника или номер договора можно заменить на условное обозначение. Но такая замена сама по себе не выдает агенту право искать связанные данные. Сначала должны сработать правила доступа, а затем — только разрешенный инструмент и контекст.

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

Здесь мы описываем DLP на уровне архитектурного принципа: конкретные правила и статус компонентов — тема отдельного технического согласования.

Единый Gateway позволяет версионировать, тестировать и централизованно менять политики, а не размазывать их по ботам и промптам.

Скиллы: код для правил, LLM — для смысла

Скилл — это не просто prompt. Это воспроизводимый сценарий, связанный с процессом, источниками, правами и проверкой результата. В нем языковая модель помогает понять смысл запроса, а код выполняет предсказуемые шаги.

У скилла должны быть:

• назначение и границы применения;

• связанный шаг процесса;

• входные данные и допустимые источники;

• правила безопасности и требуемые права;

• владелец и версия;

• критерии качества и способ проверки;

• режим выполнения: подсказка, черновик или действие;

• понятный способ отмены или вывода из эксплуатации.

Проверять такую архитектуру удобно на трех классах задач: финансовые операции, маршрутизация обращений и поиск по корпоративным данным. Это примеры классов задач, а не утверждение, что каждый из них уже находится в промышленной эксплуатации.

В финансовом контуре скилл готовит черновик и проверяет обязательные поля, но не получает права на финальную запись. В sales-сценарии он классифицирует обращение и предлагает маршрут, а неоднозначные случаи оставляет человеку. В поиске по данным он отвечает только в разрешенном контексте и фиксирует источники.

Общий критерий один: вход, действие, контроль и аудит должны быть описаны отдельно. Если ошибка дороже экономии пары минут, правила, статусы и валидации нужно выполнять кодом.

Здесь проявляется главный инженерный принцип: код используется по умолчанию, а LLM подключается там, где действительно нужно понять естественный язык или широкий контекст. Пошаговые операции, циклы, API-запросы, проверки, права и запись в системы надежнее выполнять детерминированным кодом.

Поэтому минимальная карточка корпоративного AI-скилла описывает не только промпт, но и эксплуатацию:

Интерфейс, данные и документация

Отдельный портал для AI может быть удобен, но сотрудники уже работают в мессенджерах и других привычных интерфейсах. У нас таким входом стал Mattermost с ботом на Codex App Server, однако ценность здесь — в передаче запроса и контекста, а не в конкретном мессенджере.

Интерфейсный бот не должен содержать бизнес-логику. Его задача — принять сообщение, сохранить контекст диалога, передать событие в оркестратор и показать результат. Решения о правах, модели, источниках и доступных действиях принимает платформа.

Даже тонкий интерфейс требует дисциплины: ответы должны попадать в нужный тред или контекст, команды и ошибки — быть понятными, а отказ — объяснять, какое ограничение сработало.

Данные: общая база контекста компании

Корпоративные данные распределены между рабочими системами, документами, почтой и чатами. У каждого источника свои владелец, формат и правила доступа. Поэтому подключать все данные к модели напрямую нельзя.

Есть и практическая проблема: из разрозненных систем данные сложно выгружать и еще сложнее сопоставлять между собой. Мы решили ее так: воркеры забирают данные из рабочих систем и складывают их в общую базу данных с контекстом компании. Агенты работают уже с ней: с помощью SQL-запросов они сопоставляют данные из разных источников, получают нужный контекст и проводят анализ.

Чтобы такой базе можно было доверять, вокруг нее нужен управляемый конвейер:

• системы подключаются через контролируемые коннекторы и прокси;

• изменения синхронизируются с учетом владельцев и прав;

• данные проходят подготовку и проверку качества до использования в ответе;

• права доступа связываются с корпоративной идентичностью;

• для каждого утверждения можно восстановить источник и версию;

• действия агента и инфраструктурные события попадают в аудит.

Такой слой нужен не только для поиска по документам. Он позволяет объяснить, какие источники использовались, почему пользователь имел право это увидеть и какой путь прошел запрос.

Pipeline orchestrator: агенты, которые работают 24/7

Кроме агентов, которые отвечают сотрудникам в чате, в платформе есть pipeline orchestrator — фоновые агенты, которые работают круглосуточно. Они устроены по детерминированному принципу: большая часть действий выполняется алгоритмически. Получение, маппинг и обработку данных делает обычный код, а LLM вызывается точечно — там, где алгоритмы не справляются.

Обращаться к модели оркестратор может двумя способами:

• через OpenAI Agents SDK — когда нужны сложные действия: несколько шагов, вызовы инструментов, промежуточные решения;

• через обычный вызов API с промптом — когда достаточно одного обращения к модели.

Так недетерминированная часть остается небольшой, а поведение пайплайна — предсказуемым и проверяемым. Это тот же принцип, что и в скиллах: код по умолчанию, LLM — там, где без нее не обойтись.

Документация и версии как часть системы

Документация должна быть не приложением к платформе, а частью ее жизненного цикла.

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

Для скиллов нужен понятный маршрут: описание → ревью → тесты → публикация → наблюдение за использованием → развитие или вывод из эксплуатации. Личная автоматизация не должна навсегда оставаться личным файлом без владельца и аудита.

Аудит: воспроизводимость и контроль

AI-платформа без аудита превращается в черный ящик. Ответ есть, а объяснить, почему он появился и кто разрешил действие, невозможно.

Минимальный журнал аудита должен показывать:

• кто инициировал запрос и через какой интерфейс;

• какой скилл, версия и маршрут участвовали;

• был ли запрос разрешен, замаскирован, заблокирован или отправлен на ручной разбор;

• какая сквозная трассировка связывает запрос, работу агента и инфраструктурные события.

При этом сам журнал тоже требует правил хранения. Сырые совпадения DLP могут помочь расследованию, но одновременно содержать чувствительные данные. Формат и срок хранения нужно выбирать вместе с разработкой, ИБ и юристами.

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

Чем больше действий агент может выполнить, тем важнее заранее определить, какие события обязательны для журнала, кто имеет к нему доступ и как расследуются инциденты.

Вывод: что дает такой контур и где его граница

У такой платформы есть пять опор: права пользователя, база знаний из процессов, версионируемые скиллы, заменяемый интерфейс и контроль вне LLM. Это снижает зависимость от конкретной модели, но не отменяет тестирования каждой интеграции.

Честная граница безопасности

В таком контуре Gateway защищает токены и ограничивает доступ агента к корпоративной инфраструктуре, но не может запретить сотруднику вручную скопировать данные в личный AI-сервис.

Для этого нужны меры на уровне устройства и рабочего окружения: корпоративные устройства и MDM, блокировка внешних AI-сервисов, защищенный удаленный стол и сигналы аномального использования.

Абсолютную безопасность не обеспечивает ни один компонент — только сочетание мер.

Итоговый принцип: что бы пользователь ни написал модели, у нее физически не должно быть доступа к тому, куда не допущен сам сотрудник. Это проверяется правами, инфраструктурными гейтами и аудитом.

А какие границы для корпоративных AI-агентов вы считаете обязательными — для доступа к моделям, к системам, к операциям на запись? Давайте обсудим в комментариях.

Еще по теме в блоге AGIMA на Хабре:

• Дообучение детектора промпт-инъекций: пять раундов, четыре неудачи и гейты против регресса

• Почему мы не нашли готового PII-детектора для русского языка: грабли боевого контура перед LLM - GenAI и кибербезопасность в e-commerce: как защитить бизнес и не создать новые уязвимости

Больше заметок про AI, разработку и управление инженерными командами — в Telegram-канале нашего CTO «Непряхин и машины».