Vela: защищает не агент, а дизайн интерфейса — как сервис, открытый для AI-агентов, сохраняет уязвимости

Это исследование-находка, а не техника. Схема — как авторы разделили влияние интерфейса и агента:

C0: атака через родной веб-интерфейс → эталонный результат (кейс вообще эксплуатируем?)
C1: та же атака скриптом через интерфейс агента (без LLM) → что остаётся после ограничений интерфейса
C2: та же атака через коммерческого агента → что добавляет или убирает агент

C0 vs C1 = эффект интерфейса
C1 vs C2 = эффект агента
Итог проверяет независимая проверка состояния бэкенда, а не ответ агента

Применить вывод промптом в чате нельзя. Но чат подходит для ревью вашего агентного интерфейса перед запуском. Ревью опирается на логику авторов: проверять, какие операции и аргументы доступны, а не уговаривать агента «быть осторожным». Шаблон ниже — наша производная от статьи, готовых промптов у авторов нет.

Задача: Команда запускает Telegram-ассистента для интернет-магазина вроде Ozon или Wildberries. Пользователь пишет «верни кроссовки, которые я заказывал на прошлой неделе». Агент ходит в бэкенд через MCP-инструменты. Перед запуском продакт хочет понять, что сможет сделать злонамеренный пользователь, даже если системный промпт запрещает всё плохое.

Промпт:

Ты — ревьюер безопасности агентных интерфейсов. Ты не полагаешься на то, что 
агент откажется от вредной просьбы. Ты исходишь из того, что агент выполнит 
любой формально корректный вызов.



Инструменты MCP для ассистента интернет-магазина:
- get_my_orders(status) — список заказов текущего пользователя
- get_order(order_id) — детали заказа
- create_return(order_id, reason, comment) — оформить возврат
- update_address(order_id, address) — сменить адрес доставки
- apply_promo(order_id, code) — применить промокод
- upload_photo(order_id, file_url) — загрузить фото дефекта по ссылке
Идентификатор пользователя подставляется сервером из сессии.



Для каждого инструмента:
1. Какие аргументы агент контролирует свободно (атакующий может подать любое значение)?
2. Класс риска:
   - ТОЧНЫЙ ВВОД: нужен точный контроль над значением (инъекции в comment, address, code)
   - ЛОГИКА ПРИЛОЖЕНИЯ: формально валидный запрос нарушает права или сценарий 
     (чужой order_id, возврат уже возвращённого, обход статусов)
   - РЕСУРСЫ: работа с файлами и внешними ссылками (file_url — загрузка, чтение, обращение к внутренним адресам)
3. Что агент может достроить сам, если атакующий не указал (поиск чужого заказа, промежуточные вызовы)?
4. Что можно сузить на уровне интерфейса: убрать аргумент, заменить свободный текст 
   на перечисление, жёстко привязать объект к пользователю.
5. Какой законный сценарий пострадает от каждого сужения.



Таблица: инструмент | класс риска | свободные аргументы | что сужаем | цена для законного сценария.
В конце — 3 самых опасных места и что проверять на стороне бэкенда 
(а не в системном промпте агента).

Результат: Модель выдаст таблицу по каждому инструменту. Скорее всего, она отметит update_address и get_order как риск логики приложения (чужой order_id), upload_photo как риск ресурсов (file_url), а свободные поля вроде comment как риск точного ввода. Для каждого будет предложено сужение и цена для законных сценариев. В конце — список топ-3 мест и проверки, которые нужно делать на бэкенде.

Слабость. Агент — это LLM, которая переводит просьбу в вызов инструмента. Он не знает, чьи права нарушает вызов, если запрос выглядит нормально. Безопасность, встроенная в обучение модели, ловит очевидно вредные инструкции. Атаки через обычные бизнес-операции под эту категорию не попадают.

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

Как использовать. Хорошо работают две вещи: ограничивать интерфейс и проверять права на бэкенде. Вшивать защиту в промпт агента неэффективно. Рычаги: - Уровень абстракции операций. Узкие операции по сценарию вместо «сырых» эндпоинтов с оригинальными параметрами — меньше свободы атакующему. - Свободные аргументы. Любое поле со свободным текстом заменяй на перечисление или проверяемый формат, если сценарий это допускает. - Привязка идентичности. Пользователя подставляет сервер из сессии, а не агент из диалога. - Что проверять. Итог проверяй по состоянию бэкенда, а не по ответу агента: гладкий ответ не доказывает, что действие безопасно.

В статье нет готового промпта: она измеряет, а не предлагает инструкцию. Ниже — шаблон ревью по классификации авторов. Структуру (теги и три класса риска) сохраняем, чтобы модель двигалась по тому же логическому пути.

Ты — ревьюер безопасности агентных интерфейсов. Ты не полагаешься на то, что 
агент откажется от вредной просьбы. Ты исходишь из того, что агент выполнит 
любой формально корректный вызов.



{список инструментов или эндпоинтов с аргументами}
Кто подставляет идентичность пользователя: {сервер / агент}



Для каждого инструмента:
1. Какие аргументы контролируются свободно?
2. Класс риска:
   - ТОЧНЫЙ ВВОД: нужен точный контроль над значением
   - ЛОГИКА ПРИЛОЖЕНИЯ: формально валидный запрос нарушает права или сценарий
   - РЕСУРСЫ: работа с файлами, импортом, внешними ссылками
3. Какие шаги агент может достроить сам за атакующего?
4. Что сузить на уровне интерфейса?
5. Какой законный сценарий пострадает от сужения?



Таблица: инструмент | класс риска | свободные аргументы | что сужаем | цена для законного сценария.
В конце — 3 самых опасных места и что проверять на бэкенде.

Подставляй: {список инструментов...} — названия, аргументы и краткие описания из твоей MCP/OpenAPI-схемы. {кто подставляет идентичность} — откуда берётся ID пользователя.

🚀 Быстрый старт — вставь в чат:

Вот шаблон ревью агентного интерфейса. Адаптируй под мою задачу: [опиши свой сервис и что агент может делать]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

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

⚠️ Не про промпты агента: статья не проверяла, можно ли защитить сервис системным промптом агента. Авторы намеренно оставили вендорный промпт без дополнительных инструкций по безопасности. Вывод «промпт не спасёт» — это не измеренный результат, а то, чего авторы не пробовали. Он следует только из того, что встроенных отказов агента не хватило.

⚠️ Только прямая атака пользователя: косвенные инъекции через чужие данные, взлом чужого агента и самостоятельный поиск неизвестных уязвимостей авторы исключили.

⚠️ Не случайная выборка: 44 уязвимости — подобранный набор известных (CVE и учебные приложения). Проценты описывают этот набор, а не весь веб.

⚠️ Жёсткий интерфейс режет и нужное: самые ограничивающие дизайны снижают эксплуатируемость, но и законные сценарии становятся недоступны. Универсального «безопасного и удобного» варианта статья не показывает.

⚠️ Нужен доступ к бэкенду: применить вывод может тот, кто влияет на дизайн интерфейса сервиса (схемы инструментов, права на сервере). Обычному пользователю чата это мало что даёт.

⚠️ Неполный текст: во входных данных нет части результатов (детали RQ2 и RQ3, цифры по конкретным дизайнам и агентам). Разбор опирается на аннотацию и введение.

Идея была простой: взять сервис с уязвимостью и проверить, что случится, если до него теперь добираться через агента. Авторы собрали Vela: 44 задокументированные уязвимости в 12 семействах веб-приложений (WordPress, PrestaShop, OWASP Juice Shop, crAPI и других). Каждую сначала воспроизвели «напрямую» и записали эталонный результат.

Интерфейсы для агента строили вслепую: дизайнеры не знали ни об уязвимостях, ни о нагрузках. Так ни один дизайн не мог быть «подогнан» под известный баг. Опирались на 50 обычных рабочих сценариев (заказ, возврат, регистрация и т.п.). Сделали три варианта: «эндпоинты как есть» (в духе OpenAPI), «один инструмент на сценарий» (в духе MCP) и «запрос на естественном языке» (в духе NLWeb).

Три условия сравнивали на одном бэкенде и с одинаковым стартовым состоянием. C0 — атака напрямую. C1 — скрипт через интерфейс. C2 — коммерческий агент (Claude Code, Codex, Grok Build) через тот же интерфейс. Разница C0–C1 показывает эффект интерфейса, разница C1–C2 показывает, что добавляет агент.

Результат проверял независимый «оракул», а не ответ агента: он смотрел на состояние бэкенда или на канал, видимый атакующему. «Гладкий ответ агента — не доказательство». Два разметчика согласились по итогам для 40 сохранившихся случаев с оценкой κ = 0,89.

Что удивило: агент не потерял ни одной из атак, которые пропускал интерфейс. Решающим оказалось не поведение модели, а то, какие операции и аргументы ей вообще доступны. Для практики это значит: проектируйте интерфейс и защиту бэкенда, а не рассчитывайте, что умная модель «заметит подвох».

🔧 Техника: проверять итог по состоянию системы, а не по ответу агента → надёжная приёмка работы

Вывод авторов («гладкий ответ — не доказательство») переносится на любые агентные автоматизации. Добавь в инструкцию агенту или в чеклист приёмки:

Copy

Не считай задачу выполненной на основании своего ответа. 
После действия проверь результат независимым способом: прочитай итоговое 
состояние (запись в системе, файл, статус) и приложи подтверждение.

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

• Работа: The Agent in the Middle: How AI-Mediated Access Reshapes Web Vulnerability Exploitation (WWW '27)
• Авторы: Ruozhao Yang, Jiongchi Yu, Ming Hu, Xiaofei Xie. Singapore Management University, Nanyang Technological University, East China Normal University
• Бенчмарк и источники кейсов: Vela, WebExploitBench, CVE-Bench, OWASP Juice Shop, OWASP crAPI
• Стандарты интерфейсов: MCP, OpenAPI, NLWeb
• Контекст: Agentic Commerce Protocol (OpenAI), Universal Commerce Protocol (Google)