Введение: почему ИИ-агенты — это другой тип потребителя API
Если вы раньше не сталкивались с этой проблемой, начнём с простого определения. ИИ-агент — это программная система, которая не просто выполняет заранее заданную последовательность вызовов API.
Получив цель, агент сам решает, какие API ему вызвать, в каком порядке, как интерпретировать ответы и когда остановиться. Он может вызывать десятки конечных точек, повторять неудачные запросы, перебирать альтернативы и комбинировать API в цепочки, которые ни один разработчик не спроектировал бы вручную.
Большинство традиционных средств защиты API создавались для предсказуемых потребителей: мобильных приложений, бэкенд-сервисов, партнёрских интеграций и отдельных скриптов. Каждый из них обращается к вашим API достаточно ограниченным и понятным образом. ИИ-агент в эту модель не вписывается.
Один неправильно настроенный агент может сгенерировать тысячи запросов за считанные минуты, получить доступ к системам, к которым он никогда не должен был прикасаться, или объединить API в последовательность, которая выходит далеко за пределы первоначального замысла. При этом важно понимать: это, как правило, не «хакеры» в традиционном смысле. Это системы, которые делают ровно то, что им разрешено, — но со скоростью и в масштабе, характерными для машинного обучения.
Ключевая мысль этой статьи звучит так:
ИИ-агенты не нарушают ваши правила API; они выявляют те правила, которые вы никогда не применяли.
Хорошая новость в том, что для решения этой проблемы не нужен полностью новый стек безопасности. Большая часть защиты по-прежнему сводится к правильному применению базовых принципов. Плохая новость в том, что большинство организаций никогда не применяли эти принципы по-настоящему — с учётом автономного потребителя, который действует с высокой скоростью и большим объёмом запросов.
В этой статье разработчики компании DST Global разберут пять элементов управления, которые действительно имеют значение, и — что ещё важнее — как обеспечить их соблюдение на уровне API-шлюза, где им и место.
Где находятся эти элементы управления
Каждый из перечисленных ниже элементов управления обеспечивается в одном и том же месте: на API-шлюзе, расположенном между агентом и вашими бэкенд-сервисами.
Шлюз — это единственная точка контроля, где вы можете:
- видеть каждый вызов, совершаемый агентом;
- прикреплять к нему идентификатор и контекст;
- подсчитывать количество вызовов;
- анализировать закономерности во времени;
- записывать полную историю взаимодействий.
Если рассматривать шлюз как плоскость управления для агентов, а не доверять каждому бэкенду защищаться самостоятельно, вы получаете архитектурное решение, которое делает все остальные меры практичными.
В примерах ниже используется терминология Apigee — API-продукты, квоты, предотвращение всплесков, политики. Но те же самые примитивы существуют в большинстве корпоративных шлюзов: Kong, AWS API Gateway, Azure API Management, Envoy и других. Конкретные названия могут отличаться, но принципы остаются универсальными.
1. Минимальные привилегии для агентов: ограничение области доступа
Именно здесь кроется основная часть риска. Во многих системах ИИ-агент фактически рассматривается как учётная запись бэкенд-сервиса. Получив доверие, он незаметно накапливает права доступа — иногда потому, что так проще, иногда потому, что никто не хочет рисковать нарушением функциональности. В условиях автономного поведения такой подход не работает.
Агенту, предназначенному для помощи клиентам в проверке статуса заказа, не нужен доступ к возвратам средств, обновлению учётной записи или административным операциям. Но в реальных системах эти границы часто отсутствуют или слишком размыты.
Агенту, отслеживающему статус заказа, необходим доступ только для чтения к двум ресурсам — не более того...
#DST #DSTGlobal #ДСТ #ДСТГлобал #Безопасность #ИИагент #API #искусственныйинтеллект #Контекст #шлюз #модель
Источник: https://dstglobal.ru/club/1253-bezopasnost-ii-agentov-na-urovne-api