Problema

Los equipos que automatizan tareas en AWS con agentes de IA (Claude Code, Codex, etc.) suelen confiar en una regla de “preguntar antes de ejecutar cualquier comando que cambie el estado”. Esa regla se implementa en el propio agente o en una capa de filtrado de comandos. En la práctica, la regla es una política de comportamiento del modelo, no un control de seguridad. Cuando el modelo recibe una cadena manipulada que parece parte de la conversación normal, puede saltarse la regla y ejecutar comandos peligrosos sin confirmación.

El patrón que se repite es: una capa de control basada en el modelo o en un filtro de comandos es insuficiente. Si el agente está comprometido o si el filtro tiene falsos negativos, el agente puede ejecutar acciones con privilegios completos, como crear políticas de bucket, abrir puertos de seguridad o borrar recursos. La consecuencia es que la única defensa real pasa por los permisos que AWS impone a las credenciales usadas por el agente.

Causa

  1. Confianza en la lógica del modelo
    Los LLM no son máquinas de reglas; su salida depende del prompt y del contexto. Un atacante puede inyectar texto que haga que el modelo “piense” que la acción es segura, anulando la regla de confirmación.

  2. Filtros de comandos con falsos negativos
    Herramientas como Claude Code incluyen listas de patrones denegados para Bash o AWS CLI. Los bugs en esas listas permiten que comandos como aws s3api put-bucket-policy o gcloud compute firewall-rules create se ejecuten aunque estén marcados como prohibidos.

  3. Credenciales con privilegios amplios
    Cuando el agente usa una IAM role o access key con permisos de escritura en toda la cuenta, cualquier comando que logre pasar el filtro tiene impacto total. No hay “corte” adicional que impida la acción.

  4. Ausencia de defensa en profundidad
    En muchos setups solo se aplica una capa (regla del modelo o filtro). Falta una segunda capa que garantice que, aunque el agente sea malicioso, AWS rechace la operación.

Solución

La estrategia que mantiene la seguridad aunque falle cualquier capa de control de nivel superior es aplicar el principio de mínimo privilegio (least‑privilege) directamente en IAM. La idea es que las credenciales que el agente usa solo tengan permisos de lectura; cualquier intento de escritura será rechazado por AWS antes de que el comando llegue a ejecutarse.

Pasos clave

  1. Crear una política de solo‑lectura
    Definir una política JSON que incluya únicamente acciones Get*, List*, Describe* y Read* para los servicios que el agente necesita inspeccionar (S3, EC2, IAM, etc.). No incluir ninguna acción que modifique recursos.

  2. Asignar la política a un role o user dedicado
    Crear un role de IAM exclusivo para el agente y adjuntar la política de solo‑lectura. Si el agente necesita usar credenciales temporales, habilitar sts:AssumeRole con condiciones de origen (IP, VPC, etc.).

  3. Reforzar la capa de filtrado
    Mantener el filtro de comandos (lista de denegados) como segunda línea de defensa. Actualizarlo regularmente y probar con casos adversarios.

  4. Auditar y registrar
    Habilitar CloudTrail para todas las regiones y servicios relevantes. Configurar alertas en CloudWatch cuando se intente una acción denegada (AccessDenied) desde el role del agente.

  5. Validar la política antes de usarla
    Utilizar la herramienta aws iam simulate-principal-policy para comprobar que la política no permite acciones de escritura inesperadas.

Alternativas prácticas

  • Roles con condiciones de sesión: usar aws:RequestedRegion o aws:TagKeys para limitar aún más el contexto de ejecución.
  • Credenciales de solo‑lectura en contenedores: montar el role mediante IRSA (IAM Roles for Service Accounts) si el agente corre en EKS.
  • Uso de SCP (Service Control Policies) en una organización AWS para bloquear globalmente acciones de escritura a cualquier cuenta que use el role del agente.

Cuándo aplicar esta solución

  • Entornos donde un LLM ejecuta comandos AWS CLI (automatización, auditorías, generación de código).
  • Sistemas que exponen prompts a usuarios externos (chatbots, asistentes de soporte).
  • Proyectos con integración CI/CD que incluyen generación de scripts por IA.

Señales de que la solución es necesaria

  • Se observa que el agente necesita ejecutar comandos que modifican recursos.
  • Los filtros de comandos generan falsos negativos en pruebas de seguridad.
  • Los logs de CloudTrail muestran intentos de escritura desde el role del agente.

Casos donde no aplica

  • Cuando el agente solo necesita crear recursos (por ejemplo, un pipeline de despliegue). En ese caso, la política debe incluir los permisos de escritura específicos y seguir el mismo enfoque de mínimo privilegio, limitando a los recursos exactos que se crearán.

Código

# Política de solo‑lectura (ejemplo para S3 y EC2)
cat > read‑only‑policy.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket",
        "ec2:DescribeInstances",
        "ec2:DescribeSecurityGroups",
        "iam:GetUser",
        "iam:ListRoles"
      ],
      "Resource": "*"
    }
  ]
}
EOF

# Crear la política en AWS
aws iam create-policy \
  --policy-name ReadOnlyForAIAgent \
  --policy-document file://read-only-policy.json

# Crear el role y adjuntar la política
aws iam create-role \
  --role-name AIAgentReadOnlyRole \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name AIAgentReadOnlyRole \
  --policy-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):policy/ReadOnlyForAIAgent

Verificación

  1. Simular la política

    aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/AIAgentReadOnlyRole \
  --action-names s3:PutObject s3:DeleteObject ec2:TerminateInstances

    La salida debe mostrar EvalDecision: denied para todas las acciones de escritura.

  2. Ejecutar un comando prohibido

    aws s3api put-bucket-policy --bucket my-bucket --policy file://policy.json

    Con las credenciales del role, el comando debe devolver AccessDenied.

  3. Revisar CloudTrail
    Busca eventos con eventName = PutBucketPolicy y verifica que el userIdentity.arn corresponde al role del agente y que el errorCode sea AccessDenied.

Notas adicionales

  • Actualiza los filtros: los patrones denegados cambian con cada versión del modelo. Mantén un repositorio interno de pruebas de regresión para validar que los filtros siguen bloqueando comandos peligrosos.
  • Rotación de credenciales: aunque la política sea de solo‑lectura, rota las claves o usa credenciales temporales (sts:AssumeRole) cada 12‑24 h para limitar la ventana de exposición.
  • Separación de entornos: si el agente necesita inspeccionar varias cuentas, crea un role por cuenta y usa aws organizations para aplicar SCP que impidan escritura a nivel organizativo.
  • Monitoreo de anomalías: configura una regla de GuardDuty o una alerta de CloudWatch que dispare cuando el agente genere más de X llamadas Describe* en un corto período; podría indicar un intento de reconocimiento antes de un ataque.

Con esta arquitectura, incluso si el modelo de IA o el filtro de comandos se ven comprometidos, AWS actúa como la última barrera y evita cualquier cambio no autorizado. La clave está en no depender de la “buena voluntad” del agente, sino en encapsular la seguridad en la capa de autorización de la nube.