«Своя модель» не делает AI-агента своим
aiai4sdlcteamleadengineeringmanagementmcp
«Своя модель» не делает AI-агента своим
Когда в компании обсуждают агентную платформу, разговор часто сводится к двум вариантам:
— поднимаем OpenCode и локальную модель;
— покупаем Claude Code или Codex и ходим во внешний API.
Но это ложный выбор.
Агентный стек — не один продукт. Это минимум пять компонентов:
обвязка × модель × инструменты × идентичность × границы исполнения
И каждый из них может находиться под разным контролем.
Например:
— открытый клиент не делает модель локальной;
— локальная модель не ограничивает права инструментов;
— внутренний MCP не становится безопасным только потому, что он внутренний;
— внешний API необязательно опасен, если контекст фильтруется, а модель не получает прямого доступа к рабочим системам.
Отсюда важный вывод: слово «свой» тоже ничего не объясняет.
Нужно отдельно проверять четыре вещи:
1. Контролируем ли мы исходный код?
2. Эксплуатируем ли компонент самостоятельно?
3. Контролируем ли путь и хранение данных?
4. Обеспечиваются ли права и запреты технически?
Особенно интересна рекомендуемая корпоративная архитектура. Не обязательно форкать каждого агента и самостоятельно размещать все модели. Гораздо важнее владеть двумя точками контроля.
Модельный шлюз решает:
— какие данные можно отправлять;
— в какую модель и регион;
— разрешён ли резервный маршрут;
— сколько может стоить задача.
Инструментальный шлюз решает:
— кто инициировал действие;
— что именно разрешено изменить;
— от чьего имени выполняется операция;
— нужна ли дополнительная проверка.
Это критично, потому что атакуют обычно не саму модель, а цепочку полномочий.
Агент прочитал README, письмо или задачу в Jira. Внутри оказалась вредоносная инструкция. Модель восприняла её как часть контекста и вызвала инструмент с рабочими правами.
Просьба в системном промпте «не отправляй секреты» здесь не поможет.
Поэтому модель может предложить действие, но не должна сама определять, имеет ли право его выполнить. Это задача IAM, политики и инструментального шлюза.
Что я бы проверил перед внедрением агента в команду:
— где реально исполняются команды;
— куда уходят промпты, результаты инструментов и логи;
— есть ли общие долгоживущие токены;
— разделены ли чтение, подготовка изменения и запись;
— закрыт ли исходящий трафик по умолчанию;
— что произойдёт при недоступности локальной модели;
— можно ли отдельно отключить модель, MCP или записывающий инструмент;
— связывает ли аудит пользователя, модель, инструмент и фактический результат.
И ещё один практический совет: пилот стоит начинать не с максимальной автономности.
Один репозиторий. Один класс данных. Чтение или создание merge request вместо прямой записи. Никаких широких рабочих токенов.
Цель пилота — не доказать, что агент умеет вызывать двадцать инструментов. Цель — понять, сколько полезной работы команда принимает, как часто агент ошибается и сколько времени уходит на проверку.
Безопасность и суверенность — свойства всей цепочки, а не логотипа модели. Владеть в первую очередь нужно местами, где пересекаются данные, полномочия и необратимые действия.
По мотивам разбора восьми конфигураций агентного стека Александра Поломодова.
#AI #AI4SDLC #TeamLead #EngineeringManagement #MCP
Когда в компании обсуждают агентную платформу, разговор часто сводится к двум вариантам:
— поднимаем OpenCode и локальную модель;
— покупаем Claude Code или Codex и ходим во внешний API.
Но это ложный выбор.
Агентный стек — не один продукт. Это минимум пять компонентов:
обвязка × модель × инструменты × идентичность × границы исполнения
И каждый из них может находиться под разным контролем.
Например:
— открытый клиент не делает модель локальной;
— локальная модель не ограничивает права инструментов;
— внутренний MCP не становится безопасным только потому, что он внутренний;
— внешний API необязательно опасен, если контекст фильтруется, а модель не получает прямого доступа к рабочим системам.
Отсюда важный вывод: слово «свой» тоже ничего не объясняет.
Нужно отдельно проверять четыре вещи:
1. Контролируем ли мы исходный код?
2. Эксплуатируем ли компонент самостоятельно?
3. Контролируем ли путь и хранение данных?
4. Обеспечиваются ли права и запреты технически?
Особенно интересна рекомендуемая корпоративная архитектура. Не обязательно форкать каждого агента и самостоятельно размещать все модели. Гораздо важнее владеть двумя точками контроля.
Модельный шлюз решает:
— какие данные можно отправлять;
— в какую модель и регион;
— разрешён ли резервный маршрут;
— сколько может стоить задача.
Инструментальный шлюз решает:
— кто инициировал действие;
— что именно разрешено изменить;
— от чьего имени выполняется операция;
— нужна ли дополнительная проверка.
Это критично, потому что атакуют обычно не саму модель, а цепочку полномочий.
Агент прочитал README, письмо или задачу в Jira. Внутри оказалась вредоносная инструкция. Модель восприняла её как часть контекста и вызвала инструмент с рабочими правами.
Просьба в системном промпте «не отправляй секреты» здесь не поможет.
Поэтому модель может предложить действие, но не должна сама определять, имеет ли право его выполнить. Это задача IAM, политики и инструментального шлюза.
Что я бы проверил перед внедрением агента в команду:
— где реально исполняются команды;
— куда уходят промпты, результаты инструментов и логи;
— есть ли общие долгоживущие токены;
— разделены ли чтение, подготовка изменения и запись;
— закрыт ли исходящий трафик по умолчанию;
— что произойдёт при недоступности локальной модели;
— можно ли отдельно отключить модель, MCP или записывающий инструмент;
— связывает ли аудит пользователя, модель, инструмент и фактический результат.
И ещё один практический совет: пилот стоит начинать не с максимальной автономности.
Один репозиторий. Один класс данных. Чтение или создание merge request вместо прямой записи. Никаких широких рабочих токенов.
Цель пилота — не доказать, что агент умеет вызывать двадцать инструментов. Цель — понять, сколько полезной работы команда принимает, как часто агент ошибается и сколько времени уходит на проверку.
Безопасность и суверенность — свойства всей цепочки, а не логотипа модели. Владеть в первую очередь нужно местами, где пересекаются данные, полномочия и необратимые действия.
По мотивам разбора восьми конфигураций агентного стека Александра Поломодова.
#AI #AI4SDLC #TeamLead #EngineeringManagement #MCP