Протокол — это периметр
Транспорты в стиле MCP создавались для одного доверенного вызывающего, который вызывает инструменты. В этой модели транспорт — это труба: он передаёт кадры JSON-RPC между клиентом и сервером, а все интересные решения по безопасности принимаются выше, в реализации инструмента. Когда тот же транспорт используется для равноправных агентов с разными принципалами, труба становится периметром. Каждый переход, на котором запрос повторно сериализуется, — это место, где теряется происхождение. Сообщение, которое началось как запрос пользователя, было переписано агентом-планировщиком и переслано агентом извлечения, приходит на сервер инструментов без надёжного указания на то, кто и что запросил.
Смешение обнаружения возможностей и авторизации возможностей усугубляет это. Обнаружение отвечает на вопрос «что может делать эта конечная точка?» Авторизация отвечает на вопрос «разрешено ли этому принципалу вызывать эту возможность для этой задачи?» Реестры в стиле MCP обычно предоставляют первое и оставляют второе вызывающему. В модели с одним вызывающим это оправдано. В модели с равноправными агентами это означает, что любой агент, способный достичь реестра, может перечислить всю поверхность возможностей и попытаться их вызвать, а принимающий агент не имеет оснований на уровне транспорта отказать. Реестр становится картой поверхности атаки, вручённой каждому участнику.
Это не изъян MCP как протокола инструментов. Расширять протокол инструментов до обмена сообщениями между равноправными узлами, не пересмотрев его модель доверия, — это категориальная ошибка. Уместный вопрос не в том, правильно ли сформированы кадры, а в том, может ли транспорт засвидетельствовать, кто их отправил, от чьего имени и при каких ограничениях.
Имперсонация между агентами, разделяющими пространство имён
Когда агенты идентифицируются строкой в поле сообщения, а не криптографическим принципалом, любой агент может заявить любую личность. В рое, где планировщик обращается к исполнителю по имени, скомпрометированный или просто содержащий ошибки исполнитель может отправлять сообщения, которые выглядят как исходящие от планировщика. Нижестоящие агенты не могут отличить подлинную инструкцию от поддельной, потому что транспорт не несёт ни подписи, ни привязки к каналу. Отказ происходит молча: поддельное сообщение правильно сформировано, возможность существует, и вызов succeeds.
Потоки с запутанным заместителем
Агент с низкими привилегиями ретранслирует вызов с высокими привилегиями. Это происходит всякий раз, когда транспорт авторизует соединение, а не сообщение. Агент, обладающий широкими учётными данными для своей законной работы, может быть склонён использовать эти учётные данные от имени вызывающего, у которого их быть не должно. Заместитель не злонамерен; он делает то, что разрешает протокол. Классическая мера защиты — проверка личности вызывающего — не работает, потому что вызывающий и есть заместитель, а заместитель авторизован. Чего не хватает — это привязки между исходным принципалом и конкретным вызовом.
Повтор сообщений в длительных запусках
Длительные запуски агентов сохраняют состояние в контрольных точках и возобновляются. Если транспорт не несёт nonce, переживающий контрольную точку, сообщение, перехваченное на одном шаге, может быть повторено на другом. Повтор может быть семантически допустимым: возможность всё ещё существует, аргументы всё ещё разбираются, и принимающий агент не помнит, что видел это сообщение раньше. В запуске, который длится часы и включает множество агентов, окно для повтора широко, а отсутствие долговечного nonce означает, что транспорт не может отличить повторную попытку от атаки.
Привязывайте каждое сообщение к принципалу и идентификатору задачи
Идентификатора сессии недостаточно. Сессии переиспользуются, объединяются в пулы и иногда разделяются между задачами. Каждое сообщение должно нести явный принципал (кто действует) и идентификатор задачи (частью чего является это действие), и оба должны быть покрыты подписью сообщения. Принципал — это исходный запрашивающий, а не непосредственный отправитель. Идентификатор задачи позволяет получателю применять политику, ограниченную работой, а не соединением.
Конкретный механизм: подпишите каноническую сериализацию конверта сообщения, включая принципал, идентификатор задачи, имя возможности и монотонно возрастающий порядковый номер, ключом, хранимым отправляющим агентом. Получатель проверяет подпись по ключу, привязанному к принципалу, сверяет порядковый номер с последним увиденным для этой задачи и только затем оценивает, разрешена ли возможность. Это не новая криптография; это минимум, необходимый транспорту, ч
Ограничивайте возможности сообщением, а не соединением
Авторизация на уровне соединения — корень потоков с запутанным заместителем. Соединение, авторизованное вызывать возможность, может вызывать её по любой причине. Предоставление возможности на уровне сообщения, напротив, называет возможность, задачу, принципал и срок действия. Получатель проверяет предоставление, а не соединение. Это означает, что заместитель не может повысить привилегии: он может предъявить только предоставления, выданные ему, для задач, которые ему дали.
Компромисс реален. Предоставления на уровне сообщения добавляют токен к каждому вызову, требуют издателя и вводят проблему отзыва. В высоконагруженных внутренних роях накладные расходы измеримы в задержке и в сложности издателя. Альтернатива — доверять соединению — дешевле и отказывает в открытую. Выбор при проектировании в том, должен ли транспорт отказывать закрыто при проблемах с происхождением. Для связи агент-агент через границы доверия — должен.
Сделайте журнал транспорта авторитетной записью
Журналы на стороне агента носят рекомендательный характер. Агент может быть скомпрометирован, перезапущен или просто ошибаться в том, что он сделал. Если единственная запись о сообщении находится в агенте, который его отправил или получил, эта запись не является доказательством. Транспорт должен регистрировать каждый подписанный конверт с результатом его проверки, и этот журнал должен быть авторитетной записью для аудита и для обнаружения повторов. Это также даёт место для обеспечения уникальности nonce across контрольных точек: транспорт, а не агент, помнит, что было увидено.
Честный компромисс
Каждое из этих правил переносит работу с агента на транспорт. В этом и смысл, и в этом же цена. Транспорты, которые проверяют подписи, отслеживают порядковые номера, выдают и отзывают предоставления, ограниченные сообщением, и ведут долговечный журнал, сложнее труб, передающих байты. Они требуют управления ключами, издателя и журнала, переживающего перезапуски. Они добавляют задержку и режимы отказа. При вызове инструмента одним вызывающим эта сложность не оправдана. В рое равноправных агентов, где принципалы расходятся, а длительные запуски сохраняются в контрольных точках и возобновляются, сложность и есть свойство безопасности. Вопрос не в том, платить ли за неё, а в том, где: в транспорте, один раз, или в каждом агенте, многократно и непоследовательно.
Что делать дальше
Относитесь к транспорту как к поверхности атаки и проводите его аудит как таковой. Перечислите переходы, на которых запрос повторно сериализуется, и спросите, какое происхождение сохраняется. Отделите обнаружение возможностей от авторизации возможностей и требуйте предоставление в момент вызова. Привязывайте сообщения к принципалам и задачам, а не к сессиям. Сделайте журнал транспорта авторитетным и используйте его для обнаружения повторов. Ничто из этого не требует отказа от транспортов в стиле MCP; это требует расширить их примитивами доверия, которые нужны равноправной связи. О связанной работе по безопасности протоколов агентов см. этот анализ.