Desde el 10 de septiembre de 2026, OpenAI te deja ponerle fecha de expiración a las claves de API de proyecto y permite a los admins fijar cuánto pueden vivir las claves nuevas; desde el 15 de septiembre, también pueden restringir qué tipos de clave se pueden crear. La federación de identidad de workloads (lanzada el 26 de mayo, con mTLS y X.509 disponibles de forma general desde el 29 de agosto) va más allá: permite que un workload corra sin ninguna clave de OpenAI guardada.
Son barandas para las credenciales nuevas, no una limpieza de las que ya tenés. Acá va lo que dicen los docs, un antes y después para un job de CI y para un servidor, qué revisar esta semana y qué dejan sin especificar.
1. Contexto: Siete Cambios Desde Mayo, Según la Documentación
Todo lo que sigue sale del changelog y de las guías para desarrolladores de OpenAI, que releí el 2026-10-14. Yo no configuré estas funciones, así que leelo como lo que afirman los docs, con la fecha de cada cambio, no como un reporte de campo.
Cronología (changelog de OpenAI)
Tiers de uso desde el 2026-10-06 (guía de rate limits)
La guía dice que el tier de tu organización sube automáticamente a medida que sus compras totales de crédito alcanzan cada umbral. Las alertas y los límites duros de gasto son controles aparte en la misma página: un límite duro hace que las requests afectadas devuelvan un 429.
Estos controles solo tocan claves nuevas
La guía de producción es explícita: los controles de gobernanza “aplican solo a la creación de claves nuevas; las claves existentes no se ven afectadas”. La clave que ya está en un .env, en un secret de CI o en un gestor de contraseñas sigue funcionando igual hasta que la reemplaces.
Consecuencia práctica: la plataforma te da los frenos, pero el inventario y el reemplazo son tuyos. Por qué los tiers entran en un post de seguridad de claves: la tabla de tiers lista un límite de uso mensual y, a mi lectura, es el tope exterior de lo que una clave robada podría gastar en un mes si no pusiste nada más bajo. La guía no lo plantea así, así que tomalo como inferencia mía.
2. Cuatro Implicaciones para Cómo Guardás Credenciales
Cada tarjeta es un control tal como lo describen los docs, con la fecha y la guía de la que sale.
Las claves pueden expirar y los admins fijan el tope
2026-09-10 · Claves de API
La guía de producción recomienda con fuerza una fecha de expiración en cada clave de API de proyecto y un proceso regular de rotación. Los admins pueden exigir una vida máxima a nivel de organización o proyecto, de modo que las claves nuevas deban expirar dentro del límite; el límite de un proyecto no puede superar el de la organización.
Buenas prácticas de producción — claves de APIPodés restringir qué tipos de clave existen
2026-09-15 · API Key Governance
En los ajustes de la plataforma, los admins pueden permitir solo claves de service account, solo claves de proyecto de propiedad del usuario, o desactivar la creación de claves nuevas. Las restricciones de la organización siempre mandan; un proyecto puede sumar restricciones pero no aflojarlas.
Buenas prácticas de producción — claves de APILa identidad de workload elimina el secreto guardado
Federación 2026-05-26 · X.509 2026-08-29
Un workload presenta una identidad que ya tiene (un token de CI, un token de la nube, un certificado de cliente). OpenAI la verifica y la cambia por un token de acceso de corta vida asociado a una service account, válido como máximo una hora según la referencia del intercambio. No se devuelve refresh token: repetís el intercambio. Los providers documentados incluyen GitHub Actions, Kubernetes, AWS, Azure, Google Cloud, Oracle Cloud, JWT-SVID de SPIFFE, OIDC genérico y, solo para la API, X.509.
Resumen de la federación de identidad de workloadsmTLS es una puerta extra, no un reemplazo
2026-08-29 · Mutual TLS
Cuando hay un certificado de confianza activo para una organización o proyecto, las requests de ese alcance deben presentar un certificado de cliente aceptado además de la credencial bearer normal. La guía menciona hasta 50 objetos de certificado por organización, sin chequeos CRL ni OCSP y sin compatibilidad con Private Link, y dice de activarlo primero en un proyecto no crítico.
Guía de Mutual TLSAntes y después: un job de CI (GitHub Actions)
Ilustrativo: armado con los nombres de variables de la guía de GitHub Actions y los campos de la referencia del intercambio de tokens. No lo corrí contra un proyecto real, y el “antes” es el patrón común, no algo que muestren los docs. Los ejemplos de SDK de la guía hacen el intercambio por vos; el último bloque solo muestra qué pasa por debajo.
Antes: una clave de larga vida guardada como secret del repositorio
jobs:
call-openai:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: node ./scripts/call-openai.js
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}Después: el job demuestra quién es (sin secreto de OpenAI guardado)
permissions:
id-token: write
contents: read
jobs:
call-openai:
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- run: node ./scripts/call-openai.js
env:
OPENAI_WIF_AUDIENCE: ${{ vars.OPENAI_WIF_AUDIENCE }}
OPENAI_IDENTITY_PROVIDER_ID: ${{ vars.OPENAI_IDENTITY_PROVIDER_ID }}
OPENAI_SERVICE_ACCOUNT_ID: ${{ vars.OPENAI_SERVICE_ACCOUNT_ID }}Cómo se ve el intercambio en el cable (requiere curl y jq)
AUD=$(jq -rn --arg audience "$OPENAI_WIF_AUDIENCE" '$audience | @uri')
JWT=$(curl -s -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
"$ACTIONS_ID_TOKEN_REQUEST_URL&audience=$AUD" | jq -r .value)
curl -s https://auth.openai.com/oauth/token \
-H "Content-Type: application/json" \
-d "{
\"grant_type\": \"urn:ietf:params:oauth:grant-type:token-exchange\",
\"subject_token_type\": \"urn:ietf:params:oauth:token-type:jwt\",
\"subject_token\": \"$JWT\",
\"identity_provider_id\": \"$OPENAI_IDENTITY_PROVIDER_ID\",
\"service_account_id\": \"$OPENAI_SERVICE_ACCOUNT_ID\"
}"
# response: access_token, expires_in, expires_at (no refresh token)Del lado de OpenAI, la guía te hace crear un workload identity provider (issuer https://token.actions.githubusercontent.com, audience igual a lo que pide el workflow) y un mapeo de service account, con assertions como repository, ref, environment y workflow_ref.
Antes y después: un workload de servidor (X.509)
De nuevo ilustrativo, armado con las guías de X.509 y Mutual TLS. Los nombres de variables de entorno son los de las guías; el id del modelo es un placeholder porque los ejemplos de las guías cambian de una página a otra.
Antes: una clave estática en una variable de entorno
export OPENAI_API_KEY="<static key from your secret manager>"
curl https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model": "<model>", "input": "ping"}'Después: certificado de cliente entra, token de corta vida sale
export OPENAI_MTLS_CERT_CHAIN="/path/to/client-chain.pem"
export OPENAI_MTLS_KEY="/path/to/client-key.pem"
export OPENAI_IDENTITY_PROVIDER_ID="<provider id>"
export OPENAI_SERVICE_ACCOUNT_ID="<service account id>"
# 1. certificate in, short-lived bearer token out (keep access_token as OPENAI_WIF_ACCESS_TOKEN)
curl https://mtls.auth.openai.com/oauth/token \
--cert "$OPENAI_MTLS_CERT_CHAIN" --key "$OPENAI_MTLS_KEY" \
-H "Content-Type: application/json" \
-d "{
\"grant_type\": \"urn:ietf:params:oauth:grant-type:token-exchange\",
\"subject_token_type\": \"urn:openai:params:oauth:token-type:x509\",
\"identity_provider_id\": \"$OPENAI_IDENTITY_PROVIDER_ID\",
\"service_account_id\": \"$OPENAI_SERVICE_ACCOUNT_ID\"
}"
# 2. bearer token AND client certificate on every API call
curl https://mtls.api.openai.com/v1/responses \
--cert "$OPENAI_MTLS_CERT_CHAIN" --key "$OPENAI_MTLS_KEY" \
-H "Authorization: Bearer $OPENAI_WIF_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"model": "<model>", "input": "ping"}'Corta vida no es lo mismo que revocable
Para X.509 la guía aclara que el token bearer no está atado al certificado (sin DPoP ni claim cnf), que el flujo no hace chequeos CRL ni OCSP, y que los tokens duran como máximo una hora y nunca más que el certificado de cliente. Su propio consejo es planear la respuesta a incidentes alrededor de las raíces de Mutual TLS, los providers, los mapeos y los tokens de vida corta.
3. Qué Hacer Esta Semana
Primero los ajustes, después la migración, y un workload por vez. Esta es la secuencia que correría con cualquier equipo que tenga claves de OpenAI:
☀️ Días 1–2: Inventario y prioridades
- 1. Listá cada clave de API por proyecto con su dueño y su workload. Usage y Costs se pueden filtrar y agrupar por clave desde el 2026-08-04, lo que te ayuda a separar claves vivas de muertas.
- 2. Revisá el tracking de uso: los docs dicen que las claves creadas antes del 2023-12-20 no lo tienen activo por defecto y el tráfico anterior aparece como Untracked; podés activarlo para el uso futuro desde el dashboard de claves.
- 3. Encontrá dónde vive cada clave físicamente (secrets de repos, variables de CI, archivos .env, gestores de secretos, laptops, herramientas de terceros). Cada copia es un lugar por donde se puede filtrar.
📅 Días 3–4: Cerrar los ajustes
- Gobernanza de claves: en los ajustes de la plataforma, API Key Governance, elegí solo claves de service account, solo claves de usuario o ninguna clave nueva. La organización pisa a los proyectos, así que configurala primero.
- Vida máxima: definila a nivel de organización o proyecto. Los docs no dan número ni valor por defecto, así que elegí uno que tu proceso de rotación pueda cumplir.
- Expiración y rotación: dale fecha de expiración a cada clave de proyecto nueva y seguí el orden documentado: crear el reemplazo, actualizar tus apps, confirmar que funciona y recién ahí revocar la clave vieja.
- Gasto: fijate en qué tier está tu organización tras el 2026-10-06 y poné alertas de gasto más un límite duro por debajo del límite de uso mensual del tier.
📆 Día 5: Pasar un workload a federación
- Primero CI: en Organization Settings > Security > Workload Identity Provider, creá el provider de GitHub Actions y un mapeo acotado por repository, ref, environment y workflow_ref. Usá service accounts separadas para CI y producción, y nunca le des credenciales de producción a pull requests de forks no confiables.
- Servidores: en Mutual TLS, subí tu trust anchor en PEM y activalo en un proyecto no crítico; después creá un provider X.509 y mapeá un openai.subject exacto a una service account con solo los permisos necesarios.
- Cerrar el círculo: recién cuando el camino nuevo funcione, revocá la clave estática y borrá el secret. Dejá una clave admin para llamadas a la Admin API, que los tokens federados no pueden hacer.
4. Qué No Especifican los Docs
Primero una nota de estado: el changelog llama a Mutual TLS y a la federación X.509 “generalmente disponibles” el 2026-08-29, mientras que la guía de X.509 dice solo que está “disponible para la API de OpenAI” y que Codex no la soporta. Estos son los huecos que encontré en la sección de claves de API y en las guías de federación:
Sin números
No se indica vida máxima, expiración por defecto ni mínimo. La “vida máxima de la clave” es un ajuste que elegís vos, y los docs no recomiendan un valor.
Los tipos de clave no están definidos
“Claves de service account” y “claves de proyecto de propiedad del usuario” no se definen en esa sección, y no dice si el tope de vida cubre ambas. Probalo en un proyecto descartable antes de depender de eso.
Sin runbook para claves filtradas
La revocación aparece solo como último paso de una rotación planificada. No hay un procedimiento de incidente para una clave que ya se filtró, así que escribí el tuyo: revocar, revisar el uso por clave, rotar lo que dependía de ella.
Comportamiento de la expiración
No se indica si se puede cambiar la expiración de una clave existente ni qué devuelve una clave expirada. Alertá ante cualquier fallo de autenticación en vez de asumir un código de error concreto.
Dos trampas que merecen un recordatorio
Los tokens de identidad de workload no pueden llamar a endpoints de la Admin API, así que una clave admin queda en tu infraestructura y pasa a ser tu secreto estático más sensible. Y debe coincidir exactamente un mapeo habilitado por cada intercambio, sin combinar permisos entre mapeos, así que los mapeos que se pisan hacen fallar el intercambio en vez de ampliar el acceso.
Regla de oro para 2026
Si una persona tiene que pegarla, va a vivir demasiado. Dejá que los workloads demuestren quiénes son, limitá la vida de las claves que no podés evitar, y configurá la organización para que las claves nuevas solo puedan ser del tipo que elegiste.
Conclusión
Desde mayo, OpenAI viene dándote las piezas: claves que expiran, un control a nivel de organización sobre qué claves pueden existir, y una forma de que CI y servidores se autentiquen sin guardar un secreto. Nada de eso arregla retroactivamente las claves que ya emitiste.
Hacé el sprint de una semana de arriba y salís con un inventario, defaults más estrictos para cada clave futura y un workload que ya no guarda un secreto. La misma semana en que OpenAI retira modelos viejos es un buen momento para tocar cada clave de todos modos.
Esta semana en una pantalla
Expirar
- • Vida máxima de clave
- • Expiración en cada clave nueva
- • Orden de rotación documentado
Restringir
- • API Key Governance
- • Solo claves de service account
- • Alertas de gasto + límite duro
Federar
- • CI con OIDC de GitHub
- • Servidores con X.509
- • Revocar la clave estática
Fuentes
- OpenAI — Changelog de la API (expiración de claves, gobernanza, mTLS y X.509, tiers de uso)
- OpenAI — Buenas prácticas de producción: claves de API, expiración y gobernanza
- OpenAI — Resumen de la federación de identidad de workloads
- OpenAI — Federación de identidad de workloads para GitHub Actions
- OpenAI — Federación de identidad de workloads con certificados X.509
- OpenAI — Guía de Mutual TLS
- OpenAI — Referencia del intercambio de tokens de identidad de workload
- OpenAI — Rate limits y tiers de uso



