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

Открытый код клиента не делает модель локальной. Self-hosted-модель не делает безопасными инструменты. Внутренний MCP-сервер не ограничивает права сам по себе. И наоборот: внешний модельный API не обязательно получает производственные секреты, если планирование отделено от исполнения, контекст фильтруется, а полномочия остаются во внутреннем шлюзе.

Этот материал продолжает формулу Agent = Model + Harness и идеи model/tool gateway из agent-first-подхода к внутренним платформам разработки. Но для рабочего выбора формулу полезно расширить:

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

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

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

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

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

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

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

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

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

Собственная разработка или форк даёт максимум свободы в цикле планирования, формате контекста, политике инструментов и интеграции с внутренней платформой. Цена этой свободы — постоянная работа: совместимость с моделями, сжатие контекста, восстановление после ошибок, UX подтверждений, sandbox для разных ОС, трассировка и обновление зависимостей. Форк также создаёт собственную ветку supply chain: уязвимости upstream уже не исправляются автоматически.

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

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

Ось 2. Модель

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

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

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

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

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

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

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

OpenCode

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

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

Codex CLI

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

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

Claude Code

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

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

GLM-5

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

Из этого не следует: open weights не означают «запустить на любом ноутбуке» и не снимают стоимость serving; self-hosted GLM и GLM через API — разные конфигурации по данным, эксплуатации и отказам.

GigaChat

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

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

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

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

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

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

пользователь → собственная/форкнутая обвязка → self-hosted модель → локальный или внутренний инструментальный шлюз → внутренние системы; в штатном режиме egress отсутствует

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

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

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

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

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

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

Обязательная защита. Подписанные и закреплённые версии моделей, контейнеров, клиента и MCP-серверов; закрытый реестр артефактов; запрет egress по умолчанию; выделенная идентичность агента; read/write-разделение инструментов; OS-enforced sandbox; offline-процесс доставки исправлений; централизованные логи; kill switch. Air-gap нужно регулярно проверять сетевым тестом, а не считать свойством схемы.

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

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

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

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

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

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

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

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

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

3 · Готовый клиент с локальной или self-hosted моделью

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

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

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

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

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

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

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

Обязательная защита. Закрепить клиент, модель, шаблоны и параметры serving; вести матрицу реально поддержанных возможностей; тестировать tool calling, отмену, compaction и восстановление после ошибки; запретить неразрешённый fallback; bind локального endpoint на loopback или auth; отдельный профиль ОС и sandbox; централизованный безопасный конфиг.

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

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

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

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

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

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

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

Характерные отказы. Все вызовы идут от общего service account; tool output из issue или репозитория содержит prompt injection; MCP-сервер выставляет слишком низкоуровневые команды; подтверждение в клиенте не совпадает с фактическим действием шлюза.

Обязательная защита. On-behalf-of identity вместо общих токенов; короткоживущие и привязанные к audience токены; высокоуровневые инструменты с узкими схемами; отдельные read/write capabilities; policy-as-code и повторная авторизация на шлюзе; независимый dry-run/diff для опасных действий; сквозной trace; kill switch по пользователю, клиенту и инструменту.

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

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

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

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

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

Экономика и lock-in. Низкая начальная и платформенная стоимость, но переменные расходы растут с числом мест, задач и коннекторов; дополнительно оплачиваются корпоративная проверка, договорная работа и контроль shadow usage. Lock-in высокий: клиент, модель, среда исполнения, состояние задач и коннекторы часто принадлежат одному control plane.

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

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

Обязательная защита. Enterprise-tenant и договорные режимы данных; allowlist репозиториев и типов задач; минимальные scopes коннекторов; секреты только в предназначенную фазу и не в model context; branch protection и независимый review; экспорт доступных логов; регулярная проверка retention и региона; план отключения и выгрузки данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обязательная защита. Закрытый типизированный язык намерений без произвольного shell/SQL; семантическая policy-проверка; OBO-идентичность и workflow-bound token; идемпотентность; dry-run и независимый diff; лимиты транзакции; ручное подтверждение высокорисковых изменений; фильтрация результатов и ошибок; model context без credentials; журнал «намерение → решение политики → фактическое действие».

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

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

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

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

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

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

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

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

Обязательная защита. Корпоративный реестр разрешённых MCP и версий; проверка происхождения, подписи и lockfile; sandbox локального сервера; bind на loopback, проверка Origin и auth; OAuth с PKCE, проверкой audience и короткими токенами; хранение секретов в keyring; раздельные личные и рабочие tenants; узкие scopes; запрет высокорисковых write-инструментов; централизованный способ отозвать доступ.

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

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

Утечка кода и секретов. Утечка идёт не только через prompt в модель. Каналами становятся tool arguments, результаты, traces, crash reports, телеметрия, кеш, shell history и внешний fetch. Секрет, отфильтрованный из исходного запроса, может вернуться в контекст после чтения .env инструментом. Нужны одинаковые правила для входа, tool loop и журналов.

Чрезмерные права и confused deputy. Внутренний шлюз с одним service account опаснее внешнего API с узким пользовательским scope. Агент становится confused deputy, когда действует с полномочиями шлюза, а не инициатора. В рекомендациях MCP token passthrough прямо считается антипаттерном: сервер должен принимать только токены, выпущенные для него, проверять audience и получать отдельный downstream token. А спецификация авторизации MCP требует привязки токена к ресурсу и рекомендует минимальные scopes.

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

Supply chain готовых бинарей и MCP-серверов. Подписанный бинарь подтверждает издателя, но не безопасность поведения; открытый репозиторий позволяет аудит, но не доказывает, что установленный пакет собран именно из него. MCP-сервер или skill — исполняемый код и одновременно источник инструкций для модели: их нужно версионировать, проверять как зависимости приложения и запускать с минимальными правами. В материалах NIST для ISPAB среди мер названы подписанные манифесты, закреплённые версии и sandbox для сторонних MCP.

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

Approval fatigue. Подтверждение каждой команды не создаёт informed consent: пользователь быстро учится нажимать Allow, а агент может разбить одно опасное действие на серию невинно выглядящих. Подтверждение должно показывать итоговый effect — какие данные уйдут, от чьего имени, какой ресурс изменится и можно ли откатить; повторную проверку опасного действия обязан делать шлюз.

Sandbox только в промпте или контейнере. Просьба модели «не ходить в сеть» не является сетевой политикой, а переменная окружения с proxy не запрещает прямое соединение. Нужен механизм ОС, hypervisor или изолированной среды, который физически ограничивает filesystem, процессы и egress. OpenAI отдельно описывает, что в Codex sandbox и approvals дополняют друг друга — одно не заменяет другое. Контейнер полезен, но при привилегированном режиме, смонтированном Docker socket или широких credentials его граница фиктивна.

Аудит без происхождения события. Лог «агент вызвал deploy» недостаточен. Для расследования нужны пользователь и agent identity, исходное намерение, модель и версия, route, hash конфигурации, tool name и версия, решение policy, выданные scopes, аргументы с контролируемой redaction, фактический effect и результат подтверждения. Сам лог при этом нужно защищать как чувствительные данные.

1. 01OS-enforced sandbox: файловая система, процессы и сеть ограничены независимо от поведения модели.
2. 02Egress deny-by-default: разрешены конкретные домены, методы и, где возможно, назначения; DNS и прямые IP учитываются отдельно.
3. 03Least privilege и OBO: агент действует от имени инициатора в рамках задачи, а не с постоянным общим токеном.
4. 04Короткоживущие credentials: токен ограничен audience, scope, временем и желательно workflow/task ID.
5. 05Allowlist инструментов: capability выдаётся по классу задачи и данных; обнаружение MCP не означает автоматическое доверие.
6. 06Разделение read/write: чтение, подготовка изменения и commit — разные capabilities и уровни доверия.
7. 07Policy-as-code: шлюз проверяет ресурс, действие, данные, субъект и среду исполнения; системный промпт лишь объясняет правило модели.
8. 08Закреплённые и подписанные версии: клиент, модель, system prompt, MCP, skill, контейнер и policy входят в воспроизводимый release.
9. 09Централизованные traces и алерты: необычный egress, новый инструмент, рост повторов, массовое чтение и смена маршрута видны в одном следе.
10. 10Evals и red team: тестируются не только ответы, но и отказ от действия, injection через tool output, повторные атаки, RCE и exfiltration. NIST подчёркивает, что защита и оценки должны адаптироваться к новым атакам.
11. 11Kill switch: отдельно для модели, маршрута, клиента, инструмента, пользователя и write-класса действий.
12. 12Независимая проверка эффекта: schema validation недостаточна; опасное действие проверяет policy engine, dry-run, business invariant или человек, не участвовавший в генерации плана.

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

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

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

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

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

Пилот. Начинать с конфигурации 4 или 5, но сузить задачу сильнее, чем кажется комфортным: один репозиторий, один класс данных, read-only или pull request вместо прямой записи, без production credentials. Цель пилота — измерить принятую работу, отказ и нагрузку на review, а не доказать, что агент способен вызвать много инструментов. Уже в пилоте нужен единый trace и сценарий prompt injection.

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

Регулируемый контур. Если данные не могут покидать периметр, выбирать 1 и технически запрещать внешний fallback. Если наружу допустимо передать обезличенную постановку без credentials и системных данных, рассмотреть 7. В обоих случаях внутренние инструменты всё равно должны работать с OBO, узкими scopes и OS/network sandbox: слово «закрытый» не исправляет confused deputy.

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

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

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

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