В секторе искусственного интеллекта ведутся широкие дискуссии о механизмах управления передовыми моделями и их оценке перед развертыванием. Однако эти крупные дискуссии часто игнорируют фактический программный код, который определяет, разрешено ли ИИ-агенту выполнять конфиденциальные действия, такие как отправка электронных писем, изменение ключей шифрования, слияние веток программного обеспечения или перевод денежных средств. Эти решения принимаются не крупными лабораториями и не нормативными текстами, а простыми программными функциями, возвращающими значение «истина» или «ложь».
Стресс-тесты, проведенные на протоколе с открытым исходным кодом для проверки действий агентов под названием «PIC», показали, что проблемы возникают не обязательно из-за сбоев шифрования, а из-за принятия протоколом множественных, внешне корректных форматов, которые допускают различные интерпретации. Например, структурная схема может принимать хэш-коды с заглавными или строчными буквами, в то время как интерпретатор обрабатывает их способами, приводящими к разным результатам в разных системах, не нарушая при этом заявленные стандартные спецификации.
Ограничения схем JSON при проверке достоверности данных
Схемы JSON играют важную, но ограниченную роль в проверке структуры данных; они гарантируют наличие обязательных полей, правильность их типов значений и соответствие общим правилам. Однако схема не способна навязывать сложные ассоциативные правила, такие как гарантия того, что конкретная ссылка на доказательства указывает на единственный элемент внутри массива источников без дублирования или двусмысленности.
Различия в реализации операций поиска или сопоставления идентификаторов между разными языками программирования приводят к так называемому «несоответствию парсеров» (parser differential) — старому типу уязвимостей, ранее встречавшемуся в таких протоколах, как HTTP и JWT, где два компонента считывают одни и те же входные данные двумя разными способами. В современных протоколах агентов эти нюансы приводят к тому, что действия принимаются в одном сервисе, но отклоняются другим, использующим ту же политику и спецификации.
Влияние нормализации на безопасность протокола
Разработчики обычно стремятся нормализовать входные данные, чтобы избежать отклонения восстановимых данных, например, удаляя лишние пробелы, преобразуя символы в нижний регистр или исправляя дополнения Base64. Однако эти практики представляют реальную опасность на границах аутентификации. Например, если интерпретатор нормализует имя инструмента или удаляет пробелы перед сопоставлением со списком разрешенных, система может выполнить действие, не одобренное подписавшей стороной, или манипулировать правами выполнения без ведома разработчиков.
Кроме того, опора на поля, отправляемые самим агентом для подтверждения надежности своего источника, открывает путь к проблеме «запутанного заместителя» (confused deputy) в цифровом формате. Доверие должно основываться исключительно на границах обеспечения соблюдения правил и проверки, путем проверки цифровых подписей и их сопоставления с криптографическими ключами, которым оператор доверяет напрямую, независимо от утверждений, содержащихся в полезной нагрузке запроса.
Трехуровневая архитектура и векторы исполнительного соответствия
Чтобы избежать этих уязвимостей, требуется архитектура, четко разделяющая три последовательных уровня:
- Проверка схемы: для отклонения поврежденных структур и представлений, не соответствующих сети.
- Семантическая проверка: для разрешения ссылок, проверки связей и вывода фактического доверия.
- Оценка политик: для принятия окончательного решения о разрешении или блокировке выполнения действия.
Недостаточно ограничиваться документальными примечаниями; необходимы четкие инструменты тестирования исполнительного соответствия, включающие точные входные данные, ожидаемые результаты и стабильные коды ошибок для обработки неоднозначных случаев. Эти векторы обеспечивают единообразие поведения во всех реализациях и предотвращают зависимость безопасности от различных конфигураций по умолчанию в разных программных мостах.