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

Когда такую задачу ставят внутри компании, разговор про безопасность обычно идёт про одно: что уходит в промпте и что вернулось из модели. Этим закрывается часть задачи. Остальное начинается там, где модель перестаёт отвечать текстом и начинает вызывать ваши системы. Фильтрация содержимого здесь не помогает: вопрос уже не в содержимом запроса, а в том, кому эту операцию выдавали.

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

Вызов инструментов. Способ работы, при котором модель не только формулирует ответ, но и сама обращается к внешним системам: читает данные, меняет записи, запускает процессы. Какие обращения сделать, в каком порядке и сколько раз, модель решает в момент выполнения.

Model Context Protocol, MCP. Открытый протокол, предложенный в ноябре 2024 года и описывающий, как приложение, модель и внешняя система договариваются о таких обращениях. Протокол стандартизирует интерфейс вызова, но не решает, кому и какие вызовы разрешены: это остаётся на стороне внедряющей организации.

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

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

По данным Cloudflare Radar, опубликованным 3 июня 2026 года, на автоматические запросы приходится 57,4% всех обращений HTTP к веб-страницам против 42,6% на людей. Оговорка существенная: считаются запросы к содержимому HTML, а не весь трафик интернета, и разные публикации приводят значения от 57,3% до 57,5% в зависимости от момента снятия.

Скорость роста измеряют отдельно. В отчёте HUMAN Security «2026 State of AI Traffic & Cyberthreat Benchmark Report», опубликованном 26 марта 2026 года, месячные объёмы трафика, порождаемого системами ИИ, за 2025 год выросли на 187%. Трафик именно агентов и агентных браузеров в том же отчёте вырос на 7851% за год. Это данные одной компании по её клиентской базе, а не отраслевое измерение.

Часть этого трафика уже не краулеры, а агенты, которые выполняют операции вместо своих пользователей в чужих системах. Для организации это две разные задачи, которые обычно называют одним словом «безопасность моделей». Разницу стоит проговорить до того, как выбирать средства, потому что средства для них разные.

Сотрудник открывает внутреннего помощника и просит переписать письмо клиенту. Разработчик просит ассистента объяснить кусок кода. В обоих случаях приложение отправляет модели текст и получает текст обратно. Модель остаётся собеседником, а перечень того, что приложение может у неё запросить, задан кодом этого приложения.

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

Механизмы тоже известны и повторяются от продукта к продукту: единая точка доступа к нескольким провайдерам, управление промптами с версионированием шаблонов, маскирование чувствительных полей в запросах и ответах, ограничение расхода по токенам. На российском рынке этот класс задач закрывают Platform V SOWA и Platform V SOWA AI у СберТеха, модуль AI Gateway в составе NEOMSA APIM, есть решения и у других поставщиков.

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

Оператор поддержки спрашивает у агента: почему у клиента не прошёл платёж. Чтобы ответить, агенту нужно посмотреть карточку клиента, последние операции по счёту и текущий лимит. Три системы, три запроса, и делает их агент сам.

Модель здесь перестала быть собеседником и стала исполнителем. Предмет проверки меняется: не то, что написано в запросе, а то, какие операции агенту доступны.

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

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

У этой категории риска есть принятое название. В перечне рисков приложений на больших языковых моделях, который ведёт OWASP, она называется Excessive Agency, избыточная автономия: агенту выдано больше функций или прав, чем требует его задача. В декабре 2025 года проект OWASP GenAI Security выпустил отдельный перечень рисков для агентных приложений, где злоупотребление идентичностью и привилегиями и некорректное использование инструментов вынесены в число ключевых угроз именно потому, что типовые средства защиты содержимого их не покрывают.

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

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

Asana, июнь 2025 года. Сервер MCP был запущен 1 мая 2025 года, ошибка в проверке изоляции между организациями существовала с запуска и была обнаружена 4 июня. Функциональность отключали с 5 по 17 июня, уведомления получили около 1000 клиентов. Данные одной организации могли стать видимыми пользователям MCP из других организаций в пределах прав, выданных конкретному пользователю. Компания не характеризовала произошедшее как взлом, речь шла о логической ошибке.

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

Прямой доступ дешевле, быстрее и на прототипе работает.

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

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

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

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

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

Сервисная учётная запись не разделяется. При прямом доступе все вызовы идут от одного технического пользователя. Следствия:

● нельзя понять, какой из агентов сделал вызов, если их стало двое;

● нельзя забрать доступ к одной системе, не забрав его ко всем: ключ один;

● нельзя ограничить частоту для конкретного агента: лимит общий для всех, кто ходит под этой записью;

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

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

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

Проверка содержимого запросов не закрывает ни одно из этих 4 расхождений. Каждое из них упирается в учёт: что кому выдано, кем и когда.

Задача при этом не новая. Всё перечисленное ниже организации делают с интерфейсами полтора десятка лет. Изменился только потребитель.

1. Перечень операций, а не список систем. Вернёмся к оператору поддержки. Агенту нужно посмотреть карточку клиента, и обычный способ это выдать доступ к системе карточек целиком. Но в спецификации этой системы 23 операции, и среди них смена тарифа, блокировка и объединение записей. Выдавать надо одну, чтение карточки по идентификатору. Решение о том, какие операции существуют для агента, принимается при публикации, и принимает его владелец интерфейса, а не автор агента.

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

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

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

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

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

6. Журнал, по которому видно человека. Один агент обслуживает десятки запросов от разных операторов. Если идентификатор того, кто поставил задачу, не доходит до вызова, в журнале останется строка «агент поддержки обратился к расчёту лимитов 340 раз», и разбирать по ней будет нечего.

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

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

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

Собирать реестр задним числом, когда агентов уже 5, дороже, чем завести его на первом.

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

1. Откройте средство защиты, которое считается закрывающим тему ИИ. Что оно проверяет: содержимое запроса и ответа или право на вызов операции.

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

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

4. Посмотрите на одну выдачу. Что в ней указано: операция или система целиком.

5. Найдите, где стоит ограничение частоты. Оно привязано к потребителю или к интерфейсу.

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

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

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

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

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

● Cloudflare Radar, данные о соотношении автоматического и человеческого трафика HTTP, опубликованы 3 июня 2026 года.

● HUMAN Security. 2026 State of AI Traffic & Cyberthreat Benchmark Report, 26 марта 2026 года.

● OWASP. Перечень рисков приложений на больших языковых моделях, пункт LLM06:2025 Excessive Agency.

● OWASP GenAI Security Project. Перечень рисков и мер для агентных приложений, декабрь 2025 года.

● Invariant Labs. Разбор уязвимости сервера MCP для GitHub, 26 мая 2025 года.

● Asana. Уведомление об ошибке изоляции данных в сервере MCP, июнь 2025 года; публикации BleepingComputer и UpGuard от 18 июня 2025 года.