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

Открытый код клиента не делает модель локальной. Модель в собственном контуре не делает безопасными инструменты. Внутренний 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Где уместна. Корпоративная разработка, где разрешены внешние модели, но доступ к Jira, GitHub/GitLab, CI, облакам и рабочей среде должен оставаться централизованным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обязательная защита. Корпоративный реестр разрешённых MCP и версий; проверка происхождения, подписи и файла закрепления версий; изоляция локального сервера; привязка к локальному интерфейсу, проверка Origin и аутентификация; 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 внутри песочницы лежат ключи-заполнители, а настоящие подставляются на сетевом уровне. Разбирал этот доклад в канале.Книжный куб · сеть как изолированная среда

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

1. 01Изоляция средствами ОС: файловая система, процессы и сеть ограничены независимо от поведения модели.
2. 02Запрет исходящего трафика по умолчанию: разрешены конкретные домены, методы и, где возможно, назначения; DNS и прямые IP учитываются отдельно.
3. 03Минимальные привилегии и OBO: агент действует от имени инициатора в рамках задачи, а не с постоянным общим токеном.
4. 04Короткоживущие учётные данные: токен ограничен получателем, областью доступа, временем и желательно идентификатором рабочего процесса или задачи.
5. 05Список разрешённых инструментов: возможность выдаётся по классу задачи и данных; обнаружение MCP не означает автоматическое доверие.
6. 06Разделение чтения и записи: чтение, подготовка изменения и коммит — разные возможности и уровни доверия.
7. 07Политика как код: шлюз проверяет ресурс, действие, данные, субъект и среду исполнения; системная подсказка лишь объясняет правило модели.
8. 08Закреплённые и подписанные версии: клиент, модель, системная подсказка, MCP, навык, контейнер и политика входят в воспроизводимый выпуск.
9. 09Централизованные трейсы и оповещения: необычный исходящий трафик, новый инструмент, рост повторов, массовое чтение и смена маршрута видны в одном трейсе.
10. 10Проверки и красная команда: тестируются не только ответы, но и отказ от действия, инъекции через результат инструмента, повторные атаки, RCE и вывод данных. тот же технический блог NIST CAISI подчёркивает, что защита и оценки должны адаптироваться к новым атакам.
11. 11Аварийный выключатель: отдельно для модели, маршрута, клиента, инструмента, пользователя и класса записывающих действий.
12. 12Независимая проверка эффекта: проверки схемы недостаточно; опасное действие проверяет механизм политик, пробный запуск, бизнес-инвариант или человек, не участвовавший в генерации плана.

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

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

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

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

Дерево намеренно не начинает с продукта. Сначала определяются допустимый путь данных, цена действия и операционная ответственность — только после этого выбираются клиент и модель. Если данные не могут покидать контур и нужна настоящая изоляция от сети — конфигурация 1; если допустим обезличенный план — 7. Если нужно действовать во внутренних системах и есть платформенная команда — 4; без неё — ограниченный SaaS-пилот 5. Маршрутизация 6 добавляется только после появления масштаба и собственных проверок, а личный стек 8 остаётся для низкорисковых экспериментов в отдельном арендаторе.

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

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

Регулируемый контур. Если данные не могут покидать периметр, выбирать 1 и технически запрещать внешний резервный сценарий. Если наружу допустимо передать обезличенную постановку без учётных данных и системных данных, рассмотреть 7. В обоих случаях внутренние инструменты всё равно должны работать с OBO, узкими областями доступа и изоляцией средствами ОС и сети: слово «закрытый» не исправляет подмену доверенного посредника.

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

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

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

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