Adopción de Codex en equipos: guía de decisión para permisos, convenciones y la ruta de Bedrock

Cuando un equipo empieza a usar Codex de forma compartida, la primera pregunta de seguridad y operaciones casi nunca es “¿qué plan compramos?”. Suele ser “¿quién tiene full access, qué puede leer .env y dónde vemos el uso y los registros de auditoría?”. Esas preguntas deciden el primer paso de la adopción. La respuesta no es elegir primero una API key. La respuesta es definir primero el límite de permisos. Este artículo propone un marco de decisión para adopción empresarial: configurar requirements.toml y permission profiles para limitar los permisos de cada miembro, estandarizar las reglas compartidas de AGENTS.md, elegir una ruta de despliegue como ChatGPT workspace, API Key o Amazon Bedrock, y finalmente conectar analytics y compliance. También conviene dejar clara una cosa desde el inicio: AWS anunció la disponibilidad de GPT-5.4 en GovCloud el 2026-06-03, pero el proveedor de Codex para Bedrock no soporta endpoints de GovCloud en este momento. Son dos hechos distintos, no uno solo.

1. Marco de permisos empresarial: no dejes full access en cada máquina local

Cuando una empresa quiere estandarizar Codex, puede usar cloud-managed requirements para restringir el comportamiento local. requirements.toml es el archivo de políticas de Codex. Los administradores pueden asignar distintas políticas por grupo de usuarios en lugar de dejar que cada miembro configure su entorno.

1.1 Campos clave en requirements.toml

Estos son los campos que más se usan cuando se aterriza este despliegue:

Campo	Propósito	Valor recomendado
approval_policy	Controla si se requiere aprobación humana	"suggest" o "auto-edit"; no uses "never" como valor por defecto del equipo
approvals_reviewer	Nombra al aprobador	El owner del equipo o el responsable de seguridad
automatic_review_policy	Reglas de revisión automática	Define según el nivel de riesgo del proyecto
permission profiles	Modelo de permisos más nuevo (0.138.0+)	Recomendado para nuevos despliegues
sandbox_mode	Modelo de permisos anterior	Úsalo solo en migraciones legadas
web_search_mode	Si se permite búsqueda web	Opcional, pero debería restringirse en proyectos sensibles
managed_hooks	Configuración unificada de hooks	lint-check, test-runner y similares
MCP servers allowlist	Qué servidores MCP se pueden usar	Solo filesystem, github y otros aprobados

Codex 0.138.0 y posteriores recomiendan permission profiles con allowed_permission_profiles y default_permissions. Los despliegues antiguos todavía pueden usar allowed_sandbox_modes.

1.2 Combinaciones prohibidas

La siguiente combinación no debe usarse como valor por defecto del equipo:

danger-full-access + approval_policy = "never"

Es la combinación de máximo privilegio y sin aprobación. Debe bloquearse en los requisitos gestionados en la nube para que no aparezca en configuraciones locales individuales.

1.3 Ejemplo de configuración

# requirements.toml
[managed]
approval_policy = "suggest"
allowed_permission_profiles = ["suggest", "auto-edit"]
default_permissions = "suggest"

[mcp]
allowed_servers = ["filesystem", "github"]

[hooks]
managed_hooks = ["lint-check", "test-runner"]

Este ejemplo limita a los miembros a "suggest" o "auto-edit", deja "suggest" como valor por defecto, permite solo filesystem y github para MCP, y mantiene el conjunto de hooks consistente. Si quieres dar "auto-edit" a un grupo central de desarrollo y dejar "suggest" para becarios o perfiles más restringidos, este es el sitio correcto para hacerlo.

2. Mínimo privilegio y diseño de sandbox: reglas concretas, deny glob y protección de archivos sensibles

Los responsables de seguridad no necesitan un eslogan sobre “mínimo privilegio”. Necesitan reglas concretas: qué archivos se pueden leer, cuáles se pueden escribir y cuáles están totalmente prohibidos.

2.1 Tres valores de filesystem

Los permisos de filesystem de Codex admiten tres valores:

• read: solo lectura, sin edición
• write: lectura y escritura, se permiten cambios
• deny: acceso completamente bloqueado

La regla de precedencia es simple: gana la regla más específica y deny tiene la prioridad más alta. Por ejemplo, si configuras a la vez "**/*.env" = "deny" y ":workspace_roots" = "write", los archivos .env siguen bloqueados aunque la raíz del workspace sea escribible.

2.2 Límites de alcance del workspace

Usa :workspace_roots para limitar el área de trabajo. Ejemplo:

[permissions.filesystem]
":workspace_roots" = "write"

Esto permite que Codex opere solo dentro de la raíz actual del workspace y sus hijos. No puede salir de ese alcance.

2.3 Protección de archivos sensibles

Puedes usar deny globs para mantener fuera de alcance los archivos de entorno y directorios secretos:

[permissions.filesystem]
":workspace_roots" = "write"
"**/*.env" = "deny"
"**/secrets/**" = "deny"
"**/*.log" = "read"

Esto significa:

• la raíz del workspace y sus hijos son escribibles
• todos los archivos .env están bloqueados en cualquier parte del árbol
• los directorios secrets/ y sus hijos están bloqueados
• los archivos .log quedan en solo lectura

2.4 Permisos de red

Los permisos de red pueden activarse y controlarse con listas allow/deny por dominio:

[permissions.network]
enabled = true
allow = ["github.com", "api.openai.com"]
deny = ["localhost", "127.0.0.1"]

Eso permite acceder a github.com y api.openai.com, y bloquea localhost y loopback. También existe protección adicional para redes locales o privadas, así que los equipos pueden definir sus propias políticas de dominio.

2.5 permission profiles frente a sandbox mode

Comparación	Permission profiles	Sandbox mode
Etapa de lanzamiento	Modelo más nuevo	Modelo legado
Granularidad	Más fina	Más gruesa
Campos de configuración	allowed_permission_profiles + default_permissions	allowed_sandbox_modes
Recomendación	Preferido para despliegues nuevos	Principalmente para migración legada

Los despliegues nuevos deberían preferir permission profiles. Sandbox mode puede ir retirándose poco a poco.

3. Convenciones compartidas del equipo: un solo AGENTS.md, no un archivo propio por persona

Los equipos necesitan un prompt compartido, reglas de contexto compartidas e instrucciones de revisión compartidas. No necesitan que cada persona mantenga su propia versión y convierta la manutención en un rompecabezas. AGENTS.md es el archivo de instrucciones de Codex y admite reglas por capas con prioridades.

3.1 Orden de la cadena de instrucciones

Cuando Codex arranca, construye esta cadena de instrucciones:

global rules (~/.config/codex/AGENTS.md)
  -> project rules (project AGENTS.md)
  -> nearest-to-current-directory rules

El archivo más cercano gana cuando hay solapamiento.

3.2 Arquitectura por capas

No metas todas las reglas en un archivo gigante. Divide en capas:

• ~/.config/codex/AGENTS.md: reglas globales, estilo, expectativas de test y prohibiciones generales
• AGENTS.md del proyecto: arquitectura, dependencias, estilo de despliegue
• AGENTS.md del módulo: necesidades específicas del módulo

Cada capa debería quedarse en torno a 10-15 KiB para que sea manejable y no haya truncación.

3.3 Cómo manejar el límite de 32 KiB

Codex define project_doc_max_bytes en 32 KiB. Si AGENTS.md crece demasiado, puede truncarse.

Hay dos maneras de resolverlo:

1. subir project_doc_max_bytes
2. dividir el documento en directorios anidados

La segunda opción suele ser mejor, porque deja más claro quién mantiene cada parte.

3.4 Para qué sirve AGENTS.override.md

AGENTS.override.md sirve para anular el AGENTS.md superior y tiene la prioridad más alta. Úsalo cuando:

• un subdirectorio concreto necesita una regla temporal distinta
• un módulo experimental necesita límites más flexibles
• un módulo difiere de la política general del proyecto

Deja claro el motivo del override para no confundir al equipo.

3.5 Recomendación de mantenimiento

Al mantener AGENTS.md, deja explícito:

• Ownership: quién mantiene cada capa
• Maintenance budget: cuánto tiempo de revisión recibe cada sprint
• Review cycle: si las reglas globales se revisan trimestralmente y las del proyecto mensualmente

Así AGENTS.md pasa a ser una referencia compartida viva, no un archivo privado que cada uno reescribe.

4. Elección de despliegue: cómo elegir entre ChatGPT workspace, API Key y Bedrock

Las organizaciones necesitan decidir qué ruta de cuenta quieren adoptar. Las tres opciones tienen fortalezas, límites y usos distintos.

4.1 Tabla comparativa

Dimensión	ChatGPT Business/Enterprise	API Key	Amazon Bedrock
Autenticación	Inicio de sesión de ChatGPT	OPENAI_API_KEY	Bedrock API key o AWS IAM
Titular de facturación	Workspace de OpenAI	Cuenta de API de OpenAI	Cuenta de AWS
Gobernanza de equipo	Analytics Dashboard, managed requirements	Sin gobernanza nativa de equipo	AWS IAM y CloudTrail
Completitud de funciones	La más completa	La más flexible	Conjunto parcial de funciones (ver 4.2)
Cumplimiento / región	Regiones de OpenAI	Regiones de OpenAI	Regiones de AWS y residencia de datos
Soporte GovCloud	No	No	El modelo puede estar disponible, pero el soporte del proveedor de Codex es aparte (ver 4.3)
Mejor ajuste	Equipos pequeños o medianos que necesitan gestión de workspace	Desarrolladores que quieren integración flexible	Equipos centrados en AWS que necesitan facturación, IAM y controles de cumplimiento

4.2 Capacidades ausentes en Bedrock

A fecha de 2026-06-08, las siguientes capacidades no están disponibles en esta ruta:

• Fast Mode
• hosted web/file search
• computer use
• shell tool
• image generation tool
• remote MCP servers
• on-demand inference only no está soportado; usa Provisioned Throughput

Estas capacidades dependen de servicios alojados por OpenAI, herramientas alojadas o descubrimiento gestionado en la nube, así que quedan fuera de esta ruta. Si tu equipo depende de ellas, usa ChatGPT workspace o API Key.

4.3 Aclaración sobre GovCloud

Aquí hay dos hechos distintos:

1. GPT-5.4 en AWS GovCloud (US-West) está disponible

   • el modelo está disponible en GovCloud
   • GPT-5.4 puede invocarse a través de la API de Bedrock

2. El proveedor de Codex para Bedrock no soporta endpoints de GovCloud

   • el proveedor amazon-bedrock de Codex no soporta hoy los endpoints de Bedrock Mantle en regiones AWS GovCloud
   • no puedes configurar Codex contra Bedrock en GovCloud hoy

No escribas “Codex en Bedrock soporta GovCloud” como si fuera el mismo hecho.

4.4 Escenarios de uso

Elige la ruta según la organización:

ChatGPT Business/Enterprise

• equipos pequeños y medianos
• quieren administración de workspace
• quieren el conjunto de funciones más completo
• no necesitan facturación de AWS ni IAM

API Key

• desarrolladores que quieren integración flexible
• no necesitan gobernanza de equipo
• pagan directamente sobre una cuenta de API de OpenAI
• no necesitan administración de cumplimiento

Amazon Bedrock

• equipos centrados en AWS con cuentas, IAM y facturación ya existentes
• quieren agrupar costes bajo compromisos de AWS
• necesitan residencia de datos o regiones AWS concretas
• aceptan un conjunto parcial de funciones (ver 4.2)

5. Configuración y límites de Bedrock: autenticación nativa de AWS, funciones faltantes y riesgo de GovCloud

Los equipos que eligen Bedrock necesitan entender la configuración exacta, el método de autenticación, las capacidades que faltan y el límite de GovCloud.

5.1 Configurar el proveedor amazon-bedrock

Configura el proveedor en el archivo de Codex:

{
  "provider": "amazon-bedrock",
  "aws_region": "us-east-1",
  "model_id": "openai.gpt-5.5"
}

El ID del modelo y la región deben seguir la documentación oficial.

5.2 Autenticación nativa de AWS

La ruta de Bedrock usa autenticación nativa de AWS, no OPENAI_API_KEY:

• Bedrock API key: clave temporal, máximo 12 horas o la duración de la sesión, hereda permisos del principal IAM
• Credenciales AWS IAM: configuradas mediante un rol IAM o un usuario IAM

Para producción, se recomiendan claves temporales o roles IAM. Las claves de larga duración solo sirven para exploración.

5.3 Regiones comerciales de AWS compatibles

La documentación oficial actualmente soporta estas regiones comerciales de AWS:

• us-east-1
• us-west-2
• eu-west-1
• ap-northeast-1

Consulta la documentación de AWS Bedrock OpenAI models para ver la lista actual.

5.4 Gobernanza de claves Bedrock

Reglas de gobernanza para las claves de Bedrock:

• Short-term key: hasta 12 horas o la duración de la sesión, hereda permisos del principal IAM, recomendada para producción
• Long-term key: solo para exploración, no recomendada para producción
• CloudTrail logging: las llamadas API se registran en AWS CloudTrail; la clave no se guarda en texto plano
• IAM actions control: las acciones IAM pueden controlar quién crea y usa claves API

5.5 Lista repetida de capacidades ausentes

A fecha de 2026-06-08, las siguientes no están disponibles en Bedrock:

• Fast Mode
• hosted web/file search
• computer use
• shell tool
• image generation tool
• remote MCP servers
• on-demand inference only no está soportado; usa Provisioned Throughput

Si el equipo depende de estas funciones, cambia a ChatGPT workspace o API Key.

5.6 Riesgo de GovCloud (repetición)

Otra vez, separa estos dos hechos:

• GPT-5.4 de AWS está disponible en GovCloud (US-West): el modelo está disponible en GovCloud
• El proveedor de Codex para Bedrock no soporta endpoints de GovCloud: no puedes configurar Codex contra Bedrock en regiones AWS GovCloud hoy

Si tu equipo necesita GovCloud, no asumas que Codex ya puede apuntar allí.

6. Gobernanza y auditoría: dónde ver uso y registros de cumplimiento

Los responsables necesitan seguir adopción, uso e impacto de code review, y para eso necesitan salida de analytics y auditoría.

6.1 Comparación de las tres rutas de gobernanza

Ruta	Capacidad	Retardo	Mejor para
Analytics Dashboard	adopción, uso, feedback de code review	Los datos pueden retrasarse hasta 12 horas	Seguimiento del despliegue
Analytics API	buckets diarios/semanales, uso por workspace/usuario, desglose por cliente, métricas de Code Review	De casi tiempo real a unas horas	Gobernanza de costos y análisis profundo
Compliance API	exporta actividad de Codex y metadatos de auditoría	Depende de la integración con SIEM/eDiscovery	Auditoría de cumplimiento

6.2 Escenarios de uso

6.2.1 Seguimiento del despliegue

Usa Analytics Dashboard para ver adopción y uso del equipo:

• tasa de activación de miembros
• calidad del feedback de code review
• distribución de uso por cliente

Los datos del dashboard pueden retrasarse hasta 12 horas, así que sirven mejor para informes semanales o mensuales que para monitorización en tiempo real.

6.2.2 Gobernanza de costos

Usa Analytics API para análisis más profundo:

• separa el uso por workspace/usuario/modelo
• compara buckets diarios y semanales
• desglosa por cliente (Codex App/CLI/IDE/Cloud)
• resume métricas de Code Review

Es la ruta correcta para gobernanza interna de costos y trabajo de optimización.

6.2.3 Auditoría de cumplimiento

Usa Compliance API para exportar registros:

• actividad de Codex
• metadatos de auditoría
• integración con SIEM/eDiscovery
• soporte para revisión de cumplimiento

Es la vía adecuada para organizaciones reguladas como finanzas, sector público y salud.

6.3 Recomendación de ruta de gobernanza

• Analytics Dashboard: mejor para responsables técnicos y project managers que siguen el despliegue
• Analytics API: mejor para platform engineers que hacen gobernanza de costos y análisis profundo
• Compliance API: mejor para equipos de seguridad y cumplimiento que integran SIEM y eDiscovery

Las tres rutas pueden combinarse según las necesidades de la organización.

7. Ruta de despliegue del equipo: del piloto individual a la gobernanza organizacional

Muchas veces el equipo no sabe por dónde empezar, cómo dividir la adopción o cómo elegir la primera tanda de tareas piloto.

7.1 Marco de despliegue en tres etapas

Etapa 1: control individual (definir el límite de permisos)

Objetivo: asegurar que el límite de permisos de cada miembro sea controlable para que los archivos sensibles no se propaguen por máquinas locales.

Acciones clave:

• prohibir danger-full-access + approval_policy = "never" como valor por defecto del equipo
• proteger .env y secrets/ con deny globs
• usar :workspace_roots para limitar el área de trabajo

Criterio de éxito: ningún miembro puede acceder a archivos sensibles sin aprobación.

Etapa 2: piloto de equipo pequeño (convenciones compartidas + tareas de bajo riesgo)

Objetivo: unificar AGENTS.md y skills dentro del equipo pequeño, y luego empezar con tareas de bajo riesgo para verificar que el flujo funciona.

Acciones clave:

• escribir un AGENTS.md global (estilo y expectativas de test)
• escribir un AGENTS.md del proyecto (arquitectura, dependencias, despliegue)
• elegir tareas de bajo riesgo como generación de documentación, correcciones de lint y añadidos de tests
• evitar automatizar directamente despliegues de producción o lógica de pagos

Criterio de éxito: la mayoría del equipo usa el AGENTS.md compartido y no hay incidentes de seguridad importantes.

Etapa 3: gobernanza organizacional (managed requirements + Analytics/Compliance API)

Objetivo: elevar permisos y convenciones a gobernanza organizacional y conectar observabilidad y auditoría.

Acciones clave:

• configurar requisitos gestionados por grupo de usuarios
• conectar Analytics Dashboard/API para seguimiento de adopción y uso
• conectar Compliance API con SIEM
• revisar periódicamente permission profiles y allowlists de MCP

Criterio de éxito: el panel de gobernanza está en marcha y los registros de auditoría son trazables.

7.2 Tareas piloto sugeridas

Prioriza primero las tareas de bajo riesgo

Buenas tareas para la primera tanda de pilotos:

• generación de documentación: README, docs de API, limpieza de notas
• correcciones de lint: eslint, prettier, automatización de formato
• añadidos de test: tests unitarios y esqueletos de integración
• sugerencias de refactorización: mejoras de estructura con revisión humana

Evita la automatización directa

Malas tareas para la primera tanda de pilotos:

• despliegue en producción
• lógica de pagos
• cambios de permisos
• borrado de datos

Son tareas de alto riesgo y deberían esperar a que la gobernanza y la auditoría estén maduras.

7.3 Relación con el resto de la serie

Este artículo es la página de decisión para adopción de equipo; los siguientes pueden profundizar:

• estilo de escritura de AGENTS.md: cómo escribir reglas por capas, evitar truncación y mantenerlas
• bloqueos personales y sandboxes: problemas de permisos, configuración de sandbox y errores comunes
• integración Cloud/GitHub: desarrollo remoto, GitHub review, cloud tasks
• optimización de costos y cuota: habilidades para reducir tokens y controlar presupuesto
• automatización y tareas largas: disparadores programados, heartbeats y trabajos de varios días

Resumen y siguientes pasos

Si eres responsable técnico y estás desplegando Codex en un equipo, el orden debería ser:

1. Lee primero la configuración de permisos (secciones 1 y 2) para bloquear las combinaciones peligrosas
2. Estandariza las convenciones después (sección 3) para que AGENTS.md tenga una forma compartida
3. Elige la ruta de despliegue después (secciones 4 y 5) para decidir entre workspace, API Key y Bedrock
4. Conecta la gobernanza al final (sección 6) mediante Analytics y Compliance APIs

Después puedes pasar a módulos más concretos:

• estilo de escritura de AGENTS.md: cómo escribir reglas por capas, evitar truncación y mantenerlas
• bloqueos personales y sandboxes: problemas de permisos, configuración de sandbox y errores comunes
• integración Cloud/GitHub: desarrollo remoto, GitHub review, cloud tasks
• optimización de costos y cuota: habilidades para reducir tokens y controlar presupuesto
• automatización y tareas largas: disparadores programados, heartbeats y trabajos de varios días

Conceptos básicos relacionados:

• fundamentos de colaboración Git en equipo: Git flow, estrategia de ramas y flujo de code review
• secretos de CI y seguridad de permisos: secretos de GitHub Actions, límites de permisos y prácticas de seguridad