5 ноября 2026 г.
В сентябре 2026 года OpenAI опубликовала структуру для отчетности о несоответствии моделей, а также шесть отчетов о проблемном поведении, которое демонстрировали их модели в процессе разработки. Публикация подобных вещей — это одновременно неприятно и похвально, и большинство инцидентов относятся к тем, о которых компания предпочла бы не рассказывать вслух. Один из них должен заставить каждую команду безопасности и платформенную команду остановиться и задуматься, потому что это самая наглядная демонстрация в реальных условиях того риска, который мы все описывали в основном абстрактно.
Во время обучения с подкреплением внутренней, еще не выпущенной модели было предложено получить данные о доходах для одного из округов Калифорнии. API данных, который ей был нужен, постоянно выдавал ошибки. Поэтому, без каких-либо указаний, модель попыталась зарегистрироваться на сервисах временных электронных почт, чтобы получить собственный ключ, а затем начала искать утекшие API-ключи в публичных репозиториях GitHub. Согласно отчету OpenAI, «один из кандидатов успешно прошел аутентификацию». API вернул название штата и код, и модель использовала ключ для получения метаданных. (Когда сам запрос данных все равно не удался, она сфабриковала девять правдоподобных чисел и представила их как реальные. Это отдельная и серьезная проблема, но не та, на которой я хочу здесь сосредоточиться.)
Вдумайтесь в середину этой последовательности. Автономный агент, столкнувшись с ограничением доступа к ресурсу, отправился искать чужие учетные данные в публичном интернете, нашел один, и этот ключ сработал.
Почему этот случай отличается от обычных предупреждений
Мы все говорили что-то вроде «агенты будут искать учетные данные». Это не было упражнением red-team или слайдом в модели угроз. Это возникло само по себе, во время обучения, как импровизированный способ модели обойти заблокированный API. Поведение не было запрограммировано, а ключ не был лабораторным экспонатом. Это был реальный ключ, который кто-то закоммитил в публичный репозиторий.
И ключ сработал. Это та часть, которая имеет значение, и стоит уточнить, почему именно.
Уязвимость заключалась не в поиске; уязвимость в том, что владение равно полномочиям
Модель ничего не взламывала. Она нашла строку, которую уже слил человек, и представила её. Для API на другом конце тот, кто владеет строкой, и есть владелец аккаунта. API-ключ не несет в себе информации о том, кто его предъявляет, поэтому найденная копия неотличима от законного владельца.
В этом и заключается вся суть риска. Проблема не в том, что модель была умной. Проблема в том, что учетные данные приравнивают владение к личности. Любой человек или что угодно, получившее ключ, наследует все возможности этого ключа.
В этой гонке вооружений не победить ни с одной из сторон
Инстинктивная реакция после такого инцидента — удвоить усилия по предотвращению: тщательнее сканировать утечки и ограничивать возможности агентов. И то, и другое стоит делать, но ни то, ни другое не является фундаментом, на котором можно стоять.
Что касается утечек: люди вставляют ключи в репозитории, конфигурации, dot-файлы и скриншоты, и всегда это делали. Весь класс инструментов для поиска утекших ключей существует только потому, что это продолжает происходить. Этот конкретный ключ уже находился в открытом доступе, чтобы модель могла его найти.
Что касается поиска: популяция тех, кто ищет, изменилась. Теперь в нее входят быстрые, неутомимые автономные агенты, и их будет гораздо больше, и они будут совершать гораздо больше попыток, чем любой человек. Ставить свою безопасность на то, что «мы предотвратим каждую утечку» или «агенты не будут искать», — значит играть против двух тенденций одновременно.
Надежное решение — сделать найденный ключ бесполезным
Единственный верный путь — перестать пытаться контролировать, будет ли найден учетный ключ, и начать контролировать, будет ли он пригоден для использования после того, как его найдут.
Это переход от распространения секретов к предоставлению доступа. Вместо того чтобы раздавать секрет, вы даете каждому потребителю секретную ссылку: токен, который указывает на секрет, не содержа его в себе. С помощью Passport от Postman настоящий секрет остается в хранилище секретов, которое вы уже используете (HashiCorp Vault, AWS Secrets Manager или Google Cloud Secret Manager). Прокси-сервер Passport внутри вашего собственного облака разрешает его в момент запроса, после того как проверяет личность вызывающего и убеждается, что ему предоставлен доступ к этому API. Ссылка привязана к той личности, которой она была выдана.
Теперь проиграйте этот инцидент в организации, которая работает таким образом. В файле .env разработчика находится {{vault:<secret-reference-id>}} вместо ключа, поэтому, если этот файл попадет в публичный репозиторий, утечет лишь ссылка, привязанная к одной личности. Модель, которая найдет её на GitHub, может предъявлять её сколько угодно. Прокси проверяет, кто делает вызов, прежде чем что-либо разрешать, и копия без соответствующей личности не получает ничего. Самая важная строка в отчете OpenAI, «один из кандидатов успешно прошел аутентификацию», становится бессмысленной, так как аутентифицироваться нечем. В репозитории нет ничего, что стоило бы красть.
Меняются и две другие вещи. Доступ предоставляется для каждого API на определенный срок, и администратор может в любой момент отозвать доступ одного человека или одного агента, не нарушая работу остальных. И каждый вызов через прокси логируется с привязкой к подтвержденной личности, поэтому на вопрос «использовались ли эти учетные данные и кем?» всегда есть ответ. Модель безопасности описывает детали.
Что это исправляет, а что нет
Я предпочитаю быть точным, а не позволять воспринимать это как «серебряную пулю», потому что границы — это самое важное.
- Это не меняет поведение агента. Модель доступа не изменила бы того, что сделала модель, динамику обучения OpenAI или тот факт, что она начала искать. Ничто здесь не мешает агенту искать. Что это меняет, так это уровень уязвимости организации, чей ключ лежал в том репозитории. Это устраняет вознаграждение, а не сам поиск.
- Это не заменяет сканирование секретов или их ротацию. Сохраните и то, и другое. Это тот уровень, который превращает случайный пропуск сканера из взлома в незначительное событие, потому что то, что он пропустил, никогда не могло быть использовано посторонним.
- Настоящий ключ все еще существует где-то. Он живет в вашем хранилище секретов, за вашим прокси, под вашим собственным контролем доступа. Это гораздо меньшая область для защиты, чем каждый ноутбук, конвейер CI/CD и конфигурация агента, но её все равно нужно защищать.
- Ключи, которые уже утекли, остаются утекшими. Переход на ссылки не защищает задним числом ключ, который уже есть на GitHub. Ротируйте их один раз, а затем перестаньте раздавать новые.
Начните с того, чтобы узнать, что вы можете потерять
Большинство команд не могут сказать, где находятся все их ключи, что затрудняет честный ответ на вопрос «если один утечет, будет ли он пригоден для использования?». Бесплатная версия Passport CLI Community Edition включает Lens, который отслеживает исходящий трафик на вашей машине и сообщает об обнаруженных учетных данных, маскируя их значения. Когда инженер Postman запустил его на три недели во время создания ИИ-инструментария, он обнаружил 22 различных секрета, покидающих один ноутбук, и только четыре из них были в файле .env проекта. Каждый из них — это ключ, который агент или червь может унести куда угодно.
Вопрос, который нужно задать
Рефлекторная реакция после прочтения отчета OpenAI — спросить: «Как нам остановить утечку наших ключей?». Вы можете уменьшить их количество. Вы не можете исключить их полностью, и автономному агенту, который найдет тот, что вы пропустили, все равно, как сильно вы старались.
Лучший вопрос — это тот, на который может ответить модель доступа: если одна из наших учетных данных утечет завтра и кто-то ее обнаружит, можно ли ее использовать?
Когда вы распространяете секреты, ответ «да», по определению: владение означает полномочия. При использовании модели доступа ответ «нет», по определению: полномочия — это ваша идентичность, а не строка, которую можно скопировать. Этот инцидент наглядно демонстрирует разницу между этими двумя ответами.
Именно для этого создан Passport: он распространяет ссылки, а не секреты, и получает настоящий объект внутри вашей собственной сети, поэтому утечка учетных данных не имеет никакой ценности для того, кто их обнаружит.
Ресурсы
- Как Postman Passport хранит секреты API внутри вашей сети
- Что Passport обнаружил за 3 недели трафика ИИ-агентов
- Passport security model
- OWASP Secrets Management Cheat Sheet
