Agentes en la operación cloud: primero solo lectura, y después pull requests

La operación cloud parece la tarea perfecta para un agente. La información está toda en APIs, las preguntas son repetitivas, las respuestas exigen correlacionar cinco servicios y a nadie le divierte hacerlo a las once de la noche.

Es una buena tarea para un agente. Y es un pésimo sitio donde darle acceso de escritura, y el hueco entre esas dos frases es donde está todo el diseño.

Empieza por el trabajo que es pura lectura

Antes de que nada escriba, hay mucho valor en un agente que solo mira:

Investigación de incidentes. «La latencia del servicio de checkout se ha duplicado a las 14:20, ¿qué cambió?» Un agente con lectura sobre CloudWatch o Cloud Monitoring, el histórico de despliegues, las métricas del balanceador y los datos de rendimiento de la base de datos puede correlacionar esas cuatro líneas temporales en noventa segundos. No siempre acertará. Siempre producirá una lista más corta que una persona empezando de cero, y eso es el trabajo de los cinco primeros minutos de un incidente.

Arqueología de costes. «¿Por qué subió la factura un 18 por ciento el mes pasado?» Los datos de coste son una tabla grande con un esquema incómodo, y la pregunta es una serie de consultas cada vez más específicas. Esto está muy cerca del trabajo ideal para un agente, y no necesita ninguna escritura.

Deriva e inventario. Qué existe que no está en Terraform, qué grupos de seguridad no se usan, qué instantáneas son anteriores a la persona que las creó. Todo lectura.

Documentar lo que de verdad hay. Generar una descripción de arquitectura precisa a partir de la cuenta viva, que suele ser más veraz que el diagrama del Confluence.

Dale ReadOnlyAccess menos las acciones que leen secretos —secretsmanager:GetSecretValue, ssm:GetParameter con descifrado, kms:Decrypt—, porque si no una política de solo lectura le entrega igualmente todas las credenciales de la cuenta. Esa exclusión es el paso que más se olvida.

Después déjale escribir, pero solo en git

Cuando el agente deba cambiar algo, la salida es una pull request, no una llamada a la API.

El bucle: el agente investiga, propone un cambio en Terraform, abre una rama, la integración continua ejecuta plan, una persona lee el plan y lo integra. Todo lo que hacía seguro el cambio antes —revisión, salida del plan, comprobaciones de política, traza de auditoría, camino de vuelta atrás— sigue funcionando, y el agente encaja en un proceso en el que tu equipo ya confía.

Aquí es además donde los agentes son de verdad fuertes con infraestructura, porque Terraform les da un bucle de realimentación. plan y validate le dicen al agente que se equivocó antes de que tenga que decírselo una persona, y toda la diferencia de calidad entre la salida de un agente con y sin realimentación aparece justo aquí.

Pon política como código en la tubería y cubrirá al agente gratis: las reglas de Checkov, Conftest o Sentinel no distinguen si el HCL lo escribió una persona o un modelo. Si ya las ejecutas, ya tienes casi todo el control que necesitas.

El conjunto estrecho de acciones directas que merece la pena permitir

Hay una categoría de operación donde esperar a una pull request desvirtúa el propósito: escalar un grupo de nodos durante un pico, reiniciar una tarea atascada, rotar una clave tras una alerta.

Si las permites, acótalas a fondo. Una lista fija de operaciones concretas, nunca una capacidad general de API. Acotado de recursos por etiqueta, para que el agente solo actúe sobre lo que encajó en la política. Topes de magnitud: escalar como mucho a N, nunca terminar más de una instancia por ventana. Un límite de frecuencia aplicado fuera del agente. Y una notificación inmediata a un canal con el motivo y un botón de deshacer.

Es la misma estructura que acotar las escrituras de cualquier agente, aplicada a un radio de acción que resulta ser tu producción.

Qué no automatizar

Nada que implique cambios de política IAM, nada que toque el esquema de una base de datos de producción, nada que borre. No porque un agente no sepa, sino porque son las operaciones donde un error no se recupera y el tiempo ahorrado son minutos. El valor de automatizar es proporcional a la frecuencia, y estas son raras.

Qué hacer esta semana

Crea un rol de solo lectura con las acciones que leen secretos excluidas, apunta un agente a él y hazle la pregunta con la que empezó tu último incidente. La respuesta, acierte o no, te dirá en una tarde si merece la pena desarrollarlo, y no puede cambiar nada mientras lo averiguas.