Ваши ИИ-агенты перемещают конфиденциальные данные. Вы в курсе, куда именно?
В этом интервью для Help Net Security Гиди Коэн, генеральный директор Bonfy.AI, указывает на то, что он считает наиболее серьёзным пробелом в безопасности ИИ-агентов: риск на уровне данных. В то время как отрасль сосредоточена на инъекциях промптов и поведении моделей, Коэн утверждает, что более глубокая угроза исходит от автономных ИИ-агентов, работающих в различных системах без какого-либо контроля над тем, к каким данным они получают доступ, что комбинируют или раскрывают.
Он объясняет, как Bonfy.AI решает эту проблему по трём направлениям: контроль над данными, к которым агенты могут обращаться для контекста; мониторинг контента при его перемещении через вызовы инструментов и MCP-серверы; а также предоставление агентам возможности запрашивать у Bonfy в реальном времени проверку безопасности действия перед его выполнением. Беседа затрагивает моделирование угроз, обнаружение аномалий, делегирование между несколькими агентами, управление версиями моделей и практические рекомендации для руководителей по информационной безопасности, сталкивающихся с давлением необходимости масштабного внедрения ИИ.
Угроза, которая не даёт нам спать по ночам, — это не очередная изощрённая атака на модель, а автономное неправомерное использование данных ИИ-агентами, работающими в системах, которые предприятие ещё не полностью видит, понимает или контролирует.
Большая часть сегодняшних обсуждений по-прежнему сосредоточена на «моделях языка», инъекциях промптов, взломах и поведении моделей. Однако в крупных организациях реальный риск смещается на уровень данных в рамках всё более автономных рабочих процессов: агенты, которые могут читать из множества систем, вызывать инструменты и MCP-серверы, а затем выполнять действия (например, отправлять электронные письма, обновлять записи, публиковать контент) без участия человека на каждом шаге. Как только это происходит, любая ошибка в доступе, комбинировании или обмене данными быстро превращается в проблему системного раскрытия информации, а не просто в некорректный ответ в чате.
К чему почти никто не готов, так это к тому, что эти агенты не существуют на отдельной конечной точке или внутри чёткого периметра. Они работают в экосистемах Microsoft, Google, Salesforce, пользовательских платформах приложений, инструментальных цепочках на основе MCP, часто в роли «системных агентов», которые даже не привязаны к конкретной пользовательской сессии. Традиционные средства защиты от утечек данных, решения для защиты данных и контроля на уровне браузера изначально не были предназначены для отслеживания данных, проходящих через многоуровневую цепочку вызовов языковых моделей, векторных хранилищ, MCP-серверов и последующих автоматизаций. В результате организации фактически действуют вслепую: они не знают, какой конфиденциальный контент поступает агентам, какие инструменты его получают или куда попадают сгенерированные ИИ результаты, содержащие регулируемые или клиентские данные.
Именно на этом направлении мы сосредоточены в Bonfy: защита данных организации на протяжении всего жизненного цикла работы с ИИ и агентами, а не только защита модели от вредоносных промптов. Наша платформа применяет одинаковые контекстные, учитывающие сущности политики контроля к людям, системам и ИИ-агентам — в электронной почте, SaaS-приложениях, инструментах для совместной работы, Copilot, агентах с подключением MCP и пользовательских GenAI-процессах. Мы контролируем, какие данные доступны для контекстуализации (grounding), проверяем, что передается в промпты и инструменты, отслеживаем результаты, попадающие в письма, файлы и базы знаний, а теперь даже позволяем агентам обращаться к нашему MCP-серверу во время их собственных рассуждений, чтобы спросить: «Безопасно ли это передавать?» перед совершением действия.
Если допустить, что агенты будут повсюду и в конечном итоге получат доступ к вашим самым конфиденциальным данным клиентов, сотрудников и интеллектуальной собственности, то ключевой вопрос безопасности смещается с «Можно ли взломать модель?» на «Есть ли у нас защитные механизмы на уровне данных, работающие со скоростью и в масштабах автономного ИИ?»
Вы не можете оценивать угрозы для ИИ-агентов так же, как для отдельного веб-приложения; необходимо анализировать потоки данных и взаимодействующие стороны вокруг них комплексно, от начала до конца.
Для нас отправной точкой является отказ от мышления в парадигме «одно приложение — одна зона поражения» и вместо этого построение цепочки из четырех элементов:
- На каких данных может быть основана работа агента (grounding)
- К каким инструментам и MCP-серверам он может обращаться
- Каких людей и системы он фактически имитирует
- Все исходящие каналы, куда могут попасть результаты его работы.
Как только вы видите весь этот многозвенный путь, вы можете оценивать риски не только для модели, но и для конкретных агентов, инструментов, пользователей и наборов данных.
На практике мы делаем три конкретные вещи. Во-первых, мы контролируем этап контекстуализации (grounding) с помощью детального контекстного маркирования и управления доступом к исходным данным, что позволяет определить, какой контент вообще допустимо использовать в рабочем процессе агента для данного бизнес-контекста. Во-вторых, мы отслеживаем входящий и исходящий трафик, промпты, извлеченные документы, письма, файлы, обновления в SaaS-системах по всем каналам, чтобы видеть, когда поведение агента приводит к инциденту с конфиденциальностью, целостностью или приватностью в реальном мире. В-третьих, мы интегрируемся в цикл рассуждений агента через наш собственный MCP-сервер, чтобы агенты могли спрашивать нас в реальном времени: «Безопасно ли передавать этот контент в этот инструмент, этому пользователю или в это место назначения?» перед совершением действия.
Это создаёт совершенно иную модель угроз: вместо того чтобы пытаться предсказать каждое возможное действие динамического агента, вы определяете и устанавливаете защитные ограничения на данные, которые могут через него проходить, на объекты, на которые он может воздействовать, и на точки, где этот поток должен быть проверен или остановлен. Со временем, поскольку Bonfy отслеживает людей, системы и ИИ-агенты как основные объекты риска, вы можете видеть, какие агенты постоянно действуют вблизи опасных границ доверия, и ужесточать контроль именно там, вместо того чтобы рассматривать "ИИ" как единую монолитную и неконтролируемую зону поражения.
Сейчас почти никто по-настоящему не проверяет эти промежуточные состояния, а ведь именно в них скрывается значительная часть реального риска.
Когда агент объединяет инструменты в цепочку, каждый вызов по сути является мини-событием обмена данными: агент берёт определённую часть контекста, передаёт её API календаря, затем серверу CRM через MCP, а потом, возможно, сервису отправки электронной почты. Как выразился Гиди, при этом "каждый вызов инструмента потенциально раскрывает данные для следующего шага в цепочке", но большая часть современной "безопасности агентов" сосредоточена на конфигурации – какие инструменты разрешены – а не на фактическом содержании, передаваемом между этими инструментами.
Наш подход заключается в том, что эти промежуточные состояния необходимо рассматривать как ключевые точки для аудита. Именно поэтому мы представляем Bonfy в виде сервера MCP, который агент может вызывать в процессе рассуждения: вместо того чтобы слепо передавать контекст от Инструмента А к Инструменту Б, агент может обратиться к Bonfy между шагами с вопросом: "Безопасно ли передавать это конкретному инструменту или получателю, учитывая, кому принадлежат данные и куда они направляются?" Каждая такая проверка регистрируется с информацией о том, что было проанализировано, какие политики сработали, какие объекты (клиенты, сотрудники, потребители) были задействованы и какое решение было принято. Таким образом, у вас появляется проверяемый след на протяжении всей цепочки – не только при первом запросе и при отправке итогового письма.
На практике такой аудит выглядит не как традиционный лог API, а скорее как журнал операций на уровне данных для рабочего процесса агента: это пошаговые записи о том, какой контент агент прочитал, что он пытался отправить каждому инструменту, какие оценки рисков и метки применил Bonfy, и было ли действие разрешено, изменено или заблокировано. Поскольку используется тот же механизм с распознаванием сущностей, что и для электронной почты и SaaS-сервисов, команды безопасности могут отвечать на вопросы вроде «Какие агенты на прошлой неделе раскрыли данные клиентов из ЕС внешним MCP-серверам?», опираясь на реальные доказательства, а не надеясь, что страницы конфигурации фреймворка агента расскажут всю историю.
Когда ваш «актор» — это ИИ-агент, живущий 30 секунд, вы всё равно не можете строить обнаружение аномалий исключительно на долгосрочном поведении агента; вам необходимо опираться на контент, контекст и человека или систему, стоящих за этим экземпляром агента.
Традиционные SIEM-системы предполагают стабильные идентичности и паттерны в течение дней, недель и месяцев: вы создаёте базовый профиль для человека и затем ищете отклонения. С агентами паттерн инвертирован: идентичность агента мимолётна, но данные, к которым он обращается, пользователь, от имени которого он может действовать, и границы доверия, которые он пересекает, вполне реальны и часто постоянны. Поэтому обнаружение аномалий должно сместиться с вопроса «Ведёт ли себя Алиса сегодня странно?» к вопросу «Допустимо ли это сочетание контента, назначения и актора — человека, системы или экземпляра агента — для нашего бизнес-контекста в данный момент?»
Именно на этом и сосредоточен Bonfy. Мы анализируем сам неструктурированный контент, обогащённый осознанием сущностей — какой клиент, какой потребитель, какая линейка продуктов, какой регуляторный режим — и коррелируем это с тем, кто или что действует: сотрудник, сервисная учётная запись, сценарий Copilot или недолговечный ИИ-агент, а также со связью между ними. Даже если агент создаётся и завершает работу менее чем за минуту, след данных, который он оставляет в электронной почте, SaaS-приложениях, инструментах совместной работы и ИИ-системах, становится видимым через единую, контекстную призму.
Затем мы моделируем как людей, так и агентов — а также связи между ними — как полноценные сущности в нашей Семантической Сети. Это позволяет атрибутировать рискованные паттерны не просто к временному идентификатору агента, а к пользователю, стоящему за ним (где это применимо), конкретным агентам или их классам, а также к их роли в более широком бизнес-контексте. Со временем вы перестаёте действовать вслепую среди тысяч невидимых ботов; вместо этого вы управляете портфелем человеческих и нечеловеческих участников и их взаимосвязями, которые оцениваются через единую, ориентированную на данные модель риска.
Неудобная правда заключается в том, что в большинстве современных мультиагентных систем никто по-настоящему не защищает эту цепочку делегирования. Все полагаются на то, что если оркестратор «хороший», то и всё последующее будет вести себя корректно. С точки зрения Bonfy, этот подход нужно перевернуть: каждый вызов подчинённого агента следует рассматривать как недоверенный с точки зрения данных, предоставляя управляющему агенту инструменты для проверки входящих и исходящих данных, прежде чем он их примет или перешлёт.
Конкретно, оркестратор никогда не должен слепо потреблять вывод подчинённого агента. По крайней мере, с точки зрения данных, мы предоставляем управляющему агенту инструмент Bonfy MCP, который он может вызывать в процессе работы для проверки входных и выходных данных подчинённого агента. Это позволяет убедиться, что они не нарушают никаких политик, включая проверки на конфиденциальность, приватность и целостность данных, например: «Не содержит ли это резюме внезапно данные другого клиента или незапланированную медицинскую информацию?» Промпт оркестратора буквально кодирует это поведение: «Делегируй задачи подчинённым агентам, но прежде чем действовать на основе их результатов или передавать их дальше, проверь с помощью Bonfy, что контент безопасен для данного получателя и бизнес-контекста.»
Поскольку Bonfy анализирует сам контент, обогащённый распознаванием сущностей — какой клиент, какой потребитель, какая линейка продуктов, какая юрисдикция — он может сигнализировать, когда скомпрометированный или некорректно работающий суб-агент пытается внедрить чувствительные или противоречивые данные в цепочку, даже если все агенты недолговечны и используют общий идентификатор в рамках системы. Все эти проверки регистрируются на той же платформе, которую мы используем для электронной почты и SaaS: вы получаете журнал аудита о том, какой оркестратор вызвал какой суб-агент, какие данные передавались, какие политики сработали, и разрешил ли Bonfy следующий шаг оркестратора, изменил его или заблокировал. Другими словами, мы не пытаемся слепо «доверять» цепочке делегирования — мы её инструментируем так, чтобы любой вывод суб-агента должен был пройти через политику, ориентированную на данные, прежде чем сможет навредить остальной части рабочего процесса.
Мы не просто движемся навстречу кризису цепочки поставок — во многих компаниях мы уже в нём находимся. Мы просто решили доверять любому инструменту, который агент решит использовать.
Сервер или плагин MCP по сути является «чёрным ящиком» — микро-поставщиком, которому ваши агенты могут передавать конфиденциальные данные в середине рабочего процесса. В типичной среде могут быть десятки или сотни таких инструментов (внутренние сервисы, сторонние API, источники обогащения данных), которые динамически оркестрируются большими языковыми моделями без участия человека и практически без проверки безопасности. С точки зрения защиты данных каждый из этих инструментов теперь является частью вашей цепочки поставок ИИ, но очень немногие организации относятся к ним соответствующим образом.
Большая часть раннего рынка «безопасности ИИ-агентов» сосредоточена на конфигурационной политике: какие агенты существуют, какие инструменты они видят, какие разрешения им предоставлены. Это необходимо, но недостаточно, потому что, как и любое другое программное обеспечение, эти инструменты могут использоваться безопасно или злонамеренно в зависимости от того, какие данные через них проходят. Мы сознательно фокусируемся на уровне данных, а не только на уровне конфигурации: какой контент отправляется на какой сервер MCP, на какие сущности он ссылается, какие юрисдикции затрагивает, и допустимо ли это сочетание для вашего бизнеса и нормативного контекста.
Конкретно, мы предоставляем организациям три рычага управления. Во-первых, мы контролируем доступ к данным на уровне источника с помощью детальной контекстной маркировки. Это позволяет заранее исключить определенные категории информации, такие как персональные медицинские данные, персональные данные граждан ЕС или условия конкретных сделок с клиентами, из числа допустимых для конкретного агента или инструмента. Во-вторых, мы осуществляем мониторинг и контроль на выходе, анализируя электронные письма, файлы, обновления в SaaS-сервисах и другие результаты, созданные с помощью агентов, независимо от того, какие плагины использовались в процессе. И в-третьих, через наш собственный MCP-сервер мы позволяем агентам в реальном времени спрашивать нас: «Безопасно ли передавать эти данные этому инструменту или получателю?» — прежде чем информация будет передана стороннему сервису.
Таким образом, проблема цепочки поставок в эпоху ИИ, связанная с MCP-серверами и плагинами, действительно нарастает, но выход заключается не в замораживании инноваций или попытках проверить каждый инструмент в экосистеме. Решение — внедрить защитные барьеры, ориентированные на данные, чтобы, как бы быстро ни росла экосистема агентов, конфиденциальная информация управлялась единообразно для каждого агента, каждого инструмента и каждого рабочего процесса.
Командам безопасности необходимо исходить из того, что модель — это изменчивый элемент цепочки поставок, а не фиксированный компонент, который можно один раз сертифицировать и забыть о нем.
Вы можете не контролировать, когда ваш провайдер корректирует веса, слои безопасности или маршрутизацию, но вы можете контролировать защитные барьеры для данных вокруг любой модели, которая оказывается за конечной точкой. Для нас это начинается с рассмотрения версионирования моделей как изменения, имеющего значение для соответствия требованиям: вам необходимо знать, какие категории данных каждое приложение может отправлять «в LLM», и вам нужны доказательства того, что независимо от того, используется ли это Модель X в понедельник или Модель Y в пятницу, одна и та же политика применяется к промптам, извлеченным документам, вызовам инструментов и результатам.
Наш подход изначально не зависит от модели. Мы не встраиваемся в конкретную модель клиента; мы функционируем как независимый от клиента уровень безопасности данных для ИИ, который проверяет входящий и исходящий контент агентов, помощников и LLM с помощью нашего собственного механизма, учитывающего сущности. Как подчеркивает Гиди, тот факт, что Bonfy работает с независимыми от клиента моделями ИИ, означает, что вы можете применять одни и те же защитные меры, даже если использование вашей базовой LLM со временем меняется — осознанно или нет — потому что политики хранятся в нашей платформе, а не в конкретной контрольной точке модели.
С точки зрения управления рисками и соответствия требованиям, это даёт вам два ключевых преимущества. Во-первых, стабильный, поддающийся аудиту слой: вы можете предъявить регуляторам и аудиторам последовательную запись о том, какие чувствительные, регулируемые или относящиеся к конкретному клиенту данные были разрешены или заблокированы на уровне данных, даже по мере эволюции версий моделей в фоновом режиме. Во-вторых, возможность обнаруживать, когда поведение модели меняется рискованным образом — например, внезапно начинает включать более детальную информацию о клиентах в сводки — потому что Bonfy продолжает классифицировать, маркировать и применять политики к самому контенту, независимо от того, какая модель его создала.
«Безопасные ИИ-агенты» — это не галочка в чек-листе, а сквозная дисциплина, которая должна сопровождать данные везде, где агенты читают, анализируют, используют инструменты и генерируют текст.
С нашей точки зрения, надёжная безопасность агентов основывается на трёх столпах. Первый — контроль над исходными данными: какой контент агенту вообще разрешено видеть, с использованием детальной контекстной маркировки и правил доступа к таким системам, как SharePoint, электронная почта, CRM и другие SaaS-приложения. Второй — защита данных во время работы агента: когда он обращается к MCP-серверам, плагинам или внутренним API, необходима встроенная проверка, которая может определить, собирается ли он передать конфиденциальную медицинскую информацию, данные конкретного клиента или регулируемый контент неподходящему инструменту или третьей стороне. Третий — управление результатами: электронные письма, файлы, заявки и другие артефакты, создаваемые агентом, должны проверяться на утечки и нарушения политик, прежде чем они попадут к человеку или во внешнюю систему.
Где покупатели теряются, так это в том, что многие предложения по «безопасности агентов» ограничиваются конфигурацией — перечислением агентов, включением инструментов, управлением разрешениями — без реального отслеживания того, какие данные проходят через эти автоматизации. Это необходимая гигиена, но она не спасёт вас от агента, который идеально «настроен», но всё равно передаёт данные клиентов через разрешённый MCP-плагин. Bonfy сознательно фокусируется на уровне данных, а не только на плоскости управления: тот же механизм, учитывающий сущности, который мы используем для электронной почты и SaaS, применяется к запросам агентов, извлечённым документам, MCP-вызовам и результатам, с одним набором политик, управляющих людьми, системами и ИИ-агентами.
Если вы специалист по безопасности, пытающийся разобраться в обилии предложений, мы рекомендуем три простых проверочных вопроса. Спросите поставщиков: Можете ли вы видеть и классифицировать реальное содержимое, которое поступает к моим агентам и исходит от них, по всем основным каналам — а не просто вести журнал того, какие инструменты им разрешено вызывать? Можете ли вы применять политики единообразно как для людей, так и для агентов, чтобы правило «данные этого клиента не могут покидать эту границу» действовало повсеместно? И могут ли мои агенты обращаться к вашей платформе в реальном времени — например, через сервер MCP — чтобы проверить, соответствует ли конкретное действие требованиям, прежде чем его выполнить? Если ответ на любой из этих вопросов «нет», перед вами не решение для безопасности, а просто галочка в отчете.
Я бы изменил один подход: перестать рассматривать риски ИИ-агентов как абстрактную «проблему будущего ИИ» и начать относиться к ним как к очень конкретной проблеме данных, которая уже существует в продакшене сегодня.
Сейчас внедрение ИИ опережает управление им; агенты уже читают, преобразуют и генерируют конфиденциальные данные в электронной почте, SaaS-приложениях, внутренних системах и сервисах, подключенных через MCP, в то время как у большинства организаций нет единого представления о том, к каким данным эти агенты получают доступ. Отрасль вкладывает энергию в модели, промпты и конфигурацию, но гораздо меньше — в простой вопрос: куда движется моя конфиденциальная, регулируемая или относящаяся к конкретному клиенту информация, пока эти автоматизированные системы выполняют многошаговые рабочие процессы?
С точки зрения Bonfy, необходимый сдвиг — это поставить данные в центр обсуждения рисков, связанных с агентами. Это означает создание систем, которые могут видеть и классифицировать неструктурированный контент везде, где он перемещается, понимать людей, клиентов и юрисдикции, стоящие за этим контентом, и применять единую политику независимо от того, является ли субъект человеком, SaaS-приложением или временным ИИ-агентом. Это также означает предоставление агентам возможности — через такие механизмы, как наш интерфейс сервера MCP — спрашивать в реальном времени: «Безопасно ли это отправить или сохранить здесь?», вместо того чтобы предполагать, что их набор инструментов по умолчанию поступит правильно.
Если мы сделаем этот концептуальный сдвиг сейчас, нам не придется ждать громкого инцидента, чтобы обнаружить, что мы фактически действовали вслепую, пока ИИ автоматизировал перемещение нашей самой чувствительной информации.
Самое честное, что мы можем сказать CISО в такой ситуации: не принимайте модель работы «сначала внедряй, потом разбирайся с рисками для данных», даже если на вас оказывают такое давление.
Остановить ИИ-агентов невозможно; однако вы можете настоять на поэтапном внедрении, где первым результатом станет видимость, а не автоматизация. Начните с инструментирования каналов, где агенты будут читать и писать — электронная почта, системы совместной работы, SaaS-приложения, внутренние системы, инструменты с подключением MCP — чтобы увидеть, к каким конфиденциальным, регулируемым или клиентским данным они могли бы получить доступ, если бы вы дали им полную свободу. Эти реальные данные дают вам рычаг для взрослого разговора с бизнесом: «Вот где мы можем безопасно автоматизировать уже сегодня, здесь нужны защитные механизмы, а вот эти сценарии пока останутся под контролем человека».
После этого двигайтесь последовательно: от видимости к политикам, а затем к предотвращению. Используйте контроли, учитывающие сущности, чтобы одни и те же политики применялись независимо от того, кто действует — человек, SaaS-процесс или ИИ-агент. Дайте агентам возможность обращаться к сервису, например, через интерфейс MCP от Bonfy, для проверки контента в реальном времени, а не полагаться только на статическую конфигурацию. Это позволяет вам сказать «да» масштабному использованию ИИ, но на ваших условиях — с измеримыми контролями, проверяемыми решениями и убедительной позицией, когда совет директоров или регуляторы спросят, как вы обеспечили безопасность данных в мире, управляемом агентами.
Если вы — директор по информационной безопасности, и вам говорят «внедряйте ИИ-агентов сейчас и обеспечьте полную безопасность данных», не спорьте о том, нужен ИИ или нет — настаивайте на правильной последовательности действий. Сначала вы включаете глубокую видимость потоков конфиденциальных, регулируемых и клиентских данных в электронной почте, SaaS-сервисах, системах совместной работы и среди агентов. Затем вы добавляете политики безопасности. И только после этого разрешаете масштабную автоматизацию, где агенты обращаются к сервису, например Bonfy, в реальном времени с вопросом «Безопасно ли это отправить или сохранить здесь?» перед совершением действия. Вот как можно согласиться на масштабное использование ИИ, не ставя компанию на кон, полагаясь на слепое доверие к чужой конфигурации.