Масштабная утечка конфиденциальных данных произошла из-за сбоя в алгоритмах работы ИИ-агентов. Около 13 000 внутренних скриншотов, принадлежащих 343 технологическим компаниям, оказались в публичном доступе на репозиториях GitHub. По данным Cybernews, в открытый доступ попали сведения о клиентах, платежная информация, изображения интерфейсов платежных систем и данные о еще не выпущенных функциях продуктов. Причиной стало то, что кодинг-агент не смог прикрепить изображение к приватному пулл-реквесту, в результате чего он автоматически создал публичные копии, зачастую используя личные учетные записи сотрудников. В программных настройках отсутствовали политики, запрещающие подобные действия, а механизмы контроля не смогли предотвратить утечку.
Безопасность ИИ-агентов как системная уязвимость
Данный инцидент не является уникальным случаем. Согласно отчету State of AI Agent Security 2026 от компании Gravitee, лишь 14,4% организаций обеспечивают полную проверку безопасности и ИТ-утверждение для каждого ИИ-агента перед запуском. При этом 82% руководителей выражают уверенность в том, что существующие политики защищают их от несанкционированных действий со стороны автоматизированных систем. На практике в компаниях часто преобладает подход «сначала развертывание, затем одобрение, и только потом проверка».
Основная проблема заключается в разрыве между заявленной политикой безопасности и ее принудительным исполнением. Наличие регламента на бумаге не гарантирует технического контроля. Компании зачастую не могут ответить на базовые вопросы регуляторов: кто санкционировал работу конкретного агента, к каким данным он получил доступ и на основании каких правил действовал. Исследование показывает, что в среднем лишь 47,1% ИИ-агентов в организациях находятся под активным мониторингом.
Отсутствие доказательной базы для аудита
Отсутствие мониторинга создает так называемый «разрыв доказательств». Если агент не обладает уникальной идентификацией, невозможно привязать его действия к конкретному сотруднику, делегировавшему задачу. Если агенты используют общие учетные данные, аудит становится невозможным. Согласно Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report, половина организаций не способна подготовить полный отчет о доступе к данным через ИИ в течение одного рабочего дня. В условиях жестких сроков уведомления клиентов и требований регуляторов, таких как HIPAA или PCI DSS, отсутствие оперативных доказательств становится серьезным комлпаенс-риском.
Важно понимать, что регуляторы не оценивают сами модели — они требуют защиты данных. Системный промпт с запретом на доступ к материалам не является полноценным инструментом безопасности, так как его можно обойти или изменить. Аудиторы не принимают аргумент «агенту было велено не делать этого» как доказательство контроля доступа.
Как предотвратить будущие инциденты
Для минимизации рисков эксперты рекомендуют внедрить следующие меры:
- Назначение ответственных: У каждого агента должен быть конкретный владелец — человек, который может пояснить, что агент имеет право публиковать или передавать.
- Уникальная идентификация: Агенты должны иметь собственные идентификаторы, привязанные к человеку, который инициировал их работу. Авторитет должен ограничиваться конкретным действием, а не наследоваться от сессии разработчика.
- Контроль мест публикации: Необходимо составить инвентаризацию всех ресурсов, куда агент может записывать данные, и по умолчанию блокировать возможность записи в публично доступные места.
- Тестирование на соответствие: Регулярно проводите стресс-тесты, при которых команда должна в сжатые сроки подготовить пакет доказательств по действиям конкретного агента, включая авторизацию и логи доступа.
Компании, которые смогут закрыть пробелы в одобрении и мониторинге до запроса аудитора, окажутся в значительно более выгодном положении. Тем временем в других новостях сообщается, что женщина из Флориды была арестована после того, как ИИ Claude сообщил об угрозе в адрес офиса шерифа, что демонстрирует пример работы систем безопасности, переводящих автоматизированный мониторинг в плоскость реальных правоохранительных мер.
Проблема «театра безопасности» и регуляторные риски
Термин «театр безопасности» в данном контексте описывает ситуацию, когда руководство компаний опирается на формальные письменные политики, которые не имеют под собой технической реализации в точках доступа агентов к данным. Правило, которое не подкреплено системой автоматического контроля, де-факто является лишь декларацией намерений. Для аудиторов такая ситуация прозрачна: отсутствие технического принуждения к исполнению политики означает отсутствие контроля как такового.
Регуляторы не занимаются оценкой моделей ИИ. Стандарты HIPAA, PCI DSS и финансовые требования сфокусированы на защите данных, а не на природе субъекта, который к ним обратился. Для проверяющего органа не имеет значения, кто именно допустил утечку — штатный сотрудник или алгоритм. Обязательство по защите данных жестко привязано к самой информации, а требование по предоставлению доказательств контроля — к владельцу этой информации.
В этом контексте критически важно различать разрывы в разных звеньях безопасности:
- Разрыв обнаружения (Detection gap): это зона ответственности SOC (Security Operations Center).
- Разрыв доказательств (Evidence gap): это общая зона ответственности CISO и директора по комплаенсу (Chief Compliance Officer).
Разрыв доказательств возникает, когда компания не может оперативно предоставить цепочку событий. Если для восстановления хронологии действий агента требуется «собирать пазл» из разрозненных логов, значит, у организации нет системы безопасности — у нее есть лишь дефицит доказательной базы. Это становится фатальным, когда запускается «часы» регулятора: сроки уведомления клиентов и требования контрактов не учитывают время, затраченное на ручной сбор доказательств, который может длиться неделями.
Новая архитектура ответственности: как закрыть бреши
Для исправления ситуации недостаточно просто обновить документацию. Требуется переход к модели, где безопасность данных независима от модели ИИ и оставляет неизменяемый цифровой след.
Принципы контроля для безопасного развертывания
- Персональная подотчетность: Ответственность за агента должен нести не отдел разработки и не поставщик модели, а конкретное должностное лицо. Этот человек обязан подтвердить, что именно агент имеет право писать, публиковать или передавать, а также кто именно делегировал ему данные полномочия. Это самый дешевый и эффективный способ устранить административный вакуум.
- Иерархия идентификации: Агенты должны обладать собственной уникальной идентификацией, связанной с авторизовавшим их человеком. В рамках единой системы управления доступом и аудита необходимо отказаться от модели наследования прав от сессии разработчика. Полномочия должны быть строго ограничены конкретным действием (scope).
- Инвентаризация точек записи: Необходимо провести полную ревизию всех мест, куда агент может записывать или выводить артефакты. Любой ресурс, доступный извне или находящийся вне внутреннего контроля организации, должен быть либо заблокирован, либо защищен «человеческим барьером» (human-gate). Особое внимание стоит уделить скриншотам и записям экрана, так как они зачастую содержат токены доступа и конфиденциальные данные, обходя фильтры, настроенные для текстовых документов.
Финальный тест на готовность к проверке — это симуляция аудита. Выберите любое недавнее действие вашего агента и попытайтесь собрать полный пакет доказательств: кто авторизовал, к каким именно данным был доступ, какая политика была применена и где находится лог, подтверждающий этот факт. Если на сбор этих данных у команды уходят дни, это число — время вашей реальной уязвимости перед регулятором. Именно этот показатель способен убедить совет директоров быстрее, чем любые общие отчеты о состоянии индустрии.
