ИИ-агенты проникают в корпоративную среду гораздо быстрее, чем большинство систем безопасности успевают адаптироваться.
Они больше не просто отвечают на вопросы или генерируют контент. Агенты могут читать электронную почту, получать доступ к SaaS-приложениям, делать запросы к базам данных, вызывать API, использовать инструменты MCP, изменять записи и выполнять бизнес-процессы. Другими словами, ИИ переходит от генерации ответов к совершению действий.
Для CISO и руководителей высшего звена это меняет сам подход к безопасности. Вопрос заключается не просто в том, безопасно ли организация использует ИИ. Более важный вопрос: можем ли мы уверенно идентифицировать, регулировать, отслеживать и контролировать каждого ИИ-агента, прежде чем он станет нашим следующим привилегированным инсайдером?
Вот несколько вопросов, которые, на мой взгляд, руководители в сфере безопасности и бизнеса должны задать прямо сейчас.
Подумайте о том, что делает привилегированную человеческую учетную запись рискованной.
Она имеет доступ к важным системам, конфиденциальной информации и бизнес-процессам. Именно поэтому мы устанавливаем средства контроля вокруг администраторов, привилегированных учетных записей и сервисных идентификаторов.
Теперь представьте ИИ-агента, подключенного к Microsoft 365, Salesforce, ServiceNow, облачной среде и внутренним базам данных.
Этот агент может читать информацию, принимать решения, вызывать инструменты и изменять системы — потенциально за секунды и без чьего-либо одобрения каждого отдельного действия.
Агенту не нужно иметь злой умысел, чтобы стать опасным.
Слишком много доступа + слишком много автономии + слишком мало надзора могут создать риск, подобный инсайдерскому.
Check Point хорошо описывает этот сдвиг: ИИ-агенты становятся корпоративными сотрудниками. Они не просто генерируют текст; они извлекают данные, используют учетные данные, вызывают инструменты, обращаются к API и выполняют задачи от имени пользователей и рабочих процессов.
Они необходимы, но сами по себе их недостаточно.
Традиционное управление идентификацией и доступом (IAM) отвечает на важный вопрос: к чему этой учетной записи разрешен доступ?
Агентный ИИ заставляет нас задать другой вопрос: должен ли этот агент иметь право выполнять данное конкретное действие в этом контексте прямо сейчас?
Представьте, что агент на законных основаниях имеет доступ к базе данных клиентов. Ему может потребоваться доступ на ЧТЕНИЕ для выполнения своей работы. Но должно ли это автоматически означать, что он может УДАЛЯТЬ записи клиентов?
Вероятно, нет.
В этом заключается разница между контролем доступа и контролем действий — или результатов. Check Point строит свою модель безопасности ИИ-агентов на этом различии. В агентной среде, утверждает компания, безопасность перестает быть вопросом того, кто имеет доступ, и становится вопросом того, что ИИ разрешено делать. Причина проста: доступ может быть законным, а результат — неверным. Проверка разрешений может пройти успешно, в то время как само действие является таким, которое ни один разумный оператор не одобрил бы.
Организациям следует установить жесткие границы вокруг операций агентов.
Например, компания может принять простую политику: ни одному автономному ИИ-агенту не разрешается выполнять операцию УДАЛЕНИЯ в отношении производственных данных.
Агенту может быть разрешено:
СОЗДАНИЕ → Разрешить, ЧТЕНИЕ → Разрешить, ОБНОВЛЕНИЕ → Разрешить при определенных условиях, УДАЛЕНИЕ → Заблокировать или потребовать одобрения человека.
Важно то, что это не должно быть просто прописано в системном промпте фразой: «Пожалуйста, не удаляй производственные данные».
Средство контроля безопасности должно существовать вне агента и принудительно исполняться технически. Если агент решит, что удаление — лучший способ достижения цели, последнее слово все равно должно оставаться за политикой безопасности предприятия.
Да, и Workforce AI Security от Check Point предоставляет полезный пример из реальной жизни.
Документация Workforce AI Security от Check Point по управлению взаимодействиями с агентами описывает возможности мониторинга ИИ-агентов, работающих через серверы MCP и предоставленные им инструменты. Администраторы могут видеть операции агентов, классифицированные как создание, чтение, обновление и удаление (CRUD), анализировать риски, связанные с этими возможностями, и ограничивать доступ к инструментам с более высоким уровнем риска.
Что еще важнее, структура политик агентов Check Point прямо направлена на контроль автоматизированных действий. Примеры политик контроля в руководстве администратора Workforce AI Security показывают, как политики могут определять область действия инструмента или CRUD-операции, а затем применять действие «Разрешить» или «Заблокировать». Это важно, потому что к моменту вызова инструмента контроль доступа уже сказал «да». Агент проходит аутентификацию с унаследованным токеном, который обычно несет в себе полный диапазон операций, предоставленных системой. Проверка личности подтверждает, кто делает вызов; она не может проверить «почему» — а поскольку агенты потребляют ненадежные документы, веб-страницы и выходные данные инструментов, запрос может вообще не исходить от оператора. Область действия операции остается неизменной. Правило удаления блокирует удаление независимо от того, что убедило агента попытаться его совершить.
Это важная эволюция в кибербезопасности. Мы не просто наблюдаем за тем, что агент сделал вчера. Мы движемся к принятию решения о том, следует ли разрешить действие до того, как оно произойдет.
Потому что агенты работают быстро. Представьте такую последовательность: Сотрудник → ИИ-агент → Модель → Инструмент MCP → API → УДАЛЕНИЕ.
Агент может быть аутентифицирован. Вызов API может быть технически корректным. Агент может даже полагать, что удаление необходимо для выполнения запроса пользователя. Но организационная политика гласит, что автономные агенты не могут удалять производственные записи. Безопасность во время выполнения (runtime security) обеспечивает точку контроля до того, как это окончательное действие будет выполнено.
Check Point описывает свой подход к безопасности ИИ-агентов как оценку промптов, ответов моделей, внешнего контента, вызовов инструментов и действий агентов в режиме реального времени, что позволяет политикам блокировать небезопасное или несанкционированное поведение до его выполнения.
Это существенное различие: разрешения определяют, что агент может делать. Политика времени выполнения помогает определить, должен ли он делать это сейчас.
Человек.
У каждого производственного агента должен быть четко определенный владелец. Для агентов с более высоким уровнем риска я бы рекомендовал иметь как бизнес-владельца, так и технического владельца.
Бизнес-владелец отвечает на вопросы: зачем существует этот агент и какими полномочиями он должен обладать? Технический владелец отвечает на вопросы: как он настроен, подключен, аутентифицирован, отслеживается и защищен?
Агенты могут выполнять задачи автономно. Но подотчетность не может быть автономной. Агент без идентифицируемого владельца в конечном итоге должен рассматриваться так же, как бесхозная привилегированная учетная запись.
Именно здесь проблема идентификации становится особенно интересной.
Предположим, вредоносный контент манипулирует агентом, заставляя его вызвать легитимный инструмент. Затем агент использует действительные учетные данные для выполнения действия, которое его разработчики никогда не планировали.
Аутентификация сработала.
Авторизация технически могла сработать.
Но поведение было неправильным.
Рекомендации Check Point по обеспечению безопасности ИИ-агентов выделяют инъекции промптов, косвенные атаки, утечку конфиденциальных данных и несанкционированное использование инструментов как риски, требующие контекстных средств контроля во время выполнения. Вот почему одной аутентификации недостаточно для установления постоянного доверия к автономной сущности.
Принципы на самом деле не меняются. Меняется их применение. Для агента решение все чаще сводится к формуле:
Идентификация + Контекст + Данные + Инструмент + Запрошенное действие + Поведение = Решение о доверии.
HR-агент, читающий десять записей сотрудников, может вести себя совершенно нормально. Тот же агент, внезапно запрашивающий 20 000 записей, заслуживает более пристального внимания.
От агента разработки, пишущего код, можно ожидать выполнения определенных задач. Но тот же агент, пытающийся изменить политики IAM, не должен получать доверие просто потому, что он успешно прошел аутентификацию.
Доверие должно оставаться динамическим.
Мы уже знаем, как реализовать многое из этого благодаря управлению идентификацией (Identity Governance). Примените ту же дисциплину к агентам:
Обнаружение → Регистрация → Назначение владельца → Аутентификация → Авторизация → Мониторинг → Проверка → Приостановка → Вывод из эксплуатации
При создании агента установите право собственности. При предоставлении доступа обеспечьте принцип наименьших привилегий. При изменении целей агента пересматривайте его разрешения. При изменении поведения переоценивайте уровень доверия. А когда агент выводится из эксплуатации, отзывайте его учетные данные, токены, разрешения API и доступ к инструментам.
Сегодняшний безобидный прототип не должен стать завтрашней забытой привилегированной учетной записью.
Начните с вопросов, на которые должны быть конкретные ответы:
- Сколько агентов работает в нашей среде?
- Кто является владельцем каждого из них?
- Какие агенты имеют доступ к конфиденциальным или привилегированным системам?
- Какие инструменты и MCP-серверы они могут вызывать?
- Какие операции они могут выполнять?
- Какие действия явно запрещены?
- Можем ли мы обнаружить аномальное поведение агента?
- Можем ли мы остановить опасное действие до его выполнения?
- Можем ли мы немедленно отключить агента?
- Можем ли мы восстановить хронологию событий после инцидента?
Решение Workforce AI Security от Check Point использует аналогичный подход «обнаружение, управление и защита», обеспечивая видимость всех ИИ-приложений и агентов, гранулярные политики управления и контроль рискованных агентных действий в режиме реального времени.
Агентный ИИ не следует рассматривать только как очередную проблему безопасности приложений.
Мы создаем новый класс нечеловеческих идентификаторов, наделенных полномочиями для принятия решений.
На протяжении десятилетий кибербезопасность опиралась на принцип наименьших привилегий: предоставлять идентификатору только тот доступ, который необходим для выполнения его работы.
Агентный ИИ может потребовать от нас пойти еще дальше — к тому, что я бы назвал «Наименьшей агентностью»: предоставляйте ИИ-агенту только ту степень автономии, которая необходима для достижения его авторизованной бизнес-цели, и не более того.
Некоторые действия могут быть разрешены. Некоторые должны требовать дополнительного контекста или одобрения человека. А некоторые действия могут быть просто запрещены.
Именно так мы получаем преимущества автономного ИИ, не передавая ему неограниченные полномочия. Цель состоит не в том, чтобы замедлить внедрение ИИ. Цель — убедиться, что безопасность развивается с той же скоростью. Поскольку агенты становятся частью нашей цифровой рабочей силы, вопрос, на который каждый CISO, CIO и совет директоров в конечном итоге должен уметь ответить, остается самым простым:
Можем ли мы уверенно идентифицировать, контролировать, отслеживать и управлять каждым ИИ-агентом, прежде чем он станет нашим следующим привилегированным инсайдером?
Если ответ сегодня — «пока нет», то именно с этого, вероятно, и должна начинаться стратегия безопасности ИИ.