5 октября 2026 г.

Краткий обзор

Компания: Postman
Вариант использования: Безопасный доступ к производственной среде для разработки AI-агентов
Масштаб: 70 агентов, работающих в функциях выхода на рынок (GTM), разработки продуктов и инженерии
Продукт: Passport
Системы: 33 SaaS, 9 внутренних
Инструменты для программирования: Claude Code, Codex, Postman
Внедрение: 5 дней

Предыстория

Система agentOS компании Postman (работающая на Astropods) объединяет 70 агентов, которые обеспечивают работу их команд по выходу на рынок, разработке продуктов и инженерии. Разработчики, которые создают и поддерживают их, используют своих агентов для программирования в Claude Code, Codex, Cursor, Postman и нуждаются в доступе к 42 системам (33 SaaS-провайдера и 9 внутренних собственных систем).

Распространение учетных данных. Каждый доступ к системе осуществлялся по одной и той же схеме: запрос доступа у отдела информационной безопасности, получение ключа, копирование его в локальный файл .env, интеграция в агента. Внутренний аудит безопасности выявил 278 API-ключей на ноутбуках разработчиков, в конфигурациях CI и манифестах развертывания.

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

Агенты для программирования, работающие на одной машине. Каждый разработчик запускает Claude Code, Cursor или Codex в файловой системе, где хранятся эти ключи. Каждый новый агент добавлял еще один ключ и еще один файл .env, поэтому риск утечки рос вместе с парком агентов.

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

Что было нужно Postman

Учетные данные остаются внутри периметра нулевого доверия (zero-trust), контролируемого отделом безопасности.
Область действия устанавливается для каждого ресурса, а не для каждого поставщика. Она определяется заранее и наследуется каждым разработчиком, который вносит вклад в агента(ов).
Каждый доступ к API атрибутируется разработчикам, агенту и процессу выполнения.
Доступ разработчиков к API ограничен только временем, когда они активно создают или дорабатывают агента.
Решение работает там, где работают разработчики – в терминале, IDE, инструментах для программирования и CI.

Безопасность определяет границы заранее, а система обеспечивает их соблюдение при каждом вызове.

Решение: Passport

Команда продукта Postman создала Passport после того, как увидела, что этот шаблон повторяется у многих клиентов, работающих с API-ключами.

Разработчики не хранят никаких реальных ключей. Каждое значение в файле .env является ссылкой, привязанной к разработчику, который ее запросил. Passport разрешает ее во время вызова. Легковесный демон Passport на ноутбуке разработчика перенаправляет вызовы на прокси-сервер Passport. Демон развертывается удаленно и управляется через Jamf нашей командой безопасности.

Реальные учетные данные остаются в хранилищах. Прокси-сервер Passport работает внутри нашей корпоративной сети. Он проверяет личность и область действия, считывает реальный секрет из хранилища в памяти и выполняет обычный API-вызов к поставщику. Это единственная часть системы, которая имеет доступ к реальным учетным данным.

Отдел безопасности управляет каталогом ресурсов. Безопасность ограничила 42 системы (поставщиков и внутренних) до 104 утвержденных конечных точек в этих системах. Прокси-сервер соблюдает ограничения в каталоге, поэтому ключ поставщика, который потенциально позволяет удаление ресурсов, обслуживает только конечную точку для чтения, необходимую агенту. Каждый разработчик, запрашивающий доступ через систему Passport, получает одинаковую предварительно утвержденную область действия.

Каждый API-вызов атрибутируется, и каждое предоставление доступа имеет дату окончания. Passport регистрирует каждый запрос с привязкой к разработчику, агенту и запуску, включая вызовы по общим сервисным ключам. Разработчики запрашивают доступ с указанием причины и длительности. Отдел безопасности одобряет запросы из своей очереди администрирования, а также может отозвать доступ разработчика ко всему парку агентов одним кликом.

Внедрение за 5 дней

Дни 1 и 2. Отдел безопасности и команда разработки агентов совместно работали над созданием каталога: 42 системы (поставщики + внутренние), 104 утвержденные конечные точки.
Дни 3 и 4. Каждое значение в каждом файле .env стало ссылкой Passport.
День 5. Старые ключи были обновлены отделом безопасности у каждого поставщика, что привело к выводу из обращения 278 копий.

После того как учетные данные в .env были заменены ссылками Passport, разработчики продолжили использовать свои привычные инструменты для программирования. Отдел безопасности развернул демон Passport по всей организации через Jamf и управляет доступом через Passport.

Результаты

Для безопасности

0 производственных учетных данных на машинах разработчиков
278 ключей выведено из обращения
Каждый API-вызов атрибутирован разработчику, агенту и запуску
Отзыв доступа для любого разработчика в один клик

Для инженерии

Новая производственная система добавляется в каталог за 3 дня вместо 15.
Новые разработчики могут начать вносить вклад в любой парк агентов за 2 часа
Более довольные разработчики, которые могут создавать новых и улучшать существующих агентов.

С момента внедрения парк агентов вырос с 32 до 70, интегрировавшись в 42 системы (в начале было 27). Риск утечки учетных данных остается на нулевом уровне.

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

Сэм Чехаб, руководитель отдела информационной безопасности, Postman