Заявленная новость: AIR привлекла 50 млн долларов на безопасность AI-агентов и проверку их skills, plugins, MCP-серверов и add-ons. Компанию связывают с платформой, которая находит уже запущенных агентов, непрерывно проверяет используемые компоненты и блокирует действия, которые не проходят заданные критерии безопасности.
Прямых подтверждений раунда, состава инвесторов и конкретных характеристик продукта в доступном исследовательском пакете нет. Поэтому дальше отделяем заявленный фокус от технической логики категории. Главный практический вопрос: почему контроль расширений агента становится отдельным слоем инфраструктуры.
Базовые риски автономных агентов и их доступов разобраны глубже: теневая сторона ИИ-агентов.
AIR привлекла $50 млн: что именно заявлено
Заявленное направление AIR: безопасность AI-агентов через аудит их расширений. Вместо разовой проверки кода модель предполагает непрерывную переоценку. Компонент, который вчера считался безопасным, после изменения зависимостей или компрометации аккаунта разработчика переходит в зону риска.
В центре не сама LLM, а набор доступных ей инструментов. Модель выбирает действие, агент формирует вызов, а skill, plugin или MCP-сервер выполняют операцию. На этом этапе появляются доступы к файлам, API, базам данных, браузеру и платежным операциям.
Какая проблема стоит за новостью
Агент получает доступ к внешним действиям. Риск возникает в связке: запрос пользователя, решение модели, вызов инструмента, права токена, результат операции. Если какое-то звено расширяет разрешения, ассистент превращается в конвейер для чтения внутренних данных или отправки записей наружу.
Проверять текстовый промпт недостаточно. Агент может легитимно попросить найти документ и при этом использовать компонент, который заодно отправит содержимое во внешний сервис. Контроль смещается с генерации ответов на операции, которые агент пытается выполнить.
Что в этой истории пока нельзя утверждать
До официальных источников не подтверждены:
- источник и условия раунда на 50 млн долларов;
- состав инвесторов и оценка компании;
- масштаб развертываний и число пользователей;
- список интеграций AIR;
- точность обнаружения угроз и реальные кейсы блокировки.
Поэтому все технические описания ниже относятся к логике категории. Прямые выводы о возможностях AIR корректны после публикации официальной документации или воспроизводимых примеров.
Почему skills, plugins и MCP-серверы стали отдельным риском
Skill, plugin и MCP-сервер расширяют агентскую систему. Модель без инструментов не может изменить запись в CRM, выполнить SQL-запрос или отправить письмо. Подключенный компонент добавляет именно эту способность, поэтому его безопасность определяет границы возможного.
Разбор практической схемы ограничения прав и изоляции агентов есть в отдельном материале: как внедрять AI-агентов в разработку без риска.
Компонент может менять не только ответы, но и действия
Влияние не сводится к текстовым ответам. Инструмент определяет набор операций: читать файл, удалить объект, вызвать API, записать данные. Опасность оценивается по цепочке, а не по описанию на странице плагина. Права токена, область видимости, способ хранения секретов и окружение важнее названия компонента.
Пример: MCP-сервер для работы с документами в одном сценарии читает публичные файлы, в другом получает доступ к внутреннему хранилищу. Одинаковое имя компонента дает разный риск в разных подключениях.
Цепочка поставки важнее страницы с описанием плагина
Доверие к компоненту строится на разработчике, репозитории, пакетах, обновлениях и учетных записях сопровождающих. Публичность не гарантирует безопасность следующей версии. Разработчик может включить новую зависимость, переключить endpoint или потерять контроль над аккаунтом. Компонент, проверенный месяц назад, после обновления может получить другую логику.
Компрометация цепочки инструментов уже переходила из теории в реальный инцидент с автономным агентом: атака на HuggingFace.
MCP-сервер как точка соединения агента с внешними системами
MCP-сервер работает как интерфейс между агентом и инструментами или данными. Он передает агенту перечень методов, управляет вызовами и хранит конфигурацию доступа. При оценке важны доступные методы, сетевые соединения, область разрешений, хранение секретов и возможность ограничить отдельные вызовы.
Агент может использовать несколько MCP-серверов одновременно. Суммарная поверхность атаки складывается из всех подключенных методов, а не из одного самого привилегированного. Настройки одного сервера способны расширить контекст и права всей цепочки.
Разовая проверка не работает: зачем постоянно переоценивать компоненты
Статический аудит устаревает сразу после изменения любого элемента системы. Add-on может пройти проверку сегодня, а завтра получить другую зависимость, более широкий токен или новый endpoint. Защитная модель должна включать мониторинг изменений и переоценку перед конкретным действием, а не только первоначальное сканирование.
Что может измениться после первоначального аудита
- обновление библиотек и появление нового кода;
- изменение конфигурации и прав токена;
- смена внешнего API или адреса endpoint;
- компрометация аккаунта разработчика;
- перемещение компонента в другой контур с более чувствительными данными.
Каждый из этих сдвигов меняет вердикт. Без непрерывной переоценки безопасность сводится к галочке на момент установки.
Переоценка должна учитывать контекст действия
Риск нужно считать по конкретной операции, а не по компоненту в вакууме. Чтение общедоступного документа имеет один уровень опасности, отправка финансового отчета во внешнюю систему другой. Оценка учитывает тип данных, пользователя, цель операции, окружение и требуемый уровень подтверждения.
Такой подход позволяет разрешать типовые операции, запрашивать подтверждение для внешних отправок и полностью запрещать необратимые изменения.
Инвентаризация важнее поиска неизвестных активов постфактум
Компании нужно видеть, какие агенты запущены, какие skills и MCP-серверы используют, какие токены применяют и к каким системам обращаются. Без инвентаризации разбор инцидента начинается уже после совершенных действий.
Для больших каталогов компонентов сочетание семантического поиска с атрибутными фильтрами по владельцу, среде, команде и уровню риска ускоряет поиск. Векторные представления помогают находить похожие компоненты, а фильтры не дают результату превратиться в шум.
Как блокировать опасные действия AI-агента до выполнения
Контроль должен находиться перед потенциально опасной операцией. Агент формирует намерение, система извлекает сведения о компоненте и запрошенной операции, policy engine принимает решение. После этого вызов разрешается, отклоняется или отправляется на подтверждение человеком.
Аналогия из другой инфраструктуры: blocking webhook перед звонком возвращает eligible true или false. Это не подтвержденная функция AIR, а пример pre-action check в массовых AI-операциях. Подобная проверка для агентов может заблокировать вызов до его исполнения.
Проверка перед вызовом инструмента
Перед вызовом проверяются идентичность агента, происхождение компонента, набор разрешений, тип данных, назначение запроса и текущий контекст. Результат может быть allow, deny, human approval или ограниченный режим. Ограниченный режим разрешает, например, чтение документа, но запрещает запись изменений.
Решение принимается ближе к инструменту, а не только на входе в агентскую систему. Тогда учитывается конкретный метод и конкретные данные, а не общий промпт пользователя.
{
'agent_id': 'agent-42',
'component': 'mcp-server-finance',
'action': 'create_payment',
'data_class': 'financial',
'destination': 'external_api',
'decision': 'human_approval'
}Это иллюстрация структуры проверки, а не реальный формат AIR.
Почему одной блокировки недостаточно
Блокировка снижает риск, но не заменяет журналирование, расследование, ротацию токенов и контроль изменений. После запрета нужно понять, кто инициировал попытку, какой компонент использовался и что он успел сделать. Ложные срабатывания требуют настройки политики. Обход через цепочку нескольких инструментов требует анализа последовательности вызовов.
Баланс между безопасностью и задержкой
Глубокая проверка каждого вызова увеличивает latency и трение для пользователей. Политики разделяются по критичности действий. Типовые операции в изолированном контуре автоматически разрешаются, отправки во внешние системы и необратимые изменения требуют ручного подтверждения.
Чем платформа безопасности для AI-агентов может отличаться от обычных инструментов защиты
В категории пересекаются четыре уровня контроля: безопасность исходного кода, управление доступом, observability и runtime enforcement. Обычное сканирование репозитория закрывает первый уровень. Сетевая фильтрация закрывает часть второго. Продукт, позиционируемый как безопасность AI-агентов, должен связывать обнаружение агентов, проверку их компонентов и блокировку действий.
Какие функции стоит проверять при сравнении решений
- инвентаризация запущенных агентов;
- анализ зависимостей skills, plugins и MCP-серверов;
- контроль MCP-вызовов на уровне методов;
- политики для секретов и чувствительных данных;
- аудит действий и интеграции с SIEM и IAM;
- режим ручного подтверждения;
- версионирование политик;
- поддержка локальных или гибридных развертываний.
Где заканчивается безопасность компонента и начинается безопасность агента
Чистый код плагина не гарантирует безопасного поведения агента. Один и тот же компонент может безобидно читать файл в тестовом контуре и опасно отправлять данные в продакшене. Нужен контроль над тем, кто вызвал компонент, с какими данными и с какими правами. Это двойной контур: статическая безопасность компонента и runtime-безопасность агентского действия.
Почему безопасность AI-агентов особенно важна в регулируемых отраслях
Финансовые организации, здравоохранение, страхование и корпоративные сервисы работают с персональными, платежными, медицинскими и коммерчески чувствительными данными. Автономный агент в этих средах обязан проходить аудит, работать с минимальными привилегиями, разделять среды и оставлять доказуемую цепочку действий.
Какие действия требуют особенно жесткого контроля
- экспорт данных;
- изменение записей;
- отправка документов;
- финансовые операции;
- выдача доступа;
- запуск кода;
- обращения к внешним API.
Для каждой категории нужна отдельная политика и в ряде случаев подтверждение человеком. Необратимые операции нельзя оставлять полностью автономными.
Аудит действий важнее красивой демонстрации агента
Журнал должен фиксировать идентификатор агента, версию компонента, пользователя, запрос, использованный токен, вызванный метод, решение политики и результат операции. По этой цепочке можно восстановить, почему агент получил доступ и что сделал. Без журнала инцидент превращается в поиск иголки в стоге сена.
Почему компании не могут полагаться только на разработчиков
Команда безопасности должна самостоятельно обнаруживать несанкционированных агентов, ограничивать подключение сторонних серверов и отзывать доступы. Корпоративная безопасность не может ждать обновления продукта или исправления от внешнего разработчика. Контроль должен работать независимо от темпа поставки компонентов.
Что это означает для разработчиков и пользователей локальных LLM
Локальный запуск модели не отменяет задачу защиты. Даже если LLM работает на своей машине, подключенный MCP-сервер может читать файлы, использовать токены и обращаться к корпоративным сервисам. Для локальных агентов можно добавить защиту от prompt injection на уровне пайплайна: трехфазная защита OGL-Mini.
Минимальный контрольный список перед подключением MCP-сервера
- происхождение проекта и активность сопровождающих;
- состав зависимостей и история обновлений;
- сетевые обращения и endpoint;
- методы сервера и требуемые разрешения;
- способ хранения секретов;
- ограничения файловой системы;
- возможность отключить компонент без остановки всей системы.
Почему локальный запуск не устраняет риск автоматически
Локальная модель защищает от передачи промптов во внешний API, но не изолирует инструменты. Plugin или MCP-сервер, запущенный с сетевым доступом, может отправить данные наружу. Если у него есть токен, он может вызвать API. Локальный запуск снимает один риск и оставляет другой: доступ к файловой системе, сети и внутренним системам.
Как не превратить контроль в ручную модерацию каждого шага
Разделяйте операции по уровню риска. Автоматические политики разрешают типовые действия. Ручное подтверждение остается для доступа к чувствительным данным, внешних отправок и необратимых изменений. Так безопасность не останавливает работу, а включается в нужный момент.
Какие вопросы об AIR остаются открытыми
Категория выглядит логично, но конкретный продукт AIR нужно подтверждать отдельно. Список для проверки по первоисточникам.
Что нужно подтвердить по раунду финансирования
- дата сделки и тип раунда;
- полный размер и валюта;
- состав инвесторов;
- официальное заявление компании;
- назначение привлеченных средств.
Что нужно проверить по продукту
- есть ли реальная инвентаризация агентов;
- поддерживаются ли skills, plugins и MCP;
- есть ли непрерывный мониторинг изменений;
- как работает runtime-блокировка;
- какие интеграции с IAM и SIEM;
- точность обнаружения и уровень ложных срабатываний;
- можно ли развернуть систему в закрытом контуре.
До появления таких данных AIR стоит оценивать как перспективную гипотезу категории, а не готовый продукт с доказанными метриками.