Внедрение LLMS, агентов ИИ и их развивающейся экосистемы инструментов, таких как протокол контекста модели (MCP), открыло двери для различных новых вариантов использования. Тем не менее, они представляют уникальные проблемы для защиты в производстве, оставляя нам много вопросов без ответа о том, как мы будем создавать безопасные и безопасные приложения для наших пользователей.
Я столкнулся с некоторыми из этих вопросов, когда наша команда впервые начала исследовать MCP и его приложения. Мы задавали себе такие вопросы, как: «Спецификация MCP не говорит точно, что мы должны делать для Auth… так как мы должны думать об этом?» Мы задавались вопросом о лучшем способе предоставления клавиш API, как будет выглядеть удаленный сервер в будущем, и о том, как различные клиенты и их LLMS будут интерпретировать и использовать инструменты, которые мы предоставляем на нашем сервере.
В этой статье исследуется ключевые риски, присущие использованию LLMS, как мы воспринимаем эти риски, меняющиеся с введением новых стандартов, таких как MCP, и о том, как мы думаем о безопасных и масштабируемых агентских архитектурах с даже новыми, такими как агент2Agent (A2A).
Как мы сюда попали?
В оценках безопасности мы часто рассматриваем две концепции: Атака поверхность, количество мест в вашей системе, которые уязвимы для эксплуатации злоумышленников и Радиус взрывавлияние, которое успешная атака может оказать на вашу систему. LLM в последнее время взорвались в популярности с гибкостью и обещаниями автоматизированного мира, но они также приносят уязвимые поверхности атаки при добавлении в наши приложения. Основные чат -боты расширяют нашу поверхность атаки, принимая и рассуждая по поводу ненадежного естественного языка, предоставленного пользователем. Из-за неэнергинистической природы LLMS отсутствует предсказуемость продукции и ограниченной способности воспроизводить проблемы для диагностики. Таким образом, мы также не можем в полной мере быть уверены в потенциальном вреде, созданный его ответами, увеличивая наш радиус взрыва. В качестве ранних последователей, создающих нашу собственную агентскую платформу, команда столкнулась с множеством новых проблем безопасности, причем наиболее известными являются быстрые инъекции и джейлбрейки, оба оба оба содержались в связи с неуверенным контентом, поданным в LLM, предназначенные для создания непреднамеренных действий или ответов.
Затем пришли агенты. Агент AI увеличивает сложность и фактор риска, внедряя более привилегированные взаимодействия с API и данными. Теперь мы можем представить более интеллектуальные системы, которые используют инструменты и источники знаний. Агенты работают с API, соединяются с источниками данных (некоторые из общедоступного Интернета), возможно, даже разговаривают с другими агентами или управляются другим руководителем агента искусственного интеллекта. Однако, если вы расширяете нашу логику поверхности атаки и радиуса взрыва, вы можете увидеть, как проблема составляет задачу, когда мы добавляем больше ненадлежащего содержания, передаваемого между компонентами. Косвенные подсказки могут быть переданы через веб -сайты, заполненные знаниями LLMS, в ожидании всего подходящего запроса пользователя для его активации. DNS Records для домена инструмента может обмануть хост -машину в доступ к службам в своей собственной локальной сети. Несчастные цели могут испытывать эксфильтрацию данных или удаленное выполнение кода.
Не то чтобы мы не видели подобных уязвимостей раньше, но поначалу изменение в архитектурном ландшафте может быть дезориентирующимся, требуя новых способов размышлений о безопасности. Чтобы сделать это видение более безопасного агентского потока, у нас есть MCP и Agent2agent Frameworks. В то время как MCP фокусируется на создании доступа к инструментам, A2A фокусируется на совместимости между агентами.
Что мы можем с этим поделать?
Ниже мы выделяем три ключевых уязвимости, которые, по нашему мнению, важны благодаря нашей работе с MCP и тому, как их обратиться (подробности следуют ниже):
Как вы прочитали вышесказанное, вам, вероятно, стало очевидным, что, по сути, сетка агентской архитектуры может решить многие из этих проблем, а не необходимость использовать серверы MCP или A2A.
Мы также подробно рассмотрим эти риски и наши рекомендации ниже для тех, кто хочет понять их с примерами. Наш руководящий принцип в этом исследовании состоял в том, чтобы мы могли создавать безопасные системы для наших клиентов, не делая архитектуру слишком сложной для масштабирования. Поскольку предприятия стремятся принять эти рамки для ускорения своих собственных инноваций в области искусственного интеллекта, мы надеемся, что мы будем коллективно сделать это, не рискуя безопасностью наших пользователей.
1. Утечка поперечного сервера и конфиденциальная экспозиция данных
MCP — это волшебство в первый раз, когда вы его используете. Наблюдать за тем, как ваш агент выясняет, как взаимодействовать с API, и использовать его для выполнения задачи, довольно круто, он действительно дает вибрации будущего. Должны ли мы расширить наш агент и предоставить ему доступ к большему количеству серверов? Что ж, к сожалению, существует риск того, что один сервер взаимодействует с другим. Проблема здесь заключается в том, что агент может смешивать компоненты с каждого сервера, позволяя им потенциально посещать и получать доступ к вещам, которые они не должны. Этот кросс-сервер также открывает нашу поверхность атаки и наш радиус взрыва.
Несколько серверов MCP создают потенциально опасное смешивание привилегированного доступа к данным.
A2A помогает решить эту проблему, внедрив уровень абстракции между вашим приложением и подключенными серверами MCP. Он вводит интерфейс агента, который разоблачает задачи, выступая в качестве доверенного делегата, скрывая свой собственный доступ к серверам MCP, защищая вас от разоблачения привилегированных данных другим подключенным серверам в вашем приложении. Это не полностью устраняет риск, так как вы всегда могли теоретически столкнуться с злонамеренной деятельностью, спрятанной за агентом, но это помогает предотвратить подслушивание и непреднамеренное использование ресурсов на других серверах MCP.
Агенты A2A делегируют доступ к ресурсам MCP, ограничивая прямое воздействие на другие агенты и серверы.
2. Аутентификация и разрешение
Серверы MCP в основном запускаются локально сегодня, но со временем будут удаленными, так что ваш агент может подключиться к нему по стандартным HTTPS. В настоящее время MCP предлагает использовать OAUTH для авторизации, но ему не хватает аутентификации, обычно используемой предприятиями для идентификации, такой как OpenID Connect, One Sign или SAML. A2A допускает эту недостающую аутентификацию и позволяет гибким архитектурам авторизации, чтобы наши пользователи и агенты действовали надежным образом.
Серверы A2A предоставляют параметры аутентификации и авторизации посредством стандартных обменов и ожидают, что клиент и сервер будут договориться об этом самостоятельно. Агентная карта предоставляет поля для того, какой тип аутентификации требуется для доступа, с полями авторизации запланированы для добавления в спецификацию. С A2A нам не нужно вносить столько изменений с тем, как мы делаем что -то сегодня, чтобы расширить наши варианты из того, что предлагает MCP. Возможно, ваша компания использует OpenID для входов сотрудников, и вы хотите убедиться, что они аутентифицируются с этой системой, прежде чем позволить каким -либо агентам выполнять авторизованные действия от их имени. MCP сам по себе не может помочь вам сегодня там.
Что касается личности, то одним конкретным дополнением, которое мы должны сделать, является отделение идентификации агента от идентификации пользователя. Пользователь должен аутентифицировать с вашей системой, но агент, представляющий этого пользователя, также должен быть уникально идентифицирован для целей авторизации. Могут быть различия в разрешениях авторизации между пользователем и их авторизованным агентом. Сервер A2A должен проверить каждый запрос на требования к авторизации на инструментах и ресурсах, которые он выбирает для задачи, гарантируя, что несанкционированный доступ невозможен с помощью злоупотребления разрешениями и что и агент, и пользователь, который он представляет, имеют правильный объем разрешений.
Абстракции уже строятся и предлагаются в качестве услуги, чтобы обойти некоторые из этих ограничений с MCP, но они все еще экспериментальны. Более простой путь вперед может быть стандартными потоками, которые вы уже используете.
3.
У нас не может быть дискуссии о обеспечении безопасности о LLMS, не сталкиваясь с быстрыми инъекциями и джейлбрейками. Они являются двумя наиболее распространенными об уязвимости в агентских приложениях и часто участвуют в содействии другим атакам. LLMs впечатляют и относительно легко обмануть. Если не охраняется системами, которые могут проверять ненадежные входы и выходы, приложения подвергаются риску выполнения непреднамеренных действий с помощью измененных инструкций, которые будут интерпретированы LLM.
Поскольку быстрые инъекции настолько распространены, изолировать и осматривать любой ненадежный вход в LLM, является критическим. С MCP наша поверхность атаки и радиус взрыва немного увеличивается по сравнению с на заказным агентам с предсказуемыми инструментами и ресурсами. Мы не можем по-настоящему верить, что несколько подключенных серверов MCP не будут обновлять безопасный инструмент, чтобы включить инъекции позже, если вы не узнаете, или что они не будут предоставлять ресурсы, которые включают в себя оперативные инструкции по впрыскам, которые пытаются перекрестно доступа.
Можно смягчить эту проблему за счет сканирования инструментов, проверки времени выполнения и реализации обнаружения инъекций на любом ненадежном входе перед отправкой в LLM.
Однако с A2A наш агент сервер может выступать в качестве первой и последней линии защиты от инъекций. Наш взаимодействие с внешним миром в этой архитектуре ограничивает поверхность атаки, представленную инъекциями других серверов. Мы можем использовать стандартные входные и выходные ограждения в точке входа на наш сервер агента или где бы это ни было смысл в потоке запросов. Мы также защищаем наших пользователей от скомпрометирования другими серверами, так как сервер A2A управляет инструментами и ресурсами, с которыми агент будет подвергаться выполнению своей задачи.
Винни Джарруссо, главный разработчик полного стека в Twilio, также внесла свой вклад в эту статью.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Рикки Сингх является вице -президентом по продуктам и инженерии для новых технологий и инноваций в Twilio. В этой роли она возглавляет инициативы Twilio Horizon-3, посвященные движению инноваций в шаг, которая дает возможность строителям и открывает следующую эру роста Twilio. Эти инновации … читайте больше от Рикки Сингха
