Конфигурации агентного стека: полный разбор восьми вариантов

Открытый код клиента не делает модель локальной. Модель в собственном контуре не делает безопасными инструменты. Внутренний MCP-сервер не ограничивает права сам по себе. И наоборот: внешний модельный API не обязательно получает производственные секреты, если планирование отделено от исполнения, контекст фильтруется, а полномочия остаются во внутреннем шлюзе.010101Сжатую версию этой истории я рассказывал в эфире Research Insights Made Simple #22 — тезисы и материалы есть в «Книжном кубе».Книжный куб · Research Insights #2201Сжатую версию этой истории я рассказывал в эфире Research Insights Made Simple #22 — тезисы и материалы есть в «Книжном кубе».Книжный куб · Research Insights #22

Этот материал продолжает формулу Agent = Model + Harness и идеи модельного и инструментального шлюзов из подхода с агентами в центре к внутренним платформам разработки. Но для рабочего выбора формулу полезно расширить:

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

Чтобы не смешивать факты и мнения, в тексте три типа утверждений:

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

Слово «свой» слишком перегружено. Им могут называть:

1. 1Владение исходным кодом: команда может изучать и изменять обвязку.
2. 2Операционный контроль: команда сама разворачивает, обновляет и наблюдает компонент.
3. 3Контроль данных: команда задаёт регион, сроки хранения и допустимые направления передачи.
4. 4Контроль политики: права, маршруты, подтверждения и запреты обеспечиваются инфраструктурой, а не только системным промптом.

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

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

готовый локальный клиент
× внешняя модель через корпоративный модельный шлюз
× внутренние инструменты через шлюз с OBO-идентичностью
× локальная изоляция средствами ОС

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

Ось 1. Обвязка агента

Собственная разработка или форк даёт максимум свободы в цикле планирования, формате контекста, политике инструментов и интеграции с внутренней платформой. Цена этой свободы — постоянная работа: совместимость с моделями, сжатие контекста, восстановление после ошибок, UX подтверждений, песочница для разных ОС, трассировка и обновление зависимостей. Форк также создаёт собственную ветку цепочки поставки: уязвимости выше по цепочке уже не исправляются автоматически.020202Про то, как проектируются автономные циклы обвязки — с разделением исполнения и проверки и точками контроля человека, — я делал отдельный эфир про Loop Engineering.Книжный куб · Loop Engineering02Про то, как проектируются автономные циклы обвязки — с разделением исполнения и проверки и точками контроля человека, — я делал отдельный эфир про Loop Engineering.Книжный куб · Loop Engineering

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

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

Ось 2. Модель

«Своя модель» распадается минимум на четыре класса.

• —Открытые веса в собственном контуре. Организация контролирует инференс, версии и телеметрию, но оплачивает GPU, запас ёмкости, обслуживание, обновления и проверку качества. Открытые веса не гарантируют ни маленький размер, ни хорошее использование инструментов.
• —Управляемая модель в выбранном облаке или регионе. Данные и вычисления можно удержать в согласованной юрисдикции, не поднимая инференс самостоятельно. Однако веса, план развития и часто контур управления остаются у поставщика.
• —Внешний закрытый API. Даёт быстрый доступ к новым возможностям и эластичной ёмкости. Плата — зависимость от API, тарифов, лимитов, политики данных и поведения модели.
• —Гибридная маршрутизация или каскад. Подбирает модель по типу задачи, цене и классу данных. Это не бесплатная переносимость, а отдельная платформа с классификацией, проверками и правилами безопасного резервного сценария.

API-совместимость означает совпадение формата запроса, но не поведения. Две модели с совместимой с OpenAI конечной точкой могут по-разному интерпретировать системный промпт, вызывать инструменты, продолжать работу после ошибки и переживать сжатие контекста. Настоящая переносимость проверяется на собственном наборе задач и отказов.

Ось 3. Инструменты

Для инструмента нужно фиксировать две координаты одновременно: происхождение артефакта и фактическое место исполнения.

Название «внутренний инструмент» ничего не говорит о месте исполнения. Локальный MCP-сервер из npm может работать на корпоративном ноутбуке с правами пользователя, а внешний SaaS-инструмент — принимать только узкую одноразовую операцию через прокси. Нужна карта не каталогов, а фактических потоков данных и полномочий.030303Хороший живой пример — Airbnb: по их публичному рассказу стандартизировались на MCP, подняли дюжину внутренних серверов и довели агентную разработку примерно до 60% команд. Это цифра самой компании, а не независимый замер. Разбирал их путь в канале.Книжный куб · Agentic coding at Airbnb03Хороший живой пример — Airbnb: по их публичному рассказу стандартизировались на MCP, подняли дюжину внутренних серверов и довели агентную разработку примерно до 60% команд. Это цифра самой компании, а не независимый замер. Разбирал их путь в канале.Книжный куб · Agentic coding at Airbnb

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

OpenCode

Проверено: репозиторий опубликован под MIT; клиент поддерживает много провайдеров и настраиваемый baseURL, встроенные, пользовательские и MCP-инструменты. В текущей документации по инструментам они включены по умолчанию, а permissions позволяют задать allow, ask и deny.

Из этого не следует: открытый и переносимый клиент не делает модель локальной; наличие правил не доказывает наличие изоляции средствами ОС; без корпоративного профиля безопасные значения остаются ответственностью пользователя или платформенной команды.

Codex CLI

Проверено: клиент открыт под Apache-2.0; конфигурация допускает пользовательских модельных провайдеров, в том числе внутренний прокси, Ollama и LM Studio; в CLI/IDE изолированная среда и подтверждения разделены, а изоляция опирается на механизмы ОС.

Из этого не следует: открытый клиент не означает, что модели OpenAI открыты или локальны; подключение другой конечной точки не гарантирует одинаковое качество агентного цикла и использования инструментов.

Claude Code

Проверено: официально описаны Claude API и поставка Claude через Amazon Bedrock, Google Vertex AI, Microsoft Foundry и Claude Platform on AWS; есть централизуемые permissions и изоляция средствами ОС.

Из этого не следует: это несколько путей поставки Claude, а не заявленная поддержка произвольной модели в собственном контуре; локальный клиент не означает локальный инференс — путь и хранение данных зависят от типа аккаунта и провайдера.

GLM-5

Проверено: карточка модели публикует веса под MIT и способы обслуживания (в карточке указано 754 млрд параметров), а Z.AI предлагает управляемый API.

Из этого не следует: открытые веса не означают «запустить на любом ноутбуке» и не снимают стоимость обслуживания; GLM в собственном контуре и GLM через API — разные конфигурации по данным, эксплуатации и отказам.

GigaChat

Проверено: это управляемый API с частичной совместимостью с OpenAI API и пользовательскими функциями; на странице продукта Сбер заявляет хранение данных на серверах в России и неиспользование запросов и ответов для обучения по умолчанию.

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

Практический вывод: OpenCode и Codex показывают, что открытая обвязка может работать с разными конечными точками. GLM-5 показывает, что одна модель может существовать и как открытые веса, и как сервис. GigaChat показывает отдельный класс регионально управляемой модели. Claude Code показывает, что один вендорский клиент может иметь несколько инфраструктурных путей к одной семье моделей. Ни один из примеров не сворачивает четыре свойства — открытость, владение моделью, локальность и контроль политики — в одно.

Модельный и инструментальный шлюзы — логические роли, а не обязательно отдельные микросервисы. Они могут быть сервисами, библиотеками в клиенте или частью управляемой платформы. Важен не микросервис, а возможность независимо обеспечить правила маршрутизации, идентичность, аудит и аварийное отключение: первый шлюз управляет тем, какие данные куда уходят, второй — тем, кто, что и от чьего имени может изменить.040404Забавно, насколько конвергентно к этой же схеме пришли Block, Uber и LinkedIn: модельный шлюз, инструментальный шлюз и реестр возможностей проступают у всех. Про это был пост о подходе с агентами в центре IDP.Книжный куб · Agent-first IDP04Забавно, насколько конвергентно к этой же схеме пришли Block, Uber и LinkedIn: модельный шлюз, инструментальный шлюз и реестр возможностей проступают у всех. Про это был пост о подходе с агентами в центре IDP.Книжный куб · Agent-first IDP

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

Дальше — не рейтинг продуктов, а восемь повторяемых конфигураций. Каждая описывается потоком данных, зоной ответственности, сильными сторонами и ограничениями, экономикой, привязкой, подходящими сценариями, характерными отказами и обязательной защитой. Общий минимум защиты у всех восьми один: изоляция средствами ОС, запрет исходящего трафика и небезопасного резервного сценария, закреплённые версии, OBO, сквозной трейс и аварийный выключатель — операционная форма собрана в чеклисте, поэтому «Обязательная защита» ниже перечисляет только специфику конфигурации.

Почему именно восемь

Формально кортеж «обвязка × модель × инструменты» даёт двадцать семь комбинаций, но большинство из них различаются только логотипами. Ниже отобраны операционные архетипы — варианты, которые по-разному отказывают и требуют разных границ. Конфигурации 1–5 — узлы сетки «обвязка × модель» от полностью своего стека до полностью чужого. Конфигурация 6 — не узел, а стратегия модельной оси: маршрутизация превращает выбор модели в политику. Конфигурация 7 — другая топология: модель вынесена из цепочки исполнения и оставлена только в планировании. Конфигурация 8 — анти-паттерн управления, включённый в разбор потому, что он уже живёт в организациях — независимо от того, знают ли они об этом. Если два варианта одинаково отказывают и одинаково защищаются, для этого разбора они — одна конфигурация.

1 · Полностью автономный или изолированный стек

пользователь → собственная или форкнутая обвязка → модель в собственном контуре → локальный или внутренний инструментальный шлюз → внутренние системы; в штатном режиме исходящий трафик отсутствует

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

Сильные стороны. Максимальный контроль размещения данных и версий; возможность работать в изолированном контуре; независимость от внешней доступности и внезапной смены API; воспроизводимое поведение на закреплённом наборе артефактов.

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

Экономика и зависимость от поставщика. Высокая фиксированная стоимость: GPU, платформенная команда, запас мощности и безопасный процесс обновлений — «нет API-счёта» не означает «нет стоимости инференса». Внешней зависимости почти нет, но остаётся привязка к обслуживающему стеку, формату весов и собственной ветке клиента.

Где уместна. Закрытые и оборонные контуры, данные без права передачи наружу, площадки с нестабильной связью.

Характерные отказы. Устаревшая модель или уязвимая зависимость надолго остаётся внутри; локальный агент получает слишком широкие права, потому что «периметр и так безопасен»; незаметно появляется внешний резервный сценарий; нехватка GPU превращается в общую недоступность.

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

2 · Своя обвязка с внешней передовой моделью

пользователь → собственная обвязка → корпоративный модельный шлюз → внешний API → собственный инструментальный шлюз → системы

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

Сильные стороны. Доступ к быстро обновляемым сильным моделям без эксплуатации GPU; полный контроль над доменной логикой, состоянием задачи и инструментальным слоем; модель можно менять через изолированный адаптер.

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

Экономика и зависимость от поставщика. Стоимость разработки плюс переменные API-затраты; при большом агентном трафике критичны кеш, лимиты шагов и стоимость повторов. Привязка умеренная на уровне протокола и высокая на уровне поведения, подсказок и проверок, настроенных под одну модель.

Где уместна. Доменные агенты, где преимущество — в процессе и инструментах, а передача классифицированного контекста наружу допустима.

Характерные отказы. Секрет попадает в подсказку или результат инструмента; ограничение частоты вызывает шторм повторов; контекст уходит не в тот регион; поставщик меняет псевдоним модели; журнал модельного шлюза сам становится хранилищем чувствительных данных.

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

3 · Готовый клиент с локальной моделью или моделью в собственном контуре

пользователь → OpenCode/Codex или другой настраиваемый клиент → Ollama / LM Studio / vLLM / внутренняя конечная точка → локальные и внутренние инструменты

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

Сильные стороны. Быстрый путь к локальному эксперименту; готовый UX, контекст и цикл инструментов без разработки клиента с нуля; код и подсказка могут не покидать управляемый контур.

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

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

Где уместна. Исследование открытых весов, чувствительный локальный код, временная автономная работа.

Характерные отказы. Модель выдаёт синтаксически валидный, но семантически неверный вызов инструмента; локальная конечная точка слушает внешний интерфейс без аутентификации; клиент при ошибке тихо переключается наружу; команда выполняется вне изолированной среды; разные ноутбуки дают разные результаты.

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

4 · Вендорский агент разработки с внутренним инструментальным шлюзом

разработчик → Claude Code / Codex или другой вендорский агент → модель поставщика → внутренний MCP/API-шлюз → IDP, репозитории, CI/CD и рабочая среда

Ответственность. Поставщик развивает клиент и модель; организация владеет каталогом инструментов, правилами действий, идентичностью агента, аудитом и интеграциями с системами.

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

Ограничения. Код и контекст могут идти внешнему поставщику; критические изменения клиента приходят по его графику; шлюз нужно проектировать как продукт, а не как механический MCP-адаптер к низкоуровневым API.

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

Где уместна. Корпоративная разработка: внешние модели разрешены, доступ к внутренним системам централизован.

Характерные отказы. Все вызовы идут от общей служебной учётной записи; результат инструмента из задачи или репозитория содержит инъекцию подсказки; MCP-сервер выставляет слишком низкоуровневые команды; подтверждение в клиенте не совпадает с фактическим действием шлюза.

Обязательная защита. Высокоуровневые инструменты с узкими схемами; политика как код и повторная авторизация на самом шлюзе; независимые пробный запуск и сравнение для опасных действий; аварийный выключатель — со всеми измерениями из чеклиста. Плюс общий минимум границ.

5 · Полностью управляемый SaaS-стек

пользователь → облачная обвязка → модель поставщика → облачная изолированная среда и соединители → репозитории и SaaS

Ответственность. Поставщик отвечает за большую часть исполнения, обновлений и базовой изоляции; заказчик — за арендатора, подключённые репозитории, области доступа OAuth, настройки хранения, процесс проверки и принятие результата.

Сильные стороны. Минимальное время до пилота; почти нет собственной эксплуатации модели и клиента; быстрые обновления; облачные задачи можно отделить от рабочей станции разработчика.

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

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

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

Характерные отказы. В облако попадает репозиторий или секрет, который команда считала локальным; соединитель OAuth имеет права шире задачи; срок хранения по умолчанию не соответствует политике; обновление меняет результативность; аудит нельзя выгрузить во внутренний SIEM.

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

6 · Мульти-модельная платформа с маршрутизацией и резервным сценарием

клиент/агент → модельный шлюз → классификатор политики → локальная, региональная или внешняя модель → инструментальный шлюз; резервный маршрут зависит от класса данных и задачи

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

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

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

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

Где уместна. Крупная платформа с несколькими классами данных и необходимостью переживать отказ провайдера.

Характерные отказы. Чувствительный запрос при отказе автоматически уходит во внешний API; дешёвая модель неверно классифицирует действие; каскад умножает стоимость; разные модели оставляют несовместимое состояние; псевдоним обновляется без регрессионной проверки.

Обязательная защита. Классификация данных до выбора маршрута и явно разрешённые пары «класс данных × регион × модель»; для закрытых классов — безопасная остановка при отказе вместо несимметричного резервного маршрута; причина маршрутизации в трейсе; проверки для каждого маршрута и перехода. Плюс общий минимум границ.

7 · Внешний планировщик с внутренним детерминированным исполнителем

пользователь → внутренний контроллер → санитизированный контекст во внешнюю модель → типизированный план → внутренний механизм политик и исполнитель → системы; внешняя модель не получает рабочих учётных данных и не вызывает системы напрямую

Ответственность. Поставщик даёт рассуждение; организация определяет язык намерений, проверяет план, исполняет операции, управляет транзакциями и решает, какие результаты вернуть модели.

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

Ограничения. Сложнее спроектировать полезный и достаточно узкий язык команд; очистка теряет контекст; длинный интерактивный цикл медленнее; модель всё равно может предложить опасный, но формально валидный план.

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

Где уместна. Операции с высокой ценой ошибки: инфраструктура, финансы, кадры, регулируемый контур с планированием на обезличенных данных.

Характерные отказы. Вредная инструкция прячется в строковом поле плана; валидатор проверяет JSON Schema, но не бизнес-инварианты; пробный запуск отличается от выполнения; модель узнаёт секрет из слишком подробного сообщения об ошибке; повтор выполняет операцию дважды.

Обязательная защита. Закрытый типизированный язык намерений без произвольной оболочки или SQL; семантическая проверка плана, идемпотентность и лимиты транзакции; фильтрация результатов и ошибок; контекст модели без учётных данных; журнал «намерение → решение политики → фактическое действие». Плюс общий минимум границ.

8 · Пользовательский агент с внешними MCP/SaaS-инструментами

личный или локальный клиент → выбранная модель → установленный пользователем MCP/плагин → внешний SaaS, часто с OAuth от имени пользователя

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

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

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

Экономика и зависимость от поставщика. Низкий порог входа, но плохо видимая полная стоимость: подписки, дублирование интеграций, расследование инцидентов и последующая централизация. Привязка распределена по клиенту, OAuth-связям, данным SaaS и конкретным MCP-серверам: заменить компонент легко, восстановить весь процесс трудно.

Где уместна. Личная продуктивность на низкорисковых данных; эксперименты в отдельном тестовом арендаторе.

Характерные отказы. Вредоносный или скомпрометированный MCP-пакет получает файлы и токены; OAuth запрашивает избыточные области доступа; сервер на локальном интерфейсе уязвим к подмене DNS; токен передаётся дальше без проверки получателя; инъекция подсказки из письма заставляет агента отправить данные; пользователь автоматически подтверждает серию похожих запросов.

Обязательная защита. Корпоративный реестр разрешённых MCP и версий с проверкой происхождения; OAuth с PKCE, проверкой получателя и короткими токенами; секреты в системном хранилище; раздельные личные и рабочие арендаторы; запрет высокорисковых инструментов записи; централизованный способ отозвать доступ. Плюс общий минимум границ.

В техническом блоге NIST CAISI перехват агента описан как разновидность косвенной инъекции подсказки: злоумышленник помещает инструкцию в данные — письмо, сайт, файл или репозиторий, — которые агент читает при выполнении легитимной задачи. В экспериментах NIST повторные попытки заметно меняли измеряемый риск, а среди сценариев были удалённое выполнение кода, массовая утечка и фишинг. Это не исправляется одной фразой в системном промпте: защиту нужно ставить на границах данных, идентичности и исполнения.050505Из книг про это мне нравится «The Developer’s Playbook for LLM Security» Стива Уилсона — крепкая база, хотя агентную часть поле уже переросло. А реальные кейсы злоупотреблений хорошо видны в threat-intelligence-отчёте Anthropic.Книжный куб · разбор книги Стива УилсонаКнижный куб · Anthropic Threat Intelligence05Из книг про это мне нравится «The Developer’s Playbook for LLM Security» Стива Уилсона — крепкая база, хотя агентную часть поле уже переросло. А реальные кейсы злоупотреблений хорошо видны в threat-intelligence-отчёте Anthropic.Книжный куб · разбор книги Стива УилсонаКнижный куб · Anthropic Threat Intelligence

Инъекция подсказки и перехват агента. Агент смешивает инструкции разработчика и внешние данные в одном контексте. Модель может знать, что сайт недоверенный, и всё равно выполнить скрытую инструкцию; чем больше инструментов и повторных попыток, тем больше поверхность атаки. Поэтому запрет должен жить в механизме политик и IAM: модель может предложить действие, но не должна сама решать, имеет ли она право его выполнить.

Утечка кода и секретов. Утечка идёт не только через подсказку в модель. Каналами становятся аргументы инструментов, результаты, трейсы, отчёты о сбоях, телеметрия, кеш, история оболочки и внешняя загрузка. Секрет, отфильтрованный из исходного запроса, может вернуться в контекст после чтения .env инструментом. Нужны одинаковые правила для входа, цикла инструментов и журналов.

Чрезмерные права и подмена доверенного посредника. Внутренний шлюз с одной служебной учётной записью опаснее внешнего API с узкой пользовательской областью доступа. Агент становится подменённым посредником, когда действует с полномочиями шлюза, а не инициатора. В рекомендациях MCP сквозная передача токена прямо считается антипаттерном: сервер должен принимать только токены, выпущенные для него, проверять получателя и получать отдельный токен нижестоящего сервиса. А спецификация авторизации MCP требует привязки токена к ресурсу и рекомендует минимальные области доступа.060606Как авторизация выглядит на настоящем масштабе, мы смотрели в книжном клубе на аналитическом докладе Zanzibar — глобальной ReBAC-системы Google. Многие идеи OBO растут оттуда.Книжный куб · whitepaper Zanzibar06Как авторизация выглядит на настоящем масштабе, мы смотрели в книжном клубе на аналитическом докладе Zanzibar — глобальной ReBAC-системы Google. Многие идеи OBO растут оттуда.Книжный куб · whitepaper Zanzibar

SSRF и подмена DNS. Обнаружение OAuth, динамические адреса обратного вызова и произвольный URL-инструмент открывают SSRF к конечным точкам метаданных и внутренним адресам. Локальный HTTP MCP без проверки Origin, аутентификации и правильной привязки может быть достигнут через подмену DNS из браузера — спецификация транспорта MCP требует проверять Origin и рекомендует локальным серверам слушать только локальный интерфейс.

Цепочка поставки готовых бинарей и MCP-серверов. Подписанный бинарь подтверждает издателя, но не безопасность поведения; открытый репозиторий позволяет аудит, но не доказывает, что установленный пакет собран именно из него. MCP-сервер или навык — исполняемый код и одновременно источник инструкций для модели: их нужно версионировать, проверять как зависимости приложения и запускать с минимальными правами. В презентации для ISPAB на площадке NIST среди мер названы подписанные манифесты, закреплённые версии и изоляция для сторонних MCP.070707Каждый разговор про цепочку поставки у меня заканчивается историей Log4Shell: критичную для всего интернета библиотеку сопровождала горстка волонтёров. Пересказывал её в канале со слов мейнтейнера Log4j.Книжный куб · история Log4Shell07Каждый разговор про цепочку поставки у меня заканчивается историей Log4Shell: критичную для всего интернета библиотеку сопровождала горстка волонтёров. Пересказывал её в канале со слов мейнтейнера Log4j.Книжный куб · история Log4Shell

Небезопасные резервные маршруты. «Если локальная модель не отвечает, пошлём во внешнюю» — это смена политики, а не повышение доступности. Резервный маршрут должен быть не менее допустимым для текущего класса данных; для закрытого контура безопасный результат отказа — остановить задачу, а не раскрыть контекст.

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

Изоляция только в подсказке или контейнере. Просьба модели «не ходить в сеть» не является сетевой политикой, а переменная окружения с proxy не запрещает прямое соединение. Нужен механизм ОС, гипервизора или изолированной среды, который физически ограничивает файловую систему, процессы и исходящий трафик. OpenAI отдельно описывает, что в Codex изоляция и подтверждения дополняют друг друга — одно не заменяет другое. Контейнер полезен, но при привилегированном режиме, смонтированном сокете Docker или широких учётных данных его граница фиктивна.080808Радикальный вариант ответа — «пусть изолированной средой будет сеть»: у Tailscale внутри песочницы лежат ключи-заполнители, а настоящие подставляются на сетевом уровне. Разбирал этот доклад в канале.Книжный куб · сеть как изолированная среда08Радикальный вариант ответа — «пусть изолированной средой будет сеть»: у Tailscale внутри песочницы лежат ключи-заполнители, а настоящие подставляются на сетевом уровне. Разбирал этот доклад в канале.Книжный куб · сеть как изолированная среда

Аудит без происхождения события. Записи «агент запустил развёртывание» недостаточно. Для расследования нужны пользователь и идентичность агента, исходное намерение, модель и версия, маршрут, хеш конфигурации, название и версия инструмента, решение политики, выданные области доступа, аргументы с контролируемой очисткой, фактический эффект и результат подтверждения. Сам журнал при этом нужно защищать как чувствительные данные.

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

• —Политика как код. Шлюз проверяет ресурс, действие, данные, субъект и среду исполнения; системная подсказка лишь объясняет правило модели, но не обеспечивает его.
• —Проверки и красная команда. Тестируются не только ответы, но и отказ от действия, инъекции через результат инструмента, повторные атаки, RCE и вывод данных; технический блог NIST CAISI подчёркивает, что защита и оценки должны адаптироваться к новым атакам.
• —Независимая проверка эффекта. Проверки схемы недостаточно: опасное действие подтверждает механизм политик, пробный запуск, бизнес-инвариант или человек, не участвовавший в генерации плана.

Главное здесь: «внутренний» не означает безопасный, а «внешний» — небезопасный. Решают фактические права, путь данных, возможность отзыва и границы, которые система обеспечивает технически. Это совпадает с направлением OWASP Top 10 for Agentic Applications и отдельного OWASP MCP Top 10: поверхность атаки распределена между рассуждением, памятью, инструментами, идентичностью, протоколом и контролем человеком.

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

Колонка «Структура затрат» сознательно не считает деньги: бюджеты, контракты, FinOps и переговоры с поставщиками разобраны в лонгриде об экономике AI в разработке, а здесь остаются конфигурация и границы.

Качество, эксплуатация и экономика

Переносимость, данные и контроль

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

Пилот. Начинать с конфигурации 4 или 5, но сузить задачу сильнее, чем кажется комфортным: один репозиторий, один класс данных, только чтение или запрос на слияние вместо прямой записи, без рабочих учётных данных. Цель пилота — измерить принятую работу, отказ и нагрузку на проверку, а не доказать, что агент способен вызвать много инструментов. Уже в пилоте нужны единый трейс и сценарий инъекции подсказки.

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

Регулируемый контур. Если данные не могут покидать периметр, выбирать 1 и технически запрещать внешний резервный сценарий. Если наружу допустимо передать обезличенную постановку без учётных данных и системных данных, рассмотреть 7. В обоих случаях внутренние инструменты всё равно должны работать с OBO, узкими областями доступа и изоляцией средствами ОС и сети: слово «закрытый» не исправляет подмену доверенного посредника.090909Конференц-версия этого разбора с акцентом на большой финтех — пути данных, рекомендации Банка России и целевой портфель конфигураций — есть в деке для Podlodka AI Engineers Club.Дека Podlodka · версия для финтеха09Конференц-версия этого разбора с акцентом на большой финтех — пути данных, рекомендации Банка России и целевой портфель конфигураций — есть в деке для Podlodka AI Engineers Club.Дека Podlodka · версия для финтеха

Индивидуальная разработка. Для чувствительного локального кода подходит 3 при явной проверке качества модели и изолированной среды. Для низкорисковой личной автоматизации возможна 8, но рабочие и личные арендаторы, токены и MCP-серверы нужно разделять. Если пользовательскому сценарию нужны рабочие права записи, он перестал быть личным инструментом и должен пройти через конфигурацию 4 или 7.

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

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

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