Корпоративные AI-агенты упираются в знакомую инфраструктурную проблему: команды быстро добавляют новые возможности, но никто уже не видит всю поверхность инструментов целиком.
Позиция MongoDB проста. Когда компании выводят агентов за пределы пилотов, инструменты, которыми те пользуются, часто создаются отдельно каждой командой: функции для получения данных, действия для записи записей, триггеры процессов, вызовы API, MCP-серверы и внутренние коннекторы. Локально они могут работать. Их могут быстро выпускать. Но часто они не описаны, не зарегистрированы и невидимы для всех, кроме команды, которая их сделала.
Это не только дублирование. Это проблема управления. Команды безопасности не могут проверять инструменты, о существовании которых не знают. Платформенные команды не могут убрать пересечения, если не видят, что уже создано. При расследовании инцидентов трудно понять поведение агента, если у организации нет живой карты: что агенты могут вызывать, кто владеет этими инструментами и какие права у них есть.
MongoDB предлагает не публичный пакетный менеджер для инструментов агентов, а внутренний корпоративный реестр: ограниченный одной организацией, ее данными, политиками, регуляторными требованиями и операционными привычками.
Проблема не в недисциплинированных командах, а в отсутствующей инфраструктуре#
Разрастание инструментов легко принять за слабую инженерную дисциплину. MongoDB формулирует иначе: команды пытаются решить инфраструктурную задачу на уровне приложения.
Схема старая. До того как пакетные менеджеры стали нормой, организации дублировали код, вручную копировали библиотеки и не имели надежного способа находить общие компоненты и управлять ими. Реестры сами по себе не сделали цепочки поставки ПО безопасными. Но они создали точку координации. Команды могли находить общий код. Владельцы — публиковать обновления. Безопасники — проверять зависимости. Политикам появилось куда крепиться.
Инструменты агентов теперь устроены похоже. Одна команда делает коннектор к клиентским данным. Другая создает почти такой же коннектор для процессов поддержки. Третья зашивает учетные данные в MCP-сервер, потому что демо должно заработать к пятнице. Каждое локальное решение можно понять. Вместе они создают поверхность инструментов, которую центральная команда уже не может надежно проверить.
MongoDB указывает на запуск Kong enterprise MCP Registry в феврале 2026 года как на один из признаков, что рынок сходится вокруг этой проблемы. Kong описывал сложности с ручной настройкой MCP, жестко заданной конфигурацией, изолированным управлением инструментами в разных командах, фрагментированными интеграциями и слабой видимостью на уровне всей организации. Это не крайние случаи. Так выглядит рост агентской инфраструктуры через обходные каналы.
Вывод жесткий: если инструменты агентов создаются как разовые прослойки, управление превращается в археологию.
Реестр не защищает инструменты сам. Он делает защиту возможной#
Самая сильная часть аргумента MongoDB — различие между централизацией и безопасностью.
Реестр не волшебный защитный слой. Публичные экосистемы пакетов это доказывают. npm, PyPI, Maven и похожие системы до сих пор сталкиваются с typosquatting, вредоносными пакетами, dependency confusion, компрометацией мейнтейнеров и заброшенными компонентами. Централизация даже может концентрировать риск, когда сам реестр становится доверенной инфраструктурой.
Но обратная ситуация хуже. Без реестра организация теряет базовые механики согласованной защиты.
MongoDB ссылается на исследование State of AI Agent Security 2026: только 14,4% команд, у которых агенты вышли за стадию планирования, имели полное одобрение безопасности, а 88% организаций сообщили об инциденте, связанном с агентами, за год. Источник также отмечает слабую практику идентификации: только 22% организаций рассматривали агентов как отдельные идентичности, при этом общие API-ключи оставались распространенными.
Эти цифры не стоит считать универсальным законом без проверки методологии исследования. Но они совпадают с операционным паттерном риска: внедрение агентов идет быстрее, чем процессы согласования, инвентаризации, идентификации и проверки.
Это важно, потому что агенты — не пассивные программные зависимости. Их инструменты могут получать данные, записывать записи, запускать процессы и вызывать внешние сервисы. Плохо проверенная библиотека может принести уязвимость. Плохо управляемый инструмент агента может выполнить бизнес-действие.
Реестр дает командам безопасности конкретную опору:
- какие инструменты существуют
- кто владеет каждым инструментом
- что инструменту разрешено делать
- какие агенты могут его вызывать
- какая версия развернута
- была ли проверка или выдача разрешения
- какие учетные данные, scopes или идентичности задействованы
Такая инвентаризация не доказывает безопасность. Но она превращает невидимую поверхность риска в проверяемую.
Управлению нужен общий контекст, а не копии политик по репозиториям#
Большинство внедрений агентов начинается с разрешающей модели. Инструмент доступен, если его явно не заблокировали. На этапе экспериментов это удобно. При повторении в десятках команд и агентов — опасно.
Материал MongoDB ссылается на анализ AgilityFeat о корпоративных guardrails для AI, особенно на риск архитектур, которые не построены по принципу deny-by-default. Практическая проблема проста: allow-by-default увеличивает поверхность атаки вместе с внедрением. Каждый новый инструмент, коннектор и workflow-действие становится еще одним местом, где политика может отсутствовать, расходиться с остальными или устареть.
Реестр — не движок политик. Это важное различие.
Реестр не нужно путать с авторизацией, runtime enforcement, управлением идентичностями, логированием или процессами человеческого подтверждения. Эти контроли живут в других местах. Но им нужны надежные метаданные. Если слой управления должен применять точные guardrails, ему нужно знать, какие инструменты существуют и как они классифицированы.
Например, компания может захотеть такие правила:
- инструменты чтения клиентских данных требуют одобрения перед использованием в production
- инструменты с возможностью записи нуждаются в более строгих границах идентичности, чем read-only инструменты
- платежи, удаление, возвраты и изменения аккаунта требуют подтверждения человеком
- инструменты, работающие с регулируемыми данными, должны иметь ответственную команду-владельца
- устаревшие инструменты нельзя вызывать из новых развернутых агентов
Эти правила слабы, если каждая команда ведет собственный каталог инструментов в своем репозитории. Они становятся применимыми только тогда, когда у организации есть общая точка отсчета.
Именно поэтому внутренние реестры выглядят реалистичнее публичной стандартизации. Поверхность инструментов банка, больницы, SaaS-поставщика и логистической компании не будет иметь одну и ту же форму политик. У них разные регуляторные обязанности, границы данных, операционные процессы и допустимые отказы. MongoDB справедливо отвергает идею, что ближайший ответ — широкий публичный пакетный менеджер для инструментов агентов. Полезная единица здесь — внутренний реестр.
Что должно быть внутри корпоративного реестра#
Полезный реестр инструментов агентов — не просто директория с названиями и описаниями. Если он слишком пустой, он превращается в полочный артефакт. Если слишком тяжелый, команды начинают его обходить.
Как минимум реестр должен отвечать на операционные вопросы:
- Что делает этот инструмент?
- Кто им владеет?
- Какие системы он затрагивает?
- К каким классам данных он может получить доступ?
- Может ли он читать, записывать, удалять, запускать процессы или повышать привилегии?
- Какие агенты или команды допущены к его использованию?
- Какой у него статус проверки?
- Какая версия актуальна?
- Как он аутентифицируется?
- Где видны логи и сигналы сбоев?
Сложная часть — не хранить эти метаданные. Сложная часть — поддерживать их правдивыми. Реестры инструментов ломаются, когда регистрация ручная, необязательная и оторвана от деплоя. Если команды могут выпустить MCP-сервер или коннектор агента без обновления реестра, реестр быстро становится устаревшим compliance-артефактом.
Более удачный паттерн — сделать регистрацию частью пути в production. Публикация инструмента, статус проверки, привязка идентичности и runtime-доступ должны сходиться в одной control plane. Не каждой организации нужна одинаковая реализация. Но реестр должен быть достаточно близко к деплою, чтобы отражать реальность.
Чего не стоит обещать#
Материал MongoDB — блог вендора, и рамка ожидаемо совпадает с корпоративными циклами покупки инфраструктуры. Это не делает аргумент неверным. Но формулировки нужно держать точными.
Реестр AI-инструментов не решит prompt injection. Он не гарантирует least privilege. Он не предотвратит злоупотребление доверенным инструментом со стороны скомпрометированного агента. Он не заменит runtime-мониторинг, дизайн идентичностей, процессы одобрения, безопасную разработку, red teaming или реагирование на инциденты.
Его ценность уже, но все равно важна: он создает общий контекст. Без него управление верхнего уровня остается в основном пожеланием.
Правильное сравнение — не «реестр против отсутствия риска». Правильное сравнение — «известная поверхность инструментов против неизвестной». Первой можно управлять. О второй можно только гадать.
Что проверить уже сейчас#
Если агенты уже выходят за пределы экспериментов, первый вопрос не в том, есть ли у организации отполированный продукт-реестр. Вопрос в том, может ли кто-то собрать достоверную инвентаризацию.
Начните с прямого аудита:
- перечислите всех агентов в production или рядом с production
- перечислите все инструменты, коннекторы, MCP-серверы, функции и API-действия, которые эти агенты могут вызывать
- определите владельцев инструментов и статус одобрения
- отделите read-only инструменты от инструментов с записью или запуском процессов
- найдите общие API-ключи и по возможности замените их идентичностями, привязанными к конкретным агентам
- отметьте инструменты, которые касаются чувствительных, регулируемых или клиентских данных
- определите, какие инструменты разрешены по умолчанию, а какие требуют явного одобрения
Если такой список трудно собрать, это уже результат проверки. В организации уже есть разрастание инструментов. Разговор о реестре тогда перестает быть теорией. Не хватает карты.