OpenAI теперь позволяет создавать API-ключи с областью видимости для каждого service account — что должен знать каждый оператор нескольких проектов

Управление API-учётными данными в многокомандных деплоях OpenAI наконец получило точечное решение. OpenAI Python SDK v2.46.0, выпущенный сегодня, открывает через Admin API новый endpoint, позволяющий операторам создавать и получать листинг API-ключей, привязанных к отдельным project service account'ам, — а не ко всей организации.

Это важно для любой команды, которая запускает CI/CD пайплайны, staging-окружения или поCommandline деплои, маршрутизирующие трафик через OpenAI. Раньше единственный программный путь к provisioning ключей был на уровне проекта или организации, что вынуждало команды выдавать пайплайнам более широкие права, чем реально требовалось.

Что произошло

Релиз SDK v2.46.0 добавляет три связанные возможности:

1. Создание API-ключей на уровне service account. Новый метод create_api_key в client.admin.organization.projects.service_accounts обращается к endpoint /organization/projects/{project_id}/service_accounts/{service_account_id}/api_keys. Вызов принимает name и, что особенно важно, массив scopes — явный список разрешений API, которые создаваемый ключ вправе использовать.

2. Фильтр owner_project_access в листинге ключей. Метод list для ключей организации теперь принимает owner_project_access, позволяя операторам фильтровать инвентарь ключей по принадлежащему им service account или проекту. Впервые стало возможным полноценно аудитировать активные учётные данные по воркнагрузке без выгрузки полного списка ключей.

3. Очистка beta-псевдонимов. Параллельный коммит удаляет legacy-аксессоры beta-ресурсов, накопившиеся с момента первичного выхода Organization API. Поверхность Admin API стала чище для тех, кто строит автоматизацию.

Исходный коммит SDK: 5a0094194eac9c605c8ca84d47d1c5518f8e2131. Изменение доступно начиная с openai-python>=2.46.0.

Почему это важно для AI-инженерных команд

Credential sprawl — тихая угроза в многопроектных AI-деплоях. Типичный сценарий до этого изменения: команде нужен автоматизированный доступ к OpenAI в CI-пайплайне — генерируется project-ключ, записывается в переменную окружения и забывается. Спустя несколько месяцев этот ключ аккумулирует использование в несвязанных запусках, ротировать его сложно, а отзыв ломает весь пайплайн.

Endpoint создания ключей для service account меняет архитектуру:

• Один service account на один пайплайн. Создайте service account специально для деплой-пайплайна, CI-окружения или coding agent.
• Ключи, привязанные к этому account'у. Создаётся API-ключ, ограниченный набором scopes конкретного service account, а не широким project-ключом.
• Ротация по воркнагрузке, а не по проекту. Ротируйте ключ одного пайплайна, не затрагивая учётные данные других воркнагрузок.

Особенно актуально для команд, использующих OpenAI-совместимые routing-шлюзы. Gateway, перераспределяющий запросы по нескольким upstream OpenAI-проектам, теперь может хранить scoped ключи отдельного service account для каждого маршрутизируемого проекта, а не единый широкий ключ. Это напрямую снижает радиус поражения при компрометации учётных данных.

Router/operator-угол

Для операторов AI-шлюзов, маршрутизирующих запросы в OpenAI через несколько команд или окружений, параметр scopes — главное нововведение релиза. Он позволяет явно указать, что именно вправе делать ключ: inference, fine-tuning, admin-операции — вместо того чтобы наследовать полные возможности роли service account в проекте.

На практике: routing gateway, обслуживающий coding agents (Cursor, Claude Code, VS Code Copilot), теперь может хранить ключ, ограниченный исключительно inference-вызовами. Отдельный ключ с admin-правами полностью выведен из runtime data path.

Фильтр owner_project_access в листинге ключей помогает операторам вести живой инвентарь активных учётных данных по проекту. Это удобно для governance-аудитов: какие ключи созданы автоматизацией, а какие вручную; какие близки к истечению; у каких service account есть ключи, охватывающие более одного проекта.

Чеклист для оператора при обновлении до v2.46.0:

1. Аудит существующих service account'ов. Используйте client.admin.organization.projects.service_accounts.list(project_id=...) для инвентаризации по каждому проекту.
2. Замена широких project-ключей пайплайнов. Для каждого CI/CD или agent-воркнагрузка, использующего широкий project-ключ, создайте service account и выпустите scoped ключ для него.
3. Минимальные scopes. Передавайте в scopes только то, что реально нужно воркнагрузке. Inference-пайплайнам не нужны admin или fine-tuning права.
4. Включите фильтр owner_project_access в процесс аудита ключей. Планируйте регулярную инвентаризацию — минимум раз в квартал — для выявления устаревших или избыточно привилегированных учётных данных.
5. Обновите конфигурацию шлюза. Если вы маршрутизируете через AI gateway, замените project-ключи для каждого upstream-проекта на scoped ключи соответствующих service account'ов.

Что стоит отслеживать пользователям TheRouter

Если вы используете TheRouter для маршрутизации запросов между несколькими OpenAI-проектами, это изменение даёт более чистую модель учётных данных для каждой upstream привязки. Вместо одного project-ключа на проект — создайте отдельный service account для каждого routing-назначения и выпустите для него scoped ключ. Это ограничивает область воздействия при компрометации credential шлюза.

Для деплоев с высокими требованиями к governance новый фильтр листинга ключей упрощает верификацию того, что учётные данные routing-слоя настроены с правильными scopes, — при периодических проверках.

Изучите документацию TheRouter — там подробно описано, как настраивать API-ключи для каждого provider при конфигурировании многопроектного routing через OpenAI и как выстроить надёжную политику ротации учётных данных на уровне gateway.