10 ноября 2026 г.
Письмо от Postman Secret Scanner приходит вечером. Токен носителя (bearer token) для patients-service хранится в виде открытого текста в сохраненном запросе внутри командного рабочего пространства. Вы не за рабочим столом, терминала поблизости нет, а этот токен может читать записи пациентов.
Я сымитировал этот инцидент в команде DevRel компании Postman в специальном тестовом рабочем пространстве с поддельным токеном, чтобы протестировать весь процесс от начала до конца. Мой агент кодинга с установленным плагином Postman выполнил каждый шаг — от поиска утечки до создания аудиторского следа, — при этом я ни разу не открыл приложение Postman. Больше всего меня заинтересовало, какую дверь агент использовал на каждом шаге: Postman CLI или MCP-сервер Postman. Ответ меняется несколько раз за один инцидент, и именно с чем это связано, и посвящен данный пост.
Как плагин Postman выбирает дверь
Плагин Postman предоставляет агентам кодинга набор возможностей для создания заглушек (моков), тестирования, мониторинга и документирования API. Он также предлагает два способа связи с Postman. В документации маршрутизация описана в двух предложениях. Плагин «отправляет запросы вашего агента в Postman CLI всякий раз, когда Postman CLI может их выполнить». Он «переключается на MCP-сервер Postman только для тех задач, которые Postman CLI не поддерживает».
На практике этот резервный вариант охватывает две ситуации:
- Postman CLI не может запуститься. Функция настройки плагина перенаправляет запросы на MCP-сервер только после того, как попытка установить Postman CLI терпит неудачу, например в размещенной сессии, где невозможно установить бинарные файлы.
- Postman CLI может запуститься, но в нем еще нет нужной команды. Secret Scanner, журналы аудита и роли коллекций в протестированных мной версиях попадают именно в эту категорию.
Установите плагин во все агенты кодинга, обнаруженные на вашем компьютере:
В документации по установке перечислены поддерживаемые агенты и их минимальные версии.
Плагин настраивает размещенный MCP-сервер за вас. Вот конфигурация, которую он регистрирует в Claude Code:
Путь /mcp выбирает полный набор инструментов сервера, который включает инструменты корпоративного уровня, необходимые для этого инцидента. Вы авторизуете его один раз с помощью OAuth: в Claude Code выполните слэш-команду /mcp и выберите сервер Postman. Если вы предпочитаете подключить сервер вручную, в руководстве по настройке MCP-сервера описаны удаленные, локальные варианты и варианты с использованием Docker.
Оповещение с моего телефона
Когда пришло оповещение, я был на улице, и при мне был только телефон. Ни ноутбука, ни терминала, только приложение Claude. Это исключает использование Postman CLI, поэтому первый раунд проходит через MCP-сервер. Я добавил тот же удаленный сервер (https://mcp.postman.com/mcp) в качестве пользовательского коннектора в Claude, поэтому он уже был доступен в мобильном приложении. Я спросил:
Промпт
Secret Scanner обнаружил токен в рабочем пространстве devrel-blog-mcp-test. Где он появляется и кто его туда поместил?
Агент связал три инструмента MCP: detectedSecretsQueries для получения списка активных находок в рабочем пространстве, getDetectedSecretsLocations для преобразования каждой находки в конкретное место и getTeamUser для преобразования идентификатора пользователя leakedBy в имя. Вот какой ответ он мне дал:
Агент
Две активные находки в devrel-blog-mcp-test, обе из одной и той же утечки.
Где: в заголовке Authorization запроса Get patient в коллекции Patients Service. Это единственное вхождение каждой находки, и запрос все еще существует.
Кто: Энтони Виар (Anthony Viard) сохранил запрос с токеном внутри.
Почему две находки: сканер сопоставил один и тот же заголовок дважды — один раз по префиксу Bearer и один раз по формату JSON Web Token токена. Обе проблемы необходимо решить после ротации, иначе оповещение останется открытым.
У меня есть только замаскированные превью и хеши SHA-256, а не сам токен, поэтому я не могу определить, какая служба его выдала. Запрос обращается к /api/patients/{{patient_id}}, поэтому учетные данные patients-service — это то, что нужно обновить.
Каждый факт в этом ответе получен из результатов работы инструментов. Сканер независимо распознал структуру JSON Web Token и префикс Bearer, а обнаружение произошло через 39 секунд после того, как я сохранил коллекцию. Ни одна из находок не содержит секрет целиком — только замаскированное превью и хеш, что важно, когда общение проходит через провайдера модели, которого вы не контролируете. Имя вернулось как мое, что является ожидаемым результатом для инсценированной утечки и тем, что я хотел бы узнать в первую очередь при реальной.
Под капотом каждый результат поиска представляет собой короткую запись. Это та самая запись, которая отвечает на вопросы «где» и «кто»:
Ничто в этом раунде не потребовало командной строки.
Радиус поражения, из терминала
С утечкой токена нельзя тянуть до утра, поэтому при первой же возможности я пересел за ноутбук. Чат подсказал мне, что именно утекло и где. Исправление ситуации означало обновление окружения и запуск тестов — работу, с которой отлично справляется Postman CLI. Я открыл Claude Code в папке проекта, связанной с рабочим пространством (postman workspace create сохраняет эту связь в .postman/resources.yaml), где плагин находит Postman CLI и использует его.
Прежде чем проводить ротацию, я хотел узнать, кто еще зависит от этой службы:
Промпт
Прежде чем мы заменим токен patients-service, что зависит от patients-service и как каждый потребитель аутентифицируется в нем?
Агент обратился к Postman Context Graph через Postman CLI:
Ответ пришел через 29 секунд. Сокращенно:
Цифра в 32 потребителя — это то, что делает ротацию пугающей. Граф также сузил круг поиска: утечка токена содержит область видимости (scope) patients.read, и erp-bridge-service является потребителем, который аутентифицируется именно с этой областью видимости. Это служба, конфигурацию которой необходимо изменить в том же временном окне, что и ротацию.
patients-service поступает из healthcare-org-app, симулированной платформы здравоохранения, которую команда DevRel поддерживает и загружает в свой граф контекста (Context Graph). В справочнике по CLI Context Graph описаны команды ask, status и ingest. Каждый запрос расходует квоту графа контекста вашей команды, поэтому один точный вопрос лучше пяти расплывчатых.
Ротация с помощью одного промпта
Я выдал новый токен для patients-service на стороне службы. Я не вставлял его в чат, файл или переменную окружения. Всё остальное я поручил агенту в одном промпте:
Промпт
Я выпустил новый токен patients-service. Удалите захардкоженный заголовок из коллекции Patients Service, сохраните новый токен как секрет в хранилище для общего окружения Patients Service (значение я введу сам), убедитесь, что запрос работает, и сделайте коллекцию доступной только для чтения для всей команды, пока мы наводим порядок. Не закрывайте находки Secret Scanner, пока я не подтвержу, что старый токен отозван.
Функции плагина превратили это в шесть шагов и выбрали дверь для каждого из них. На одном из этапов потребовался я: агент выполнил команду postman secret create, которая открыла одноразовую форму в моем браузере с кодом соответствия (fuzzy-orchid-42), чтобы я мог убедиться, что она исходит именно от этой команды. Я вставил туда токен. Вот сводка, которую агент выдал мне после этого:
Агент
Ротация завершена. Находки все еще открыты, ждут вас.
Я прочитал роли коллекции перед их изменением и сохранил вашу роль редактора вместе с ролью читателя команды. Этот вызов заменяет весь набор ролей, поэтому исключение вас лишило бы вас доступа.
Столбец «Как» демонстрирует правило маршрутизации плагина в действии. Postman CLI редактирует запросы в локальных файлах коллекций, но эта коллекция существует только в облачном рабочем пространстве, поэтому изменение заглавия прошло через сервер MCP. Секрет, ссылка на переменную и запуск прошли через Postman CLI, так как у него есть эти команды и была доступна оболочка. Для ролей коллекции нет команды Postman CLI, поэтому этот шаг вернулся к серверу MCP. Я никогда не говорил агенту, какой инструмент использовать.
Шаг хранилища — это часть, которую я бы скопировал в любую ротацию. Токен попал из моего буфера обмена в Postman Shared Vault минуя контекст агента, стенограмму чата, историю моей оболочки или значение среды в виде обычного текста. Последнее имеет большее значение, чем кажется: Secret Scanner проверяет общие значения переменных, поэтому сохранение нового токена в качестве обычного значения могло бы привести к новому предупреждению. С ссылкой на хранилище сканер не обнаружил ничего нового. Агент выполнил каждый шаг, кроме работы с самим секретом.
Утверждения (assertions) для запуска хранятся в коллекции, поэтому агент их тоже не писал. В моем тестовом рабочем пространстве Postman Echo заменяет службу пациентов (patients-service) и возвращает полученные им заголовки, поэтому тест проверяет именно то, что было отправлено:
В случае с реальной службой проверка, имеющая наибольшее значение, заключается в том, что старый токен получает статус 401 Unauthorized, а новый — 200.
Закрыть оповещение
Как только старый токен был отозван на стороне службы, я сказал агенту:
Промпт
Старый токен отозван. Закройте обнаруженные уязвимости.
Агент ответил:
Агент
Обе уязвимости помечены как отозванные.
- Токен Bearer: отозван
- JSON Web Token: отозван
Один из двух вызовов завершился тайм-аутом с моей стороны, поэтому я перепроверил результаты перед повторной попыткой. Оба уже показывали статус «Отозван», поэтому я не стал отправлять изменение снова.
Этот последний абзац описывает поведение, которого я жду от агента при любой операции записи. Инструмент updateDetectedSecretResolutions сервера MCP также предписывает агентам никогда не помечать проблему как «Отозванную», пока ключ фактически не будет заменен, поэтому я оставил этот шаг за своей собственным подтверждением. Устраненные проблемы исчезают из результатов Secret Scanner по умолчанию, поэтому агент проверил их с помощью запроса, который включает устраненные проблемы.
Бумажный след
Журналы аудита не регистрируют изменения коллекций или среды. Они фиксируют события администрирования команды: ключи API, участников, роли, единый вход (SSO) и жизненный цикл результатов Secret Scanner. Это делает их подходящим местом для закрытия инцидента:
Промпт
Покажите мне журнал аудита для этого инцидента.
Агент запросил журналы аудита и обобщил их:
Агент
События Secret Scanner в devrel-blog-mcp-test, 21 октября (UTC)
Две записи об отзыве содержат пользовательский агент postman-claude-code-plugin/2.0.1/postman-api-mcp-server/1.8.0 (набор инструментов: полный).
Этот пользовательский агент — моя любимая деталь во всем инциденте. Журнал аудита фиксирует, что изменение поступило через плагин Postman, через сервер MCP с полным набором инструментов. Когда через шесть недель кто-то спросит, кто закрыл это оповещение и как, ответ содержится в журнале: я, через своего агента.
Будьте осторожны: для журналов аудита требуется роль администратора или суперадминистратора. До того, как у меня появились права администратора, этот же запрос возвращал ответ «У вас нет прав на просмотр журналов аудита команды». Агент может видеть только то, что видит ваша учетная запись.
Попробуйте самостоятельно
Вам нужен тарифный план Postman Enterprise для использования Secret Scanner и журналов аудита. Для сканирования внутренних рабочих пространств также требуется надстройка Advanced Security Administration. Для Context Graph необходима команда с загруженными источниками.
- Установите плагин с помощью команды npx @postman/postman-plugin install.
- Создайте командное рабочее пространство для теста. Сохраняйте его видимым для команды, а не публичным: в публичных рабочих пространствах Secret Scanner автоматически заменяет обнаруженные секреты, что портит весь эксперимент.
- Сначала предупредите администраторов вашей команды. При обнаружении отправляется электронное письмо администраторам команды и администраторам рабочего пространства.
- Вставьте образец токена в заголовок сохраненного запроса, дождидесь оповещения, затем передайте инцидент своему агенту и понаблюдайте, какую дверь он выберет на каждом шаге.
Затем попросите о чем-то, чего Postman CLI пока не поддерживает, например, о чтении вашего каталога API или журналов аудита, и посмотрите, переключится ли ваш агент на сервер MCP самостоятельно или ему потребуется подсказка.
Что мне нравится в этой настройке, так это то, что правило маршрутизации устроено предельно просто и логично. Postman CLI стоит на первом месте, так как он дешевле и проще в написании скриптов. Сервер MCP подхватывает то, что Postman CLI не может запустить или еще не поддерживает. Во время инцидента это означает меньше решений для меня, а агент выбирает правильный инструмент без дополнительных просьб.
Ресурсы
- Обзор плагина Postman
- Установка плагина Postman
- Обзор сервера Postman MCP
- Настройка сервера Postman MCP
- Обзор Postman Secret Scanner
- О Postman Context Graph
- Команды Context Graph в Postman CLI
- Роли и разрешения
- Лента активности рабочего пространства
- Журналы аудита
- postman-mcp-server на GitHub
- healthcare-org-app на GitHub
- Протокол контекста модели (Model Context Protocol)
