Permisos de infraestructura para agentes de IA y apply seguro

Los agentes de IA no deberían recibir un permiso permanente que signifique «aplicar cambios de infraestructura». Deben recibir una autorización limitada y temporal para aplicar un cambio revisado en una única cuenta de destino verificada, con un procedimiento de recuperación que un operador haya leído y aceptado.

He visto equipos confundir un plan de Terraform con un control de seguridad y un botón de aprobación con una decisión. Ninguno basta por sí solo. Un plan puede regenerarse contra otra cuenta. Una aprobación puede seguir vigente aunque cambie el commit. Una nota de rollback puede decir «revertir» cuando el cambio destruye datos o altera una dependencia que ya no existe.

El límite útil exige más: el agente prepara las evidencias, una persona las revisa y la ruta de ejecución se niega a continuar si las evidencias ya no describen la acción. Puede parecer excesivo hasta la primera vez que un asistente hereda el perfil de nube equivocado, lee una instantánea de estado obsoleta y dirige un comando perfectamente válido contra producción.

El permiso debe vincular una acción, no un cargo

Los permisos de infraestructura para agentes de IA deben autorizar una modificación concreta, no una categoría como «desplegar», «Terraform» u «operaciones de producción». Las categorías amplias parecen cómodas porque las personas piensan en roles. Sin embargo, las API de nube ejecutan solicitudes, y las solicitudes tienen destinos, parámetros, identidades y consecuencias.

Una autorización de apply útil debe vincular al menos estos datos:

• La revisión inmutable del código fuente y el directorio de configuración usados para crear el plan.
• El artefacto del plan revisado o su resumen SHA-256.
• La identidad de la cuenta de nube o del tenant de destino que informa la credencial de ejecución.
• La identidad de ejecución, el rol, la suscripción, el proyecto y la región permitida cuando corresponda.
• Una caducidad y una referencia de recuperación que indiquen al operador qué ocurrirá si hay que detener o revertir el apply.

Importa distinguir entre el permiso para calcular un cambio y el permiso para realizarlo. Permite que el agente inspeccione repositorios, llame a API de solo lectura, ejecute validaciones y proponga un plan. No trates esas actividades como prueba de que puede modificar producción. El acceso de descubrimiento suele revelar detalles operativos. El acceso de modificación cambia la factura, la disponibilidad y, a veces, las evidencias disponibles después de un incidente.

Un rol llamado InfrastructureDeployer no es un objeto de aprobación. Es un detalle de implementación. Si puede aplicar cualquier cosa en todas las cuentas cada vez que un proceso lo obtiene, tu proceso de aprobación depende de que las personas recuerden usarlo correctamente. Los agentes son lo bastante rápidos como para convertir esa prueba de memoria en un incidente.

El plan revisado debe ser exactamente el artefacto que se aplica

Un plan revisado solo tiene valor si el comando de apply consume ese mismo plan. Volver a ejecutar terraform plan después de que alguien aprueba el resultado crea un artefacto nuevo, aunque los archivos parezcan iguales.

La documentación de comandos de Terraform deja clara esta diferencia. terraform plan -out=FILE escribe un archivo de plan pensado para terraform apply FILE; terraform apply sin un plan guardado crea un plan nuevo antes de pedir confirmación. La segunda forma está bien en una sesión interactiva humana. Es incorrecta en un flujo de agente que afirma que una persona revisó los cambios propuestos.

Usa un plan guardado y muéstralo en JSON para revisarlo. Una secuencia mínima de shell sería esta:

set -euo pipefail

git rev-parse HEAD > evidence/source-revision.txt
terraform init -lockfile=readonly
terraform plan -out=evidence/change.tfplan
terraform show -json evidence/change.tfplan > evidence/change.json
shasum -a 256 evidence/change.tfplan > evidence/change.tfplan.sha256
terraform providers lock -platform=darwin_arm64

El resumen de salida tiene una forma sencilla:

f1f5f2...a94c  evidence/change.tfplan

El registro de aprobación debe copiar el resumen completo, no limitarse a adjuntar una captura de la terminal. El runner de apply lo verifica antes de la ejecución:

shasum -a 256 -c evidence/change.tfplan.sha256
terraform apply -input=false evidence/change.tfplan

Esto evita un fallo habitual: el agente abre una pull request, genera un plan, recibe un comentario de aprobación, obtiene después la rama main más reciente y ejecuta un plan nuevo. Un compañero puede haber integrado otro cambio entre esas acciones. El plan posterior puede añadir un borrado, cambiar la versión de una imagen o apuntar a otro alias de proveedor. La persona revisora aprobó el grafo propuesto ayer, no lo que el runner encuentra ahora.

Un plan binario de Terraform puede contener valores sensibles. No lo pegues en tickets ni chats. La representación JSON también puede revelar información sensible según los esquemas y valores del proveedor, así que redáctala solo mediante un proceso de revisión que comprendas. La redacción no debe eliminar las direcciones de recursos, las acciones, la identidad de destino ni los cambios de dependencias. Esos son precisamente los datos que necesita quien aprueba.

El patrón del plan guardado es más sólido cuando el entorno de ejecución también está fijado. Usa el mismo archivo de bloqueo de proveedores, la versión de Terraform, las variables, la configuración del backend y la selección del espacio de trabajo que crearon el plan. Si cambia cualquiera de esas entradas, descarta el plan y genera un paquete de revisión nuevo. Intentar rescatar una aprobación antigua es la forma en que los equipos convierten un control sensato en una representación vacía.

El destino indicado debe proceder de la credencial, no de una etiqueta

Un destino llamado prod no demuestra casi nada. Los repositorios copian nombres de directorios. Los espacios de trabajo se desvían. Las variables de entorno permanecen en las shells. Un agente puede seguir fielmente una configuración llamada producción mientras está autenticado en una cuenta de pruebas o, peor aún, en una cuenta de producción seleccionada por un perfil heredado.

Exige que la identidad de ejecución pregunte al plano de control de la nube quién es antes de planificar y de nuevo inmediatamente antes del apply. Guarda el resultado en el paquete de evidencias y compáralo con el destino aprobado.

Para una acción basada en AWS, una comprobación puede ser tan sencilla como esta:

aws sts get-caller-identity --output json > evidence/caller-identity.json
cat evidence/caller-identity.json

El resultado identifica la cuenta y la entidad principal:

{
  "UserId": "AROAXXXXX:apply-run",
  "Account": "123456789012",
  "Arn": "arn:aws:sts::123456789012:assumed-role/InfraApply/apply-run"
}

En Google Cloud, registra por separado la cuenta activa y el proyecto. En Azure, registra el ID de suscripción y el ID de tenant del contexto de credenciales. No dependas del nombre visible de una cuenta de nube, porque esos nombres pueden duplicarse. Los identificadores numéricos o globalmente únicos son menos cómodos de leer, pero mucho más seguros de ejecutar.

La comprobación previa al apply debe usar la misma ruta de credenciales que el apply. Parece obvio, pero los wrappers lo incumplen a menudo. Un script de planificación puede usar un rol asumido de corta duración mientras un comando posterior hereda el perfil predeterminado de un desarrollador. Un agente que llama a un runner remoto puede planificar localmente y aplicar de forma remota con una identidad de servicio que nunca inspeccionó.

Incluye en el runner una aserción del destino que pueda comprobar una máquina. Este ejemplo rechaza una cuenta AWS inesperada:

expected_account="123456789012"
actual_account="$(aws sts get-caller-identity --query Account --output text)"

if [ "$actual_account" != "$expected_account" ]; then
  printf 'refusing apply: expected account %s, got %s\n' \
    "$expected_account" "$actual_account" >&2
  exit 1
fi

Esta comprobación no sustituye la revisión humana. Detecta una clase completa de errores antes de que una llamada a la API modifique la infraestructura. Combínala con una configuración del proveedor que declare la cuenta o suscripción permitida cuando el proveedor admita esa protección. Una aserción a nivel del proveedor y otra a nivel del runner fallan de forma independiente, que es exactamente lo que necesitas.

La deriva del estado vuelve inseguras las aprobaciones antiguas

Un plan describe el cambio deseado en relación con un estado observado concreto. No promete que ese estado siga existiendo una hora después.

Otro ingeniero puede desplegar. Un autoscaler puede añadir o eliminar recursos. Un servicio de nube puede rotar una conexión, sustituir un nodo o terminar una operación asíncrona. Terraform suele detectar parte de esto al actualizar el estado, pero la respuesta segura ante una diferencia importante no es continuar porque el plan pareciera pequeño antes. Genera un artefacto nuevo y revisa el diff nuevo.

La caducidad resuelve gran parte del problema. Haz que una aprobación dure lo bastante poco como para que una persona aún recuerde por qué la aceptó. La duración adecuada depende del proceso de lanzamiento, pero debe cubrir una ventana de ejecución definida, no todo un día laboral por defecto. Cuando se cierre la ventana, obliga a crear un plan nuevo, repetir la verificación del destino y solicitar una aprobación nueva.

También necesitas una regla de invalidación. Rechaza un plan cuando ocurra cualquiera de estos cambios después de la revisión:

• Cambia la revisión de origen, el conjunto de variables, la referencia del módulo o el archivo de bloqueo del proveedor.
• El espacio de trabajo, backend, cuenta, suscripción, tenant, proyecto o región difiere de las evidencias aprobadas.
• El resumen del plan no coincide con el registro de aprobación.
• Un bloqueo de estado, una actualización o una precondición relevante informa de un conflicto que cambia la acción propuesta.

No uses «no hay cambios en la pull request» como sustituto de esta regla. Las fuentes de datos externas, los valores predeterminados del proveedor, el estado actual y las credenciales quedan fuera del diff. La infraestructura tiene demasiadas entradas para que una aprobación basada solo en el código fuente sostenga toda la decisión.

Algunos equipos intentan resolver la deriva permitiendo que el agente vuelva a planificar automáticamente hasta que el plan quede limpio. La recomendación es popular porque reduce el tiempo de espera. Es incorrecta para cuentas de consecuencias importantes. La planificación automática puede convertir una actualización revisada en un reemplazo no revisado. Permite la planificación automática para una vista previa de solo lectura si quieres, pero exige otra revisión humana antes de modificar nada.

El rollback debe describir un estado recuperable

Una ruta de rollback clara explica cómo devuelven los operadores el servicio a una condición aceptable, quién puede hacerlo, qué datos pone en riesgo y cuándo debe detenerse. «Ejecuta Terraform destroy» y «revierte el commit» rara vez cumplen ese estándar.

Los cambios de infraestructura pertenecen a distintas clases de recuperación. Tratarlos igual crea una falsa sensación de seguridad.

Un cambio de configuración reversible, como una regla de security group o un peso de balanceador, puede admitir un apply inverso directo desde una revisión conocida como correcta. La sustitución de un grupo de instancias puede necesitar comprobaciones de capacidad antes de revertirse. Una migración de base de datos puede ser irreversible después de escribir datos, por lo que la recuperación puede consistir en una migración posterior, una restauración desde una copia de seguridad verificada o una feature flag que detenga las escrituras nuevas.

Escribe la ruta de rollback en lenguaje operativo. Un registro útil responde a estas preguntas:

1. ¿Qué condición observable indica que debemos hacer rollback, como comprobaciones de salud fallidas, aumento de las tasas de error o un smoke test fallido?
2. ¿Qué revisión, conjunto de parámetros o comando exacto devuelve el servicio a la configuración conocida como correcta?
3. ¿Qué requisito previo debe existir, como un punto de restauración de una copia, capacidad libre o una ventana de mantenimiento aprobada?
4. ¿Quién tiene autoridad para actuar si la sesión del agente terminó o la persona que aprobó no está disponible?
5. ¿Qué no puede restaurarse automáticamente, incluidos registros, secretos, direcciones públicas o cambios manuales en la nube?

Una ruta de recuperación debe probarse antes del incidente, no expresarse como una frase optimista durante el incidente. Si un equipo considera reversible un cambio, ejecuta la reversión en un entorno representativo y registra las condiciones que hicieron que funcionara. Los proveedores pueden conservar el nombre de un recurso eliminado, las cuotas pueden impedir su recreación y los servicios dependientes pueden almacenar en caché un endpoint antiguo. Estos detalles aparecen cuando el cambio ya está bajo presión.

Para los cambios destructivos, exige una decisión separada. Eliminar un recurso después de revisar un plan no equivale moralmente a actualizarlo. El agente debe mostrar las direcciones eliminadas, las acciones de reemplazo, la configuración de retención y las evidencias de copia de seguridad de una forma que no pueda desaparecer entre cientos de actualizaciones inofensivas. Si el cambio incluye una base de datos, un almacén de objetos, una vinculación de identidad, un límite de red o una zona DNS, asegúrate de que la persona responsable de la recuperación haya leído el plan.

El runner de apply debe rechazar la ambigüedad

El runner que realiza la modificación debe aplicar por sí mismo los datos de la aprobación. Un bot que puede recibir un mensaje de chat que diga «adelante» no tiene una forma fiable de distinguir un plan confirmado de una instrucción informal.

Usa un registro de aprobación estructurado. Puede vivir en un sistema de despliegue firmado, en un registro protegido de un repositorio o en otro almacén controlado. La elección del almacenamiento importa menos que los campos y la verificación. Este JSON ilustrativo muestra la estructura:

{
  "change_id": "infra-2025-041",
  "source_revision": "4ad7d2f",
  "plan_sha256": "f1f5f2...a94c",
  "target": {
    "cloud": "aws",
    "account_id": "123456789012",
    "region": "us-east-1",
    "workspace": "production"
  },
  "approved_by": "operator-id",
  "expires_at": "2025-04-18T15:30:00Z",
  "rollback_ref": "runbook: payments-api capacity revert"
}

El agente puede preparar esta solicitud, pero no debe escribir approved_by ni ampliar expires_at. El servicio de aprobación debe añadir esos datos después de que una persona vea el cambio renderizado. El runner de apply lee el registro, vuelve a calcular el resumen del plan, comprueba la revisión de origen y la identidad de destino, y marca la autorización como consumida antes de enviar la primera solicitud de escritura.

Consumir una aprobación importa. Sin ello, un agente puede volver a intentar una acción aprobada más tarde, cuando el entorno haya cambiado. Un apply fallido también necesita un estado explícito. No lo marques como completado simplemente porque el runner emitió un comando. Registra si Terraform terminó correctamente, si una operación de la API de nube sigue pendiente y si un operador aceptó el estado resultante.

Mantén reducida la superficie de escritura del agente. Puede necesitar llamadas HTTP para API de despliegue o acceso SSH a un runner controlado, pero nunca debería recibir en su contexto un secreto de nube reutilizable. Sallyport conserva las credenciales API y SSH en su bóveda cifrada mientras ejecuta la acción solicitada y devuelve el resultado al agente. Esa configuración ayuda a evitar que se copien las credenciales, pero no vuelve segura una solicitud de apply imprecisa.

La aprobación por llamada debe rodear el límite peligroso

La aprobación por llamada tiene un lugar en el trabajo de infraestructura, pero no puede sustituir la revisión del artefacto. Si un agente pide permiso para cada llamada a la API de nube, los operadores aprobarán una secuencia larga sin entender el resultado conjunto. Eso es fatiga de aprobación y enseña a las personas a hacer clic sobre el único control que tienen.

Coloca la intervención humana donde decide algo importante: aprobar un plan vinculado a un destino y permitir después una ejecución de apply limitada. Reserva las confirmaciones individuales para acciones con un radio de impacto inusual, como rotar secretos, eliminar un objeto protegido, usar acceso de emergencia o ejecutar un comando fuera del contrato esperado del runner.

La autorización por sesión de Sallyport puede establecer que un proceso específico del agente puede usar un canal de acción durante su ejecución actual, mientras que las claves por llamada pueden exigir una confirmación aparte para credenciales sensibles. Es un límite de credenciales claro. Tu flujo de despliegue aún debe definir qué llamada cuenta como un apply aprobado y qué credenciales merecen la fricción de una aprobación por llamada.

Una persona debería ver suficientes evidencias para decidir sin leer el tráfico bruto del proveedor. Muestra las direcciones de recursos agrupadas por acción, los reemplazos y borrados por separado, la identidad de destino, la revisión de origen, el resumen, la caducidad y la referencia de rollback. Después, ofrece acceso al plan completo a quien lo necesite. Ocultar un cambio destructivo entre cien actualizaciones es un fallo de presentación, no del operador.

Un apply fallido requiere una decisión distinta de uno correcto

Terraform puede devolver un fallo después de haber cambiado varios recursos. Los planos de control de nube también pueden aceptar una solicitud y terminarla más tarde. Tratar cualquier código de salida distinto de cero como «no ocurrió nada» es uno de los hábitos más peligrosos de las operaciones automatizadas.

Cuando un apply falla, congela los reintentos automáticos. Captura la salida del runner, la información del bloqueo de estado, la identidad de destino y el subconjunto de recursos que se completó. Después inspecciona el entorno real antes de elegir una respuesta. Un reintento a ciegas puede agravar un fallo parcial, mientras que un rollback inmediato puede eliminar un recurso intermedio que el proveedor todavía está creando.

Usa esta secuencia de decisión:

1. Confirma la identidad actual en la nube y recopila el estado real de cada recurso mencionado en la operación fallida.
2. Determina si el estado deseado puede completarse de forma segura, si puede revertirse sin riesgo o si requiere un plan de reparación.
3. Genera un plan nuevo a partir del estado actual y haz que un operador lo revise como un cambio nuevo.
4. Registra la decisión sobre el incidente junto a la aprobación original, incluidas las acciones manuales que Terraform no puede representar.

Aquí es donde los registros de auditoría demuestran su valor. Conserva juntos la revisión de origen, el resumen del plan, la identidad de aprobación, las evidencias del destino, la transcripción de comandos, el estado resultante y la decisión posterior. Un registro de eventos que evidencie cualquier manipulación es mejor que capturas distribuidas por hilos de chat, porque quienes responden al incidente necesitan establecer la secuencia, no reconstruir la intención de memoria.

No prometas que la automatización deshará todos los apply fallidos. Algunos cambios requieren a una persona que entienda las dependencias del servicio, la durabilidad de los datos y el impacto en los clientes. El agente puede recopilar evidencias rápidamente. No debería inventar una operación de recuperación porque la canalización espera un resultado correcto.

Haz que el primer lanzamiento en producción sea deliberadamente aburrido

El primer apply en producción mediado por un agente debe cambiar algo pequeño, reversible y observable. Elige un ajuste de configuración conocido con un procedimiento de recuperación ya probado, no una migración, un rediseño de red o una rotación de secretos que afecte a varios consumidores.

Ejecuta el flujo completo en condiciones normales: genera el paquete de evidencias, verifica la cuenta exacta, revisa el plan renderizado, aprueba el resumen, aplica el artefacto guardado, inspecciona el resultado y consume la autorización. Después ejecuta un simulacro de fallo controlado. Haz caducar una aprobación, modifica la revisión de origen o apunta el runner a una cuenta no aprobada, y confirma que el runner se niega a actuar.

Estas pruebas de rechazo importan más que un despliegue correcto por el camino feliz. Cualquier herramienta parece disciplinada cuando la cuenta, el plan y el estado coinciden. El control demuestra su valor cuando un operador con prisa, un artefacto obsoleto o un agente confundido le pide hacer algo incorrecto y se detiene.

No amplíes el modelo de permisos porque el primer lanzamiento parezca lento. Mide dónde se emplea el tiempo de revisión. Si las personas dedican tiempo a comparar identificadores de cuenta, mejora la presentación de evidencias. Si los planes contienen demasiados cambios no relacionados, corrige la propiedad de los módulos o los límites del estado. Si las notas de rollback son débiles, exige a los equipos de servicio que las escriban y prueben. El acceso amplio y permanente no soluciona un proceso de lanzamiento incómodo; solo oculta la debilidad hasta que un agente llega a ella.