У Вашего ИИ-Агента Проблема с Идентификацией (И Вот Шаблон, Который Её Решает)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

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

Что мешает сессии агента одного пользователя видеть данные другого пользователя? Что если агент будет обманут через инъекцию промпта? Что если он вызовет инструмент неожиданным образом?

Это не крайние случаи. Это проектные решения, которые нужно принять перед запуском.

Новый шаблон azd от Curity и Microsoft даёт вам рабочий эталон именно для этой проблемы.

Основная Проблема: Аутентификация ≠ Авторизация

Большинство примеров агентов хорошо справляются с аутентификацией пользователей. Они плохо справляются с авторизацией. Знание кто является пользователем не говорит вам, какие данные он должен видеть.

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

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

Как Работает Цепочка Токенов

Шаблон использует токены доступа OAuth 2.0 с обменом токенов для сужения разрешений на каждом шаге. Токен пользователя обменивается дважды, прежде чем достигнет MCP-сервера:

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

Как выглядит токен MCP-сервера:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

customer_id встроен в токен сервером авторизации, а не передаётся как параметр, которым управляет агент. API проверяет токен, а не инструкции агента.

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

Что Развёртывает Шаблон

С несколькими командами azd вы получаете:

Бэкенд-агент на Microsoft Foundry (C#, SDK Microsoft A2A и MCP)
MCP-сервер, предоставляющий пример портфельного API
Curity Identity Server в качестве сервера авторизации, наряду с Entra ID для аутентификации
Внешние и внутренние API-шлюзы, обрабатывающие обмен токенов и журналирование аудита
Bicep для всей инфраструктуры Azure: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, хранилище

Весь шаблон поддаётся проверке и настройке.

Принцип Дизайна, Достойный Заимствования

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

Это устойчиво к творческим агентам, ошибкам и инъекции промпта теми способами, которыми «просто убедитесь, что агент не делает плохих вещей» никогда не будет.

Заключение

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