За последние несколько лет искусственный интеллект незаметно перешёл очень важную границу. Сначала нейросети просто отвечали на вопросы, потом начали писать код. Затем уже научились работать с документами, таблицами и базами знаний. А сейчас мы наблюдаем следующий этап развития — AI начинает выполнять действия внутри корпоративной инфраструктуры. Именно здесь начинается история, которую многие пока недооценивают.
От помощника к исполнителю
Посмотрим на эволюцию AI буквально в одной схеме.
2022
AI отвечает
↓
2023
AI создаёт контент
↓
2024
AI пишет код
↓
2025
AI получает доступ к инструментам
↓
2026
AI начинает выполнять действия
Разница кажется небольшой. На самом деле она фундаментальна. Когда ChatGPT отвечает на вопрос, последствия ошибки обычно ограничиваются неправильным ответом. Когда AI-агент получает доступ к инфраструктуре компании, последствия могут выглядеть совершенно иначе. Теперь ошибка может привести не к неправильному тексту, а к реальному действию. Мы постепенно переходим от эпохи:
AI отвечает
к эпохе:
AI действует!
Почему старая модель безопасности начинает ломаться?
Большинство корпоративных систем безопасности проектировались вокруг простой идеи — любое действие совершает человек, поэтому современные компании умеют отвечать на вопросы:
-
Кто вошёл в систему?
-
Кто скачал файл?
и тд.
Схематично это будет выглядеть вот так:
Пользователь
│
▼
Корпоративная система
│
▼
Журнал событий
Кто сделал действие?
Ответ известен. Но появляется новый участник — AI-агент. И он начинает вести себя не как программа, он начинает вести себя как сотрудник, только значительно быстрее.
А что происходит сегодня?
Представим обычный рабочий день. Менеджер пишет агенту: «Подготовь отчёт по всем клиентам за последние три года.» Что происходит дальше?
Сотрудник
│
▼
AI-Агент
│
┌────┼────┐
▼ ▼ ▼
CRM ERP API
│ │ │
└─────┴────┘
│
▼
Отчёт.
На первый взгляд всё хорошо, но появляется новый вопрос. Кто именно выполнил действия? Сотрудник? AI? CRM? Система? — Ответ уже не выглядит очевидным.
Новый класс рисков
Важно понимать: проблема не в том, что AI злой, проблема не в том, что AI однажды захватит мир. Проблема то намного прозаичнее — AI действует очень быстро. Грубо говоря, обычный сотрудник способен изменить десятки записей. AI способен изменить десятки тысяч записей за то же время. Обычный сотрудник заметит ошибку. AI может масштабировать ошибку раньше, чем её заметят люди.
Например:
Запланировано:
100 записей
—————
Фактически:
100 000 записей
Или:
Нужно:
отчёт по отделу
—————-
Получилось по итогу:
выгрузка всей клиентской базы
Или:
Нужно:
отправить письмо клиенту
—————-
Получилось:
массовая рассылка
Все эти сценарии объединяет одна вещь, как по мне, они происходят не из-за злого умысла. Они происходят ещё потому, что автономная система получила право выполнять реальные действия.
Главное изменение ближайших лет
До сих пор компании управляли:
-
Пользователями
-
Серверами
-
Приложениями
В ближайшие годы придётся управлять ещё одним объектом — AI Агентами. Именно здесь появляется новый вопрос, если сегодня существуют:
-
Firewall
-
SIEM
-
IAM
-
DLP
-
EDR
, то что будет контролировать действия AI-агентов?
На этот вопрос индустрии ещё только предстоит ответить.
Почему обычная информационная безопасность не готова к AI-агентам?
В первой части мы пришли к простой мысли: AI постепенно перестаёт быть инструментом для генерации текста и становится участником бизнес-процессов. А значит появляется новый вопрос: если у компаний уже есть IAM, SIEM, DLP, PAM, Firewall и другие средства защиты, зачем нужен отдельный уровень контроля для AI-агентов?
На первый взгляд кажется, что существующих систем должно быть достаточно. Но если посмотреть глубже, становится понятно: классическая информационная безопасность отвечает немного на другие вопросы.
Классическая ИБ контролирует доступ и события
Современная корпоративная безопасность строится вокруг нескольких типов систем.
-
IAM — кто имеет доступ
-
PAM — кто имеет привилегированные права
-
DLP — куда уходят данные
-
SIEM — что уже произошло
-
WAF — какие запросы идут в приложение
-
Firewall — какой сетевой трафик разрешён
Эти инструменты очень важны. Они не становятся бесполезными из-за появления AI. Но большинство из них создавались для мира, где действие выполняет человек, сервис или приложение с заранее понятной логикой.
Схематично это выглядит так:
Сотрудник
↓
Корпоративная система
↓
Средства ИБ
↓
Журнал событий
Человек вошёл в систему. Человек выполнил действие. Система записала событие. Ответственность относительно понятна.
AI-агент размывает привычную модель
Теперь добавим AI-агента.
Сотрудник
↓
AI-агент
↓
CRM / ERP / API / БД / Почта
Сотрудник формулирует задачу, а AI сам строит план, сам выбирает инструмент и уже сам работает с инпут-аутпутами. И вот здесь появляется проблема. Кто именно выполнил действие?Сотрудник(человек), или агент(ИИ)? На практике ответ часто выглядит так: все сразу. Именно поэтому в агентных системах начинает размываться привычная модель ответственности.
Пример с CRM
Представим обычную задачу. Менеджер пишет агенту: подготовь отчёт по клиентам за последние три года. Для выполнения задачи агент может:
прочитать CRM
↓
обратиться к ERP
↓
запросить аналитику
↓
сформировать файл
↓
отправить результат сотруднику
С точки зрения классической безопасности всё может выглядеть нормально, доступ есть, запросы корректные, пользователь авторизован, сервис отвечает штатно, но возникает другой вопрос: должен ли агент выполнять именно такую цепочку действий?
Например:
отчёт по отделу
↓
выгрузка всей клиентской базы
Формально доступ мог быть разрешён, но фактически же операция стала рискованной!
Проблема не только в доступе
Это ключевой момент. Большинство систем безопасности отвечают на вопрос: можно ли субъекту получить доступ? Но AI-агенты добавляют новый вопрос: нужно ли выполнять это действие сейчас, в этом контексте и в таком объёме? Разница принципиальная.
Например, агент может иметь право отправлять письма. Это нормально. Но должен ли он отправлять 10 000 писем без подтверждения? Агент может иметь право читать CRM. Но должен ли он выгружать всю клиентскую базу? Агент может иметь право изменять записи. Но должен ли он менять 100 000 записей за одну минуту? Для обычного пользователя такие сценарии чаще заметны, для AI-агента они могут стать результатом одной неправильно понятой задачи.
Что не закрывают существующие системы полностью
Условно можно сравнить так:
|
Система |
На какой вопрос отвечает |
|
IAM |
Кто имеет доступ? |
|
PAM |
У кого повышенные права? |
|
DLP |
Какие данные уходят наружу? |
|
SIEM |
Что уже произошло? |
|
API Gateway |
Какой сервис вызывает API? |
|
AI Control Layer |
Что AI собирается сделать до выполнения действия? |
Именно последний вопрос становится новым. Не “что уже произошло”, а “что сейчас собирается произойти”. В этом отличие контроля AI-агентов от классического мониторинга.
Новая логика контроля
Классическая модель часто выглядит так:
Есть право?
↓
Разрешить действие
Для AI-агентов этого становится недостаточно. Нужна более осторожная цепочка:
Есть право?
↓
Да
↓
Какое действие выполняется?
↓
Какой контекст?
↓
Какой объём данных?
↓
Какие последствия?
↓
Разрешить / заблокировать / отправить на подтверждение
То есть контроль смещается от простой проверки доступа к анализу намерения, риска и последствий.
Что нужно компаниям в эпоху AI-агентов
По мере роста числа AI-агентов организациям придётся отвечать на новые вопросы: какой агент выполняет действие? Кто инициировал задачу? Почему агент выбрал именно этот инструмент? Какие данные были использованы? Какие системы затронуты? Можно ли отменить действие? Можно ли быстро остановить агента? Можно ли перевести его в безопасный режим? Можно ли доказать аудитору, что критическая операция была проверена до выполнения? Сегодня эти вопросы часто решаются вручную или вообще не решаются.
AI-агент как новый цифровой сотрудник
Самая простая аналогия — новый сотрудник. Только необычный.
Он:
-
имеет доступ к системам
-
умеет работать с данными
-
может выполнять действия
-
работает круглосуточно
-
не устаёт:)
-
может выполнять тысячи операций в минуту
Если компания выдаёт такому “цифровому сотруднику” доступ к корпоративным системам, логично, что ему нужен отдельный уровень контроля.
Когда-то появились:
-
Firewall — для сетей
-
IAM — для пользователей
-
EDR — для рабочих станций
-
SIEM — для событий безопасности
Возможно, следующим инфраструктурным слоем станет:
-
AI Firewall
-
AI Gateway
-
AI Control Layer
То есть система, которая контролирует не только доступ AI, но и его действия до выполнения. И именно к этому мы постепенно подходим.
Как может выглядеть AI Firewall
Если принять мысль, что AI-агент становится новым участником корпоративной инфраструктуры, то следующий вопрос возникает почти автоматически. Как его контролировать? Не после инцидента, не когда данные уже ушли, не когда операция уже выполнена. А до того, как действие произошло. Именно здесь появляется идея AI Firewall.
Название условное. Кто-то может называть это AI Gateway, Agent Gateway, Runtime Control Layer, Policy Enforcement Layer или AI Control Layer. Суть от этого не меняется. Нужен отдельный слой между AI-агентом и корпоративными системами!
Главная задача AI Firewall
Классический firewall контролирует сетевой трафик. AI Firewall должен контролировать действия AI-агента. Схематично это можно представить так:
AI-агент
↓
Запрос действия
↓
AI Firewall / AI Gateway
↓
Проверка политики
↓
Оценка риска
↓
Решение
↓
Корпоративная система
То есть агент больше не должен обращаться к CRM, ERP, базе данных или почте напрямую. Он должен отправить запрос действия в промежуточный слой.
Например:
-
хочу прочитать клиента
-
хочу изменить запись
-
хочу выгрузить отчёт
-
хочу отправить письмо
-
хочу запустить бизнес-процесс
И только после проверки это действие либо выполняется, либо блокируется, либо отправляется человеку на подтверждение.
Три базовых решения
У такого слоя контроля должно быть как минимум три варианта ответа.
-
ALLOW
действие разрешено
-
BLOCK
действие запрещено
-
APPROVAL REQUIRED
нужно подтверждение человека
Это простая логика, но именно она меняет модель безопасности. Вместо подхода:
-
у агента есть доступ → действие выполнено
то есть появляется совершенно другой подход:
у агента есть доступ
↓
действие проверено
↓
риск оценён
↓
решение принято
↓
только потом действие выполнено
Для корпоративной среды это принципиальная разница.
Пример с массовой операцией
Представим, что AI-агент работает с CRM. Обычная задача:
-
обновить данные одного клиента
Это низкий риск. Система может разрешить действие автоматически.
Action: update_client
Records: 1
Decision: ALLOW
Но если агент внезапно пытается изменить 100 000 записей, контекст становится другим.
Action: update_client
Records: 100000
Decision: APPROVAL REQUIRED
Или даже:
Decision: BLOCK
Формально действие то же самое, но риск здесь совершенно другой. Именно поэтому важен не только тип действия, но и его объём, контекст и последствия.
Что должен анализировать AI Firewall
Хороший AI Firewall должен смотреть не на один параметр, а на весь контекст операции.
Например:
-
какой агент действует
-
кто поставил задачу
-
какой инструмент вызывается
-
какие данные затрагиваются
-
сколько записей обрабатывается
-
куда отправляется результат
-
есть ли персональные данные
-
есть ли массовая операция
-
были ли похожие действия раньше
-
похоже ли поведение на аномалию
Только после этого можно принимать осмысленное решение.
Архитектура в простом виде
Один из возможных вариантов архитектуры может выглядеть так:
Пользователь
↓
AI-агент
↓
Tool Gateway
↓
Policy Engine
↓
Risk Engine
↓
Decision Engine
↓
Корпоративная система
↓
Audit Log
Где:
Tool Gateway
принимает все запросы к инструментам
—————
Policy Engine
проверяет правила
—————
Risk Engine
оценивает риск операции
—————-
Decision Engine
принимает итоговое решение
—————-
Audit Log
записывает всю цепочку действий
Важно, что это не обязательно должен быть один продукт. Это может быть архитектурный слой, набор сервисов или часть корпоративной AI-платформы. Главное — сам принцип. AI не должен выполнять критичные действия напрямую.
Почему журналирование становится обязательным
Когда AI действует внутри компании, важно не только предотвратить ошибку. Важно ещё и понять, что произошло. Если агент всё-таки выполнил действие, компания должна иметь возможность ответить на вопросы: кто инициировал задачу? какой агент её выполнял? какой инструмент был вызван? какие данные были затронуты? какая политика сработала? почему действие было разрешено? кто подтвердил операцию? каков был результат?
Без такого журнала расследование инцидента превращается в гадание. С таким журналом AI-агент становится наблюдаемым и управляемым участником инфраструктуры. По сути, это “чёрный ящик” для AI-действий. :/
Безопасный режим
Ещё одна важная функция — возможность быстро ограничить агента. Например, если система замечает аномальное поведение, она может перевести агента в безопасный режим.
В безопасном режиме агент:
-
не сможет выполнять массовые операции
-
не может удалять данные
-
не может отправлять внешние письма
-
не может изменять финансовые записи
-
все рискованные действия отправляются на подтверждение
Это похоже на режим ограниченной функциональности. AI может продолжать помогать, но уже не способен нанести серьёзный ущерб без участия человека.
Почему это может стать отдельным классом ПО?
История IT часто развивается одинаково. Сначала появляется новая технология. Потом компании начинают использовать её в реальных процессах. Затем появляются инциденты. После этого возникает отдельный рынок защитных и управляющих решений. Так было с веб-приложениями. Так было с облаками. Так было с мобильными устройствами. Так было с контейнерами. С AI-агентами может произойти то же самое.
Сначала компании будут строить агентов. Потом начнут подключать их к данным и API. Затем столкнутся с вопросом:
-
как понять, что AI делает
-
как ограничить его действия
-
как расследовать ошибку
-
как доказать аудитору, что контроль был
-
как быстро остановить агента
И именно здесь может появиться новый слой корпоративной инфраструктуры.
Главное отличие от обычной безопасности
Классическая безопасность часто отвечает на вопрос:
-
кто имеет доступ?
AI Firewall должен отвечать на другой вопрос:
-
что агент собирается сделать прямо сейчас?
Это принципиальный сдвиг. Потому что доступ сам по себе уже не даёт полной картины риска.
Важны:
-
действие
-
контекст
-
объём
-
последствия
-
возможность отката
-
необходимость подтверждения
Именно поэтому контроль AI-агентов нельзя свести только к IAM, SIEM или DLP. Эти системы остаются важными, но рядом с ними может появиться ещё один слой.
Слой контроля действий AI.
Вывод
AI-агенты меняют привычную модель корпоративной безопасности. Раньше компаниям нужно было понимать, кто имеет доступ к системе. Теперь же всё чаще придётся понимать, что именно AI собирается сделать внутри этой системы. И если уж AI действительно становится новым цифровым сотрудником, то ему понадобится не только доступ, но и контроль. Возможно, через несколько лет понятия AI Firewall, AI Gateway или AI Control Layer станут такими же привычными, как сегодня firewall, IAM или SIEM. Пока это только формирующаяся область. Но логика её появления уже видна. Чем больше AI получает полномочий, тем важнее становится вопрос:кто контролирует действия AI до того, как они станут последствиями?
ссылка на оригинал статьи https://habr.com/ru/articles/1043160/