«Своя модель» не делает AI-агента своим

Когда в компании обсуждают агентную платформу, разговор часто сводится к двум вариантам:

— поднимаем OpenCode и локальную модель; — покупаем Claude Code или Codex и ходим во внешний API.

Но это ложный выбор.

Агентный стек — не один продукт. Это минимум пять компонентов:

обвязка × модель × инструменты × идентичность × границы исполнения

И каждый из них может находиться под разным контролем.

Например:

— открытый клиент не делает модель локальной; — локальная модель не ограничивает права инструментов; — внутренний MCP не становится безопасным только потому, что он внутренний; — внешний API необязательно опасен, если контекст фильтруется, а модель не получает прямого доступа к рабочим системам.

Отсюда важный вывод: слово «свой» тоже ничего не объясняет.

Нужно отдельно проверять четыре вещи:

1. Контролируем ли мы исходный код? 2. Эксплуатируем ли компонент самостоятельно? 3. Контролируем ли путь и хранение данных? 4. Обеспечиваются ли права и запреты технически?

Особенно интересна рекомендуемая корпоративная архитектура. Не обязательно форкать каждого агента и самостоятельно размещать все модели. Гораздо важнее владеть двумя точками контроля.

Модельный шлюз решает:

— какие данные можно отправлять; — в какую модель и регион; — разрешён ли резервный маршрут; — сколько может стоить задача.

Инструментальный шлюз решает:

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

Это критично, потому что атакуют обычно не саму модель, а цепочку полномочий.

Агент прочитал README, письмо или задачу в Jira. Внутри оказалась вредоносная инструкция. Модель восприняла её как часть контекста и вызвала инструмент с рабочими правами.

Просьба в системном промпте «не отправляй секреты» здесь не поможет.

Поэтому модель может предложить действие, но не должна сама определять, имеет ли право его выполнить. Это задача IAM, политики и инструментального шлюза.

Что я бы проверил перед внедрением агента в команду:

— где реально исполняются команды; — куда уходят промпты, результаты инструментов и логи; — есть ли общие долгоживущие токены; — разделены ли чтение, подготовка изменения и запись; — закрыт ли исходящий трафик по умолчанию; — что произойдёт при недоступности локальной модели; — можно ли отдельно отключить модель, MCP или записывающий инструмент; — связывает ли аудит пользователя, модель, инструмент и фактический результат.

И ещё один практический совет: пилот стоит начинать не с максимальной автономности.

Один репозиторий. Один класс данных. Чтение или создание merge request вместо прямой записи. Никаких широких рабочих токенов.

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

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

По мотивам разбора восьми конфигураций агентного стека Александра Поломодова.

#AI #AI4SDLC #TeamLead #EngineeringManagement #MCP