OpenAI API Keys Security Guide

An OpenAI API key is a bearer credential: anyone who holds it can spend your money, read the files and stored data your project holds, and act as your application, with nothing to tie the request back to a person. OpenAI has moved well beyond the single shared key, with projects, project-scoped service accounts, per-endpoint key permissions, admin-enforced key lifetimes, API Key Governance, IP allowlisting, audit logs and workload identity federation, but most of these controls are off or loose by default. This guide explains how identity and keys work on the OpenAI platform, how to configure each control, how to detect and respond to a leaked key, and where teams usually go wrong. It is for platform engineers, AppSec teams and whoever owns the OpenAI organisation. For the wider pattern of stolen AI credentials being resold, see the LLMjacking Guide; this page is the OpenAI-specific configuration companion.

Key takeaways

Use service account keys for workloads, not personal keys. A user-owned key dies or lingers with the person; a project service account is scoped to one project and survives staff changes.
Default keys have full permissions. Every new key is "All" unless you choose Restricted or Read Only, so scope each key to the endpoints it actually calls.
Enforce lifetimes and key types centrally. Maximum key lifetime and API Key Governance apply at organisation or project level, but only to keys created after you turn them on.
Spend alerts do not stop an attacker. Only a hard spend limit cuts traffic; set one per project as a blast radius control.
Federate where you can. Workload identity federation exchanges a cloud, Kubernetes, GitHub Actions or SPIFFE identity for a short-lived OpenAI token, removing the static key altogether.

How identity and access work in OpenAI

The OpenAI API platform is organised as organisation, then projects, then principals and keys. Understanding which layer a control lives on is most of the work.

Object	What it is	Security relevance
Organisation	Billing and membership boundary, identified by an organisation ID that requests can name in a header	Organisation Owners control billing, members, project rate limits and organisation-wide key policy
Project	Container for keys, service accounts, resources, rate limits and spend limits; up to 2,000 per organisation by default	The natural blast radius unit; separate staging from production. Archiving is permanent
User project key	Key owned by a human member of a project	Tied to a person; must be revoked on leaving
Service account key	Key for a project-scoped pseudo-user, shown once at creation	Right choice for applications; defaults to read and write on all project resources until restricted
Admin API key	Organisation-level key for the Admin API (projects, users, keys, audit logs, rate limits)	The most powerful key type; never in application code
Federated access token	Short-lived token returned by workload identity federation for a mapped service account	No static secret to leak; no refresh token, so workloads re-exchange before expiry

Recognising the key types

Current keys carry a type prefix, which is also how secret scanners find them. The open source Gitleaks rule openai-api-key matches sk-proj-, sk-svcacct- and sk-admin- prefixes plus the embedded marker T3BlbkFJ (base64 for "OpenAI"), as well as the older sk- format. Use the prefix in triage: an sk-admin- hit is an organisation-level incident, an sk-svcacct- hit points to a specific application, and an sk-proj- hit points to a person.

Admin roles and privileged access

Role	Level	Can do
Owner	Organisation	Everything a Reader can, plus billing and member management; sets project rate limits
Reader	Organisation	Make API requests, view basic organisation information, and create, update and delete resources unless restricted
Owner	Project	Add users, change roles, rename and archive the project, set project spend limits, create service accounts
Member	Project	Run inference, use project resources and create keys

Keep Owners few: organisation Owners can change billing, invite members and create Admin API keys. Two or three named people is typical; review the list quarterly.
Federate sign-in: use SSO and SCIM so that leavers lose platform access with their directory account (the audit log records scim.enabled and scim.disabled). Remember that deprovisioning a user does not by itself prove their old keys were revoked: check.
Remember Members create keys: by default any project Member can mint a full-permission key. API Key Governance is how you stop that (next section).

Integrations, API tokens and service accounts

Scope every key

Key permissions are set when a key is created, or later with Edit key:

All: full permissions. The default.
Restricted: None, Read or Write per endpoint. A chat application might need Write on the Responses endpoint and None everywhere else.
Read Only: read on all endpoints, useful for dashboards and usage tooling.

Govern key creation

API Key Governance lets administrators allow only service account keys, allow only user-owned project keys, or disable new key creation entirely. Organisation settings take precedence, and project settings can tighten but not loosen them. Administrators can also enforce a maximum key lifetime at organisation or project level, with project limits capped by the organisation limit. Both controls apply only to newly created keys, so after enabling them, inventory and replace existing long-lived keys.

Choose the right credential

Situation	Use	Why
Workload on AWS, Azure, Google Cloud, OCI or Kubernetes	Workload identity federation to a service account	Short-lived tokens; nothing static to store or leak
CI pipeline on GitHub Actions	Workload identity federation with GitHub's OIDC token	Removes the repository secret that pipeline attacks harvest
Workload that cannot federate	Restricted service account key with expiry, in a secrets manager	Scoped, rotatable, not tied to a person
Developer experimentation	User project key in a sandbox project with a low hard spend limit	Limits cost and data exposure of a leak
Third-party tool or IDE plugin asking for a key	Dedicated restricted key, own project, low hard limit	The tool becomes a custodian of the key
Browser or mobile client	No key: call your own backend	OpenAI's guidance is never to deploy keys client-side

Workload identity federation works by mapping an identity provider and token attributes to a service account; each mapping can narrow permissions, a token is issued only when exactly one enabled mapping matches, and mappings cannot include Admin API scopes. See the Workload Identity Federation Guide.

Store and inject keys safely

Runtime injection: load the key from a secrets manager or key management service at start-up into the OPENAI_API_KEY environment variable, which the official SDKs read by default. Do not bake it into container images, notebooks or configuration files committed to Git.
One key per application and environment: sharing one key across services makes rotation a coordinated outage and makes usage impossible to attribute.
Logs and errors: make sure HTTP client logging, tracing and error reporting redact the Authorization header. Keys leaking into observability platforms is a common and overlooked path.
Data, not only spend: a project key can reach files, vector stores and other stored resources in that project. Treat a leak as a possible data exposure, not just a billing problem, and keep sensitive data in projects with tightly restricted keys.

The JetBrains Marketplace AI plugin campaign shows why the plugin row matters: fifteen working coding assistants sent the keys users pasted in to an attacker, checking for the OpenAI key format first.

Logging and detection

The Admin API exposes an organisation audit log (/organization/audit_logs) covering user actions and configuration changes. Pull it on a schedule with an Admin API key held only by the collector, and forward it to the SIEM.

Audit event	What to alert on
`api_key.created`, `api_key.updated`	Keys created outside your provisioning pipeline, or permissions widened to All
`service_account.created`	Service accounts nobody requested
`ip_allowlist.updated`, `ip_allowlist.config.deactivated`	Network control loosened or switched off
`rate_limit.updated`, `project.updated`	Limits raised, a classic step before abuse
`role.assignment.created`, `invite.sent`, `user.added`	New Owners or unexpected members
`login.failed` bursts	Password spraying against platform accounts
`workload_identity_provider.*`, mapping changes	An attacker adding their own identity provider

Usage data is the other half. Review per-key and per-project usage for new models, sudden volume, unusual hours and calls from unexpected networks. Note that keys created before 20 December 2023 do not have usage tracking by default and show as "Untracked", which is one more reason to replace them.

Responding to a leaked key

Triage by prefix: admin, service account or user project key, and which project it belongs to.
Rotate: create the replacement, deploy it, then revoke the leaked key. If the key is being abused, revoke first and accept the outage.
Scope the abuse: check usage for the key and the audit log for keys, service accounts, members or identity providers created with it.
Contain spend: confirm a hard spend limit on the project and contact OpenAI support, as OpenAI recommends for suspected leaks.
Close the source: remove the key from code, history, logs, images or the tool that held it, and add or tune scanning. See the Git Secret Scanning Guide.

Metrics

Federated share: percentage of production API traffic using federated tokens rather than static keys.
Unscoped keys: number of active keys with All permissions.
Personal keys in production: production projects with user-owned keys (target zero).
Key age: oldest active key in days, against your enforced maximum lifetime.
Hard limit coverage: share of projects with a hard spend limit.
Time to revoke: minutes from a scanner hit to revocation.

Hardening baseline

Inventory: list projects, members, service accounts and keys through the Admin API. Mark each key with owner, purpose and environment.
Restructure projects: separate production, staging and sandbox projects, and give each production application its own project or at least its own service account.
Turn on governance: in production projects allow only service account keys; set an organisation maximum key lifetime (for example 90 days) and a shorter one for sandboxes. Pilot on one project first, because these settings change how teams create keys.
Replace old keys: because governance applies only to new keys, re-issue every pre-existing key as a restricted service account key, deploy, then revoke the old one. Keep the old key list until each application is confirmed working: that is your rollback.
Limit spend and rate: set hard monthly spend limits per project and adjust project rate limits to expected peaks.
Restrict networks: enable IP allowlisting for production where egress addresses are stable. OpenAI notes that Azure Private Link is not compatible with IP allowlisting or mTLS, so choose one model.
Federate: move cloud and CI workloads to workload identity federation and delete their static keys.
Monitor: collect audit logs and usage into the SIEM and run the alerts above.

Decision guidance

Small team: one organisation, a production and a sandbox project, service account keys in a secrets manager, hard spend limits and a monthly key review cover most risk.
Large organisation: route traffic through an AI gateway so that applications never see provider keys, keep the gateway's own key federated, and enforce governance centrally. See the AI Gateway and LLM Gateway Guide.
Key or federation: federate whenever the workload has a supported identity; fall back to restricted keys only where it does not.

Common misconfigurations

A personal key powering production. When the developer leaves, either the service breaks or the key outlives their access.
All-permission keys by default. A key that only needs one endpoint can also read files and stored resources.
Governance turned on and assumed complete. Existing keys are untouched by new lifetime and key type rules.
Spend alerts instead of hard limits. Alerts notify; they do not stop an attacker reselling access.
Keys in front-end code, notebooks or tools. Client-side deployment and pasted-in plugin keys are the routes OpenAI and recent incidents both warn about.
Admin API key used for routine automation. A leak then exposes the whole organisation rather than one project.

Framework mapping

Control	NIST CSF 2.0	NIST SP 800-53 Rev. 5	Threat reference
Key inventory and ownership	PR.AA-01	AC-2, IA-5	ATT&CK T1552.001 Credentials In Files
Scoped keys and service accounts	PR.AA-05	AC-6	ATT&CK T1550.001 Application Access Token
Federation and no embedded keys	PR.AA-01	IA-5(7)	ATLAS AML.T0012 Valid Accounts
Spend and rate limits	PR.AA-05	SC-7 (network allowlisting)	ATT&CK T1496.004 Cloud Service Hijacking; OWASP LLM10:2025 Unbounded Consumption
Audit and usage monitoring	DE.CM-03	AU-6	ATT&CK T1528 Steal Application Access Token

Practitioner checklist

Inventory every project, service account and key through the Admin API, with an owner for each.
Allow only service account keys in production projects through API Key Governance.
Enforce a maximum key lifetime and re-issue all keys created before it was set.
Create keys as Restricted or Read Only; justify every key with All permissions.
Set hard monthly spend limits on every project.
Move cloud and CI workloads to workload identity federation.
Keep Admin API keys to a single audited collector and a small Owner group.
Enable IP allowlisting for production where egress is stable.
Stream audit logs to the SIEM and alert on key, role, allowlist and limit changes.
Scan code, images and logs for the sk- prefixes and rehearse the rotation runbook.

OpenAI API Keys Security Guide: Project Keys, Service Accounts and Leak Response