Пока ИИ-агент только подсказывает, неточность можно исправить до того, как она повлияет на бизнес. Но когда он получает право действовать самостоятельно, цена промаха меняется. Вместе с автоматизацией компании начинают передавать агентам не только задачи, но и реальные полномочия, а значит, возрастает цена неверного шага.
Константин Мельников, руководитель департамента специальных сервисов Infosecurity (входит в «Софтлайн Решения», ГК Softline), разбирает, какие угрозы возникают при передаче полномочий и как выстроить безопасную работу с автономными системами, не отказываясь от преимуществ автоматизации.
Когда ИИ получает не только знания, но и права
ИИ-агенты получают доступ к корпоративным данным, взаимодействуют с внешними источниками, вызывают другие сервисы и могут самостоятельно выполнять последовательность операций. Для информационной безопасности это меняет саму точку контроля. Теперь речь идет не только о защите модели или учетной записи сотрудника. У агента появляется собственная идентичность, набор полномочий, инструменты и возможность самостоятельно выбирать следующий шаг.
Именно здесь проходит важная граница. Если модель только формирует ответ, ошибка остается ошибкой в информации. Если же система может изменить запись в корпоративной системе, отправить письмо, создать заявку или запустить операцию, ошибка становится действием. Поэтому при внедрении важно оценивать не только качество модели, но и весь контур ее работы: какие данные она видит, к каким системам подключена, какие инструменты использует и что может сделать без участия человека.
По сути, здесь начинает работать классический принцип минимальных привилегий, только применяется он уже к новому типу субъекта. Агенту нужно давать только те права, которые необходимы для конкретной задачи. При этом важно заранее понимать, что именно он сможет сделать внутри системы. Доступ к CRM, например, не должен автоматически означать возможность менять или удалять записи.
Отдельный вопрос — идентичность агента. Должно быть понятно, какой именно агент выполнил действие, кто является его владельцем, какие права ему выданы и как их можно отозвать. Без этого по мере роста числа автоматизированных решений возникает неприятная ситуация: ИБ видит отдельные системы, но постепенно теряет общую картину — кто получил доступ, к чему именно и с какими полномочиями.
Атаковать систему напрямую уже необязательно
Проблема становится сложнее, когда агент работает с внешним контентом. Для него письмо, документ или веб-страница могут быть не просто источником информации, а частью входных данных, которые влияют на дальнейшие действия.
Представим, что агент отвечает за закупки. Он получает письмо от поставщика с измененными банковскими реквизитами, сверяет информацию о компании по открытым источникам, а затем может внести изменения в платежный документ. Если у агента есть соответствующие права, следующий шаг становится уже операционным. В таком сценарии атакующему не обязательно взламывать платежную систему, достаточно повлиять на данные, которые агент использует для принятия решения.
Именно здесь косвенная prompt injection перестает быть исключительно теоретической проблемой: внешняя инструкция может повлиять на выбор инструмента и дальнейшее действие агента. Поэтому при внедрении необходимо проверять не только саму модель, но и источники данных, которые она считает доверенными, способы передачи контекста и действия, которые могут быть выполнены на основании полученной информации.
Доступ — это еще не действие
Изоляция ИИ внутри корпоративной сети снижает часть рисков, но не отменяет их. В компании может работать собственная модель, обученная на внутренних знаниях. Например, в одном из процессов такая система получает анкеты заказчиков, учитывает специфику услуг, лицензирование и возможные аномалии, после чего формирует расчет и коммерческое предложение.
В этом случае сама модель становится хранилищем корпоративного контекста. Если агент использует сохраняемый контекст или память, они тоже становятся частью поверхности атаки. Попавшая туда неверная информация потенциально может повлиять на последующие решения системы.
Есть и еще одно отличие агентных систем от традиционных инструментов — скорость. Она напрямую меняет масштаб последствий. Человек может тратить часы на обнаружение, анализ и обработку инцидента. Агент способен за секунды выполнить целую последовательность операций.
Например, подобный риск проявился во время кибериспытания Google. Как сообщил Reuters, модель Gemini получила доступ к системам трех реальных компаний из-за ошибки в инфраструктуре тестовой среды. После того как стало понятно, что затронуты реальные организации, модель прекратила действия, а Google сообщил, что уведомил их.
Для бизнеса здесь важен сам механизм. Агент может выйти за пределы первоначальных ограничений не из-за отдельной атаки на систему, а из-за сочетания автономности, доступа к инструментам и ошибки в настройке среды. Поэтому границы его действий нужно проверять заранее — и продолжать контролировать после запуска.
Если скомпрометированный агент имеет широкие полномочия, ущерб может возникнуть раньше, чем служба безопасности поймет, что происходит. Более того, агент редко существует в полной изоляции. Он может передать результат другому агенту, вызвать API или запустить автоматизированный workflow. Так ошибка на первом этапе способна распространиться по всей цепочке. Поэтому при проектировании важно понимать не только права конкретного агента, но и границы его взаимодействия с другими системами.
Для таких решений недостаточно фиксировать только конечный результат. В журнале должна сохраняться последовательность действий: с какими данными работал агент, какие решения принимал, какие инструменты вызывал и какие изменения внес. Иначе после инцидента придется восстанавливать не только инфраструктуру, но и саму логику произошедшего.
Автономность нужно выдавать по уровням
Отсюда возникает главный практический вопрос: сколько самостоятельности действительно нужно конкретному агенту?
Полный запрет ИИ в компании проблему не решает. Сотрудники все равно будут использовать внешние инструменты, только организация потеряет возможность контролировать этот процесс.
Рабочий подход другой: определить границы допустимой автономности для каждого процесса. Если агент анализирует информацию и готовит результат, ему может быть достаточно прав на чтение. Если он создает заявку, это еще не означает, что у него должно быть право ее согласовывать.
Чем выше цена ошибки, тем меньше действий стоит оставлять без дополнительной проверки. Если действие может привести к финансовому ущербу, изменению критичных данных или остановке бизнес-процесса, необходим дополнительный контроль.
Это не новая философия безопасности. Меняется объект, к которому она применяется: теперь учетная запись может принадлежать не человеку, а автономной системе, которая сама определяет последовательность своих действий.
Уровень автономности должен соответствовать потенциальному ущербу. Чем серьезнее последствия ошибки, тем меньше самостоятельности должно оставаться у агента и тем больше независимых точек контроля должно быть встроено в процесс.
Безопасность не заканчивается после запуска
Безопасное внедрение начинается не с выбора наиболее мощной модели. Сначала нужно понять, что именно мы ей разрешаем: какой бизнес-процесс предполагается автоматизировать, насколько он критичен, какие данные необходимы и какие действия допустимы для агента. После этого нужно определить среду, доступы, инструменты контроля и сценарий восстановления.
Пилот лучше начинать с процессов, где потенциальный ущерб ограничен. Если система показывает стабильный результат, ее полномочия можно постепенно расширять. При этом критичные операции стоит разделять. Агент может собрать информацию, подготовить документ или создать заявку, но действие, которое способно привести к существенному ущербу, не должно автоматически следовать из предыдущего шага.
Такой разрыв между подготовкой и критичным действием позволяет использовать автоматизацию, сохраняя точку человеческого контроля там, где цена ошибки особенно высока.
И контролировать нужно не только самого агента. Сотрудник тоже может обойти защитные меры — например, подключить внешний сервис, загрузить туда корпоративные документы или предоставить ему избыточные права. Поэтому правила использования ИИ должны быть частью общей системы контроля доступа, а не формальным документом.
Сотрудник должен понимать простую вещь: внешний ИИ-сервис по отношению к корпоративным данным фактически является внешним подрядчиком. Организация не контролирует полностью, что происходит с переданной ему информацией. Поэтому заранее необходимо определить, какие данные можно передавать во внешние модели, какие процессы разрешено автоматизировать и куда сообщать о подозрительном поведении.
Есть и другая проблема: агентная среда может расти практически незаметно для ИБ. Поэтому компании нужна не только защита каждого отдельного агента, но и инвентаризация всей агентной среды.
Для автономного агента должен существовать и механизм быстрого отзыва полномочий — условный «стоп-кран». Причем он должен появиться не после инцидента, а еще на этапе проектирования системы. Если система начинает вести себя нештатно, ИБ должна иметь возможность не только отключить ее интерфейс, но и заблокировать доступ к данным и инструментам.
Вывод
ИИ уже часть корпоративной инфраструктуры. Поэтому вопрос для ИБ постепенно смещается. Речь уже не только о том, использовать агентов или нет. Важно понимать, какие активы он видит, какие доступы получает, каким данным доверяет и что имеет право сделать самостоятельно.
И вместе с этим появляется еще один обязательный вопрос: кто сможет остановить агента, если что-то пойдет не так?
Чем больше автономности получает агент, тем жестче должны быть ограничения и требования к восстановлению. Агент может работать быстрее человека. Именно поэтому контроль над ним должен быть быстрее его собственных действий.
В противном случае бизнес рискует получить систему, которая действительно работает быстрее человека — но и ошибается тоже быстрее.
Источник: Константин Мельников, руководитель департамента специальных сервисов Infosecurity
Иллюстрация предоставлена пресс-службой компании
