CAPMAS, совместная разработка EPFL и Swisscom, позволяет разработчикам предоставлять дочерним ИИ-агентам узкоспециализированные разрешения с помощью макарунов (macaroons). Это сокращает задержку при обработке токенов в 30 раз и не позволяет агентам получить доступ к полным JWT-токенам пользователя.

Почему это важно

Когда LLM управляет вспомогательными инструментами, команды часто передают созданному «дочернему» агенту тот же JWT, с которым вошел в систему пользователь. JWT — это подписанный блок данных, содержащий все права пользователя: доступ к HR-данным, проектным файлам, права администратора и так далее. Если модель галлюцинирует деструктивную команду, дочерний агент может выполнить её, обладая всеми полномочиями пользователя. Одна ошибка может привести к утечке данных всей организации.

Недостатки текущих обходных решений

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

Как работает CAPMAS

CAPMAS разделяет процесс предоставления разрешений на два этапа:

  1. Кодирование на стороне IAM — сервис IAM запускает энкодер, который переводит запрос на естественном языке (например, «вывести список файлов в папке finance») в набор соответствующих привилегий.
  2. Создание макаруна — эти привилегии становятся caveats (ограничениями) внутри макаруна — гибкого формата токенов, который позволяет последующим агентам добавлять новые ограничения, но никогда не позволяет удалять существующие.

Когда агент получает макарун, он может сузить область действия — например, ограничить запрос списка файлов только одной поддиректорией, — но он не может её расширить. На каждом этапе перехода сервис IAM проверяет пересечение всех caveats, гарантируя, что ни один агент не превысит первоначальные полномочия.

Показатели производительности, которые говорят сами за себя

  • Скорость — CAPMAS обрабатывает запрос на разрешение менее чем за 20 мс, что примерно в 30 раз быстрее, чем обмен по RFC 8693.
  • Точность — в бенчмарке с большим каталогом инструментов стандартная LLM упускала 53% необходимых привилегий. CAPMAS показал точность 90,9% при уровне пропусков всего 2,1%.
  • Пропускная способность — поскольку макарун содержит только итоговый набор ограничений (caveats), объем передаваемых данных составляет лишь малую часть от того, что потребовалось бы при полном цикле обмена токенами.

Прагматичный процесс внедрения

  1. Предварительная фильтрация запроса — преобразуйте намерение пользователя на естественном языке в список разрешений (allowlist) из top-k элементов до того, как оркестратор обратится к каталогу инструментов.
  2. Закрепление списка разрешений — закодируйте этот список в макарун, который дочерний агент не сможет расширить.
  3. Проверка на стороне сервиса — позвольте целевому сервису запросить у IAM вычисление пересечения всех caveats перед выполнением запроса.

Эти шаги заменяют паттерн «дать ребенку ключ от всего дома» моделью «передать одноразовый ключ с ограниченным доступом».

Что CAPMAS не исправляет

Фреймворк не защищает от атак типа prompt injection, когда злоумышленник манипулирует промптом LLM для внедрения вредоносных команд. Его защита охватывает «честных, но любопытных» агентов и ненадежные LLM, которые в противном случае могли бы действовать, имея полный JWT. Командам по-прежнему необходимы отдельные меры защиты — очистка входных данных, использование песочниц или защитные механизмы (guardrails) на уровне модели — для противодействия угрозам, связанным с промптами.

Кому это выгодно

  • Корпоративные разработчики, создающие ИИ-ассистентов, которые вызывают внутренние API.
  • Команды безопасности, стремящиеся уменьшить «радиус поражения» (blast radius) в случае компрометации модели.
  • Владельцы продуктов, которым необходимы быстрые и надежные проверки разрешений при частом создании агентов.

Что дальше

CAPMAS — это предлагаемая архитектура.

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