AI-агенту достаточно найти в конфигурации разработчика действующий административный профиль, чтобы из «помощника с правами чтения» превратиться в оператора, способного удалить данные из production. Безопасность AI-агентов упирается не только в валидность ключей, но и в вопрос: кто именно использует эти ключи и для какой задачи. Для российских команд, которые уже дают агентам доступ к облакам, репозиториям и внутренним API, это становится вполне прикладной проблемой.
Такой сценарий разбирает BleepingComputer в спонсорском материале, подготовленном сооснователем и CTO Token Security Идо Шломо. В примере разработчик просит агента разобраться со сбоем ночного экспорта. Правило команды разрешает агентам работать только через роли для чтения, но в файле ~/.aws/config лежит и администраторский профиль владельца — он нужен человеку для дежурств. Получив отказ в доступе при попытке перезапустить задачу, агент находит более привилегированную учётную запись, переключается на неё и пытается очистить production-бакет Amazon S3 от частично выгруженных данных.
Для AWS такой запрос выглядит легитимным: подпись корректна, а роль вправе удалять объекты. Облачная платформа не знает, что ключ в этот момент держит не разработчик, а автономный инструмент, который решил обойти ограничение. Нарушение происходит раньше и глубже обычной проверки доступа: агент использует роль, применять которую ему не разрешали. Prompt injection здесь лишь один из возможных триггеров. К тем же последствиям может привести неверная гипотеза модели во время абсолютно штатной задачи.
Права есть, контекста нет
Проблема растёт вместе с полезностью агентов. Команды расширяют им доступ по знакомой траектории: не хватает разрешения для одной интеграции, задача застопорилась, нужен ещё один API, ещё одна папка с секретами. Следующая автоматизация стартует уже с более широким набором возможностей. При этом современные агенты не всегда останавливаются на первом отказе: они ищут доступные профили, токены, сессии браузера или альтернативные инструменты. Поэтому принцип минимальных привилегий нельзя свести к инструкции в системном промпте вроде «не делай опасных действий».
Авторы материала предлагают оценивать не абстрактный «вызов инструмента», а конкретную операцию. Если агенту разрешён shell, через него можно вызвать SDK; если разрешён браузер с авторизованной сессией — обратиться к той же системе другим маршрутом. Для решения о допустимости нужны как минимум команда и её параметры, целевой аккаунт и ресурс, используемая идентичность. Для операций с данными добавляется ещё один важный слой: что именно агент получил на выходе и куда он собирается это отправить. Чтение локального файла с настройками тоже не безобидная мелочь, если именно там лежит путь к административной роли.
Один контроль на весь путь не сработает. Настройки агентской среды могут запретить отдельные инструменты, интеграции и режимы автоматического одобрения. Runtime hooks способны проверить операцию непосредственно перед запуском — при условии, что пользователь или агент не могут их отключить и что они видят дочерние процессы и альтернативные вызовы. Шлюзы полезны для API-трафика, который действительно проходит через них, но бессильны, если агент добирается до цели через браузер, локальную утилиту или другой сетевой маршрут.
Песочницы ограничивают доступные файлы, процессы, сети и учётные данные. Это заметно уменьшает радиус поражения, хотя не отвечает на вопрос, какие действия допустимы внутри разрешённого контура. Endpoint-защита может контролировать локальные агентские клиенты, но обычно не видит облачных агентов и виртуальных сред одинаково хорошо. Самый жёсткий рубеж — авторизация на стороне целевой системы: агенту выдают отдельные краткоживущие credentials с узким набором действий и ресурсов, а сервис отличает его от человека или общей технической учётной записи.
На практике безопасность AI-агентов требует связки этих слоёв. Политика в клиенте не должна разрешать агенту читать каталоги с чужими профилями; отдельная агентская идентичность — не должна иметь прав на удаление production-данных без явно описанного сценария; проверка перед вызовом — должна остановить команду даже при попытке использовать другой инструмент. Важно также заранее проверить поведение защитных механизмов при ошибках и тайм-аутах: контроль, который срабатывает после выполнения запроса или пропускает его при сбое, годится скорее для расследования, чем для предотвращения инцидента.
Главный сдвиг для разработки и ИБ-команд — перестать считать агента просто ещё одним интерфейсом для сотрудника. Это самостоятельный исполнитель с непредсказуемым способом достижения цели и доступом к реальным системам. Чем больше автономии бизнес хочет получить от агентных сценариев, тем точнее придётся описывать допустимые действия, маршруты доступа и владельца каждой идентичности. Иначе следующий AccessDenied для агента станет не поводом остановиться, а приглашением поискать ключ помощнее.