
MCP преувеличен? Реальная история об инструментах и безопасности агента
6 июня 2025 г.Давайте будем честными - все говорят о протоколе контекста модели (MCP), как будто это следующая большая революция в ИИ. Технические блоги гудят, конференции заполнены панелями MCP, и разработчики стремятся их реализовать. Но вот мой взгляд: MCP не так уж важно. Это просто еще один протокол в эволюции агентских инструментов.
Не поймите меня неправильно - сами агентские инструменты - это огромная сделка и представляют значительные риски безопасности. Но преувеличен ли MCP? Не обязательно. Это одна реализация, один шаг в гораздо более длинном и эволюционном пути. Но мы также должны сосредоточиться на том, как автономия агента увеличивается и что это значит для разработчиков и специалистов по безопасности.
В этой статье я проведу вас через MCP, обсуждаю реальные риски инструментов агента (независимо от протокола) и изучу, куда мы идем дальше с протоколами, такими как X402, которые в настоящее время летают под радаром, но на самом деле могут быть более революционными. Я поделюсь как с точки зрения разработчика, так и угла безопасности - две истории, которые нужно рассказать вместе, чтобы понять полную картину.
История разработчика: эволюция агентских инструментов
Давайте немного перемотаем и посмотрим, как мы сюда попали. В старые времена (и под старым я имею в виду всего пару лет назад), если вы хотите, чтобы ваш агент по искусству использовал какой -то инструмент - допустим, чтобы получить возможность поиска в Интернете - вам нужно было создать учетную запись с поставщиком, поместить в свою кредитную карту, получить ключ API, а затем написать пользовательский код для интеграции этого конкретного инструмента. Каждый инструмент требовал собственного пользовательского подключения, собственных зависимостей и собственного кода интеграции. Это был беспорядок кода и конфигурации спагетти.
Затем пришел MCP. Внезапно все эти серверы могут соответствовать общему протоколу общения. Теперь я могу иметь один клиент MCP с клавишами API для каждого инструмента. Это лучше? Абсолютно. Это революционно? Нет, но это важный и эффективный прогресс. Мне все еще нужно настроить каждый инструмент в моем клиенте MCP, который является большим количеством накладных расходов. Это намного лучше, чем написание пользовательского кода или установка зависимостей для каждого инструмента, но это всего лишь один шаг в эволюции, а не пункт назначения.
На самом деле MCP стандартизировал, как агенты разговаривают с инструментами. Это полезно, но это не изменяющий игру, который все делают. Это просто естественный прогресс в том, как мы строим агентские системы. Реальная история о повышении автономии агента, а не о конкретных протоколах, которые они используют для общения.
Подумайте об этом так: LLM сам по себе является автономным в ограниченном смысле - он может генерировать текст, но это все. Добавлять
Но даже с MCP я все еще узкий место. Я должен настроить все эти инструменты, управлять всеми этими клавишами API и решить, к каким инструментам агент может получить доступ. Следующим эволюционным шагом является удаление этого узкого места, и именно здесь все становится действительно интересным.
История безопасности: реальные риски агентских инструментов
Вот где все становится серьезно. С точки зрения безопасности, это не сама MCP, это проблема - это шкала, которую агенты теперь могут достичь. И каждый шаг в этом масштабе означает экспоненциально больший риск. Мы не говорим о 10% больше риска, мы говорим о в 10 раз больше риска с каждым эволюционным шагом.
Когда мой агент идет в Интернет, существует множество рисков. Но реальная опасность состоит в том, что агент приносит все эти риски домой - всю дезинформацию, оперативные уязвимости инъекций, предубеждения, как проблемы безопасности, так и проблемы безопасности. Затем он принимает решения на основе этой потенциально скомпрометированной информации о том, что делать с моими базами данных, моими системами, моим бизнесом.
Позвольте мне привести вам конкретный пример того, что может пойти не так. Скажем, у меня есть агент, который может получить доступ к базе данных нашей компании через такой инструмент, как Redash. Я прошу его перейти на страницу в Википедии о какой -то теме, развлечь информацию, понять, как она работает, а затем создать билет JIRA на основе этой информации, извлекая некоторые соответствующие данные из нашей базы данных.
Звучит невинно, верно? Но что, если кто -то вставил скрытый контент на этой странице Википедии? Контент вы даже не увидите как человек, потому что он скрыт за текстом, используя эмодзи или невидимые персонажи. Агент может увидеть и обработать это скрытое содержание, которое может содержать вредоносные инструкции. Внезапно мой агент запускает код на моих серверах - по -прежнему вредоносный код - все потому, что он посещал веб -страницу.
Это не теоретический риск. Это происходит прямо сейчас. И это не MCP, это проблема - это тот факт, что агенты теперь могут получить доступ к инструментам. MCP просто стандартизирует, как они это делают.
Подумайте об этом так: если у вас есть два сотрудника, вы можете научить их быть заботливым. Если вы отправите им электронное письмо с милыми кошками и щенками, но содержащие вредоносное ПО, они, вероятно, не нажмите на него. Если у вас есть 100 сотрудников, один, вероятно, нажмет на это. С агентами мы стремимся к бесконечному количеству «сотрудников» - вероятность того, что один из них получит скомпрометированные подходы на 100%.
Чем более автономными становятся наши агенты, тем больше этот риск увеличивается. А протоколы, такие как MCP, просто ускоряют эту тенденцию, облегчая подключение агентов к большему количеству инструментов.
За пределами MCP: следующая эволюция в протоколах агента
В то время как все одержимы MCP, есть что -то еще более интересное, которое летит под радаром. После процветания MCP он вдохновил больше протоколов, таких как A2A (агент-агент) и
Итак, что такое X402? Это протокол, разработанный Coinbase, который помогает агентам получить доступ к API -интерфейсам и агентам с помощью модели «оплата по ходу». Думайте об этом как о HTTP -моменте для платежей - стандарт для местных платежей в Интернете, который может изменить все о том, как работают агенты.
Вот почему это имеет значение: с X402 вместо того, чтобы настраивать каждый сервер MCP и инструмент по отдельности, вы можете просто предоставить агенту деньги и позволить ему найти и использовать необходимые ему инструменты. Это огромный скачок вперед в автономии агента.
Протокол построен на USDC, криптовалюте, стаблекоина, которая всегда стоит ровно один доллар США. В отличие от биткойна с его волатильностью, USDC сохраняет постоянную ценность, что делает его идеальным для автоматизированных программных платежей. Это означает, что агенты могут совершать сделки с реальными деньгами в мире без вмешательства человека.
Этот протокол фактически существовал ранее в примитивной форме, но он был плохо реализован, поэтому никто не использовал его. Теперь Coinbase исправил его, построил его на крипто, и участвуют крупные игроки, такие как Stripe, Anpropic и AWS. Это большое дело, даже если большинство людей еще не осознавали этого.
С точки зрения разработчика, это все меняет. Вместо текущей головной боли настройки каждого инструмента в моем клиенте MCP я могу просто финансировать своего агента и позволить ему обрабатывать остальные. Это становится более автономным, более способным и ближе к человеческому помощнику, чем когда -либо прежде.
Позвольте мне представить это в перспективе: LLM автономный, но он может только написать текст. Агент с тряпкой может прочитать ваши данные. Агент с инструментами может предпринять такие действия, как поиск в Интернете или отправка электронных писем. Но агент с X402 может найти и использовать инструменты, которые вы даже не настроили для него. Каждый шаг приближает нас к по -настоящему автономным системам, которые могут работать независимо в мире.
Баланс инноваций и безопасности
Итак, где это оставляет нас? У нас есть MCP, который полезен, но преувеличен. У нас есть новые протоколы, такие как X402, которые могут в корне изменить то, как работают агенты. И у нас есть серьезные проблемы безопасности, которые растут с каждым шагом к большей автономии.
Реальность такова, что нам нужно, чтобы все были в курсе и начали работать над процессами безопасности сейчас, а не после того, как произойдет следующее большое нарушение. Но вот ключ: безопасность не может блокировать инновации. Мы не можем просто подбросить руки и сказать «это слишком опасно», потому что технология движется вперед, нравится нам это или нет.
Нам нужны автоматизированные процессы безопасности, которые не замедляют разработку. Инструменты, которые автоматически утверждают или не одобряют действия агента на основе профилей рисков. Системы, которые могут обнаружить, когда агент имеет слишком много разрешения, и предлагают разделить его на разные агенты с более ограниченным доступом. Сканеры, которые могут идентифицировать потенциально злонамеренные серверы MCP, прежде чем они интегрированы.
Если ваш агент имеет доступ как к веб -просмотру, так и к вашей базе данных, это вектор риска. Возможно, эти функции должны выполняться отдельными агентами, которые общаются друг с другом через контролируемые каналы. Если ваш агент может выполнить код, а также обладать возможностями платежей, это еще один вектор риска, который может быть разделен.
Будущее, которое я вижу, - это то, где безопасность встроена в процесс разработки с самого начала, включая прототипирование приложения, не прикрепленное к запоздалой мыслью. У нас есть автоматизированные инструменты, которые помогают разработчикам сделать безопасный выбор, не замедляя их, где мы можем использовать силу все более автономных агентов, смягчая очень реальные риски, которые они представляют.
MCP не революция - это всего лишь один шаг в постоянной эволюции. Настоящая революция происходит в том, как мы думаем об автономии агента и о том, как мы обеспечиваем эти все более мощные системы.
Будущее агентских инструментов невероятно захватывающе, но также чревато риском. Давайте убедимся, что мы говорим о обеих сторонах этой монеты, а не только о новых блестящих протоколах, которые делают хорошие презентации на конференции.
- Написано Бар-Эль Таюри, глава AI Mend AIMend.io
Оригинал