Криптографическая идентичность для ИИ-агентов: как AWS и Keyfactor решают проблему доверия в мультиагентных системах
AWS Machine Learning · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
AWS и Keyfactor представили референсную архитектуру, использующую инфраструктуру открытых ключей (PKI) для обеспечения безопасной идентификации ИИ-агентов. Решение закрывает пробелы в протоколе Model Context Protocol (MCP), исключая возможность подмены агентов и несанкционированного доступа к корпоративным данным.
С ростом использования автономных ИИ-агентов для работы с базами данных и API критически важно гарантировать, что запросы исходят от авторизованных субъектов. Традиционные методы передачи токенов не обеспечивают требований zero-trust, создавая риски подмены и повторного использования перехваченных данных.
По мере того как мультиагентные ИИ-фреймворки все чаще используют Model Context Protocol (MCP) для интеграции с внешними инструментами, возникает фундаментальная проблема безопасности: MCP не имеет встроенного стандарта аутентификации. Как отмечают инженеры AWS и Keyfactor, это создает критический разрыв, позволяющий любому компоненту имитировать агента или повторно использовать перехваченные учетные данные. Чтобы закрыть этот пробел, компании разработали совместную референсную архитектуру, объединяющую сервисы Amazon Bedrock и платформу управления идентичностью Keyfactor EJBCA. Ключевым элементом решения является внедрение криптографической идентичности на основе сертификатов X.509, что позволяет доказать владение ключом и авторизацию действий без передачи общих API-ключей или полных OAuth-токенов между компонентами.
Архитектура опирается на четыре взаимодополняющих механизма безопасности. Во-первых, используются подписанные конверты запросов, обеспечивающие криптографическое доказательство владения ключом при каждом вызове инструмента. Во-вторых, применяются делегированные утверждения, подписанные пользователем, которые авторизуют агентов без передачи их учетных данных. В-третьих, реализованы токены с ограниченной областью действия (audience-scoped) согласно RFC 8693, что минимизирует ущерб при утечке одного токена. Наконец, система использует проверку статуса отзыва сертификатов в реальном времени через протокол OCSP, что позволяет мгновенно отозвать доступ ко всем агентам при необходимости.
Процесс аутентификации начинается с входа пользователя в систему Keycloak. Приложение выполняет обмен токенов RFC 8693 для получения ограниченного токена, предназначенного исключительно для MCP-сервера. Параллельно генерируется пара ключей RSA 2048+, и запрос на подпись сертификата (CSR) отправляется в EJBCA. Приватный ключ никогда не покидает локальное окружение приложения и хранится в AWS Secrets Manager в контейнере PKCS#12. Пользователь подписывает делегированное утверждение, содержащее отпечатки сертификатов назначенных агентов, тем самым передавая им полномочия без раскрытия своих собственных ключей.
При передаче запроса от оркестратора к суб-агенту (например, для работы с MySQL или электронной почтой) формируется подписанный конверт. Он включает имя инструмента, аргументы, временную метку и криптографически случайный nonce, подписанный приватным ключом отправителя с алгоритмом RSA-PSS-SHA256. Получающий агент выполняет шесть проверок: верификацию подписи, свежесть временной метки (по умолчанию 60 секунд), уникальность nonce для предотвращения повторного использования, валидацию цепочки доверия CA, проверку ролевой авторизации и статус отзыва через OCSP. Такой подход исключает сценарии записи и повторной отправки запросов, а также подмены отправителя.
На стороне MCP-сервера действует принцип «глубокой защиты». Сервер выполняет интроспекцию токена, проверяя его активность и правильную область действия. Затем верифицируется подписанный конверт агента и делегированное утверждение пользователя. Особое внимание уделяется перекрестной проверке идентичности: имя пользователя в токене, субъект делегирования и префикс CN сертификата агента должны строго совпадать. Это гарантирует целостность цепочки доверия от человека до выполнения инструмента.
Важным аспектом архитектуры является каскадное отозвание прав. При выходе пользователя из системы или при необходимости блокировки доступа, отзыв сертификата пользователя в EJBCA мгновенно инвалидирует все активные делегирования и подписанные конверты агентов. Поскольку каждая проверка включает запрос к OCSP, эффект распространяется на всю систему в реальном времени, без необходимости индивидуального удаления сессий или токенов. Приватные ключи генерируются локально и никогда не передаются в EJBCA, которая выступает исключительно в роли центра сертификации.
Данный подход обеспечивает изоляцию приватных ключей, предотвращение повторного использования запросов и строгое соблюдение ролевых границ. Агенты могут вызывать только предопределенные инструменты, а суб-агенты не имеют права обращаться друг к другу или к оркестратору. Для производственных сред AWS рекомендует дополнять PKI-контроли механизмами Amazon Bedrock Guardrails для фильтрации контента и проверки тематических ограничений. Источник: web:AWS Machine Learning — https://aws.amazon.com/blogs/machine-learning/securing-ai-agent-identity-with-x-509-pki-on-aws/