4 августа Varonis представила Agent Intent-Based Access Control, или Agent IBAC, для платформы Atlas. Новая функция сравнивает исходную задачу ИИ-агента с его шагами, вызовами инструментов и доступом к данным, а при отклонении может остановить действие еще до выполнения.
Для компаний, которые уже подключают агентов к CRM, внутренним хранилищам и рабочим сервисам, это не декоративное ограничение. Широкие права делают ИИ полезным, но тем же ходом превращают его в удобный источник утечки или лишних действий.
Контроль работает прямо в потоке запросов
Материал о запуске вышел на BleepingComputer как спонсорский материал Varonis, поэтому технические детали пока стоит воспринимать как заявление самой компании. По описанию Varonis, Atlas стоит между агентом и моделью: через него проходят запросы, ответы и вызовы инструментов.
За счет этого система не только отправляет предупреждение, но и блокирует действие до исполнения. Если риск высокий, Atlas может отправить в карантин сессию или связанную с ней учетную запись на срок, который задает клиент. По словам Varonis, функция уже доступна пользователям Atlas.
RBAC проверяет права, Agent IBAC — цель действия
Логика продукта строится на старой проблеме корпоративной безопасности. Классический RBAC отвечает на вопрос, есть ли у учетной записи право открыть таблицу, вызвать API или запустить инструмент. Agent IBAC пытается проверить другое: соответствует ли этот шаг задаче, с которой пользователь вообще начал работу.
«Вопрос уже не в том, может ли пользователь получить доступ к данным, а в том, должен ли агент в этом контексте выполнять действие над ними», — сказал в материале вице-президент Varonis по стратегии ИИ и данных Рон Беннатан.
Varonis приводит и бытовые примеры. Если пользователь просит узнать погоду, а агент внезапно вызывает инструмент миграции, система может заблокировать такой вызов. Если агент вместо разового ответа ставит ежедневное напоминание, отклонение можно просто записать в журнал.
Проверка охватывает всю сессию
Varonis утверждает, что Agent IBAC смотрит не на одно действие, а на всю сессию целиком: запросы, ответы модели, выбор инструментов и параметры вызовов. Для чувствительности доступны три режима — мягкий, сбалансированный и строгий. Команды также могут задавать собственные правила для сессии обычным языком и указывать, после какого числа событий запускать повторную проверку.
Это важно для многошаговых обходов защит. Отдельный запрос может выглядеть безобидно, но цепочка из нескольких действий уже ведет к лишнему доступу к данным или к попытке выйти за рамки исходной задачи. В Atlas поэтому сохраняется и полный журнал действий: что агент сделал, какое правило сработало и как именно система отреагировала.
В числе ответных мер Varonis перечисляет предупреждение, блокировку, изменение ответа, запись в журнал и передачу спорного действия человеку на подтверждение. Карантин идет еще дальше и перекрывает все следующие запросы на заданное время.
Значение для рынка
Для российского рынка сигнал простой: если компания подключает ИИ-агентов к GitLab, CRM, BI, хранилищам документов или службе поддержки, одной настройки прав уже мало. Придется проектировать и допустимую траекторию действий: что агент может читать, что может менять, а что обязан передавать человеку. Иначе сервисная учетная запись с «чуть более широким доступом, чтобы все работало» быстро станет проблемой для ИБ, внутренних аудитов и соблюдения требований регуляторов.
Оригинал: .
Следующий вопрос для рынка уже не в том, нужны ли такие проверки, а в том, удастся ли им работать без потока ложных срабатываний.