Что Passport обнаружил за 3 недели трафика AI-агентов

Каждому вызову API нужны учетные данные, и до тех пор, пока программное обеспечение вызывает API, способом передачи учетных данных вызывающей стороне было их копирование. В файл .env, в профиль bash, в хелпер учетных данных, в связку ключей ОС. Исследование Postman показало, что в среднем каждый действующий секрет появляется примерно в восьми разных местах на одной и той же машине.

Ваш ноутбук — это еще не предел. Вспомните, когда ваш коллега в последний раз останавливался из-за ключа. Его вставили в ветку Slack, ввели в онбординг-документ, отправили по электроннойсти или запечатлели на скриншоте чьей-то рабочей конфигурации. Каждый из этих случаев — обычный вторник после обеда, и каждый из них перманентен. Slack не знает, что он хранит учетные данные. Google Doc не может их ротировать. Никто не возвращается назад, чтобы отредактировать скриншот. Так что количество мест, где хранится конкретный ключ, только растет.

Теперь мы все работаем так годами и в основном все обходится хорошо, и это не удача. Это работало, потому что каждый вызов API выбирал человек. Вы написали запрос, поэтому вы знали, какой ключ он использует и куда примерно он направляется, и если что-то выглядело странно, вы сидели прямо там и наблюдали за этим. Копии были везде, но тратили их вы.

Агенты отбирают это. Агент прямо во время работы решает, какие инструменты вызывать и к каким хостам обращаться, и каждый запускаемый им процесс наследует ваши переменные среды, независимо от того, нужны они ему или нет. Таким образом, ключ, который вы экспортировали для одной задачи, теперь доступен коду, который вы не писали, и совершает вызовы к эндпоинтам, которые вы не выбирали. Вот в чем реальный сдвиг. Дело не в том, что агенты делают больше запросов, чем мы, хотя они будут это делать (по оценкам Postman — в 1000 раз). Сдвиг заключается в том, что никто не может заранее сказать, куда попадут учетные данные. Раздача копий секрета работает только тогда, когда вы знаете, у кого они находятся, и именно на это нацелен Postman Passport: перестать давать каждому потребителю собственную копию и вместо этого предоставить ему ограниченное разрешение на выполнение вызова.

Мне захотелось узнать, как это выглядит на практике на рабочей машине разработчика. Поэтому я провел эксперимент самостоятельно.

Я потратил последние три недели на создание AI-обвязки для измерения того, как Context Graph API влияет на потребление токенов агентом. В первый день я включил Postman Passport, а затем приступил к разработке.

Три недели спустя, когда я наконец проанализировал дашборд, Passport зафиксировал 22 уникальных секрета, покинувших этот ноутбук в рамках 33 запросов, направлявшихся к 18 разным хостам, в 8 различных форматах, отправленных 17 разными пользовательскими агентами.

В моем файле .env было четыре записи.

Это сравнение и есть суть. Файл .env — это то, к чему разработчики относятся как к своему инвентарю учетных данных: когда кто-то спрашивает, какие секреты использует проект, вы открываете именно его. Мой файл содержал менее пятой части учетных данных, с которыми эта машина фактически проходила аутентификацию. Остальные восемьдесят не были украдены или скрыты. Они поступали из связки ключей ОС, хелпера учетных данных git, конфигурации npm и из переменных среды, которые наследует каждый подпроцесс. Все это легитимные места для хранения ключа. И ни одно из них не занесено в какой-либо инвентарь.

Passport измерил то же самое распространение со стороны хранилища и обнаружил примерно восемь копий на каждый действующий секрет. Я измерил это со стороны трафика и обнаружил в пять раз больше используемых учетных данных, чем мог назвать.

Я не писал ни одного из этих запросов. Я запустил агента, агент выбрал свои инструменты, а инструменты выбрали свои сетевые вызовы. Путь выполнения не существовал до момента запуска, поэтому не было файла, который я мог бы открыть заранее, чтобы предсказать его. Мой статический сканер оставался зеленым все это время, и он был прав: ни один из этих 22 секретов не находился в репозитории.

В этом и заключается разрыв. Сканер секретов сообщает вам, где хранятся учетные данные. Ничто в этой цепочке инструментов не говорит вам, куда перемещаются учетные данные. И решение заключается не в лучшем хранилище. Решение — это сдвиг, вокруг которого построен Passport: инвертировать модель совместного использования секретов в модель контроля доступа, так чтобы вместо распространения секретов среди потребителей API вы предоставляли контролируемый и детальный доступ для использования API.

Вот краткая сводка, с которой открывался дашборд:

[SCREENSHOT: Passport dashboard summary and findings table]

Появилось восемь классов секретов: bearer-токены, заголовки apikey, заголовки x-api-key, учетные данные Basic auth, учетные данные авторизации AWS, JWT, идентификаторы сеансов в параметрах запроса и параметры запроса с подписью.

Почему ваш инвентарь учетных данных неполный

Учетные данные обеспечивают доступ к ресурсу для программы/человека. Ваш ноутбук ими полон. Некоторые лежат в файле, некоторые в связке ключей операционной системы, некоторые в конфигурации инструмента, который вы установили два года назад и забыли о нем.

Большую часть истории программного обеспечения вопрос безопасности заключался в том, где они хранятся, и на этот вопрос был удовлетворительный ответ. Вы куда-то положили ключ, поэтому знали, где он находится. Инструменты сканирования выросли вокруг этого предположения: направьте их на свой код, и они скажут вам, находится ли ключ там, где ему быть не положено.

Разработка на основе агентов разрушает это предположение вполне конкретным образом, и здесь стоит быть точным в отношении механизма, а не отделаться общими фразами вроде «ИИ — это страшно».

Когда вы даете агенту задачу, он выясняет, как ее выполнить во время работы. Он выбирает инструменты. Эти инструменты запускают другие программы. Эти программы открывают сетевые соединения. Каждый слой передает свое окружение следующему, и учетные данные по умолчанию переносятся в этом окружении:

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

Четыре находки в моем отчете делают это очевидным. Я пройдусь по каждой с реальными данными, потому что совокупные подсчеты — это заголовки, а детали — это урок.

Из всего в отчете эти четыре я бы исправил в первую очередь.

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

Посмотрите на первые две строки. Тот же хост, тот же клиент, та же секунда: 17:02:58. Один запрос содержал как JWT, так и параметр подписи в строке запроса. Это предварительно подписанный URL-адрес ресурса, и функционально он представляет собой токен доступа с таймстемпом. Любой, у кого есть полный URL-адрес, получает доступ.

необычайно прямолинеен в отношении того, почему это является проблемой. Bearer-токены «НЕ ДОЛЖНЫ передаваться в URL-адресах страниц» из-за «высокой вероятности того, что URL-адрес, содержащий токен доступа, будет залогирован». В спецификации перечислены история браузера, логи веб-серверов и заголовки referrer в качестве путей утечки. Третий путь документирован на MDN: если сайт не устанавливает строгую политику реферера (referrer policy), полный URL-адрес, включая строку запроса, передается на следующий хост, к которому обращается браузер.

Ничего из этого не новость. Новым является то, кто именно строит эти URL сейчас. Я не писал вызов codex_sdk_ts и не писал вызов curl, который извлек артефакт релиза. Это сделал агент, пройдя по цепочке перенаправлений, которую я даже не видел.

Так почему же заголовок безопаснее, чем URL, если оба передаются по одному и тому же зашифрованному соединению на один и тот же сервер? Ответ не в шифровании. Дело в том, что записывается на другом конце.

Отправьте один и тот же секрет дважды, по разу в каждом направлении, и посмотрите на «сырой» запрос:

Оба секрета доходят до адресата. Разница в том, что первая строка — это строка HTTP-запроса, а строка запроса — это то, что серверы сохраняют. В общем формате логов (Common Log Format), который по умолчанию используют Apache, nginx и большинство обратных прокси, записываются строка запроса, статус и количество байтов. В форматных строках Apache это поле называется %r; в формате combined по умолчанию в nginx — $request. Ни одно из них не записывает Authorization.

Таким образом, секрет в строке запроса сохраняется в виде открытого текста каждым сервером, прокси, балансировщиком нагрузки и CDN на пути следования, а также любым сервисом, который пересылает эти логи вашему поставщику систем наблюдаемости. Тот же самый секрет в заголовке отбрасывается ими всеми. Тот же транспорт, то же доверие, совершенно разное время хранения.

И это ближе к дому, чем кажется. Ваша собственная оболочка сохраняет копию каждой запущенной вами команды, так что поищите в ней:

Все, что обнаружится, — это учетные данные, хранящиеся в файле открытым текстом на вашем диске, в месте, которое не сканирует ни один сканер секретов, и они все еще будут там через шесть месяцев.

Выводы: «Короткоживущий» — это утверждение, а не свойство: предварительно подписанные URL часто имеют семидневный срок действия, а семь дней в 30-дневном логе — это целая неделя экспозиции. Поэтому я смотрю на реальное число, а не доверяю слову, и проверяю, что значение ограничено одним объектом и одной операцией, а не всей моей учетной записью.

Находка 2: один ключ, две программы и никакой возможности отключить половину

Две программы, которые не имели друг к другу никакого отношения, проходили аутентификацию с помощью одного и того же пароля.

Посмотрите на последний столбец. sk-ant-••••4AAA — это один и тот же замаскированный хвост во всех трех случаях, значит, это один и тот же ключ. Теперь посмотрите на столбец клиента: его отправили две совершенно разные программы. Bun/1.4.0 — это среда выполнения JavaScript, выполняющая ту же роль, что и Node.js, и что-то в моей утилите использовало ее для вызова Anthropic API напрямую. claude-code — это агент для написания кода. Ни одна из них не знала о существовании другой.

Стоит сделать паузу и обсудить, почему я вообще могу это видеть. Passport показывает несколько символов каждого секрета, чего достаточно для доказательства того, что два запроса содержали одни и те же учетные данные, но при этом сам отчет не превращается в список моих ключей в открытом виде. Этот замаскированный хвост здесь выполняет реальную работу: это единственная причина, по которой я могу отличить эти три строки от трех не связанных друг с другом ключей.

Сам по себе это не инцидент. Ничего не было украдено и ничто не использовалось не по назначению. Это превращается в проблему в первый же момент, когда я хочу предпринять какие-то действия в отношении одной из этих программ, потому что учетные данные — это единственное, с чем я могу работать.

Подумайте о том, какими на самом деле являются доступные действия. Отключение доступа, замена значения, сужение зоны доступности: каждое из этих действий является операцией с ключом, а не с программой. Здесь нет кнопки «перестать доверять этому конкретному процессу». Поэтому, когда один ключ обслуживает две программы, наименьшее доступное мне действие затрагивает обе.

Допустим, я решил, что процесс Bun подозрителен, а агент нормален. Я хочу отключить первый и оставить второй работающим. Я не могу. Это не две учетные записи с двумя паролями. Это две программы, владеющие одним паролем, и для Anthropic API они являются одним и тем же вызывающим объектом.

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

Реагирование на это приводит к простою, именно поэтому такие находки залеживаются. «Мы сделаем ротацию после релиза» — вот как подозрительный ключ остается активным еще один квартал.

Из этого есть очевидный выход. Если бы Anthropic API мог видеть, что один запрос поступил от моего агента, а другой от скрипта Bun, он мог бы отклонить один и продолжать обслуживать другой, и я получил бы ровно тот контроль над конкретными программами, которого так не хватало в этом разделе.

Существует даже поле, которое выглядит созданным специально для этой задачи. Каждый HTTP-запрос содержит user agent (пользовательский агент) — короткую строку, в которой клиент сообщает, что это за программное обеспечение. Именно она заполнила столбец Client в моем отчете, и это единственная причина, по которой я вообще смог различить эти три строки.

Вот чего на самом деле стоит эта строка. Флаг -H говорит curl установить заголовок на все, что я захочу, поэтому я отправлю два запроса, каждый из которых заявляет, что он является другой программой:

Оба они были отправлены обычным curl. Ни Bun, ни агент в тот момент не находились рядом с моей машиной. Клиент выбирает значение, сервер записывает его, и ничто и нигде его не проверяет. Пользовательский агент — это утверждение, а не учетные данные, что делает его действительно полезным для статистики и бесполезным для контроля доступа. Так что столбец Client в моем отчете — это реальная подсказка о том, что произошло, и на нем нельзя безосновательно строить ни одно решение по безопасности.

Остается сам ключ, а ключ несет в себе еще меньше информации. sk-ant-••••4AAA — это одна непрозрачная строка, которая ничего не говорит о том, кто ее предъявляет. Для API любой, кто отправляет эту строку, и есть учетная запись. Мой агент, мой скрипт Bun и любой, кто скопировал это значение из моего окружения, являются одним и тем же вызывающим объектом, и в запросе нет ни одного поля, которое могло бы их разделить. Владение — это вся идентичность, поэтому здесь нечего отключать для каждой отдельной программы. Это не изъян в API Anthropic. Так работают API-ключи повсюду.

Теперь сравните строки GitHub в том же отчете:

Два разных хвоста, то есть два разных токена для номинально одного и того же инструмента. Потоковая авторизация устройств GitHub (GitHub OAuth device flow) выдает учетные данные для каждого клиента вместо того, чтобы давать каждому клиенту один общий ключ. Каждый из них можно отключить отдельно, и уничтожение одного оставляет другой работающим. Это именно тот контроль, которого я хотел три абзаца назад, и я получил его по умолчанию, а не благодаря хитрости.

Последняя причина не строить политики на основе строки клиента. В моем отчете claude-code появляется под шестью различными отпечатками: версии 2.1.221, 2.1.223 и 2.1.231, каждая в варианте (cli) и в «голом» варианте, плюс один (sdk-cli). Один инструмент, шесть идентификаторов, меняющихся по собственному графику релизов. Любой список разрешений (allowlist), написанный для этих строк, устарел бы в течение месяца, и для этого дрейфа не потребовалось ни единого изменения в моем коде.

Выводы: я перестал считать секреты и начал считать потребителей на один секрет. Ключ, используемый одной программой, — это ключ, который я могу сменить во вторник после обеда. Тот же ключ, используемый четырьмя программами, — это сбой в работе, который мне приходится планировать, а это значит, что на практике он не меняется вообще. Это число — потребителей на учетные данные — стоит отслеживать, и именно его ссылки, привязанные к владельцу, в Passport призваны удерживать на уровне единицы.

Находка 3: учетные данные, которые я ни к чему не могу отнести

Эта строка появилась дважды с интервалом в четыре недели.

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

Проще говоря: что-то на этой машине использовало пароль для связи с Microsoft и не назвало своего имени. Я знаю, что вызов был. Я не знаю, что его совершило.

Я до сих пор не знаю, что это было. Вероятно, редактор или SDK со встроенной телеметрией. В этом и суть: у меня есть исходящий запрос с учетными данными, пункт назначения, метка времени и отсутствие возможности соотнести его с процессом только на основе сетевого представления. Если бы этот ключ принадлежал мне, а не вендору, я бы понятия не имел, какое из примерно 40 приложений, запущенных на этом ноутбуке, нужно пойти и выключить.

Именно здесь наблюдение за выполнением отрабатывает свою ценность и здесь же проявляются его ограничения. Passport сообщил мне, что запрос был совершен, а это 90% ценности, потому что в противном случае я бы ничего о нем не знал. Атрибуция помимо пользовательского агента требует корреляции на уровне процессов, поэтому объедините эту находку с lsof или eslogger в macOS, если вам нужно замкнуть круг.

Выводы: учетные данные, которые невозможно отнести к определенному источнику, хуже известных вредоносных, так как с ними ничего нельзя поделать. Теперь я рассматриваю пустой столбец «Клиент» как отдельный класс критичности, а не как пробел в данных, и проверяю его в первую очередь, поскольку все остальные находки хотя бы говорят мне, куда идти. Это также самый убедительный аргумент в моем отчете в пользу идентичности, от предоставления которой программа не может отказаться.

Находка 4: мой агент передает учетные данные третьим лицам

Семь из моих 33 находок были направлены на эндпоинты MCP:

Краткое пояснение, если вы не знакомы с MCP. Model Context Protocol — это стандартный способ подключения агента к внешнему сервису, позволяющий ему считывать данные и выполнять действия в нем. Я подключил два сервиса, Vercel и Atlassian, один раз вставив токен в файл конфигурации несколько месяцев назад. С тех пор мой агент самостоятельно решал, когда к ним обращаться.

Проблема

Сервер MCP — это посредник. Мой агент не общается с Atlassian напрямую; он общается с mcp.atlassian.com, который общается с Atlassian от моего имени. Это означает, что сервер получает учетные данные, способные действовать от моего лица, и из этого вытекают две вещи.

Первое — это область действия (scope). Всё, что может этот токен, может и сервер, до тех пор пока токен живет. Я никогда не садился и не решал, какими должны быть эти разрешения. Я вставил токен и пошел дальше.

Второе — более тонкий момент, у которого есть свое название. Если сервер MCP берет токен, отправленный моим агентом, и пересылает его в неизменном виде в настоящий сервис, реальный сервис видит действительные учетные данные и не имеет возможности узнать, санкционировал ли я это конкретное действие или посредник воспроизвел мой токен в собственных целях. В спецификации это называется передачей токена (token passthrough) и прямо запрещается, поскольку создает скомпрометированного посредника (confused deputy): доверенный компонент, действующий по инструкциям, которые он не должен был выполнять, используя полномочия, не принадлежащие ему самому.

В этих строках есть и третья вещь, которая должна показаться знакомой. В двух из них идентификатор сеанса (sessionid) помещен в параметр запроса, что представляет собой Находку 1 во всей красе, в трафике, который я не писал, к сервису, который я не запускаю.

Решение

Спецификация четко определяет, чья это обязанность. Серверы MCP «ДОЛЖНЫ проверять, что предоставленные им токены были выпущены специально для их использования». Корректно созданный сервер проверяет, что токен был создан для него, отклоняет все остальное и получает собственные нисходящие (downstream) учетные данные, а не воспроизводит ваши.

Это обязанность сервера, а не ваша, поэтому у вас остаются две вещи, которыми вы действительно можете управлять. Предоставьте каждому серверу MCP собственные учетные данные, никогда не используйте те, которые разделяются с другим потребителем, чтобы ловушка отзывов из Находки 2 не сработала. И относитесь к каждому серверу как к служебной учетной записи, которую вы подключаете: какой токен он получает, какова область действия этого токена и что он с ним делает в дальнейшем. Страница лучших практик безопасности MCP является вашим чек-листом.

Где вступает в дело Passport

В двух аспектах, которые соответствуют двум половинам продукта.

Половина, отвечающая за видимость, — это причина, по которой я вообще узнал обо всем этом. Я искренне забыл, что эти серверы были настроены. Ни один файл на моей машине не подсказал бы мне, что в прошлом месяце мой агент отправлял bearer-токены на два эндпоинта третьих лиц, потому что трафик — это единственное место, где существует этот факт. Семь находок из конфигурации, которую я настроил один раз и больше к ней не возвращался.

Архитектурная половина гораздо интереснее, так как она делает проблему передачи токенов структурно невозможной, а не требует от третьей стороны осторожности. Если мой агент хранит ссылку на учетные данные вместо ключа, то все, что он может передать серверу MCP, не является многократно используемым секретом. Ссылка привязана к ее владельцу, поэтому посредник не может воспроизвести ее от моего имени. Настоящие учетные данные разрешаются внутри прокси безопасного доступа (Secure Access Proxy) в моей собственной сети и вообще не доходят до третьей стороны. Передавать просто нечего.

Выводы: каждый настроенный вами сервер MCP — это третья сторона, которой вы дали постоянное разрешение действовать от вашего имени, и их количество только растет. Теперь я проверяю их с той же периодичностью, что и служебные учетные записи, и никогда не направляю сервер на учетные данные, которые использует другая программа. Более глубокое исправление заключается не в том, чтобы относиться к посредникам с большим доверием, а в том, чтобы не давать им ничего, что стоит воспроизводить.

Настройте Passport и изучите собственный трафик

Всё вышеописанное произошло на одном ноутбуке — моем. Ваши хосты будут другими, ваши клиенты будут другими, и ваша худшая находка, вероятно, отсутствует у меня. Именно по этой причине стоит запустить этот инструмент самостоятельно, а не полагаться на мои цифры: я могу подсказать, что искать, но я не могу знать, что именно вы найдете.

Так что это единственная вещь из данного поста, которую я действительно попрошу вас сделать. Это требует выполнения одной команды и недели игнорирования процесса после этого, а в итоге у вас появится собственная версия отчета, на которой построено всё вышесказанное.

Community Edition утилиты Passport CLI работает полностью локально, маскирует секретные значения и не отправляет трафик никуда. Установите ее из npm:

Затем запустите инспектор. passport lens располагается в пути запроса и перехватывает вызовы от агентов и инструментов разработчика без каких-либо изменений в этих клиентах:

Теперь займитесь своей обычной работой в течение недели. Ничего не инструментируйте, не регистрируйте учетные данные, не перестраивайте под это свой проект. Вся ценность этого упражнения заключается в том, чтобы узнать, как ведет себя ваша среда, когда вы за ней не наблюдаете.

Вот несколько полезных флагов, о которых стоит знать:

На панели управления результаты сгруппированы по месту назначения, клиенту и типу обнаружения, а под ними находится таблица «Обнаружено / Место назначения / Клиент / Тип / Маскированный секрет». Кнопка «Экспорт отчета» в правом верхнем углу позволяет получить артефакт, на котором основана эта публикация. Все подробности приведены в документации по Passport CLI.

Когда вы читаете собственный отчет, прорабатывайте его в следующем порядке:

• Отфильтруйте столбец «Тип» по параметрам запроса. Все, что заканчивается на query param, а также sig, sessionid и access_token. Это находка 1, и она стоит на первом месте, поскольку учетные данные в URL-адресе уже записаны на диск в большем количестве систем, чем вы можете перечислить.
• Отсортируйте по замаскированному хвосту и найдите одинаковые хвосты у разных клиентов. Это находка 2. Каждая группа из двух или более элементов — это учетные данные, которые невозможно заменить без планирования простоя.
• Найдите пустого клиента. Это находка 3, и ее следует эскалировать, а не расследовать, поскольку в представлении сети больше не осталось нитей, за которые можно дергать.
• Посчитайте сторонние пункты назначения, MCP или иные. Это находка 4. Каждый из них — это то, чему вы выдали постоянное разрешение действовать от вашего имени, вероятно, за один присест, который вы уже не помните.

Качество извлечения данных оказалось переменной безопасности

Контроль трафика и изъятие секрета из рук агента делают существующие вызовы более безопасными. Последний пункт касается того, что некоторых из этих вызовов вообще не нужно совершать, и именно на это я случайно наткнулся. Я начинал этот проект совсем с другой целью, но отчет Passport предоставил мне переменную, измерять которую я не планировал.

Тестовый стенд сравнивает запуски агента с использованием Context Graph API и без него. Этот API отвечает на вопросы о зависимостях между репозиториями на основе индексированного графа, а не заставляет модель искать ответ самостоятельно. Что касается токенов и задержки, результат оказался очевидным: количество токенов в промптах сократилось на 48%, а стоимость — на 47% для обеих протестированных моделей.

Цифра, которая имеет значение здесь, — другая. Запрос к графу в первую очередь сократил количество вызовов инструментов с 70 до 45 на промпт, а количество шагов агента — с 32 до 20.

Сокращение количества вызовов инструментов не равносильно сокращению воздействия учетных данных, и здесь стоит быть осторожным в различиях. Множество вызовов инструментов — это чтение локальных файлов, которые вообще не затрагивают сеть. Что еще важнее, объем работы, действительно требуемый задачей, не уменьшается. Для получения того же ответа по-прежнему нужны те же аутентифицированные конечные точки, поэтому вызовы, выполняющие работу, сократить невозможно.

Здесь сократился объем поиска, а поиск — это именно то место, откуда появлялись дочерние процессы с учетными данными. git, npm, curl, MCP-серверы и облачные CLI — все они появляются в моем отчете, потому что агент обращался к ним в поисках ответа о зависимости, который он не мог найти самостоятельно.

Поэтому честная версия этого утверждения звучит узко: «меньше вызовов — меньше секретов». На двадцать пять вызовов инструментов меньше на один промпт — это не сократило количество моих учетных данных на треть, и я бы не ожидал этого при выполнении другой задачи. Было удалено лишь то множество вызовов, которые существовали только потому, что агент не знал, где искать, и вместо них добавился один аутентифицированный пункт назначения: сам граф. Окупится ли это в вашу пользу, зависит от того, к чему агенту в противном случае пришлось бы прикасаться, чтобы ответить на тот же вопрос медленным путем.

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

Прежде чем выпускать в продакшен

Ограничивайте область действия по объектам, а не по учетным записям, когда URL-адрес должен содержать учетные данные. URL с предварительной подписью хороши, когда подпись охватывает один объект и один метод. Они становятся уязвимостью, когда наделяют полномочиями уровня учетной записи.

Ресурсы