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