#модель — посты и обсуждения

​Введение: почему ИИ-агенты — это другой тип потребителя 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