Почему агентам нужна верификация skills до доступа к продакшену

Раунд AIR: индикатор спроса, а не доказательство качества верификации

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

1 сентября 2026 года стартап AIR сообщил TechCrunch о раунде на 50 млн долларов. По описанию компании, платформа предназначена для обнаружения агентных систем в организациях, проверки подключённых skills, плагинов, MCP-серверов и внешних источников, а также для блокировки компонентов, которые не соответствуют критериям заказчика. Это новостной повод, который указывает на формирование рынка контроля агентных интеграций, но сам по себе не подтверждает эффективность продукта.

AIR также заявила, что отсеивает около 27% обнаруживаемых в интернете add-ons и skills и работает более чем с 20 клиентами. Эти показатели нельзя трактовать как независимую оценку рынка или доли небезопасных компонентов. В доступной публикации не раскрыты выборка, период наблюдений, критерии отсева, доля ошибок и процедура внешнего аудита. Корректнее считать цифры заявлением поставщика и признаком коммерческого интереса к контролю внешних возможностей агентов.

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

Изменяемые сведения о раунде AIR, заявлениях компании и её продукте проверены по публикации TechCrunch 2 сентября 2026 года.

• AIR сообщила о раунде на 50 млн долларов и продукте для проверки агентных add-ons.
• Заявления AIR о клиентах и доле отсеянных компонентов не являются независимой оценкой рынка.
• Верификация skills продолжает практики управления цепочкой поставки ПО, но учитывает самостоятельный выбор инструмента агентом.

Цитата в переводе

«Все будут это делать.»

Что меняется в экосистеме OpenAI

Тема выходит за пределы демонстрационных чатов. В обновлении Agents SDK от 15 апреля 2026 года OpenAI сообщила о general availability ряда возможностей для API: MCP-инструментов, skills, shell, редактирования файлов и изолированных sandbox-сред. При этом статусы отдельных компонентов различаются. Например, TypeScript-поддержка новых sandbox-возможностей в сообщении была обозначена как план. Общая доступность части платформы не означает одинаковой зрелости и одинакового уровня риска для каждой конфигурации.

MCP, Model Context Protocol, позволяет ИИ-приложению подключать контекст и инструменты внешнего сервера. Агенту можно предоставить поиск по внутренней базе, доступ к календарю, создание тикета или операцию в бизнес-системе. Ценность и риск такого подключения определяются не только ответом модели. Значение имеют подключённый сервер, объявленные методы, доступные данные и учётные данные, от имени которых действует инструмент.

В справочном материале OpenAI поддержка MCP-действий, способных менять данные, обозначена как beta для организаций на планах Business, Enterprise и Edu. Безопасность и пригодность собственных MCP-приложений организация должна оценивать самостоятельно. Приложения из реестра OpenAI проходят проверку перед включением в реестр. После одобрения администратором ChatGPT использует снимок доступных инструментов и входов приложения. Это уменьшает риск незаметного расширения интерфейса, но не заменяет аудит поставщика, зависимостей и изменений вне реестра.

Статусы возможностей OpenAI и условия работы MCP в ChatGPT проверены 2 сентября 2026 года. Их следует перепроверить непосредственно перед публикацией и внедрением, поскольку beta-статус и доступность отдельных компонентов могут меняться.

• Skills и MCP-серверы расширяют возможности агента по работе с внешними системами, а не только по генерации текста.
• Проверка приложений в реестре и административное одобрение не равны универсальной независимой сертификации.
• Статус beta у MCP write-действий в ChatGPT следует отличать от статуса других возможностей Agents SDK.

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

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

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

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

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

Что проверять до первого tool call

Первый уровень проверки: идентичность и происхождение компонента. Для допуска недостаточно названия skill или бренда поставщика. Организации нужны зафиксированные URL, пакет, версия, владелец и зависимости. Важна также декларация инструмента: описание и schema влияют на то, когда модель выберет функцию и какие аргументы попытается ей передать. Контролировать следует и исполняемый компонент, и контракт его методов.

Второй уровень: фактические полномочия. Следует отдельно определить, какие данные инструмент читает, может ли записывать или удалять их, к каким адресам обращается, какие OAuth-scopes использует, имеет ли доступ к shell, файловой системе, секретам или внутренней сети. Принцип минимальных привилегий здесь выражается в конкретных мерах: отдельные сервисные аккаунты для разных задач, минимальные scopes и запрет по умолчанию на новые права.

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

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

• Фиксируйте конкретную конфигурацию инструмента, а не только имя поставщика.
• Проверяйте права на чтение, запись, удаление, сетевой доступ и работу с секретами.
• Тестируйте сценарии отказов и попытки выхода за установленные границы до production.

Почему доверие к skill не должно быть бессрочным

Белый список полезен только как снимок состояния. Компонент, проверенный в одной версии, не становится автоматически приемлемым после смены зависимости, домена, OAuth-scope, описания метода или владельца репозитория. Для агентных tools даже небольшое изменение schema способно расширить набор доступных действий, а смена endpoint способна изменить маршрут корпоративных данных.

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

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

• Привязывайте допуск к версии, правам, endpoint и tool schema, а не к бренду skill.
• Считайте триггерами повторной проверки изменения версии, зависимости, scope, endpoint, schema или владельца.
• Не отменяйте ручное решение для действий с высоким потенциальным ущербом.

Runtime-контроль: политика должна работать на уровне вызова

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

Agents SDK поддерживает human-in-the-loop: выполнение инструмента можно приостановить до approve или reject. Такой механизм подходит для платежей, удаления, публикации, изменения прав доступа и передачи чувствительной информации за пределы периметра. Подтверждение эффективно только при ясной точке принятия решения. Проверяющий должен видеть цель действия, адресата, аргументы и последствия, а не механически одобрять поток однотипных запросов.

Необходима и возможность расследования. Журнал должен связывать исходную задачу, выбранный tool, аргументы, применённое правило, факт подтверждения, ответ внешнего сервиса, версию компонента и использованную учётную запись. Agents SDK поддерживает tracing, а документация по guardrails указывает, что покрытие защитных механизмов зависит от класса инструмента. Формулировки о том, что guardrails включены, недостаточно: нужно проверить, на какие tools они распространяются в конкретном workflow.

• Применяйте контроль чувствительных действий к конкретному вызову, а не только к серверу при первоначальном подключении.
• Используйте human-in-the-loop прежде всего для высокорисковых и необратимых операций.
• Сохраняйте логи, которые восстанавливают цепочку инструментальных решений, а не только финальный ответ модели.

Цитата в переводе

«Это не задача сканирования.»

Guardrails, sandbox и верификация закрывают разные риски

OpenAI Agents SDK предоставляет guardrails: проверки, способные остановить или перенаправить выполнение при заданных условиях. В документации указано существенное ограничение. Tool guardrails применяются к custom function tools; hosted и встроенные инструменты, включая HostedMCPTool, ComputerTool и ShellTool, не проходят через тот же pipeline tool guardrails. Это не означает, что такие инструменты небезопасны. Команде необходимо отдельно понимать, какие меры контроля действуют для каждого класса tools и где остаются пробелы покрытия.

Верификация внешнего skill не конкурирует с runtime-guardrails, sandbox или approvals. Это разные рубежи контроля. Проверка происхождения и конфигурации определяет, что можно подключить. Политика вызова определяет, что разрешено сделать сейчас. Изоляция ограничивает среду исполнения. Трассировка помогает выявлять и расследовать отклонения. Управляемость обеспечивает сочетание этих мер, а не один продукт с названием AI firewall.

Поэтому для поставщиков верификации важнее не риск-скор на витрине, а воспроизводимые доказательства: что проверено, когда и на какой версии, какие права обнаружены, что изменилось и как решение применяется в рабочем контуре. Без экспортируемого audit trail одобрение остаётся непрозрачным мнением, которое трудно использовать в разговоре со службой безопасности или внутренним аудитом.

• Не считайте guardrails единым защитным слоем для всех категорий tools.
• Разделяйте проверку подключения, контроль вызова, sandbox и аудит: они решают разные задачи.
• Оценивайте поставщика верификации по качеству доказательств и истории изменений, а не только по риск-оценке.

Рост action-tools повышает цену ошибки, но не доказывает массовый production

Один из препринтов на arXiv проанализировал 177 436 публичных агентных инструментов, созданных с ноября 2024 года по февраль 2026 года и наблюдаемых через репозитории MCP-серверов. Авторы сообщают, что в выбранный период доля action-tools, способных менять внешнюю среду, выросла с 27% до 65%. Среди таких действий названы редактирование файлов, отправка писем и финансовые операции.

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

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

Число инструментов, диапазон роста action-tools и границы выборки относятся только к указанному препринту. Данные проверены 2 сентября 2026 года и не должны использоваться как оценка внедрения агентных систем в закрытых корпоративных средах.

• 177 436 инструментов и рост доли с 27% до 65% относятся к конкретному препринту о публичной MCP-экосистеме.
• Action-tool меняет внешнюю среду, а не только возвращает информацию.
• Рост таких инструментов повышает цену ошибки, но не измеряет частоту инцидентов.

Как выстроить допуск без ложного чувства безопасности

Минимально зрелый процесс начинается с инвентаризации. Компании нужен реестр агентов, MCP-серверов, skills, владельцев, сервисных аккаунтов, категорий данных, разрешённых действий и правил эскалации. Без него после инцидента невозможно быстро установить, какой агент получил доступ к системе и через какой компонент. Это практическая рекомендация редакции, основанная на подходах к наблюдаемости и контролю агентных workflow.

Далее нужен конвейер допуска: проверка в staging или sandbox, фиксация версии и schema инструмента, оценка прав, сетевых маршрутов и зависимостей, назначение владельца риска и решение о production-доступе. Новый или изменившийся tool разумно по умолчанию считать запрещённым до отдельного разрешения. Для платежей, удаления, публикации, изменения ролей и внешней передачи конфиденциальных данных необходимы дополнительные условия, включая подтверждение человека.

При выборе внешнего верификатора стоит спрашивать о методологии, а не только о проценте заблокированных skills. Проверяет ли сервис код и зависимости или лишь описание? Анализирует ли фактические OAuth-права и сетевое поведение? Как часто запускается повторная проверка? Что считается изменением? Можно ли выгрузить доказательства и применить решение в runtime? В случае AIR особенно важно помнить, что доступная публикация передаёт заявления компании, а не независимый бенчмарк.

Российский контекст не требует искусственной локализации. В предоставленных источниках нет проверяемого кейса о сопоставимом масштабе независимой верификации MCP-skills в российских production-средах. Однако инженерная модель риска переносима: если агент подключён к документам, почте, ERP, CRM или внутренним API, нужны инвентаризация, узкие права и контролируемый допуск внешних компонентов. Это общий принцип управления доступом, а не оценка российского рынка.

• Создайте реестр: агент, tool, владелец, учётная запись, данные и разрешённые действия.
• Требуйте повторной оценки при изменении версии, прав, зависимостей, endpoint или tool schema.
• Сохраняйте доказательства допуска и трассу вызовов для аудита и расследований.

Что это означает на практике

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

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

• Не выдавайте агенту единый привилегированный токен для всех интеграций. Разделяйте сервисные аккаунты и OAuth-scopes по инструментам и задачам.
• Привязывайте разрешение к версии skill, зависимостям, endpoint и tool schema. Изменение этих параметров должно становиться событием для переоценки.
• Используйте sandbox и staging до production, но не считайте изоляцию заменой политике доступа.
• Настройте обязательное подтверждение для необратимых операций: платежей, удаления, публикации, изменения прав и внешней передачи чувствительных данных.
• Проверьте покрытие guardrails по типам инструментов: в Agents SDK оно различается для custom function tools и ряда hosted или встроенных tools.
• Выбирая внешнего верификатора, требуйте методологию, историю изменений и экспортируемый audit trail. Процент отсеянных компонентов без этих данных малоинформативен.

Вывод

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

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

Источники

• TechCrunch: AIR raises $50M to help companies vet the skills and add-ons AI agents use
• OpenAI: The next evolution of the Agents SDK
• OpenAI: A practical guide to building agents
• OpenAI Help Center: Developer mode and MCP apps in ChatGPT beta
• OpenAI: Running Codex safely
• OpenAI: ChatGPT agent system card
• OpenAI Agents Python: Guardrails
• arXiv: исследование публичной MCP-экосистемы агентных инструментов

Практический чек-лист

Чек-лист допуска skills и MCP-инструментов

Материал можно использовать как рабочую памятку перед подключением нового внешнего инструмента к агентному workflow. Для скачивания подготовьте PDF-файл downloads/checklist-agent-skills-verification.pdf и добавьте его отдельной строкой на лист Downloads.

Инвентаризация и происхождение

• Зафиксируйте название инструмента, пакет, URL, версию, владельца и зависимости.
• Сохраните описание методов и tool schema, с которыми компонент проходит допуск.
• Определите владельца риска и команду, ответственную за последующие изменения.

Права и данные

• Проверьте доступ к чтению, записи, удалению, файловой системе, shell, внутренней сети и секретам.
• Разделите сервисные аккаунты и OAuth-scopes по задачам и инструментам.
• Зафиксируйте разрешённые категории данных, адреса назначения и сетевые маршруты.

Проверка до production

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

Контроль изменений и исполнения

• Настройте повторную проверку при изменении версии, зависимостей, scope, endpoint, schema или владельца.
• Применяйте политику к конкретному tool call, его аргументам, учётной записи и контексту данных.
• Сохраняйте трассу: задача, выбранный tool, аргументы, правило, подтверждение, ответ сервиса и версию компонента.
• Подготовьте механизм быстрого отзыва доступа и блокировки изменившейся версии.