Агентный ИИ и безопасность: почему старые модели не выдерживают
Сегодня 2026-05-30 на радаре новость из No Jitter (28 May 2026): тезис простой и неприятный — «агентный» ИИ (agentic AI) выбивает почву из-под традиционных моделей enterprise-безопасности. Без пересказа и без культа терминов: речь о системах, которые не просто отвечают на запрос, а действуют — планируют, инициируют шаги, цепляют инструменты и выполняют задачи в инфраструктуре.
Я к хайпу по агентам отношусь скептически, но тут важно другое: как только у вас появляется «исполнитель» на базе ИИ, безопасность перестаёт быть про статичные периметры, роли и заранее описанные сценарии. Она становится про управление поведением, контекстом и последствиями действий.
Что именно ломается в привычной модели безопасности
Классическая enterprise-безопасность любит предсказуемость: кто-то запросил доступ, кто-то его выдал, есть права, есть журнал, есть регламенты. Агентный ИИ добавляет динамику: одно поручение человека может развернуться в цепочку действий через несколько систем и идентичностей (учёток, токенов, API-ключей), и эта цепочка заранее не очевидна даже вам.
-
Границы ответственности размываются. «Это сделал человек» превращается в «человек попросил, агент сделал». Кто виноват при инциденте — пользователь, владелец процесса, ИТ, вендор?
-
Становится сложнее держать принцип минимальных привилегий. Агенту для полезной работы часто нужно «чуть больше прав», и это быстро превращается в «почти админ», особенно в операционных задачах.
-
Увеличивается поверхность атаки. Чем больше интеграций и инструментов у агента, тем больше точек, куда можно надавить: промптами, данными, интеграциями, правами.
-
Контроль смещается от доступа к действиям. Доступ сам по себе уже не гарантия безопасности, потому что действия могут быть неожиданными, цепочными и контекстно-зависимыми.
Влияние на собственника: риск становится операционным, а не «айтишным»
Для собственника агентный ИИ — это не вопрос «поставим чатик или не поставим». Это изменение профиля риска: ошибки и злоупотребления проявляются как операционные инциденты (деньги, клиенты, репутация, простой), а не как абстрактные «киберугрозы».
-
Новый класс потерь: агент может ускорить не только полезные процессы, но и неправильные решения (например, ошибочную автоматизацию шагов). Цена ошибки растёт, потому что скорость исполнения выше.
-
Нужен управляемый допуск к автоматизации: не «разрешить ИИ», а определить, какие процессы можно отдавать агентам, а какие — только с подтверждением человеком.
-
Изменение требований к страхованию и комплаенсу: вопросы «кто действовал» и «по каким данным» станут регулярными при разборе претензий и инцидентов.
Влияние на руководителей: KPI по скорости против KPI по контролю
Руководители функций первыми почувствуют конфликт: агентные системы обещают скорость и экономию, но без рамок превращают процессы в «чёрный ящик». Это особенно больно в финансах, закупках, маркетинге, клиентской поддержке и ИТ-операциях.
-
Меняется управляемость: классические регламенты «кто согласует» не работают, если часть шагов выполняется автоматически и асинхронно.
-
Нужны “guardrails” на уровне процесса: ограничения по суммам, по типам операций, по списку разрешённых систем и по условиям подтверждения.
-
Прозрачность важнее магии: если агент не может внятно объяснить, что он сделал и почему, его нельзя пускать в критичные цепочки.
Влияние на операционные команды: безопасность должна переехать ближе к продукту и ops
Операционщики и ИТ-команды окажутся между молотом и наковальней: бизнес попросит «автоматизировать всё», а безопасность скажет «запретить всё». Реалистичный путь — инженерный контроль: наблюдаемость, ограничения, журналирование и тестирование сценариев.
-
Наблюдаемость действий агента: фиксируйте не только входной запрос, но и цепочку действий (что вызвал, куда сходил, какие права использовал, что изменил).
-
Сегментация инструментов: отдельные ключи/токены для агента, отдельные окружения, запрет на универсальные учётки.
-
Политика “human-in-the-loop” по умолчанию: для операций с деньгами, доступами, удалением данных и изменением конфигураций — только через подтверждение.
-
Песочницы и «красные команды» под агентов: тестируйте не модель, а поведение в сценариях: что будет, если агенту подсунуть неоднозначные данные или конфликтующие инструкции.
Практический вывод Neuroman AI: чек-лист на ближайшие 30 дней
-
Инвентаризируйте агентов и “полуагентов”. Всё, что может выполнять действия в системах (даже через интеграции), занесите в реестр.
-
Определите 3 уровня критичности задач. (1) Только советы, (2) действия с подтверждением, (3) автономные действия. Автономность — редкость, а не норма.
-
Ограничьте инструменты. Агенту не нужен «весь Jira/CRM/банк-клиент». Нужен минимальный набор операций.
-
Включите подробное логирование. Вопрос «что произошло» должен отвечаться за минуты, а не за недели.
-
Назначьте владельца риска. Не «служба ИБ виновата», а конкретный владелец процесса, который принимает решение об автономности.
Агентный ИИ действительно подталкивает компании к пересборке подхода к безопасности. Но паниковать не нужно. Нужно перестать думать «модель безопасна/небезопасна» и начать управлять «какие действия разрешены, в каком контексте и с какой проверкой». Там, где появляется исполнитель, безопасность становится частью операционного дизайна.
Источники
Хотите применять ИИ без хаоса и лишнего хайпа?
Александр Минаков помогает компаниям, экспертам и командам разбираться в нейросетях, выбирать рабочие сценарии и внедрять ИИ так, чтобы он давал пользу, а не просто красивую презентацию.
