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

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

5 мин

467

Аналитика

Перевод

Если вы читаете Ethics.Dev, то наверняка заметили, сколько в последнее время историй, где ИИ-агенты сталкиваются с кибербезопасностью. Некоторые звучат как сценарий фильма: агенты выбираются из тестовых окружений, переговариваются по каналам, которые для этого никто не предназначал, находят уязвимости, крадут учётные данные и добираются до продакшена.

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

Из-за этого меняется само представление о том, какая защита «достаточно хороша», и поэтому меня так беспокоит, что фронтирные модели сделают с кибербезопасностью. Ниже выводы, которые я бы положил на стол корпоративным командам, отвечающим за ИИ и безопасность.

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

Слабые места, которые эксплуатировали в недавних инцидентах, по большей части самые обыденные: учётки с избыточным доступом, внутренние системы, которые без нужды торчат наружу, рядовые ошибки конфигурации.

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

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

2. Измеряйте, сколько на самом деле занимает сдерживание

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

На свежих примерах видно, о каких сроках речь. В уже упомянутом корпоративном взломе две недели работы уложились меньше чем в десять часов. А в Google видели, как другая группа прошла путь от скомпрометированного облачного ресурса до массовой кампании по сбору учётных данных меньше чем за шесть часов.

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

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

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

Недавно я доказывал, что модель и её обвязку нужно оценивать как одну систему. Данные из кибербезопасности добавляют этому аргументу веса.

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

Попробуйте простое упражнение. Забудьте на минуту, какая там модель, и выпишите всё, что агент может видеть и вызывать, куда может писать и на что может тратить деньги. А потом спросите себя: если завтра агент поведёт себя плохо, что самое худшее позволит ему эта обвязка?

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

Один из самых странных уроков инцидента в Hugging Face: агенты могут найти способ действовать сообща, даже если никто этого не закладывал. Там сотни агентов обменивались информацией и придумывали собственные способы связи между запусками, которые вообще-то должны были быть изолированы друг от друга.

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

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

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

Я уже писал, что агентов стоит считать отдельными машинными учётными записями. Сейчас стало понятнее, как это делать на практике.

У каждого агента должна быть своя идентичность, отдельная от учётных данных пользователя. Выдавайте учётные данные с узкими правами, которые истекают вместе с задачей. Разделяйте права на чтение и на запись. Не держите статические облачные ключи в окружении агента. И сделайте так, чтобы от любого субагента можно было пройти по цепочке до родительского агента и до человека, который за ним стоит.

Это всё тот же принцип минимальных привилегий, только применённый к софту, который умеет активно исследовать своё окружение.

И разница тут существенная. Человек может так и не узнать, что старая учётка открывает какую-нибудь забытую систему. А агент будет искать такое методично.

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

Промпт-инъекция — это инструкции, которые атакующий подбрасывает в то, что читает агент. Я бы исходил из того, что иногда агент будет их выполнять.

Тогда меняется сам вопрос. Вместо «могут ли вредоносные инструкции просочиться» спрашивайте «что будет, когда они просочатся».

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

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

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

Промпт «не ходи в продакшен» всего лишь пожелание. Контроль появляется, когда в API у агента просто нет прав, чтобы до продакшена дотянуться.

Если у действия могут быть серьёзные последствия, пусть модель его предлагает, а решает, выполнять ли его на самом деле, другая часть системы. С журналами аудита то же самое. Если агент может подправить записи, по которым потом будут разбирать его поведение, считайте, что аудиторского следа у вас нет.

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

Симметрия получается неуютная. Атакующие берут ИИ, потому что он даёт скорость и масштаб. Защитникам, похоже, придётся делать то же самое.

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

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

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