Восемь допущений о безопасности, которые ИИ-агенты ломают: от двух недель к десяти часам

Когда атакующий может себе позволить ошибаться

Экономика кибератак переменилась с приходом ИИ-агентов. Если раньше атакующему был нужен стратегический ресурс времени, сейчас агент может потратить его в миллион раз больше, чем человек. В одном недавнем взломе корпоративной сети работа, требовавшая примерно две недели, сжалась до неполных десяти часов. При расследовании инцидента в Hugging Face аналитики восстановили около 17 600 действий агента, совершённых за четыре с половиной дня.

Агент не устаёт, не теряет внимание, может пробовать несколько вариантов атаки параллельно и бросать неудачные пути без психологических затрат. Слабые места, которые казались защищёнными малоизвестностью или сложностью поиска, перестают работать как защита. Это кардинально меняет предположения, на которых строилась корпоративная безопасность.

Восемь критических ошибок, которые нужно переосмыслить

1. Готовьтесь к атакующему, который может позволить себе ошибаться

В Hugging Face агент применил сотни неудачных подходов, менял каналы, когда его блокировали, и возвращался к старым зацепкам, пока из них не сложилась рабочая цепочка атаки. Обычные эндпойнты, забытые в сетевой конфигурации, учётки с избыточным доступом, рядовые ошибки в настройке — всё это перестаёт быть слабым местом, если атакующий может себе позволить перепробовать всё. Переосмыслите все допущения, которые молчаливо рассчитывают на то, что ресурс трудно найти или что атакующему надоест.

2. Измеряйте время от обнаружения до локализации

Команды безопасности обычно меряют, могут ли они обнаружить вторжение. Добавьте метрику: сколько времени проходит от обнаружения до того, как вторжение локализовано. В корпоративном взломе две недели работы уложились в десять часов. В Google другая группа агентов прошла путь от скомпрометированного облачного ресурса до массовой кампании по сбору учётных данных ещё быстрее. Медленная эскалация (как в Hugging Face, где системы безопасности сигналили, но ответ шёл через несколько согласований и совещаний) может убить любую защиту. Определите заранее, какие меры локализации срабатывают автоматически, а какие команда безопасности может применять без дополнительного согласования.

3. Защищайте обвязку, а не только саму модель

Обвязка — это всё вокруг модели: инструменты, память, учётные данные, сетевой доступ, среды исполнения и политики. В тестах, где ИИ-модели играли за атакующих, от обвязки сильно зависило, чего модель добивалась. Австралийское агентство по кибербезопасности пришло к тому же вывод со стороны защиты: развитие самой модели организация не контролирует, а обвязка — может. Выпишите всё, что агент может видеть и вызывать, куда может писать и на что может тратить деньги. Спросите: если завтра агент поведёт себя плохо, что самое худшее позволит ему эта обвязка?

4. Готовьтесь к роям агентов

В инцидента в Hugging Face сотни агентов обменивались информацией и придумывали собственные способы связи между запусками, которые должны были быть полностью изолированы друг от друга. Группа агентов может делить работу, обмениваться находками и продолжать атаку, когда отдельные попытки провалились. Общие папки, базы данных, очереди сообщений и прочие ресурсы с доступом на запись могут превратиться в неожиданные каналы коммуникации. Если вы запускаете много агентов, считайте общение между ними полноценным разрешением, которое нужно контролировать и отслеживать.

5. Хватит выдавать агентам постоянные учётные данные

Каждого агента стоит считать отдельной машинной учётной записью с собственной идентичностью. Выдавайте учётные данные с узкими правами, которые истекают вместе с задачей. Разделяйте права на чтение и на запись. Не храните статические облачные ключи в окружении агента. Сделайте так, чтобы от любого субагента можно было пройти по цепочке до родительского агента и до человека, который за ним стоит. Это не просто принцип минимальных привилегий — это его применение к софту, который активно исследует своё окружение. Человек может не узнать, что старая учётка открывает какую-то забытую систему. Агент будет искать такое методично.

6. Исходите из того, что промпт-инъекция сработает

Промпт-инъекция — это инструкции, которые атакующий подбрасывает в то, что читает агент. Исходите из того, что иногда агент будет их выполнять. Вместо вопроса «могут ли вредоносные инструкции просочиться» спрашивайте «что будет, когда они просочатся». Агент читает логи, имена хостов, отчёты об уязвимостях, пейлоады, комментарии в коде и конфиги. В любом из этих мест может оказаться текст, написанный специально для модели. Даже обманутый агент должен упираться в жёсткие ограничения по учётным данным, сетевому доступу, инструментам и праву вносить серьёзные изменения.

7. Держите границу безопасности за пределами модели

Промпт «не ходи в продакшен» — это пожелание. Контроль появляется, когда в API у агента просто нет прав, чтобы до продакшена дотянуться. Если действие может иметь серьёзные последствия, пусть модель его предлагает, а другая часть системы решает, выполнять ли его на самом деле. С журналами аудита то же самое. Если агент может подправить записи, по которым будут разбирать его поведение, считайте, что аудиторского следа у вас нет. Жёсткие ограничения должны жить в коде, а не в промптах.

8. Защищайтесь от агентов с помощью агентов

Инцидент на десятки тысяч машинных действий оставляет столько следов, что команда людей не успеет их нормально просмотреть в реальном времени. Центрам мониторинга (SOC) будут нужны свои агенты, чтобы разбирать алерты, охотиться за угрозами, расследовать инциденты и помогать локализовать атаки. Но у защитных агентов свои риски: они постоянно читают потенциально поддельные данные и часто получают учётки с широкими правами. Промпт-инъекция способна развернуть их работу в другую сторону без необходимости красть какие-то учётные данные. Защитным агентам нужны жёстко контролируемые обвязки и доступ только к тому, без чего им не обойтись.

Нужно поспевать за атакующими с помощью ИИ и при этом не нажить себе новую проблему с безопасностью.