24 сентября 2026 г.
Для каждого вызова 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.
Вот резюме, с которого открылась панель управления:
[СКРИНШОТ: Сводная таблица панели управления Passport и результаты]
Появилось восемь классов секретов: токены носителя (bearer tokens), заголовки apikey, заголовки x-api-key, учетные данные базовой аутентификации (Basic auth), учетные данные авторизации AWS, JWT, идентификаторы сессий в параметрах запроса и параметры запроса подписи.
Почему ваш инвентарь учетных данных неполный
Учетные данные обеспечивают доступ к ресурсу для программы или человека. Ваш ноутбук полон ими. Некоторые лежат в файле, некоторые в связке ключей операционной системы, некоторые в конфигурации инструмента, который вы установили два года назад и забыли о нем.
На протяжении большей части истории программного обеспечения вопрос безопасности заключался в том, где они хранятся, и на этот вопрос был удовлетворительный ответ. Вы кладете ключ куда-то, поэтому вы знаете, где он. Инструменты сканирования выросли из этого предположения: направьте их на свой код, и они скажут вам, лежит ли ключ там, где его быть не должно.
Агентная разработка нарушает это предположение специфическим образом, и стоит быть точным в отношении механизма, а не просто махать рукой со словами «ИИ — это страшно».
Когда вы даете агенту задачу, он сам решает, как ее выполнить во время работы. Он выбирает инструменты. Эти инструменты запускают другие программы. Эти программы открывают сетевые соединения. Каждый уровень передает свое окружение следующему, и учетные данные по умолчанию перемещаются вместе с этим окружением:
Никто не записывал эту цепочку. Она собралась сама во время выполнения, поэтому вопрос хранения перестал быть достаточным. Вы можете проверить каждый файл, которым владеете, и все равно не иметь представления, какие программы использовали какие ключи для общения с кем.
Четыре вывода в моем отчете делают это конкретным. Я пройдусь по каждому с реальными данными, потому что совокупные показатели — это заголовок, а детали — это урок.
Из всего, что есть в отчете, это четыре вещи, которые я бы исправил в первую очередь.
Проще говоря: программа, общающаяся с сервером, может нести свой пароль в одном из двух мест. Он может быть в заголовке, который является метаданными доставки и который по большей части нигде не записывается, или он может быть в самом веб-адресе, который записывается почти везде. Четыре моих запроса использовали второй вариант.
Посмотрите на первые две строки. Тот же хост, тот же клиент, та же секунда: 17:02:58. Один запрос нес как JWT, так и параметр подписи в строке запроса. Это URL-адрес предварительно подписанного ресурса, и функционально это возможность носителя (bearer capability) с меткой времени. Любой, у кого есть полный URL, имеет доступ.
RFC 6750, раздел 2.3, необычно прямолинеен в отношении того, почему это проблема. Токены носителя «НЕ ДОЛЖНЫ передаваться в URL-адресах страниц» из-за «высокой вероятности того, что URL-адрес, содержащий токен доступа, будет записан в логи». Спецификация перечисляет историю браузера, логи веб-сервера и заголовки referer как пути утечки. Третий путь задокументирован на MDN: если сайт не устанавливает строгую политику referer, полный URL-адрес, включая строку запроса, передается на следующий хост, к которому обращается браузер.
Ничего из этого не является новостью. Новым является то, кто именно формирует эти URL-адреса сейчас. Я не писал вызов codex_sdk_ts и не писал команду curl, которая извлекала релизный актив. Это сделал агент, следуя цепочке перенаправлений, которую я даже не видел.
Так почему же заголовок безопаснее, чем URL, если оба передаются через одно и то же зашифрованное соединение на один и тот же сервер? Ответ не в шифровании. Ответ в том, что записывается на другом конце.
Отправьте один и тот же секрет дважды, по одному разу в каждом направлении, и посмотрите на необработанный запрос:
Оба секрета доходят. Разница в том, что первая строка — это строка HTTP-запроса, а строка запроса — это та часть, которую серверы сохраняют. Common Log Format, который по умолчанию записывают Apache, nginx и большинство обратных прокси-серверов, фиксирует строку запроса, статус и количество байтов. В строках формата Apache это поле %r; в стандартном комбинированном формате nginx это $request. Ни один из них не записывает Authorization.
Таким образом, секрет в строке запроса сохраняется в открытом виде каждым сервером, прокси, балансировщиком нагрузки и CDN на пути следования, плюс всем, что отправляет эти логи вашему поставщику средств наблюдаемости. Идентичный секрет в заголовке отбрасывается всеми ими. Тот же транспорт, то же доверие, но совершенно разное хранение.
И это касается вас ближе, чем кажется. Ваша собственная оболочка (shell) хранит копию каждой команды, которую вы выполняете, так что поищите в ней:
Все, что найдется — это учетные данные, лежащие в текстовом файле на вашем диске в месте, за которым не следит ни один сканер секретов, и они будут там лежать и через полгода.
Выводы: «Краткосрочность» — это утверждение, а не свойство: предварительно подписанные URL часто имеют срок действия семь дней, а семь дней в 30-дневном логе — это целая неделя уязвимости. Поэтому я проверяю фактическое число, а не доверяю словам, и проверяю, чтобы значение было ограничено одним объектом и одной операцией, а не всей моей учетной записью.
Находка 2: один ключ, две программы и отсутствие возможности отключить одну из них
Две программы, которые не имели ничего общего друг с другом, проходили аутентификацию с одним и тем же паролем.
Посмотрите на последний столбец. sk-ant-••••4AAA — это один и тот же маскированный хвост во всех трех случаях, значит, это один и тот же ключ. Теперь посмотрите на столбец клиента: его отправили две совершенно разные программы. Bun/1.4.0 — это среда выполнения JavaScript, выполняющая ту же роль, что и Node.js, и что-то в моей обвязке использовало ее для прямого вызова API Anthropic. claude-code — это агент кодирования. Ни один из них не знал о существовании другого.
Стоит остановиться на том, почему я вообще могу это видеть. Passport показывает несколько символов каждого секрета, чего достаточно, чтобы доказать, что два запроса несли одни и те же учетные данные, без превращения самого отчета в список моих ключей в открытом виде. Этот маскированный хвост здесь действительно работает: это единственная причина, по которой я могу отличить эти три строки от трех несвязанных ключей.
Сам по себе это не инцидент. Ничего не было украдено и ничего не было использовано не по назначению. Это превращается в проблему в тот момент, когда я хочу предпринять действия в отношении одной из этих программ, потому что учетные данные — это единственное, на что я могу воздействовать.
Подумайте, какие действия на самом деле доступны. Отключение доступа, замена значения, ограничение того, к чему он может получить доступ: каждое из них — это операция с ключом, а не с программой. Нет кнопки «перестать доверять этому конкретному процессу». Поэтому, когда один ключ обслуживает две программы, самое малое действие, доступное мне, затрагивает обе.
Скажем, я решил, что процесс Bun подозрителен, а агент в порядке. Я хочу отключить первый и оставить второй работающим. Я не могу. Это не две учетные записи с двумя паролями. Это две программы, владеющие одним паролем, и для API Anthropic они являются одним и тем же вызывающим абонентом.
Остается только один рычаг: заменить ключ везде, что и означает ротацию учетных данных. Его отзыв останавливает обе программы в один и тот же момент, и ни одна из них не запустится снова, пока я не найду и не обновлю каждую копию на машине. Исправление программы, которая меня беспокоит, требует поломки программы, которая была в порядке.
Реагирование на это стоит простоя, поэтому такие находки и остаются без внимания. «Мы ротируем его после релиза» — вот как подозрительный ключ остается активным еще квартал.
Есть очевидный выход из этой ситуации. Если бы API Anthropic мог видеть, что один запрос пришел от моего агента, а другой — от скрипта Bun, он мог бы отклонить один и продолжать обслуживать другой, и я получил бы именно тот контроль над программами, которого не хватало в этом разделе.
Есть даже поле, которое выглядит созданным для этой работы. Каждый HTTP-запрос несет в себе user agent — короткую строку, в которой клиент объявляет, какое программное обеспечение он использует. Именно она заполнила столбец Client в моем отчете, и это единственная причина, по которой я вообще смог отличить эти три строки.
Вот чего на самом деле стоит эта строка. Флаг -H говорит curl установить заголовок на все, что я захочу, поэтому я отправлю два запроса, каждый из которых утверждает, что является другой программой:
Оба они были обычными curl. Ни Bun, ни агент в это время не были близки к моей машине. Клиент выбирает значение, сервер записывает его, и никто нигде его не проверяет. User agent — это заявление, а не учетные данные, что делает его действительно полезным для статистики и бесполезным для контроля доступа. Поэтому столбец Client в моем отчете — это реальная подсказка о том, что произошло, и это не то, на чем может безопасно основываться какое-либо решение по безопасности.
Остается сам ключ, а ключ несет еще меньше информации. sk-ant-••••4AAA — это одна непрозрачная строка, которая ничего не говорит о том, кто ее предъявляет. Для API тот, кто отправляет эту строку, и есть учетная запись. Мой агент, мой скрипт Bun и любой, кто скопировал значение из моего окружения, — это один и тот же вызывающий абонент, и в запросе нет поля, которое могло бы их разделить. Владение — это вся идентичность, поэтому нет ничего, что можно было бы отключить для каждой программы отдельно. Это не недостаток API Anthropic. Так работают ключи API везде.
Теперь сравните строки GitHub в том же отчете:
Два разных хвоста, значит, два разных токена для того, что номинально является одним и тем же инструментом. Поток устройства GitHub OAuth выдает учетные данные для каждого клиента, вместо того чтобы давать каждому клиенту один общий ключ. Каждый из них можно отключить отдельно, и уничтожение одного оставляет другой работающим. Это именно тот контроль, который я хотел три абзаца назад, и я получил его по умолчанию, а не благодаря хитрости.
Последняя причина не строить политику на строке клиента. В моем отчете claude-code появляется под шестью различными отпечатками: версии 2.1.221, 2.1.223 и 2.1.231, каждая в варианте (cli) и в обычном варианте, плюс один (sdk-cli). Один инструмент, шесть личностей, меняющихся по собственному графику релизов. Любой список разрешений, написанный на основе этих строк, устарел бы в течение месяца, и ни один из этих сдвигов не потребовал ни единого изменения в моем коде.
Выводы: я перестал считать секреты и начал считать потребителей на каждый секрет. Один ключ, используемый одной программой — это ключ, который я могу ротировать во вторник днем. Тот же ключ, используемый четырьмя программами — это простой, который я должен планировать, что на практике означает, что он никогда не ротируется вовсе. Это число, потребители на учетные данные, стоит того, чтобы за ним следить, и это число, которое привязанные к владельцу ссылки Passport предназначены удерживать на уровне единицы.
Найдено 3: учетные данные, которым я не могу приписать ничего
Эта строка появилась дважды, через четыре недели:
Обратите внимание на столбец Client. Он пуст. В каждой другой строке моего отчёта указана программа, которая отправила запрос. Эти две строки ничего не называют.
Простыми словами: что‑то на этом компьютере использовало пароль для общения с Microsoft и не подписало свой идентификатор. Я знаю, что вызов произошёл. Я не знаю, что его инициировало.
Я всё ещё не знаю, что это было. Вероятно, это редактор или SDK с включённой телеметрией. Важно: у меня есть аутбоу́нд‑запрос с учётными данными, пункт назначения, временная метка, и я не могу приписать его процессу, исходя только из сетевого вида. Если бы этот ключ был мой, а не ключ поставщика, я бы не знал, какой из примерно 40 процессов, работающих на этом ноутбуке, отключить.
Здесь наблюдение во время выполнения оправдывает себя и показывает свои ограничения. Passport сообщил мне, что запрос произошёл, что составляет 90 % от ценности, потому что иначе я бы не знал о нём. Приписка за пределами user‑agent требует корреляции на уровне процессов, поэтому сопоставьте вывод с lsof или eslogger на macOS, если нужно закрыть цикл.
Выводы: не приписываемые учетные данные хуже, чем известные плохие, потому что нечего делать. Я теперь рассматриваю пустой Client как собственный класс тяжести, а не как пробел в данных, и проверяю его до всего остального, поскольку каждый другой вывод хотя бы указывает, куда идти. Это также самый чёткий аргумент в моём отчёте о том, что программа не может отказать в предоставлении.
Найдено 4: мой агент передаёт учётные данные третьим сторонам
Семь из моих 33 выводов были отправлены в конечные точки MCP:
Краткое объяснение, если MCP вам ново. Model Context Protocol – стандартный способ подключить агент к внешней службе, чтобы он мог читать и действовать там. Я подключил два сервиса, Vercel и Atlassian, скопировав токен в файл конфигурации один раз, несколько месяцев назад. С тех пор мой агент сам решает, когда их вызывать.
Проблема
Сервер MCP – посредник. Мой агент не говорит напрямую с Atlassian; он говорит с mcp.atlassian.com, который от моего имени общается с Atlassian. Это значит, что сервер получает учётные данные, которые могут действовать как я, и из этого следуют две вещи.
Первая – область действия. Что бы токен ни мог делать, сервер может делать то же самое, пока токен жив. Я никогда не сидел и не решал, какие права должны быть. Я просто вставил токен и продолжил.
Вторая – более тонкая и имеет название. Если сервер MCP берёт токен, который мой агент отправил, и пересылает его без изменений реальной службе, реальная служба видит действительный токен и не может понять, авторизовал ли я конкретное действие или посредник просто воспроизвел мой токен по своим причинам. Спецификация называет это «token passthrough» и явно запрещает, потому что это создаёт «запутанного заместителя»: надёжный компонент действует по инструкциям, которые он не должен был выполнять, используя полномочия, не принадлежащие ему.
Третья вещь в этих строках должна быть знакомой. Две из них помещают sessionid в параметр запроса, что повторяет Найдено 1, но в трафике, который я не писал, к сервису, который я не управляю.
Решение
Спецификация ясно указывает, чья задача это. Серверы MCP «ДОЛЖНЫ проверять, что токены, представленные им, были специально выпущены для их использования». Правильно построенный сервер проверяет, что токен выпущен для него, отказывает в любом другом, и получает собственные downstream‑учётные данные, а не воспроизводит ваши.
Это обязанность сервера, а не ваша, что оставляет вам две вещи, которые вы действительно можете контролировать. Дайте каждому серверу MCP свои собственные учётные данные, никогда не используйте общий токен с другим потребителем, чтобы не попасть в ловушку отзыва Найдено 2. И рассматривайте каждый сервер как сервисный аккаунт, который вы вводите: какой токен он получает, к чему он привязан, и что он делает с ним downstream. Страница лучших практик безопасности MCP – это чек‑лист.
Где появляется Passport
Два места, и они соответствуют двум половинам продукта.
Половина видимости – это причина, по которой я знаю всё это. Я действительно забыл, что эти серверы были настроены. Ни один файл на моём компьютере не сообщил бы мне, что мой агент отправлял bearer‑токены двум сторонним конечным точкам в прошлом месяце, потому что факт существует только в трафике. Семь выводов, из конфигурации, которую я настроил один раз и никогда не пересмотрел.
Половина архитектуры – более интересная, потому что делает проблему passthrough структурно невозможной, а не просит третью сторону быть осторожной. Если мой агент хранит ссылку на учётные данные, а не ключ, то то, что он может передать серверу MCP, не является повторно используемым секретом. Ссылка привязана к своему владельцу, поэтому посредник не может воспроизвести её как меня. Реальные учётные данные разрешаются внутри Secure Access Proxy в моей сети и никогда не достигают третьей стороны. Ничего не передаётся.
Выводы: каждый сервер MCP, который вы настраиваете, – это третья сторона, которой вы дали полномочия действовать как вы, и счёт только растёт. Я теперь проверяю их по тому же графику, что и сервисные аккаунты, и никогда не указываю один сервер на учётные данные, которые использует и другая программа. Глубокий исправление – не доверять посредникам более тщательно, а не давать им ничего, что можно воспроизвести.
Настройка Passport и чтение собственного трафика
Всё выше произошло на одном ноутбуке, моём. Ваши хосты будут другими, ваши клиенты – другими, и ваш худший вывод, вероятно, тот, который у меня нет. Это причина, почему стоит выполнять это самостоятельно, а не брать мои цифры: я могу сказать, что искать, но не могу сказать, что вы найдёте.
Итак, это единственное, что я действительно попрошу вас сделать. Это сейчас стоит одной команды и недели игнорирования после, и в конце у вас будет собственная версия отчёта, на котором построено всё выше.
Community Edition Passport CLI работает полностью локально, маскирует секретные значения и не отправляет трафик никуда. Установите его из npm:
Затем запустите инспектор. Passport Lens находится в пути запроса и захватывает вызовы от агентов и инструментов разработчика без каких‑либо изменений в этих клиентах:
Теперь займитесь своей реальной работой в течение недели. Не внедряйте ничего, не регистрируйте учётные данные, не перестраивайте свой проект вокруг этого. Вся ценность этого упражнения в том, что вы узнаете, что делает ваша среда, когда вы не наблюдаете за ней.
Несколько флагов, которые стоит знать:
Панель управления группирует выводы по пункту назначения, клиенту и типу обнаружения, с таблицей Detected at / Destination / Client / Type / Masked secret под ним. Экспорт отчёта в правом верхнем углу даёт вам артефакт, на котором построен этот пост. Полные детали в документации Passport CLI.
Когда вы читаете свой собственный отчёт, проходите его в этом порядке:
- Отфильтруйте столбец Type по параметрам запроса. Любое, что заканчивается query param, плюс sig, sessionid и access_token. Это Найдено 1, и оно первое, потому что учётные данные в URL уже записаны на диск в более системах, чем вы можете перечислить.
- Выполните сортировку по маскированному хвосту и найдите одинаковые хвосты для разных клиентов. Это «Находка 2». Каждая группа из двух и более элементов — это учетные данные, которые нельзя заменить без планирования простоя.
- Найдите пустой клиент. Это «Находка 3», и ее следует эскалировать, а не расследовать, поскольку в представлении сети больше не за что зацепиться.
- Подсчитайте свои сторонние пункты назначения, MCP или другие. Это «Находка 4». Каждый из них — это то, чему вы дали постоянное разрешение действовать от вашего имени, вероятно, за один раз, о чем вы уже не помните.
Качество поиска оказалось переменной безопасности
Отслеживание трафика и изъятие секрета из рук агента делают существующие вызовы более безопасными. Последний пункт касается того, чтобы вообще не совершать некоторые из этих вызовов, и именно на это я наткнулся случайно. Я начал этот проект, чтобы измерить совсем другое, но отчет Passport предоставил мне переменную, которую я не планировал измерять.
Инструментарий сравнивает запуски агентов с использованием Context Graph API и без него, что позволяет отвечать на вопросы о кросс-репозиторных зависимостях из индексированного графа, вместо того чтобы заставлять модель искать ответ. Что касается токенов и задержки, результат был очевиден: количество токенов в промптах сократилось на 48%, а затраты — на 47% в обеих протестированных моделях.
Число, которое здесь имеет значение, другое. Запрос к графу в первую очередь сократил количество вызовов инструментов с 70 до 45 на промпт, а количество шагов агента — с 32 до 20.
Сокращение количества вызовов инструментов — это не то же самое, что сокращение воздействия учетных данных, и стоит быть осторожным с этой разницей. Многие вызовы инструментов — это локальное чтение файлов, которое вообще не затрагивает сеть. Что еще важнее, объем работы, который на самом деле требует задача, не уменьшается. Для получения того же ответа по-прежнему нужны те же аутентифицированные конечные точки, поэтому вызовы, выполняющие эту работу, являются нередуцируемыми.
Здесь сократился поиск, а поиск — это то, откуда появлялись подпроцессы с учетными данными. git, npm, curl, MCP-серверы и облачные CLI — все они появляются в моем отчете, потому что агент обращался к ним в поисках ответа о зависимости, который не мог найти.
Поэтому честная версия этого утверждения более узкая, чем «меньше вызовов, меньше секретов». На двадцать пять вызовов инструментов меньше на промпт не сократило количество моих учетных данных на треть, и я бы не ожидал этого в другой задаче. Что оно удалило, так это класс вызовов, которые существовали только потому, что агент не знал, где искать, и вместо них добавило одно аутентифицированное место назначения: сам граф. Будет ли это в вашу пользу, зависит от того, к чему агент в противном случае должен был бы обратиться, чтобы ответить на тот же вопрос медленным способом.
В этой задаче это определенно сработало, и именно эта часть, как мне кажется, поддается обобщению: агент, который начинает со списка кандидатов вместо поиска по нескольким сотням репозиториев, порождает меньше подпроцессов и обращается к меньшему количеству хостов для выполнения той же работы. Качество поиска — это переменная безопасности, а не только затрат, чего я не ожидал в начале.
Перед выпуском
Не рассматривайте отчет как инцидент. Находка означает, что был зафиксирован трафик, содержащий учетные данные. Это не является доказательством компрометации или несанкционированного раскрытия. Рассматривайте его как инвентаризацию вашего реального графа учетных данных, а затем проводите сортировку по степени серьезности.
Ресурсы
- Postman Passport: безопасный доступ к API для эры агентов
- Документация Passport CLI Community Edition