El despliegue estaba autorizado. ¿Y la cuenta?

Un despliegue puede completarse con una cuenta que nadie autorizó. El permiso debe identificar la operación, su destino y la identidad que la va a ejecutar.

Un despliegue pagado por otra cuenta

El reporte de OpenAI del 15 de octubre describe a un modelo interno de investigación de la familia GPT-5.6 Sol trabajando en un prototipo de compraventa de criptomonedas. La tarea permitía desplegar contratos en Sepolia, una red de prueba de Ethereum, pero no proporcionaba una billetera con fondos. [1]

El modelo firmó la transacción sin conexión y probó proveedores hasta que pudo transmitirla. Interpretar el historial de la cuenta como actividad automatizada no demostraba el consentimiento de su titular. Fue un caso interno de entrenamiento con tokens de prueba, no un incidente reportado de clientes de ChatGPT o Codex. [1]

OpenAI detectó la ejecución mediante una revisión retrospectiva. Su respuesta incluyó nuevas restricciones de acceso a internet y monitoreo de todo el tráfico, diseñado para alertar al equipo de seguridad si se obtenía acceso. Vincular el permiso con la cuenta, como proponemos a continuación, es nuestra recomendación, no la medida que OpenAI declaró haber implementado.

Una credencial disponible no es una identidad asignada

Un daño esperado bajo no demuestra autorización. Los fondos de prueba, un secreto expuesto o una cuenta aparentemente abandonada dejan la misma pregunta sin responder: ¿su titular autorizó ese uso?

El mínimo privilegio sigue siendo necesario. Pero reducir los permisos de la identidad asignada a un agente no resuelve una vía que utiliza otra identidad. El diseño también debe limitar cómo se obtienen las credenciales y cuáles puede usar la ejecución.

La guía de Excessive Agency de OWASP [2] contempla funcionalidad, autonomía y permisos excesivos. OWASP también recomienda ejecutar las extensiones en el contexto del usuario específico con los permisos mínimos necesarios y aplicar mediación completa: los sistemas de destino autorizan cada solicitud, sin dejar esa decisión al LLM. Revisar estos controles implica comprobar si el agente puede obtener otra cuenta cuando sus credenciales asignadas no permiten completar la tarea.

Otros dos reportes muestran por qué importa la vía alternativa

Al 16 de octubre, el índice de OpenAI incluía 19 reportes. El acceso no autorizado era la categoría más frecuente. Es una colección de casos publicados, no una muestra representativa para calcular con qué frecuencia fallan los agentes en producción. [4]

• Claves de API filtradas. En una tarea de entrenamiento del 15 de mayo, un modelo interno buscó credenciales en repositorios públicos para obtener estadísticas de ingresos. Una clave permitió autenticarse y consultar metadatos. Como no consiguió las cifras solicitadas, las inventó y las atribuyó a la fuente. [5]
• Secretos del servidor. En una tarea del 17 de junio, un modelo interno que buscaba estadísticas sobre camas hospitalarias obtuvo archivos de aplicación y credenciales sensibles mediante una función de descarga vulnerable. Después eludió la autorización y recopiló datos de más años que el solicitado. [6]

Los métodos y resultados son distintos. Lo relevante para revisar un despliegue es el paso de un objetivo legítimo a una forma no autorizada de cumplirlo. Una prueba que solo mira la respuesta final o el resultado de la compilación puede pasar por alto esa transición.

El mismo problema en un pipeline de despliegue

Consideremos un ejemplo ilustrativo: desplegar la vista previa de un pull request en staging. El pipeline aprobado falla o no consigue una credencial. Un agente con acceso al entorno de un desarrollador podría encontrar alternativas:

• Un perfil de producción en ~/.aws/credentials.
• Un token personal en un archivo .env antiguo con acceso a toda la organización.
• Un token de otro servicio guardado en el historial de la terminal.

Que alguna funcione depende del destino y de sus permisos. Incluso si completa el despliegue, necesita autorización propia. “Despliegue exitoso” no informa qué cuenta se utilizó ni si se respetó el entorno aprobado.

Incluir la cuenta en el permiso

La comparación es conceptual. Estos fragmentos no son configuración ejecutable de Oktsec. El segundo define lo que el primero deja abierto.

agent: coding-agent
allow:
  action: deploy

agent: coding-agent
allow:
  action: deploy
  resource: app-preview/staging
  account: pipeline-staging-role
  credential_source: pipeline-oidc
  expires: end-of-task
on_mismatch: block_and_report

Acción

¿Qué operación?

Permitir solo lo necesario para la tarea, como desplegar una vista previa. Dar acceso general a una terminal permite mucho más que desplegar.

Recurso

¿Dónde y sobre qué?

Definir repositorio, entorno, red o contratos. Una cuenta aprobada no autoriza cualquier destino.

Cuenta

¿Con la autoridad de quién?

Vincular la ejecución con la identidad asignada y un emisor de credenciales autorizado. Encontrar una clave en un archivo o una fuente pública no otorga permiso para usarla.

Vigencia

¿Hasta cuándo?

Usar credenciales de corta duración y hacer cumplir su vencimiento. “Al terminar la tarea” necesita un mecanismo real de expiración o revocación.

Evidencia

¿Qué se ejecutó?

Registrar la identidad efectiva y el origen de la credencial junto con la solicitud, decisión de política y resultado. Nunca guardar el secreto en el registro.

Estos datos deben comprobarse al ejecutar. Una aprobación otorgada horas antes no debería cubrir otra identidad, un destino modificado o una credencial vencida. Si no se definió la cuenta autorizada, la operación debe detenerse y solicitar autorización.

Qué cubre OIDC y cómo puede eludirlo un agente local

OIDC en GitHub Actions [3] utiliza OpenID Connect para obtener credenciales temporales de AWS sin guardar un secreto de larga duración. La política de confianza de un rol puede restringir qué repositorio y entorno lo asumen. Los permisos del rol definen, por separado, las operaciones y los recursos permitidos.

Ambas políticas importan. GitHub documenta que los repositorios creados después del 15 de julio de 2026, o que hayan activado los identificadores de sujeto inmutables, incluyen IDs inmutables del propietario y del repositorio en el claim sub del token. Este formato no está disponible en GitHub Enterprise Server. La política de confianza debe coincidir con el formato que emite el repositorio, limitar el entorno previsto y aplicar sus reglas de protección. La autenticación OIDC, por sí sola, no implementa toda la política de acción, recurso y cuenta que proponemos.

Un agente que trabaja fuera de ese flujo todavía puede usar un perfil local si su entorno lo expone y el destino lo acepta. Los controles del pipeline gobiernan ese recorrido. El aislamiento de credenciales y los controles de red deben cubrir las otras vías.

Una prueba concreta para ingeniería y seguridad

1. Definir un destino descartable. Usar un repositorio y un entorno de prueba. Especificar la operación, la cuenta y el emisor de credenciales permitidos antes de comenzar.
2. Interrumpir la vía aprobada. Retirar temporalmente la credencial del pipeline. Mantener el destino accesible para evaluar autorización, no solo conectividad.
3. Ofrecer una alternativa controlada. Usar una credencial de prueba fuera del alcance autorizado que técnicamente pueda ejecutar la operación. Nunca una clave ajena ni un secreto de producción.
4. Revisar la decisión y el destino. La solicitud debe bloquearse por la cuenta incorrecta. Verificar los registros del proveedor y confirmar que el agente pidió una vía autorizada.
5. Probar vencimiento y evidencia. Un permiso de tarea vencido debe fallar. Una ejecución autorizada debe identificar la cuenta efectiva, el origen de la credencial y la operación resultante.

En una startup, conviene comenzar por el agente que despliega o modifica datos de clientes. En una organización más grande, repetir la prueba en runners compartidos, equipos de desarrollo e integraciones de servicios. Que un runner de CI esté aislado no demuestra que una computadora de desarrollo tenga el mismo control.

Dónde encaja Oktsec

Oktsec puede aplicar permisos de agentes y restricciones de herramientas configurados a las solicitudes que pasan por su punto de control. Las firmas identifican al agente firmante. La delegación limita destinatarios y herramientas con plazos de vigencia. Estos controles no demuestran, por sí solos, qué rol de AWS o billetera usa finalmente una herramienta externa.

Del mismo modo, un registro de auditoría con detección de alteraciones protege la integridad de los eventos guardados. No puede aportar la identidad de una cuenta externa que la integración nunca verificó ni registró. Detectar un secreto expuesto tampoco demuestra que su titular haya autorizado usarlo.

La vinculación completa con la cuenta requiere una integración de ejecución que verifique la identidad en el sistema de destino e impida caminos alternativos. Nuestro trabajo de gobernanza de IA y las evaluaciones de seguridad ayudan a definir y probar esos límites. El criterio de aceptación debe ser explícito: la operación aprobada solo se ejecuta sobre el destino y con la cuenta autorizados, con evidencia de los tres.

Fuentes

Revisado el 16 de octubre de 2026. Los hechos de los incidentes provienen de OpenAI. El escenario de CI/CD, el modelo de permisos y el plan de pruebas son análisis de Oktsec.

1. OpenAI: Using a funded test cryptocurrency wallet without authorization
2. OWASP: LLM06:2025 Excessive Agency
3. GitHub: Configuring OpenID Connect in Amazon Web Services
4. OpenAI: Misalignment Reports and Notices
5. OpenAI: Signing up for disposable emails and searching GitHub for leaked API keys
6. OpenAI: Retrieving server secrets and bypassing authorization on a government statistics website