OpenAI Now Lets You Create Scoped API Keys Per Service Account — What Every Multi-Project Operator Must Know

The operational headache of managing API credentials for multi-team OpenAI deployments just got a targeted fix. OpenAI Python SDK v2.46.0, released today, exposes a new Admin API endpoint that lets operators create and list API keys scoped specifically to individual project service accounts — not the whole organization.

This matters for any team running CI/CD pipelines, staging environments, or per-team deployments that route through OpenAI. Previously, the only programmatic path for key provisioning was at the project or organization level, forcing teams into broader credential grants than workloads actually need.

What happened

The v2.46.0 SDK release adds three related capabilities:

1. Per-service-account API key creation. The new create_api_key method under client.admin.organization.projects.service_accounts targets the endpoint /organization/projects/{project_id}/service_accounts/{service_account_id}/api_keys. You pass a name and, critically, a scopes array — an explicit list of API permissions the created key is allowed to exercise.

2. owner_project_access filter on key listing. The list method for organization API keys now accepts owner_project_access, letting operators filter the key inventory by which service account or project a key belongs to. This makes auditing active credentials per workload tractable for the first time without exporting full key lists.

3. Beta alias cleanup. A parallel commit removes legacy beta resource accessors that had accumulated since the organization API first went public. The API surface is now cleaner for operators who build automation against the Admin API.

The source SDK commit is 5a0094194eac9c605c8ca84d47d1c5518f8e2131. The change is live in openai-python>=2.46.0.

Why it matters for AI engineering teams

Credential sprawl is the silent risk in multi-project AI deployments. The common pattern before this change: a team needs automated access to OpenAI in a CI pipeline, so they generate a project-scoped key at setup time, check it into an environment variable, and forget it. Months later, that key has accumulated usage across unrelated runs, rotations are hard to track, and revocation takes out the whole pipeline.

The service-account key creation endpoint changes the architecture:

• One service account per pipeline. Create a service account specifically for your deployment pipeline, CI environment, or coding-agent workload.
• Keys scoped to that account. Create an API key that is bound to that service account's scope list — not a broad project key.
• Rotation per workload, not per project. Rotate the key for one pipeline without touching credentials that serve other workloads.

This is especially relevant for teams using OpenAI-compatible routing gateways. A gateway that re-dispatches requests to upstream OpenAI projects can now hold scoped per-service-account keys for each routed project rather than a single broad key. This directly reduces the blast radius of a credential compromise.

The router/operator angle

For AI gateway operators routing requests to OpenAI across multiple teams or environments, the scopes parameter is the most important addition. It allows you to specify exactly what the key can do — model inference, fine-tuning, admin operations — rather than inheriting the full capability of the service account's project role.

Concretely, a routing gateway serving coding agents (Cursor, Claude Code, VS Code Copilot) can now hold a key scoped exclusively to model inference calls. A separate key, scoped to admin operations, stays out of the runtime data path entirely.

The owner_project_access filter on key listing also helps operators maintain a live inventory of which credentials are active per project. This is useful for governance audits: which keys were created by automation vs. by humans, which ones are approaching their expiration, and which service accounts have keys that span more than one project.

Operator checklist for the v2.46.0 upgrade:

1. Audit existing service accounts. Use client.admin.organization.projects.service_accounts.list(project_id=...) to inventory service accounts per project.
2. Replace org-wide pipeline keys. For every CI/CD or agent workload that currently uses a broad project key, create a service account and generate a scoped key for it.
3. Set minimal scopes. Pass only the scopes the workload actually needs. Model inference pipelines do not need admin or fine-tuning scopes.
4. Wire the owner_project_access filter into your key audit process. Schedule a regular inventory check — quarterly at minimum — to catch stale or over-privileged credentials.
5. Update your gateway configuration. If you route through an AI gateway layer, swap project keys for scoped service-account keys per upstream project.

What TheRouter users should watch or try

If you use TheRouter to route requests across multiple OpenAI projects, this change gives you a cleaner credential model for each upstream project binding. Rather than holding a single project key per project, you can create a dedicated service account for each routing destination and issue a scoped key for that account. This limits what a compromised gateway credential can reach.

For governance-conscious deployments, the new key listing filter makes it easier to verify that your routing layer's credentials are scoped correctly during periodic reviews.

Check TheRouter's docs for how to configure per-provider API keys when setting up multi-project OpenAI routing.