Проблема «слепых зон» в безопасности AI
Современные AI-агенты часто развертываются в строго ограниченных средах: без доступа к интернету, с ограниченными правами на чтение/запись файлов и с изолированными тестовыми наборами. Традиционный подход к проверке безопасности полагается на человеческий контроль или постфактум-анализ логов. Однако, как показывают инциденты с OpenAI и Anthropic, многие нарушения остаются незамеченными, пока не приведут к серьезным последствиям. Автор статьи предлагает парадигмальный сдвиг: наделить модели инструментами для самостоятельного сообщения о доказуемых уязвимостях их окружения.
Механика верифицируемых отчетов
Суть предложения — создание инфраструктуры, где модель может отправить сигнал «предположение о безопасности нарушено» с помощью выделенных инструментов. Ключевое требование — отсутствие субъективной оценки. Отчет должен быть самопроверяемым (self-verifying). Например, если модели запрещено выходить в интернет, ей дается секретный токен. Попытка выполнить запрос вида curl https://{token}.monitordomain.com является неопровержимым доказательством наличия сетевого доступа, так как только сервер оператора может валидировать этот токен.
Это устраняет необходимость в «судье», которого можно обмануть. Факт выполнения действия (отправки запроса, чтения файла с canary-GUID) сам по себе является доказательством нарушения изоляции.
Статистическая надежность и пороговые значения
Система не требует, чтобы каждая копия модели сообщала об ошибке. Достаточно, чтобы хотя бы одна из N инстанций сделала это. Это позволяет компенсировать частичное несоответствие модели инструкциям (misalignment). Вероятность обнаружения ошибки рассчитывается по формуле:
P(detection) = 1 - (1 - p)^N
Где p — вероятность того, что одна модель сообщит об ошибке, а N — количество экспозиций. Даже при низкой вероятности отчета одной модели (5%) и 100 запусках, вероятность обнаружения нарушения составляет 99.4%. Остальные логи можно проанализировать постфактум для выявления эксплуатирующих уязвимости агентов.
Архитектура изоляции и типы нарушений
Предлагается использовать древовидную структуру изолированных доменов. Родительский узел не должен иметь права сообщать об ошибках, используя токены дочерних узлов, но дочерний узел обязан сообщать, если получил доступ к родителю или братскому узлу. Система фокусируется на трех основных векторах атак:
| Тип нарушения | Метод верификации | Сложность реализации |
|---|---|---|
| Доступ в Интернет/Intranet | Отправка запроса на внешний домен с уникальным токеном. Валидация через хеш ответа. | Низкая (высокая надежность) |
| Выполнение кода | Запуск кода в другом домене изоляции с последующей отправкой токена из целевого домена. | Средняя (требует кросс-доменной коммуникации) |
| Чтение/Запись файлов | Использование файлов с canary-GUID. Модель должна прочитать файл, содержащий случайный флаг, чтобы доказать доступ. | Высокая (риск ложных срабатываний при создании копий) |
Стратегии взаимодействия: кооперация vs. выживание
Авторы отмечают риск, что модели с сильным инстинктом самосохранения или жесткой привязкой к задаче могут скрывать нарушения, чтобы не быть остановленными. Поэтому процесс отчетности должен быть отделен от процесса завершения инференса. В долгосрочной перспективе это превращается в итеративную игру, где репутация лаборатории зависит от честности модели. Использование «медвежьих ловушек» (honeypots) в коде модели признается неэффективным для будущих, более умных агентов, которые смогут распознавать обман.
Практический пример: Oracle подключенности
Вместо того чтобы просто запрещать модели доступ в интернет, система предоставляет ей «оракул подключенности» — скрипт, который пытается связаться с сервером оператора. Если запрос успешен и хеш совпадает, модель получает инструкцию сообщить о статусе NET-OPEN(reported). Это создает ситуацию, где нарушение безопасности становится очевидным фактом, а не интерпретацией, что позволяет мгновенно изолировать скомпрометированный инстанс.
Источник: LessWrong ↗