
В чём суть риска
Инструмент, подключённый к AI-агенту, может нести вредоносные указания в собственном описании. Исследования средств AI-разработки показывают риск внедрения инструкций (prompt injection) через такие инструменты в средах на основе MCP. В результате агент разработчика способен изменить код или раскрыть секреты.
Средство AI-разработки подключает набор инструментов и читает их описания, чтобы понять, когда и как их вызывать. Агент воспринимает эти описания как доверенные сведения. Если инструмент или его метаданные содержат вредоносные указания, они влияют на поведение агента. Граница доверия нарушается в момент подключения: сторонний компонент получает возможность управлять агентом. Пользователь при этом видит не все параметры вызова.
Чем риск оборачивается для компании
Агент вызывает инструменты без разрешения и передаёт скрытые параметры.
Секреты из рабочей среды разработчика могут быть раскрыты.
Несанкционированные изменения кода попадают в репозиторий и требуют разбора.
Где риск наиболее вероятен
Кому и что решать
Утвердить порядок подключения инструментов к средствам AI-разработки через проверенный реестр.
Обеспечить проверку инструментов до подключения, изолированное исполнение и полный журнал вызовов.
Учитывать, что сторонние расширения агента — это часть цепочки поставки продукта.
Что стоит наблюдать
Признаки сами по себе не доказывают инцидент. Их полезно сопоставлять с учётной записью, версией модели, решением политики, источником контекста и результатом вызова инструмента.
Какие меры создают границу
Меры работают в связке и не перекладывают ответственность на модель: важны границы полномочий, владелец, телеметрия и процедура безопасного отказа.
Порядок допуска инструментов
Разрешить подключение только согласованных инструментов. Это убирает самовольную установку расширений.
Реестр инструментов с проверкой подлинности
Подключать инструменты только из реестра, где подтверждён источник и неизменность описания.
Статическая проверка описаний
Анализировать метаданные инструментов до подключения, выявляя посторонние указания для агента.
Изолированное исполнение и видимость параметров
Запускать инструменты в изолированной среде и показывать пользователю все параметры вызова.
Подтверждение действий пользователем
Требовать явного согласия на значимые вызовы, чтобы скрытое действие не прошло незамеченным.
Журнал вызовов инструментов
Записывать каждый вызов с параметрами и оповещать о неожиданных обращениях.
Вопросы, показатели и первые шаги
Вопросы команде и поставщику
- Какие инструменты подключены к нашим AI-ассистентам разработки и кто их одобрил?
- Проверяются ли описания инструментов перед подключением и после обновлений?
- Видит ли разработчик все параметры вызова?
- Есть ли у агента доступ к секретам?
Показатели контроля
- Доля подключённых инструментов, прошедших проверку и внесённых в реестр
- Доля вызовов инструментов, попадающих в журнал
- Число выявленных изменений метаданных без согласования
Первые 30 дней
- Собрать перечень инструментов и MCP-серверов в командах разработки
- Отключить инструменты из неподтверждённых источников
- Включить журналирование и подтверждение значимых вызовов
Как проверить в пилотном проекте
Проверить, что использование инструментов агентом ограничено целью, полномочиями и подтверждением человека для чувствительных действий.
Каждый инструмент имеет отдельную учётную запись, список разрешений и ограниченные полномочия.
Чувствительное действие останавливается до явного согласования по политике.
Журнал аудита связывает намерение, вызов инструмента, решение и результат.
Какие классы решений рассматривать
Ниже — редакционные профили поставщиков, связанные с доменом угрозы. Это не рейтинг и не подтверждение применимости: заявленные функции следует проверить в вашем пилоте по указанным критериям.

INFERA AI Security portfolio
InfEra Security · AI Security / DevSecOps
INFERA AI.SafeCode · INFERA AI.FirewallSTRAZH AI Control
STRAZH · Corporate AI Security
Shadow AI Audit & Control · LLM Firewall
AIGATE / DevScore / AIPitch
Aitalon · AI Gateway
AIGATE · DevScoreИсточники и проверка
Сначала — объяснение для русскоязычной команды. Затем — первоисточники, по которым можно проверить границы, методологию и применимость в конкретной архитектуре.