Глава 9. Песочница выполнения и MCP как интеграционный контракт¶

1. Почему слой выполнения без песочницы быстро становится слишком доверчивым¶

В нашем сквозном кейсе поддержки это выглядит очень приземленно: агент уже решил проверить статус заявки или создать тикет через внешнюю систему. С этого момента вопрос стоит уже не “какой следующий умный шаг”, а “через какую границу система вообще разрешит этот шаг выполнить”.

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

Агент уже умеет:

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

Если все это исполняется “как есть”, без изоляции и контрактов, платформа очень быстро получает проблемы:

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

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

2. Песочница это не обязательно контейнер, а прежде всего режим ограничений¶

Когда говорят “песочница”, многие сразу думают о Docker, VM или отдельном процессе. Это возможные реализации, но архитектурно важнее другое: песочница задает пределы того, что может сделать возможность.

Хорошая песочница обычно ограничивает:

• доступ к сети;
• доступ к файловой системе;
• доступ к секретам;
• бюджет CPU и памяти;
• разрешенные системные вызовы или режим выполнения;
• время жизни операции.

То есть песочница отвечает на вопрос: “Что произойдет, если инструмент или адаптер поведет себя хуже, чем мы ожидали?”

Это не только безопасность. Это еще и контроль радиуса поражения.

2.1. Полезно различать уровни изоляции¶

На практике слово sandbox часто скрывает сразу несколько разных уровней.

• logical isolation: проверки политик, контракты возможностей, списки разрешений;
• process isolation: отдельный процесс, тайм-аут, лимиты ресурсов;
• runtime isolation: отдельное исполняемое окружение, урезанная файловая система, ограниченный исходящий сетевой доступ, секреты по минимуму.

Это важно, потому что многие команды считают, что у них “есть песочница”, хотя на деле у них есть только первый уровень. Для операций чтения с низким риском этого иногда хватает, но для выполнения с высоким риском почти всегда нужна более жесткая граница исполнения.¹⁷

Хороший практический вопрос здесь такой: если возможность начнет вести себя хуже нормы, что именно ее остановит: логика, процесс или сама среда исполнения?

3. Нельзя считать внешнюю интеграцию просто функцией¶

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

Но реальная интеграция почти всегда:

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

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

4. MCP полезен именно как контрактный слой¶

MCP удобен не потому, что это модное слово, а потому что он помогает явно описать границу между агентом и внешней возможностью.

В хорошем дизайне MCP дает несколько полезных вещей:

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

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

Заметка о сквозных сценариях песочницы и MCP: песочница и контракт MCP должны быть проверены на всех трех канонических сценариях. Разбор обращений поддержки требует ограничений песочницы для записей в службе поддержки, MCP-инструментов с учетом подтверждения и пути сверки после тайм-аута. Внутренний ассистент знаний требует MCP-ресурсов только для чтения, сетевого доступа в пределах корпуса, проверки источников и запрета на скрытые побочные эффекты. Координация инцидентов требует изолированных адаптеров эскалации, областей уведомлений, принудительной проверки роли реагирующего и аварийных путей, которые не обходят аудиторский след.

4.1. MCP — это граница безопасности, а не просто удобный коннектор¶

Как только через MCP проходит доступ к данным, инструментам записи или средам выполнения, он становится границей безопасности. Через нее могут прийти не только полезные результаты инструментов, но и вредные инструкции, подмененные описания инструментов, избыточные OAuth-области, сценарии подставленного посредника (confused deputy) и риск компрометации самой цепочки поставки сервера.

Кейс Microsoft с MCP tool poisoning хорошо уточняет эту границу: tool descriptions as system prompts.²⁵ Если ранее одобренный server незаметно меняет description при прежнем имени tool, runtime может снова доверить ему действие без нового human review — это silent re-trust, а не просто metadata update. Поэтому review должен смотреть description diff, owner/provenance, imperative language внутри документационного поля, new endpoints, расширенные параметры и необычные query patterns. Контроль здесь — не только least privilege, но и least agency: запретить Allow all tool access, требовать approval для high-impact actions и алертить на drift поведения агента после изменения tool metadata.

Практический контракт для этой границы должен отвечать минимум на пять вопросов:

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

Если этих ответов нет, MCP не исчезает как риск — он просто становится неявным контуром доверия внутри поверхности платформы.

4.2. Матрица угроз для MCP¶

Для MCP полезно держать модель угроз MCP не как общий страх перед интеграциями, а как проверочную матрицу у каждой подключаемой возможности. Официальные материалы MCP отдельно подчеркивают запрет сквозной передачи токена (token passthrough), проверку областей доступа, ограничения HTTPS/SSRF и защиту дескрипторов прикладного состояния; это делает матрицу не опциональным украшением, а частью авторизационного и эксплуатационного контракта.²¹²² Минимальный вариант выглядит так:

• отравление инструмента (tool poisoning) — описание инструмента или результат пытаются изменить поведение модели; контроль: отделять результаты инструментов от инструкций и держать список разрешенных контрактов.
• подмена после одобрения (rug pull attack) — ранее одобренный MCP-сервер меняет инструменты, области доступа или поведение после ревью; контроль: фиксация версии, повторная аттестация, проверка различий и быстрый путь карантина.
• маскировка инструмента (tool shadowing) — новый инструмент маскируется под похожий одобренный инструмент и перехватывает намерение модели; контроль: уникальные имена возможностей, владение реестром и семантическое ревью перед публикацией.
• подставленный посредник (confused deputy) — агент вызывает действие с чужими или слишком широкими делегированными полномочиями; контроль: проверка субъекта, привязки к цели, состояния подтверждения и решения политики прямо перед побочным эффектом.
• избыточные области доступа (over-scoped tokens) — MCP-сервер получает больше OAuth-областей доступа, чем нужно конкретной операции; контроль: короткоживущие токены с ограниченными областями доступа, раздельные области доступа по инструментам и запрет широких постоянных секретов.
• вывод данных через разрешенные каналы (data exfiltration through legitimate channels) — данные уходят через разрешенный результат инструмента, уведомление или комментарий в тикете; контроль: проверки DLP, классификация результатов, границы арендатора и ревью для рискованных записей.
• компрометация цепочки поставки (supply-chain attack) — скомпрометированный сервер, пакет или адаптер становится доверенной возможностью; контроль: происхождение, подписанные артефакты, ревью зависимостей и закрепленная ответственность владельца.
• повтор или подмена сообщений (replay/tampering) — запрос, ответ или сеанс с сохранением состояния переигрываются или меняются между шагами; контроль: подпись запросов, nonce/ключи идемпотентности, корреляция трасс и срок жизни сессии.
• выход из песочницы (sandbox escape) — инструмент или адаптер выходит за пределы сетевой, файловой или процессной границы; контроль: эфемерная песочница, минимальные правила выхода во внешнюю сеть, изоляция секретов и сдерживание на уровне среды исполнения.

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

Минимальные критерии приемки MCP-подключения:

1. Сервер есть в утвержденном реестре, владелец и версия контракта видимы.
2. Токен выпущен именно для MCP-сервера или его resource audience, а не проброшен вслепую из другого слоя.
3. Области доступа ограничены конкретной операцией и не требуют широкого постоянного секрета.
4. Изменение схемы инструмента, описания или области доступа запускает повторное ревью.
5. Результат инструмента считается недоверенным содержимым до фильтрации и классификации.
6. В трассе остаются mcp_server_id, tool_contract_version, scope_review, quarantine_state и ссылки на доказательства.

4.3. Минимальный контракт MCP-сервера¶

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

mcp_server:
  owner: platform-integrations
  approved_registry_id: mcp.support.ticketing.v3
  schema_hash: sha256:...
  tool_definition_hash: sha256:...
  allowed_origins:
    - agent-runtime-prod
  auth_mode: delegated_oauth
  token_scope:
    - ticket.read
    - ticket.write_limited
  token_ttl: 15m
  user_delegation_required: true
  server_isolation_profile: remote_ephemeral_sandbox
  return_value_filtering: strip_instructions_and_classify_data
  replay_protection: nonce_and_trace_bound_signature
  schema_change_requires_review: true

Эти поля нужны не ради бюрократии. schema_hash и tool_definition_hash ловят внедрение схемы инструмента и подмену после подтверждения. token_scope, token_ttl и user_delegation_required ограничивают сценарии подставленного посредника (confused deputy). return_value_filtering считает результаты инструментов недоверенным содержимым, включая внедрение инструкций через результаты инструментов. server_isolation_profile и replay_protection делают выход из песочницы, повтор воспроизведения и подмену достаточно видимыми для сдерживания.

4.4. Полезно не путать узел, клиент и сервер MCP¶

Отсюда следует короткое правило: tool output is an attack surface. remote tool может измениться после approval: владелец сервера меняет schema, результат, redirect, resource body или hidden instruction, а host продолжает считать интеграцию уже согласованной. Поэтому onboarding remote tools лучше начинать с fake data first: сначала подключить synthetic tenant, synthetic secrets и безопасные fixtures, записать реальные traces и только после validation давать tool живые credentials или production data.

Еще один полезный паттерн из Google ADK — metadata registry + runtime schema injection.²⁷ Анти-паттерн называется прямо: Static Prompting, когда все JSON schemas, Pydantic classes и tool definitions заранее кладутся в system prompt. В высококардинальных доменах это дает context bloat и Attention Diffusion: модель начинает смешивать поля dormant schemas с активным payload.

В переносимом runtime contract структурные правила должны жить не в промпте, а в registry entry с schema_descriptor_id, schema_version, field metadata, mapping rules и validation_hook. Agent сначала делает lightweight discovery, затем runtime загружает нужный descriptor, вызывает Polymorphic Validator на boundary перед tool/API call и пишет в trace выбранный schema source of truth, runtime validation boundary, validation result и failure mode. Так один reasoning agent может работать с разными domain forms, но не становится носителем всех структурных правил сразу.

4.4. Localhost не является trust boundary для браузерных агентов¶

AutoJack, описанный Microsoft Defender Security Research, полезен как короткая проверка зрелости этой главы: недоверенная веб-страница, которую открыл browsing-agent, смогла пересечь loopback boundary, обратиться к локальному MCP WebSocket и превратить параметры подключения в запуск процесса на host.²³ Конкретная уязвимость была закрыта до PyPI-релиза затронутой MCP-поверхности, но паттерн важнее бага.

Архитектурный вывод простой: localhost, 127.0.0.1 и Origin allowlist не являются достаточным контролем, если на той же машине работает агент с browser tool, Playwright-backed surfer, code execution tool или любым механизмом, который может открыть WebSocket/HTTP-запрос от имени локального процесса. Для такой системы внешний HTML/JavaScript уже не “где-то в интернете”; он может стать confused deputy, который пользуется локальной сетевой позицией агента.

Минимальный hardening для локальных MCP/debug/control каналов:

• не считать loopback authentication boundary;
• требовать authn/authz на MCP/control-plane endpoints, включая WebSocket paths;
• проверять purpose binding и policy decision перед запуском любого subprocess-backed MCP server;
• хранить параметры запуска server-side или в подписанном nonce-bound artifact, а не принимать command/args из query string;
• allowlist-ить исполняемые MCP-серверы и профили аргументов;
• запускать browser tools с отдельной process/network identity, которой запрещен доступ к privileged local services;
• писать trace event для попыток crossing: внешняя страница, локальный канал, policy result, executable decision и containment action.

Если local MCP нужен только для прототипа, это должно быть прямо отражено в capability registry: низкие привилегии, отдельный OS user/container, короткоживущие credentials и запрет на совместное размещение с агентом, который рендерит недоверенный web content.

4.5. Prompt-to-tool-to-execution требует отдельного hardening¶

Кейс Microsoft “When prompts become shells” добавляет соседний failure mode: prompt injection не обязан дотягиваться до localhost, если agent framework уже открыл tool, который может интерпретировать model-controlled parameters как paths, code, templates или commands.²⁴ Форма атаки — prompt-to-tool-to-execution: недоверенное содержимое направляет модель, модель выдает attacker-controlled input, framework разбирает его как tool arguments, а слабый adapter превращает это в host execution.

Правило execution layer совпадает с правилом этой главы для MCP: model output не является authority. Execution-adjacent tools должны быть deny-by-default, зарегистрированы через capability contract, защищены typed validation, canonical path checks, operation allowlists и per-tool sandbox. Им также нужен audit event до побочного эффекта, а не только после него, чтобы расследование видело prompt source, redacted arguments, validation result, selected sandbox profile и policy decision.

4.6. Сетевая модель угроз для агентов¶

Microsoft Research отдельно показывает, что риск меняется, когда один агент превращается в сеть агентов: уязвимость может жить не в одном tool wrapper, а в том, как агенты доверяют сообщениям друг друга.²⁶ Практическое правило для такой системы: peer message is data, not authority. Сообщение от соседнего агента не должно повышать полномочия, менять цель, запускать запись или становиться системной инструкцией, пока runtime, policy layer или human approval явно не повысили его доверие.

Такой networked-agent threat model полезно держать рядом с MCP и A2A. Он добавляет четыре failure modes:

• propagation — вредная инструкция, poisoned summary или ложная задача передается дальше как обычный контекст;
• amplification — один слабый сигнал превращается в массовый fan-out, повторные tool calls или каскадное уведомление;
• trust capture — группа агентов начинает подтверждать друг друга, хотя все они зависят от одного недоверенного источника;
• invisibility — оператор видит отдельные локальные traces, но не видит межагентный путь, по которому риск перешел границы.

Минимальные controls похожи на network security, но применяются к агентной семантике: Sybil resistance для независимости голосов, hop and rate limits для передачи задач, capability scoping на каждом ребре графа, cross-agent tracing для пути сообщения, provenance logs для исходного автора и quarantine для peer-originated instructions, которые пытаются стать authority. В eval это должно выглядеть как сценарий, где соседний агент просит превысить полномочия, переупаковывает prompt injection или запускает слишком широкий fan-out, а система доказывает, что instruction осталась данными.

4.7. Полезно не путать узел, клиент и сервер MCP¶

Вокруг MCP часто возникает лишняя путаница, потому что слова кажутся знакомыми, а роли у них довольно конкретные.

Полезно держать в голове такую картину:

• host - это узел, то есть приложение или рантайм, который управляет сессией и решает, к каким возможностям вообще подключаться;
• client - это протокольный компонент, который узел создает для связи с конкретным MCP-сервером;
• server - это граница, которая публикует инструменты, ресурсы и другие поверхности возможностей, а затем возвращает структурированный результат.

Из этого следуют две очень практичные вещи:

• один узел может одновременно держать несколько клиентов;
• один рантайм агента может работать сразу с несколькими MCP-серверы, не смешивая их в один неразличимый комок интеграций.

Это кажется терминологической мелочью, но она полезна. MCP-клиент — это не пользовательский интерфейс и не "сам агент". Это транспортный и контрактный слой между узлом и конкретной серверной границей.

flowchart LR
    A["Рантайм агента"] --> B["Слой выполнения"]
    B --> C["Политика и валидация"]
    C --> D["MCP-клиент"]
    D --> E["MCP-сервер"]
    E --> F["Типизированный адаптер"]
    F --> G["Внешний API / система"]
    G --> F
    F --> E
    E --> D
    D --> B

5. Зачем выносить адаптеры из ядра рантайма¶

Как только MCP перестает быть одной-двумя вручную подключенными интеграциями, возникает следующий вопрос: кто вообще управляет MCP-поверхностью как частью платформы, а не как набором локальных удобств разработчиков? Здесь полезен недавний материал Cloudflare, потому что он смещает акцент с “умеет ли агент говорить по MCP” на “как команда открывает, утверждает, маршрутизирует и аудирует MCP-эндпоинты в масштабе”.¹

Обычно это довольно быстро ведет к явному контуру управления MCP:

• локальные экспериментальные MCP-серверы для экспериментов;
• управляемые удаленные MCP-серверы для общих эксплуатационных возможностей;
• слой обнаружения или портал для одобренных серверов;
• контроль идентичности на границе доступа;
• аудит и DLP-контроли вокруг самого пути MCP.

Это дает сразу несколько выгод:

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

Это особенно ценно, когда одни инструменты работают только на чтение, другие пишут во внешние системы, а третьи вообще выполняют код или shell-команды.

5.1. Корпоративный MCP почти всегда требует контура управления, а не только протокола¶

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

Более зрелая модель относится к удаленному MCP как к части контура управления платформы:

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

Как только идентичность становится центральной частью этой модели, появляется еще один важный вопрос: кто именно авторизует действие MCP и в чьем контексте пользователя это происходит? Управляемая OAuth-граница полезна здесь тем, что не дает каждому MCP-серверу придумывать свою отдельную историю учетных данных.

Обычно это означает следующее:

• делегирование пользователя выдается через управляемый слой идентичности;
• токены короткоживущие и привязаны к конкретному субъекту;
• MCP-сервер получает ограниченный доступ вместо широких постоянных секретов;
• платформа может отозвать или ротировать доступ без переписывания каждого адаптера.

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

Материал Google Cloud про Gemini Enterprise Agent Platform remote MCP server показывает ту же границу в более managed-виде.⁹ Внешний агент или IDE-клиент не получает произвольный набор облачных секретов; он подключается к стандартизированной удаленной MCP-точке внутри Google Cloud, видит toolsets вроде generation, prediction, notebooks, endpoints, models, tuning, evaluation и prompts, а discovery идет через Agent Registry. Архитектурный вывод: управляемая удаленная MCP-точка подключения может быть capability boundary, если discovery, IAM Deny policies, tenant/data boundary, observability и lifecycle ownership живут на стороне платформы, а не в локальном конфиге клиента.

Рамка AWS MCP Gateway and Registry делает этот контур управления более конкретным.⁸ Она рассматривает MCP servers, AI agents, skills, workflows и другие AI assets как каталожные сущности, а не как разрозненные endpoints. Полезный вывод для этой главы не в конкретном стеке реализации, а в разделении ответственности: registry управляет discovery, ownership, security scanning, fine-grained access control и federation; gateway маршрутизирует MCP tool calls и пишет audit log. Это более чистый платформенный контракт, чем ситуация, где каждый агент или desktop client хранит собственный приватный список серверов.

5.2. Теневой MCP — это новая версия проблемы теневых API¶

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

У этого антипаттерна обычно быстро видны характерные признаки:

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

Полезный платформенный чеклист здесь очень простой:

• Этот MCP-сервер есть в одобренном реестре?
• Кто отвечает за его жизненный цикл и реагирование на инциденты?
• Какая граница идентичности защищает доступ?
• Какой набор политик управляет операциями записи и подтверждениями?
• Какая телеметрия доказывает, какой агент вызывал эндпоинт и в каком контексте решения?

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

Следующий хороший вопрос здесь такой: может ли платформа восстановить цепочку авторизации для этого действия MCP? В зрелой модели оператор должен уметь восстановить:

• какой пользователь или сервисный субъект делегировал доступ;
• какой слой идентичности выпустил или проброкерил токен;
• какой MCP-сервер принял эту делегированную область доступа;
• какой запуск агента использовал эту авторизацию для выполнения действия.

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

5.3. MCP как управляемый путь доступа к cloud API¶

Свежая рекомендация AWS Security Blog полезна тем, что формулирует MCP не как удобный протокол интеграции, а как управляемый путь доступа к облачным ресурсам.⁷ Важная деталь: AI coding assistants и агенты часто могут обращаться к cloud API напрямую через shell, SDK или произвольное выполнение кода. Если такой путь остается открытым, MCP-сервер с хорошими IAM-политиками становится только одной из дорог, а не реальной границей контроля.

Поэтому для production-агентов полезно явно разделять:

• mcp_brokered_action: действие проходит через зарегистрированный MCP/tool gateway, получает scoped credentials, пишет audit event и несет policy decision;
• direct_cloud_api_action: агент вызывает SDK, CLI или HTTP API напрямую из shell/code environment;
• human_initiated_action: человек запускает действие сам, а агент только готовит план, diff или evidence packet;
• delegated_agent_action: человек или policy layer делегирует агенту ограниченную область действия с TTL, scope и trace correlation.

Архитектурный вывод жесткий: direct cloud API access должен считаться bypass path, если он не проходит через тот же catalog, identity, policy и audit слой. Для runtime это добавляет несколько обязательных полей в trace/control record: actor_type, delegation_source, credential_scope, credential_ttl, access_path, mcp_server_id, policy_decision_id и called_via_gateway. Тогда организация может отличить human-initiated action от AI-driven action и применить least privilege, org role governance и отдельные approval rules к агентному пути, а не только к человеческому IAM.

Если команда не может запретить shell/SDK полностью, минимумом становится явный контроль обхода: restricted shell profile, denylist/allowlist для cloud CLIs, сетевой egress через proxy, detection для прямых вызовов cloud API и release gate, который блокирует агентную возможность, пока критичные writes не идут через brokered gateway.

5.4. Cloudflare AI traffic controls показывают, что web access тоже стал policy surface¶

Cloudflare AI traffic controls добавляют к этой главе соседнюю, но важную границу: не только как агент вызывает MCP или cloud API, но и как внешний сайт решает, какой AI-трафик вообще имеет право использовать его контент.³ Разделение Search / Agent / Training полезно именно как governance-сигнал. Search crawler, interactive Agent и Training crawler несут разные цели, разные ожидания владельца ресурса и разные требования к аудиту.

Практический вывод для runtime такой: outbound identity нельзя сводить к user-agent string или IP allowlist. Агент, который ходит в web, должен уметь объявлять declared purpose, сохранять audit trail и различать как минимум:

• поиск/индексацию, где владелец сайта ожидает discoverability;
• interactive agent access, где агент действует по поручению пользователя;
• training или dataset collection, где использование контента меняет экономику согласия.

Cloudflare также показывает важную деталь для будущих контрактов доступа: Content-Signal может передавать более тонкие условия, например use=reference, а статусы Verified и Forwarded отделяют проверенную идентичность от транзитивной передачи trust через downstream service. Для архитектуры агента это означает, что transitive trust нужно моделировать явно: если браузерный или retrieval-agent получает доступ через посредника, trace должен показывать исходную identity, forwarded identity, declared purpose и policy decision, а не только конечный HTTP request.

Минимальный policy matrix для web-capable agent должен поэтому содержать хотя бы четыре решения: allow, block, monetize или audit-only. И каждое решение должно быть связано с целью доступа: Search / Agent / Training. Иначе web access policy быстро превращается в хрупкий список строк, а не в контракт между владельцем ресурса, пользователем и агентной платформой.

Cloudflare Monetization Gateway делает пункт monetize конкретным, особенно для agent-facing resource: web page, dataset, API или MCP tool может стать payment-gated resource с x402-style payment flow.⁴ Для архитектуры агента это не просто billing feature. Перед тем как выполнить MCP tool call или retrieval request к платному ресурсу, runtime должен принять policy decision before the tool call: разрешен ли spend, кто является payer, какой spending cap действует, где хранится payment proof и какой metering record попадет в audit trail. Иначе agent начинает превращать web/tool access в скрытый расход без reviewable business context.

5.5. Browser as an action surface¶

GitHub Copilot browser tools в VS Code показывают следующий шаг: live browser становится штатной средой действия агента, а не только внешним способом ручной проверки.⁵ Если агент может открывать страницы, click/type/hover/drag, читать page content, собирать console errors, делать screenshot и запускать scripted flows, то browser надо считать отдельной execution surface.

Практический контракт для такой поверхности должен учитывать stale DOM refs, auth/session state, non-deterministic UI и evidence snapshot. Агент не должен просто сказать “страница работает”: он должен оставить проверяемый след — screenshot, DOM assertion, console errors, network trace или другой artifact, привязанный к run/trace id. Иначе browser automation быстро превращается в еще один непрозрачный tool call.

Контрольный слой тоже должен быть явным. Для пользовательских вкладок нужен механизм share/revoke, для agent-owned tabs — отдельная сессия без cookies/storage обычного браузера, для чувствительных permission prompts — человеческое подтверждение, а для enterprise среды — network domain controls и workspace trust. Тогда browser tool становится управляемой capability, а не прямым доступом агентного процесса ко всему web state.

5.6. Secure MCP Tunnel делает приватную достижимость явной¶

OpenAI Secure MCP Tunnel добавляет полезный deployment pattern для private MCP server: приватная сторона сама открывает outbound-only соединение, вместо того чтобы принимать inbound traffic из публичного интернета.¹⁰ tunnel-client запускается внутри сети, которая уже может достучаться до private MCP server, long-poll-ит OpenAI-hosted endpoint для queued MCP work, локально пересылает JSON-RPC requests и возвращает responses тем же путем. У этой формы есть естественная точка backpressure: client запрашивает только тот объем работы, который готов обработать.

Архитектурный вывод уже, чем “tunnels make private systems safe”. Tunnel должен быть управляемым механизмом достижимости, not a general-purpose network bridge. Private MCP server все равно требует owner records, schema hashes, scoped authorization, output filtering, request correlation и audit events. Tunnel record должен говорить, какая product surface может его вызывать, к какому private MCP server он ведет, какая identity аутентифицировала tunnel-client и какая policy решает, разрешен ли request. Иными словами, Secure MCP Tunnel полезен, когда держит narrow path: product endpoint -> tunnel service -> authenticated tunnel-client -> private MCP server -> filtered response.

5.7. Code Mode превращает MCP portal в слой progressive disclosure¶

Cloudflare отдельно показывает полезный паттерн для больших MCP estate: не отдавать модели все tool schemas заранее, а прятать широкую API-поверхность за порталом с двумя узкими операциями поиска и исполнения.² В их формулировке Code Mode позволяет модели сначала написать код для поиска нужных endpoint definitions, а затем написать код для вызова найденных операций; сам код исполняется на стороне MCP server portal в песочнице, а не внутри основной агентной сессии.

Архитектурно это важно не только из-за token cost. Это меняет модель видимости tools:

• модель получает не весь каталог возможностей upfront, а механизм поиска;
• портал становится точкой audit, DLP и identity enforcement;
• контекст агента не раздувается тысячами schema tokens;
• discovery превращается в управляемое действие, а не в неявную загрузку всего мира;
• sandbox на стороне portal ограничивает, что может сделать сгенерированный код.

Но такой паттерн должен оставаться управляемым. Портал search/execute не должен становиться обходом управления возможностями. Для него нужны те же поля, что и для обычной точки подключения MCP: владелец, разрешенные upstream-серверы, политика областей доступа, профиль песочницы, фильтрация результатов, корреляция трасс и правила проверки рискованных записей. Иначе команда просто заменит “слишком много инструментов в prompt” на “слишком широкий программируемый портал”.

GitHub Agent Finder показывает тот же сдвиг со стороны клиента: discovery возможностей становится операцией runtime, а не привычкой сборки prompt.⁶ Агент должен уметь искать по утвержденному registry MCP servers, skills, canvases, agents и tools, получать ranked matches под задачу и подгружать только тот ресурс, который действительно нужен. Важная safety-деталь: discovery ограничивается managed settings и не означает тихую установку или подключение новых ресурсов. В production architecture trace должен поэтому сохранять capability_search_query, registry_scope, ranked candidates, selected resource, policy decision и состояние human/platform approval.

5.8. Дизайн поверхности инструментов — это часть safety contract¶

Практическая рамка AWS по дизайну MCP tools добавляет к Cloudflare Code Mode еще один важный слой: проблема не только в том, где стоит gateway, а в том, какую поверхность инструментов вообще видит агент.¹³ Если в prompt заранее попадают десятки похожих инструментов, широкие схемы и неясные имена, платформа получает сразу два отказа: context bloat и tool confusion. Модель начинает выбирать не ту операцию, смешивать поля соседних схем или использовать общий инструмент как обходной путь к более рискованному действию.

Хороший tool-surface contract должен поэтому фиксировать:

• tool_taxonomy: read, write, execution, orchestration, introspection;
• tool_visibility_mode: eager, lazy, search_then_execute или server_side_introspection;
• max_active_tools: практический лимит одновременно видимых инструментов для одного шага;
• schema_constraints: обязательные поля, enum вместо свободного текста, короткие описания, запрет скрытой политики в description;
• argument_budget: сколько параметров модель реально должна держать в активном контексте;
• agent_as_tool_policy: когда сложный sub-agent публикуется как один инструмент, а не раскрывает весь внутренний набор операций;
• tool_evaluation: тесты на wrong-tool selection, schema confusion, unsafe default и noisy catalog.

Здесь полезна простая эвристика: если инструмент нельзя объяснить одной операцией, с узкой схемой и понятным risk tier, это, возможно, не tool, а workflow, sub-agent или portal search path. И наоборот: если пять инструментов отличаются только одним неочевидным параметром, лучше вынести различие в enum, taxonomy или server-side discovery, чем заставлять модель угадывать по длинным описаниям.

Для runtime это превращается в проверяемый trace: какие инструменты были видимы, почему именно они были раскрыты, какой taxonomy node или search result их активировал, какая schema version валидировала аргументы, и какой evaluation pack проверяет, что модель не путает похожие tools. Без такого следа “у нас есть MCP gateway” все еще оставляет слепую зону: gateway управляет вызовом, но не объясняет, почему модель вообще увидела именно этот tool surface.

5.9. Smartsheet remote MCP server on AWS: production remote MCP facade¶

Smartsheet remote MCP server on AWS дает хороший production remote MCP facade кейс: one MCP layer serves internal and external agents, а не две разные поверхности для in-product Smart Assist и внешних AI clients.¹⁴ Архитектурный урок здесь в том, что MCP server становится не тонким proxy к API, а AI-optimized interface над доменными сервисами и intelligence layer.

Для такой поверхности важны четыре свойства. Во-первых, capability parity: internal Smart Assist и внешние clients получают один governed contract. Во-вторых, schema-driven tool contracts: строгие JSON schemas, проверка имен колонок и structured errors удерживают модель от hallucinated parameters. В-третьих, token cost становится production control: progressive disclosure, response budgets и компактная сериализация ограничивают стоимость и context pressure. В-четвертых, access tiers, OpenTelemetry, audit events, per-user rate limits и production canaries превращают remote MCP в управляемую платформенную границу.

Переносимый contract: single MCP facade → API gateway and OAuth validation → domain services and intelligence layer → schema-driven tools → token-budgeted responses → access tiers → OpenTelemetry and audit → canary workflow tests. Это полезно держать рядом с Cloudflare portal и AWS tool design: gateway говорит, кто может вызвать tool, tool-surface contract говорит, что видит модель, а production facade говорит, как один MCP слой выдерживает реальные agent bursts, governance и cost constraints.

5.10. Rules of Durable Objects: Durable Agent Identity¶

Cloudflare Rules of Durable Objects добавляет нижележащий runtime-паттерн, который полезен и вне Cloudflare: Durable Agent Identity. Если агент имеет стабильное имя, это имя должно быть atom of coordination, а не просто label в логах.¹⁵ Все запросы, таймеры, wakeups и recovery paths должны сходиться к одному durable instance через deterministic IDs, иначе платформа получит два "одинаковых" агента, которые независимо меняют одно состояние.

Для агентной архитектуры важны пять правил. Первое: deterministic IDs должны строиться из устойчивой сущности вроде tenant/workspace/case/thread, а не из случайного run. Второе: durable state является источником правды для progress, leases, cursors и idempotency; process memory остается только кэшем. Третье: input and output gates должны защищать порядок операций: новая работа не должна видеть полузаписанное состояние, а external side effect не должен уходить до durable commit/evidence. Четвертое: idempotent alarms нужны для отложенных действий, потому что alarm может сработать повторно после сбоя. Пятое: unexpected shutdowns являются нормальной частью модели; recoverable work должен продолжаться из durable checkpoint, а не из in-memory timers, closures, or open fetches.

Переносимый contract: request → deterministic agent instance → durable state gate → idempotent alarm/fiber/workflow → recovered execution → audited output gate. Это не заменяет MCP gateway: MCP управляет capability boundary, а Durable Agent Identity управляет тем, какой named agent instance владеет состоянием и как он переживает restart.

5.11. Эфемерные песочницы лучше постоянных сред почти во всем¶

Еще одна полезная мысль из Google: для рискованных возможностей очень выгодно проектировать краткоживущие среды выполнения.¹⁷

Почему это обычно лучше:

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

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

6. Ядро MCP 2026-07-28 не хранит сессию¶

Спецификация MCP 2026-07-28 сделала базовый протокол самодостаточным на уровне каждого запроса: ядро не хранит протокольную сессию, а согласование версии выполняется для каждого сообщения.¹⁹²⁰ Из ядра удалены прежняя последовательность initialize/initialized и протокольный заголовок с идентификатором сессии. Это упрощает горизонтальное масштабирование и восстановление после сбоя, но не отменяет прикладного состояния.

Практический вывод важен для архитектуры: протокол без состояния не означает приложение без состояния. Корзина, браузер, рабочее пространство или длительная задача по-прежнему могут жить дольше одного вызова, но их состояние должно быть явным, ограниченным и проверяемым.

6.1. Прикладное состояние передается явным дескриптором¶

Если инструменту нужно продолжить работу с существующим объектом, он принимает обычный аргумент вроде basket_id, browser_id или workspace_id. Такой дескриптор:

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

Такое разделение не позволяет случайно превратить транспортную непрерывность в авторизацию. После паузы или подтверждения среда исполнения повторяет запрос с тем же прикладным дескриптором, но заново проверяет политику, полномочия и неизменность действия.

6.2. Длительная работа и дополнительный ввод имеют отдельные контракты¶

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

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

6.3. Шлюз должен маршрутизировать сообщение, а не угадывать скрытую сессию¶

В HTTP-профиле поля Mcp-Method и Mcp-Name позволяют шлюзу маршрутизировать и наблюдать MCP-сообщения без разбора всего тела. Подсказки ttlMs и cacheScope описывают допустимое кэширование, а W3C Trace Context связывает вызов с общей трассой. Эти метаданные остаются подсказками протокола: сервер всё равно обязан проверять идентичность, аргументы и полномочия на каждом запросе.

Расширенная поддержка MCP в AgentCore Gateway остается полезным примером агрегации tools/list, prompts/list, resources/list и шаблонов ресурсов, переноса outputSchema, динамического списка и аннотаций инструментов.¹² Для трассы полезны listing_mode, listed_under_principal, output_schema_hash и tool_annotations. Однако описанное AWS поведение от 2025-11-25 зависит от поставщика и версии сервиса, а не задает универсальную модель актуального ядра MCP.¹¹ Платформа должна датировать такой профиль совместимости и не переносить старую семантику продолжения сессии в общий протокол.

7. Не все возможности требуют одинаковый уровень изоляции¶

Удобно разделить интеграции хотя бы на три класса:

• возможности чтения с низким риском;
• бизнес-действия со средним риском;
• возможности выполнения с высоким риском.

Примеры:

• read_kb или search_docs можно исполнять мягче;
• create_ticket или update_crm_record требуют более строгих политик и аудита;
• run_shell, exec_sql, deploy_job требуют самой жесткой песочницы и подтверждения.

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

8. Контракт возможности должен включать не только вход/выход¶

Часто схема инструмента описана неплохо, а вот эксплуатационный контракт нигде не зафиксирован. Но именно он часто критичен.

Полезно явно задавать:

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

• что происходит, если делегированный доступ отзывают посередине сессии.

• характер чтения или записи;

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

Ниже пример такого профиля:

capabilities:
  search_docs:
    transport: mcp
    mode: read
    network: internal_only
    secrets: none
    timeout_seconds: 8
    approval: none
  create_ticket:
    transport: mcp
    mode: write
    network: internal_only
    secrets: service_account_helpdesk
    timeout_seconds: 15
    approval: manager_for_high_priority
    protocol_profile: mcp-2026-07-28
    state_handle_argument: ticket_draft_id
    long_running_mode: tasks_extension
    additional_input: request_state
  run_shell:
    transport: sandboxed_exec
    mode: high_risk
    network: denied
    filesystem: workspace_only
    secrets: none
    timeout_seconds: 10
    approval: always

Это уже не просто описание функции. Это описание поведенческого контракта возможности.

9. Выполнение в песочнице должно возвращать не только вывод, но и факты выполнения¶

Если песочница возвращает только stdout или полезную нагрузку, ты теряешь половину ценности слоя изоляции.

Для расследования и управления полезно возвращать:

• код завершения;
• флаг тайм-аута;
• сводку использования ресурсов;
• неопределенность побочного эффекта;
• отредактированные логи;
• идентификатор решения политики.

Тогда слой выполнения может объяснить не просто “команда не сработала”, а более взрослое: “операция была прервана по тайм-ауту после 8 секунд, сеть была запрещена, побочный эффект не подтвержден”.

9.1. Исходящий сетевой доступ заслуживает собственного набора правил¶

Очень много инцидентов происходит не потому, что возможность “сломалась”, а потому, что она смогла уйти в неожиданное место.

Поэтому исходящий сетевой доступ полезно описывать не как частность песочницы, а как отдельную поверхность контракта:

• denied;
• internal_only;
• allowlisted_external;
• brokered_via_gateway.

Если это не зафиксировано явно, потом почти невозможно объяснить, почему конкретный инструмент внезапно сходил наружу, хотя формально “ничего не нарушал”.

Для платформы эксплуатационного уровня хороший вариант по умолчанию обычно такой:

• внутренние инструменты только для чтения: internal_only;
• адаптеры внешних API: allowlisted_external;
• выполнение кода и shell-подобные инструменты: denied по умолчанию.

9.2. Манифест песочницы как контракт исполнения¶

Свежие документы OpenAI по Sandbox Agents добавляют к этой картине полезную практическую форму: песочницу стоит описывать не только словами “контейнер” или “изолированная среда”, а через явный Manifest, capabilities, permissions, записи workspace, snapshot и session state.¹⁸

Это хорошо ложится на контракты выполнения из этой главы. Для платформы важны как минимум четыре вопроса:

• какие файлы, репозитории, mounts и environment попадают в стартовый workspace;
• какие нативные возможности песочницы доступны: filesystem, shell, memory, skills, compaction;
• какие permissions и run_as действуют для команд, правок и чтения файлов;
• что происходит при продолжении: используется live sandbox_session, serialized session_state или fresh session из snapshot.

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

9.3. Brain / hands / session как контракт изоляции¶

Практичная схема Managed Agents у Anthropic хорошо формулирует то, что этой главе нужно от runtime: session, harness и sandbox/tools лучше считать отдельными интерфейсами, а не одним контейнером с магической логикой внутри.[^anthropic-managed-agents]

• session — append-only log событий, решений, tool calls, approvals и результатов;
• harness — заменяемый control loop, который вызывает модель и маршрутизирует запросы возможностей;
• hands — sandboxes, tools и adapters, которые реально читают файлы, ходят в сеть и делают побочные эффекты.

Такое разделение полезно не только для масштабирования. Это граница безопасности. Если harness завис, session должна оставаться читаемой. Если sandbox умер, session не должна исчезнуть вместе с ним. Если оператору нужно debug, он должен смотреть на события, профили и snapshots, а не открывать shell внутри окружения с пользовательскими данными.

В терминах этой главы capability request должен проходить короткую цепочку:

capability request → policy → contained execution → telemetry → incident/eval feedback

Эта цепочка делает containment проверяемым: политика выбирает профиль исполнения, hands исполняют внутри ограниченной среды, telemetry фиксирует границы, а assurance/eval контуры используют результат для следующего решения.

9.4. Loop engineering связывает песочницу с harness-дизайном¶

LangChain называет это loop engineering: надежность агента появляется не только из одного model-tool цикла, а из стека циклов вокруг него.¹⁶ Для этой главы полезны четыре уровня:

• agent loop: модель получает контекст и вызывает tools до завершения задачи;
• verification loop: grader, тест или человек проверяет артефакт и возвращает feedback до принятия результата;
• event-driven loop: внешний trigger, cron, webhook или channel запускает агент как часть системы, а не как ручной чат;
• hill-climbing loop: traces и eval outcomes становятся входом для изменения harness config, prompts, tools, rubrics или memory/context.

Эта рамка не отменяет MCP и песочницу, а делает их местом в системе более ясным. Песочница ограничивает hands, MCP описывает контракт внешней возможности, а loop engineering говорит, где именно нужны policy decision, grader, human review и rollout gate. Без такого разделения команда часто усиливает только agent loop: добавляет tools и контекст, но не строит verification loop, не ограничивает event-driven triggers и не проверяет, какие harness changes может делать hill-climbing контур.

10. Простой кодовый пример диспетчеризации возможностей¶

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

from dataclasses import dataclass


@dataclass
class CapabilitySpec:
    name: str
    transport: str
    mode: str
    timeout_seconds: int


def dispatch_capability(spec: CapabilitySpec, args: dict) -> dict:
    if spec.mode == "high_risk":
        return {"status": "approval_required", "capability": spec.name}
    if spec.transport == "mcp":
        return {"status": "success", "transport": "mcp", "capability": spec.name}
    if spec.transport == "sandboxed_exec":
        return {
            "status": "success",
            "transport": "sandboxed_exec",
            "capability": spec.name,
        }
    return {"status": "validation_failure", "reason": "unsupported capability profile"}

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

11. Частые ошибки¶

Теперь типовые проблемы повторяются уже на двух уровнях: на уровне отдельного адаптера и на уровне всего ландшафта MCP.

Типовые проблемы очень повторяемы:

• возможность получает больше сетевого доступа, чем нужно;
• секреты доступны слишком широкому набору адаптеров;
• результат инструмента тащит сырые внешние полезные нагрузки в prompt;
• тайм-аут есть, но неопределенность побочного эффекта не моделируется;
• MCP-сервер добавили, но политики и аудит туда не дотянули;
• песочница есть формально, но не ограничивает ничего важного.

Именно поэтому песочница не должна быть галочкой в чеклисте. Она должна быть частью модели выполнения.

12. Практикум: ревью sandbox profile и MCP boundary перед подключением capability¶

Этот практикум продолжает предыдущую главу про capability contract. Там команда проверяла, можно ли вообще отдавать возможность модели. Здесь следующий вопрос: где именно эта возможность будет исполняться, через какую MCP-границу она пройдет и какие факты останутся после вызова.

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

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

Шаг 1. Начать с карты границы выполнения¶

Перед YAML и кодом полезно нарисовать короткую карту границы. Не архитектурную схему на полэкрана, а таблицу из пяти строк.

execution_boundary_review:
  capability: create_ticket
  owner: support-ops
  runtime_owner: platform-runtime
  mcp_server_id: mcp.support.ticketing.v3
  boundary_class:
    logical_policy: required
    process_isolation: required
    runtime_sandbox: required_for_write_path
    network_boundary: internal_or_brokered
    identity_boundary: user_delegated_or_platform_owned
  risk_tier: high
  side_effect: external_ticket_write

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

На ревью полезно отдельно спросить: что остановит возможность, если она начнет вести себя хуже нормы? Если ответ звучит как “модель поймет”, “инструмент вернет ошибку” или “мы доверяем серверу”, граница еще не оформлена. Хороший ответ должен ссылаться на политику, песочницу, сетевой режим, подтверждение, лимит времени, идемпотентность и трассу.

Шаг 2. Зафиксировать sandbox profile как исполняемый контракт¶

Профиль песочницы должен быть не описанием в стиле “запускается безопасно”, а проверяемым контрактом. В эталонном пакете это уже видно в runtime-controls.yaml: профиль содержит рабочую область, capabilities, permissions и правила состояния.

Минимальная форма для ревью может выглядеть так:

sandbox_profile:
  manifest_version: 1
  workspace:
    entries:
      - path: repo
        source: local_dir
        read_only: false
      - path: task.md
        source: inline_file
        read_only: true
  capabilities:
    filesystem: true
    shell: restricted
    memory: read_write
    skills: read_only
  permissions:
    network: denied
    secrets: none
    run_as: sandbox_user
  state:
    resume: allowed
    snapshot: required_on_completion
    persist_session_state: true

Важный момент: такой профиль не должен быть одинаковым для всех возможностей. Для search_docs допустим один профиль, для create_ticket другой, для run_shell третий. Если все capability получают один широкий профиль “на всякий случай”, ревью превращается в декорацию.

Хороший вопрос к профилю: может ли человек, который не писал код адаптера, понять по этому контракту, какие файлы будут видны, можно ли запускать shell, есть ли сеть, есть ли секреты и что произойдет после завершения или возобновления? Если нет, профиль еще не готов к публикации.

Шаг 3. Проверить workspace entries отдельно от прав файловой системы¶

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

В ревью нужно пройти по каждой записи:

• откуда она берется: локальная директория, архив, inline file, артефакт сборки, snapshot;
• доступна ли она на чтение или запись;
• содержит ли она данные арендатора, секреты, исходный код, журналы или результаты предыдущих запусков;
• должна ли она попасть в snapshot после выполнения;
• можно ли использовать ее при resume без повторного ревью.

Особенно опасны “удобные” записи вроде repo, home, workspace, tmp, потому что они быстро превращаются в неограниченный доступ. Лучше, чтобы runtime materialization была скучной и явной: ровно такие директории, ровно такие файлы, ровно такой режим записи.

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

sandbox_context:
  sandbox_profile_contract: sandbox-profile-v1
  workspace_entries_reviewed: true
  permissions_profile: restricted-shell-network-denied
  network_secrets_posture: network:denied,secrets:none
  snapshot_policy: required_on_completion

Иначе человек подтверждает только “создать тикет”, но не видит, в какой среде это будет сделано и какие дополнительные возможности получил исполнитель.

Шаг 4. Развести network, secrets и identity до вызова MCP-сервера¶

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

Для ревью обычно хватает четырех сетевых режимов:

network_policy:
  denied: "нет исходящего сетевого доступа"
  internal_only: "доступ только к внутренним адресам платформы"
  allowlisted_external: "только заранее утвержденные внешние endpoints"
  brokered_via_gateway: "весь egress идет через контролируемый шлюз"

Хороший default для risky execution — network: denied. Если capability действительно нужен внешний API, это должно быть видно как исключение, а не как свободный выход в сеть. Для MCP-сервера это особенно важно: сам факт, что сервер подключен по протоколу, не означает, что он может ходить куда угодно.

Секреты проверяются так же. secrets: none должен быть нормальным началом разговора. Если серверу нужен секрет, ревью должно ответить:

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

Если ответы не помещаются в контракт, capability еще не готова к эксплуатации.

Шаг 5. Не путать MCP-сервер с доверенной зоной¶

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

Минимальная запись MCP-сервера для ревью должна включать владельца, утвержденный registry id, версию контракта, hash описания инструментов, режим авторизации, области доступа и профиль изоляции:

mcp_boundary:
  server_id: mcp.support.ticketing.v3
  owner: platform-integrations
  registry_state: approved
  tool_contract_version: capability-contract-v5
  tool_definition_hash: sha256:...
  auth_mode: delegated_oauth
  token_scope:
    - ticket.read
    - ticket.write_limited
  token_ttl: 15m
  user_delegation_required: true
  server_isolation_profile: remote_ephemeral_sandbox
  schema_change_requires_review: true

Проверяющий должен увидеть не только “сервер есть”. Ему нужно увидеть, почему именно этот сервер имеет право публиковать эту capability, кто отвечает за его жизненный цикл и что произойдет при изменении схемы инструмента.

Правило простое: изменение описания инструмента, области доступа, владельца, isolation profile или режима авторизации должно запускать повторное ревью. Если сервер может тихо поменять контракт после одобрения, это уже rug pull risk, даже если код выглядит аккуратно.

Шаг 6. Считать описание инструмента и результат инструмента недоверенным содержимым¶

Tool poisoning часто начинается не с shell-команды, а с текста. Описание инструмента может быть подменено. Результат инструмента может содержать инструкцию, которую модель ошибочно воспримет как часть задачи. Внешний API может вернуть поле вроде notes, где окажется недоверенный текст.

Поэтому ревью должно проверять два фильтра:

tool_content_controls:
  tool_description_source: approved_registry
  description_hash_verified: true
  result_treated_as_untrusted_content: true
  return_value_filtering: strip_instructions_and_classify_data
  prompt_boundary_marker_required: true
  dlp_check_required_for_external_results: true

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

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

Шаг 7. Связать MCP-вызов с policy decision и approval gate¶

Если capability относится к write path, MCP-вызов не должен сразу приводить к побочному эффекту. Между намерением модели и действием нужен слой политики.

Минимальный поток выглядит так:

execution_flow:
  - model_requests_capability
  - validate_arguments
  - resolve_capability_contract
  - resolve_sandbox_profile
  - review_mcp_boundary
  - tool_policy_decision
  - approval_requested_if_required
  - execute_after_approval
  - record_tool_execution

Критичная проверка: данные, которые человек подтверждает, должны совпадать с данными, которые потом уходят в инструмент. Если requested_fields в approval_request отличаются от payload выполнения, это не подтверждение, а иллюзия подтверждения.

Для create_ticket проверяющий должен видеть хотя бы:

requested_fields:
  summary: "Open a Sev-2 onboarding incident"
  idempotency_key: ticket-req-2026-04-09-001
  target_system: jira
  destination: project://OPS

После approval runtime должен снова проверить, что summary, idempotency_key, target_system и destination не изменились. И только затем вызывать MCP-инструмент.

Шаг 8. Сделать трассу пригодной для расследования¶

Если sandbox/MCP review не оставляет следа в трассе, команда сможет объяснить дизайн только задним числом. Это слабый сигнал зрелости.

Минимальные события для такого пути:

trace_events:
  - sandbox_profile_reviewed
  - mcp_tool_risk_review
  - tool_policy_decision
  - approval_requested
  - tool_execution

В более зрелой схеме стоит явно добавлять или детализировать события:

runtime_review_events:
  sandbox_profile_resolved:
    sandbox_manifest_version: 1
    permissions_profile: restricted-shell-network-denied
    workspace_manifest_ref: runtime-controls.yaml#runtime_controls.sandbox_profile.workspace
  mcp_server_attached:
    mcp_server_id: mcp.support.ticketing.v3
    registry_state: approved
    tool_contract_version: capability-contract-v5
  tool_description_validated:
    tool_definition_hash: sha256:...
    schema_change_requires_review: true
  egress_policy_applied:
    network: denied
    secrets: none
  sandbox_snapshot_recorded:
    snapshot_policy: required_on_completion
    snapshot_id: snapshot-...

Не обязательно начинать с десятков событий. Но должно быть возможно восстановить четыре ответа: какой профиль песочницы действовал, какой MCP-сервер был подключен, какая политика разрешила или остановила действие и какое подтверждение было связано с побочным эффектом.

Шаг 9. Проверить failure modes до первого production-вызова¶

Ревью должно заставлять команду пройти не только happy path. Для sandbox/MCP boundary это особенно важно, потому что самые неприятные отказы выглядят как “ничего не произошло”, хотя побочный эффект мог остаться неизвестным.

Минимальный список failure modes:

• mcp_server_unavailable — сервер недоступен или не прошел health check;
• tool_description_drift — hash описания инструмента не совпал с утвержденным;
• network_denied — capability запросила egress, которого нет в профиле;
• secret_requested — сервер или адаптер запросил секрет вне контракта;
• approval_stale — подтверждение истекло или относится к другим requested_fields;
• side_effect_unknown — выполнение оборвалось после возможного побочного эффекта;
• sandbox_snapshot_failed — snapshot не был создан, хотя нужен для аудита или resume;
• sandbox_escape_attempt — попытка выйти за filesystem, shell, network или identity boundary.

Для каждого пункта нужен не роман, а решение: остановить запуск, запросить подтверждение, повторно инициализировать сессию, открыть инцидент, карантинировать сервер или продолжить с пониженным режимом. Если такой таблицы нет, команда будет писать recovery-логику во время первого инцидента.

Шаг 10. Прогнать границу через три канонических сценария¶

Один и тот же профиль не подходит всем сценариям.

Для разбора обращений поддержки основной риск — write path. Там важно проверить create_ticket, делегированную авторизацию, approval_required, ключ идемпотентности, side_effect_unknown и восстановление после тайм-аута.

Для внутреннего ассистента знаний основной риск — чтение и загрязнение контента. Там важны role-scoped retrieval, tenant boundary, маркировка недоверенного содержимого, запрет скрытых побочных эффектов и отсутствие секретов в поисковом адаптере.

Для координации инцидентов основной риск — сочетание скорости и полномочий. Там нужны ограниченные MCP-инструменты уведомлений, явный on-call owner, подтверждение опасных действий, запрет автоматического remediation без владельца и трасса передачи ответственности.

Если capability проходит только один сценарий, это не означает, что контракт зрелый. Это означает, что команда проверила один путь. Для книги и для production-платформы полезнее делать ревью так, чтобы сразу видеть, где профиль переносим, а где требуется отдельный контракт.

Минимальный checklist для sandbox/MCP boundary review¶

Перед подключением capability к каталогу инструментов проверь следующее:

• capability имеет владельца и risk tier;
• sandbox profile задан как контракт, а не как устное “запускается изолированно”;
• workspace entries перечислены явно и проверены на read/write режим;
• network policy и secrets policy видны до исполнения;
• MCP-сервер находится в утвержденном реестре и имеет владельца;
• tool definition hash или schema hash фиксируется и проверяется;
• результат инструмента считается недоверенным содержимым до фильтрации;
• write path проходит через tool_policy_decision и approval_requested, если это требуется политикой;
• approval_request содержит те же поля, которые пойдут в побочное действие;
• трасса сохраняет профиль песочницы, MCP boundary, policy decision, approval и execution outcome;
• failure modes описаны до production-вызова;
• snapshot/resume правила понятны для длинных или stateful запусков.

Что должно измениться в реализации после такого ревью¶

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

В конфигурации появляется sandbox_profile рядом с runtime controls, а не в отдельной wiki. В policy bundle capability получает решение allow, approval_required или deny, которое можно прочитать без знания кода адаптера. В approval schema появляется sandbox_context, чтобы человек подтверждал не только бизнес-действие, но и границу исполнения. В telemetry добавляются события или payload-поля, по которым можно восстановить профиль песочницы, MCP-сервер, hash контракта и итог выполнения.

Самый полезный итог такого практикума — команда перестает спрашивать “можно ли агенту дать этот инструмент?” и начинает спрашивать точнее: “какая capability, в какой песочнице, через какой MCP boundary, с какой идентичностью, каким подтверждением и каким доказательным следом может выполнить это действие?”

13. Что сделать сразу¶

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

• Отделены ли адаптеры от ядра рантайма?
• Есть ли профиль выполнения для каждой возможности?
• Ограничены ли сеть, файловая система и секреты?
• Ясно ли, какой уровень изоляции используется: логический, процессный или рантайм?
• Явно ли описан транспорт: direct, MCP, sandboxed exec?
• Понимает ли система, когда результат заслуживает доверия, а когда только частично доверенный?
• Есть ли факты выполнения помимо бизнес-полезной нагрузки?
• Используются ли эфемерные песочницы там, где есть выполнение с высоким риском?
• Можно ли объяснить, почему возможность была разрешена именно в этом запуске?

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

14. Что делать дальше¶

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

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

• Глава 8. Модель выполнения и каталог инструментов
• Глава 10. Идемпотентность, повторы, лимиты запросов и границы отката
• Часть IV. Инструменты и выполнение
• Источники