Безопасность ИИ-агентов на уровне API

​Введение: почему ИИ-агенты — это другой тип потребителя API

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

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

Один неправильно настроенный агент может сгенерировать тысячи запросов за считанные минуты, получить доступ к системам, к которым он никогда не должен был прикасаться, или объединить API в последовательность, которая выходит далеко за пределы первоначального замысла. При этом важно понимать: это, как правило, не «хакеры» в традиционном смысле. Это системы, которые делают ровно то, что им разрешено, — но со скоростью и в масштабе, характерными для машинного обучения.

Ключевая мысль этой статьи звучит так:

ИИ-агенты не нарушают ваши правила API; они выявляют те правила, которые вы никогда не применяли.

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

В этой статье разработчики компании DST Global разберут пять элементов управления, которые действительно имеют значение, и — что ещё важнее — как обеспечить их соблюдение на уровне API-шлюза, где им и место.

Где находятся эти элементы управления

Каждый из перечисленных ниже элементов управления обеспечивается в одном и том же месте: на API-шлюзе, расположенном между агентом и вашими бэкенд-сервисами.

Шлюз — это единственная точка контроля, где вы можете:

- видеть каждый вызов, совершаемый агентом;

- прикреплять к нему идентификатор и контекст;

- подсчитывать количество вызовов;

- анализировать закономерности во времени;

- записывать полную историю взаимодействий.

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

В примерах ниже используется терминология Apigee — API-продукты, квоты, предотвращение всплесков, политики. Но те же самые примитивы существуют в большинстве корпоративных шлюзов: Kong, AWS API Gateway, Azure API Management, Envoy и других. Конкретные названия могут отличаться, но принципы остаются универсальными.

1. Минимальные привилегии для агентов: ограничение области доступа

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

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

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

```

Allowed:

GET /orders/{id}

GET /customers/{id}

Denied by default:

POST /refunds

DELETE /accounts

PUT /admin/

```

Как это обеспечить

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

На практике это означает предоставление каждому агенту собственных учётных данных клиента, привязанных к API-продукту, который содержит только необходимые ему конечные точки. В терминах Apigee API-продукт является границей области действия: если `POST /refunds` отсутствует в продукте, к которому привязан ключ агента, шлюз отклоняет вызов на этапе проверки ключа или OAuth-токена — до того, как запрос достигнет бэкенда, независимо от намерений агента.

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

Область действия ограничивается двумя уровнями:

- Крупнозернистая область — ограничивает агента набором продуктов или путей к ресурсам.

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

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

Антипаттерн, которого следует избегать

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

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

2. Жёсткие ограничения на поведение: защита от всплесков и квоты

Обычно ограничение скорости запросов рассматривается как управление трафиком. В случае с агентами ИИ это становится механизмом безопасности. Угроза здесь не только во вредоносном трафике, но и в неконтролируемом поведении.

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

Два механизма — две разные проблемы

Команды часто ограничиваются одним лимитом скорости и останавливаются. Агентам нужны два разных механизма управления, которые решают две разные задачи.

Защита от всплесков сглаживает пики и защищает бэкенд от внезапной перегрузки. Например, ограничение количества запросов к агенту до 30 в секунду, чтобы плотный цикл повторных попыток не перегрузил нижестоящий сервис. Речь идёт о мгновенной скорости.

Квота ограничивает объём работы в течение определённого периода — например, N вызовов в день на одного оператора или жёсткий потолок для конкретной операции, такой как возврат средств, в час. Речь идёт о совокупном намерении, а не о мгновенной скорости.

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

Какие ограничения действительно важны

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

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

Безопасное завершение при срабатывании лимита

При срабатывании лимита возвращайте ошибку `429 Too Many Requests` с заголовком `Retry-After` и убедитесь, что агентская платформа рассматривает это как сигнал к остановке и снижению нагрузки, а не как причину для более интенсивной повторной попытки.

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

Компромисс

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

3. Не доверяйте «действительным токенам» как доказательству намерений

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

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

- Кто активировал агента?

- Какую задачу он должен был выполнить?

- Соответствует ли данный конкретный запрос поставленной задаче?

- Соответствует ли такое поведение тому, как обычно действует субъект?

Рассмотрим агента, который обычно получает небольшое количество записей, а затем внезапно начинает извлекать большие объёмы конфиденциальных данных из несвязанных доменов. В токене ничего не меняется. Каждый запрос считается «действительным». Однако поведение явно таковым не является.

Как обеспечить проверку намерений

Контекст задачи должен содержаться в самом токене, а затем запрос должен соответствовать ему на шлюзе.

Делегированный токен, действующий от имени другого лица — например, посредством обмена токенами по стандарту RFC 8693 — позволяет связать три вещи: пользователя, для которого действует агент; агента, выполняющего действие; и заявленную цель задачи.

```json

{

"sub": "user:4821",

"act": { "sub": "order-status-agent" },

"purpose": "order-status",

"scope": "orders:read customers:read"

}

```

Поле `sub` указывает, от имени какого пользователя действует агент. Поле `act` идентифицирует самого агента. Поле `purpose` фиксирует заявленную цель. Поле `scope` ограничивает область действия.

Затем на шлюзе следует применить политику, учитывающую контекст. Это может быть собственная условная логика или внешний механизм обработки политик, такой как OPA/Rego, который отклоняет запрос, если действие не соответствует заявленной цели, даже если токен действителен.

```rego

deny if request.action == "refund"

and token.purpose != "refund"

deny if request.path ~= "/admin/"

and token.purpose != "admin"

allow if request.scope covers request.path + request.method

```

Компромисс

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

4. Следите за поведением, а не только за запросами

Традиционная защита API основана на сигнатурах: недействительный токен, некорректный запрос, известный шаблон атаки. Трафик агента редко выглядит так.

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

Вам нужно наблюдать за поведением во времени. Полезно рассматривать поведение агентов в нескольких измерениях и устанавливать базовые значения для каждого из них для каждой идентичности агента.

Ключевые измерения поведения

- Скорость — частота запросов по сравнению с собственным нормальным показателем агента, а не с глобальным порогом.

- Последовательность — вызывает ли агент конечные точки в порядке, который он никогда ранее не использовал.

- Объём данных — сколько данных извлекает сессия относительно своего базового уровня.

- Новизна ресурса — внезапное обращение к ресурсам или областям, к которым агент никогда ранее не обращался.

- Согласованность делегирования — соответствует ли заявленная цель и задача, выполняемая от имени пользователя, характеру деятельности.

Неудача почти никогда не связана с одним неудачным запросом. Она заключается в закономерности:

```

Normal : 15–30 customer lookups per day

Abnormal : 5,000 lookups in one hour

```

Здесь нет ни одного «неправильного» запроса. Есть паттерн, который выходит за пределы нормы.

Где работает обнаружение

У вас есть три основных варианта, где задержка компенсируется эффективностью контроля.

- Автономная аналитика журналов шлюза — легко внедряется, но выявляет проблемы только постфактум.

- Потоковое обнаружение — уменьшает задержку до уровня, близкого к реальному времени.

- Встроенное обнаружение — находится непосредственно на пути запроса и может блокировать выполнение, увеличивая задержку каждого вызова.

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

Что делать при обнаружении нарушения

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

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

Компромиссы

Обнаружение поведения имеет реальные ограничения.

Холодный старт. У совершенно нового агента нет базового уровня, поэтому к его первым дням следует относиться с осторожностью.

Ложные срабатывания. Легитимное пакетное задание или новая функция могут выглядеть как аномалия. Необходимо быстро вносить ожидаемые изменения в белый список.

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

5. Обеспечьте сквозную прослеживаемость каждого действия

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

Как минимум, вам необходимо восстановить:

- какой агент совершил вызов;

- для какого пользователя он действовал;

- какой API он использовал;

- какое решение привело к вызову;

- к каким данным он обращался или какие изменял.

Как это реализовать

Распространите единый идентификатор корреляции по всей цепочке — агент, шлюз и бэкенд — используя контекст трассировки W3C, чтобы каждый узел использовал одну трассировку.

```

traceparent: 00-4bf92f3577b3we20e0e4736-00f062b7-01

```

Каждая запись аудита на шлюзе должна содержать полный контекст:

```json

{

"trace_id": "4bf9f3577a6a3ce929d0e0e4736",

"agent_id": "order-status-agent-prod",

"on_behalf_of": "user:4821",

"method_path": "GET /orders/9931",

"purpose": "order-status",

"decision": "allow",

"data_scope": "order:9931"

}

```

Две детали отличают реальную прослеживаемость от простого набора логов.

Во-первых, каждая запись должна содержать как идентификатор агента, так и идентификатор пользователя, от имени которого был совершён вызов. Лог, содержащий только данные об агенте, не может ответить на вопрос: «Чей это был запрос?»

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

Компромисс

Подробные трассировки означают наличие конфиденциальных данных и персональной информации в ваших журналах. Заранее спланируйте:

- Редактирование — маскирование конфиденциальных полей перед записью.

- Контроль доступа — кто может читать эти журналы.

- Ограничения на хранение — как долго хранятся данные.

- Объём данных — трафик от агентов генерирует значительно больше строк в журналах, чем трафик от людей.

Собираем всё воедино: сценарий с пятью элементами управления

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

Легитимный вызов

Клиент запрашивает информацию о заказе. Агент получает токен от имени другого лица (Элемент 3), назначение которого — отслеживание статуса заказа, а область действия — чтение заказов и клиентов.

Агент вызывает `GET /orders/9931`. Шлюз подтверждает:

1. Конечная точка находится в продукте агента (Элемент 1).

2. Вызов находится в пределах лимитов на всплески и квот (Элемент 2).

3. Действие соответствует заявленной цели (Элемент 3).

4. Поведение соответствует базовому уровню (Элемент 4).

5. Шлюз записывает запись аудита с идентификатором трассировки, агента и пользователя (Элемент 5).

Вызов завершается успешно.

Суть проблемы

Теперь тот же агент — из-за ошибки, некорректного вызова инструмента или манипуляций — пытается отправить `POST /refunds`, а затем начинает извлекать тысячи записей о клиентах.

- Элемент 1 блокирует возврат средств: конечная точка отсутствует в продукте агента, поэтому шлюз отклоняет запрос до того, как его увидит какой-либо бэкенд.

- Даже если бы она была доступна, Элемент 3 отклонил бы запрос, поскольку назначение токена — статус заказа, а не возврат средств.

- Процесс извлечения записей остаётся синтаксически корректным, поэтому Элемент 2 срабатывает первым и возвращает ошибки `429`.

- Базовый уровень Элемента 4 отмечает аномалию, связанную с объёмом и новизной, и помещает учётные данные в карантин.

- На протяжении всего процесса Элемент 5 оставляет полный, взаимосвязанный след, поэтому на вопрос, возникший после инцидента, даётся ответ в течение нескольких минут, а не на основе догадок.

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

Заключение

Большая часть рисков, связанных с агентами ИИ, исходит не от экзотических атак. Она исходит от хорошо известных уязвимостей:

- чрезмерно разблокированные учётные записи служб;

- отсутствующие или слабые ограничения скорости запросов;

- слепое доверие к токенам;

- отсутствие мониторинга поведения;

- плохая наблюдаемость.

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

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

Основные принципы не изменились. Изменились масштаб и скорость.

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

Источник: https://dstglobal.ru/club/1253-bezopasnost-ii-agentov-na-urovne-api