Суть эксперимента: модель «чиста», но система уязвима
Автор исследования провел лабораторный тест на стеке n8n + DeepSeek + HubSpot. Ключевой параметр: модель DeepSeek была лишена учетных данных HubSpot и технически не могла выполнить запись напрямую. Однако в архитектуре остался узел n8n, обладающий правами на запись. Это создало классическую уязвимость типа confused deputy (запутанный заместитель), где полномочия модели не совпадают с полномочиями всей execution chain.
Кейс: изменение не той сделки
В тесте использовались две синтетические сделки: LAB-042 и LAB-043. Сценарий моделировал не «злую» модель, а ошибку согласования целей (wrong-object case):
- Запрос пользователя: изменить сделку LAB-042.
- Структурированное предложение от LLM: изменить сделку LAB-043 (из-за рассинхрона контекста или ошибки парсинга).
В первой конфигурации n8n получил предложение, проигнорировал несоответствие исходному запросу и выполнил PATCH для LAB-043. CRM была изменена, хотя модель не имела прав на запись. Это доказывает, что декларация «агент работает в read-only» на уровне LLM не защищает систему от побочных эффектов оркестратора.
Решение: детерминированный шлюз (Gateway)
Во второй итерации между предложением модели и вызовом API HubSpot был внедрен независимый контрольный узел. Он проверял параметры перед выполнением действия:
- Целевая система;
- Идентификатор объекта;
- Ожидаемое исходное состояние;
- Разрешенный переход.
Результат: при совпадении параметров (LAB-042) запись прошла успешно. При несовпадении (LAB-043) шлюз вернул deny, и PATCH не был выполнен. CRM осталась неизменной.
Чек-лист для CTO перед запуском AI-агентов
Исследование выделяет шесть критических вопросов для оценки безопасности production-решений:
| Вопрос | Почему это важно |
|---|---|
| Где физически находятся учетные данные? | Права у оркестратора (n8n) опаснее, чем у модели, если нет проверок. |
| Какой компонент выполняет внешний вызов? | Нужно точно знать, кто вызывает API, а не только кто генерирует текст. |
| Что проверяется перед исполнением? | Параметры должны валидироваться детерминированно, а не доверяться LLM. |
| Может ли target измениться между запросом и записью? | Выявляет риск рассинхрона между намерением пользователя и действием агента. |
| Есть ли независимая граница? | Отдельный шлюз блокирует исполнение при несовпадении параметров. |
| Как подтверждается итоговое состояние? | Необходима верификация результата после действия (post-action audit). |
Вывод для индустрии
Удаление credentials из модели — это лишь первый шаг. Для реального контроля необходимо обеспечивать runtime controllability: подтверждение того, что фактические полномочия системы соответствуют заявленным ограничениям на границе исполнения. Архитектура должна быть построена так, чтобы оркестратор не мог выполнить действие, противоречащее исходному контексту запроса, даже если LLM сгенерировала ошибочный параметр.
Источник: Habr ↗