Problema

Los equipos que usan agentes de IA (Claude, Cursor, Kiro, Cline, etc.) para generar código a menudo necesitan validar la seguridad de la infraestructura AWS antes de aplicar cambios. El flujo típico implica:

  1. Exportar una lista de recursos (ARN, IDs) a un servicio externo.
  2. Ejecutar un escáner de CNAPP o una herramienta de compliance.
  3. Revisar los resultados y volver a la IA para que proponga correcciones.

Este proceso rompe la premisa de “read‑only” y “no‑exfiltración” que muchos clientes exigen. Cada vez que la IA recibe un ARN sin tokenizar, el dato potencialmente viaja a servidores externos, lo que genera riesgos de exposición y problemas de cumplimiento (PCI, HIPAA, etc.). Además, la mayoría de los dashboards de seguridad están diseñados para uso humano, no para consumo directo por un modelo de lenguaje.

En entornos donde los agentes de IA son parte del pipeline de CI/CD, la latencia de llamadas a APIs externas y la necesidad de mantener credenciales limitadas hacen que la integración sea frágil. El patrón problemático es: un motor de análisis de seguridad que vive fuera del entorno local y que necesita datos sin anonimizar.

Causa

  1. Diseño centrado en UI – Las soluciones CNAPP tradicionales asumen un dashboard web; no exponen una API que acepte datos tokenizados.
  2. Falta de tokenización previa – Los scripts de extracción suelen enviar los IDs tal cual, sin aplicar hashing o cifrado local.
  3. Credenciales demasiado amplias – A menudo se usan roles con permisos de escritura, lo que aumenta la superficie de ataque.
  4. Dependencia de servicios gestionados – Cuando el motor de análisis está alojado en la nube del proveedor, cualquier llamada implica salida de red.
  5. Ausencia de grafo de infraestructura en tiempo real – Sin un modelo de topología actualizado, la IA solo recibe información estática, lo que dificulta la simulación de “fixes”.

Solución

Una arquitectura que permite a los agentes de IA ejecutar análisis de seguridad localmente, manteniendo los IDs tokenizados antes de que el modelo los vea, resuelve los puntos anteriores. El enfoque se divide en tres capas:

1. Preparación del entorno local

  • Instalar un servidor MCP (Modular Compute Provider) que contenga el motor de análisis. El proyecto original lo distribuye como un paquete npm ejecutable, pero cualquier contenedor Docker con Node.js funciona.
  • Crear un rol IAM de solo lectura con permisos iam:List*, ec2:Describe*, s3:ListBucket, etc. Este rol nunca podrá modificar recursos.
  • Configurar la tokenización: antes de pasar cualquier ARN a la IA, aplicar un hash SHA‑256 con una sal única por máquina. El motor MCP debe aceptar los hashes y mapearlos internamente a los IDs reales.

2. Construcción del grafo de infraestructura

  • El servidor MCP consulta AWS usando el rol de solo lectura y genera un grafo dirigido donde los nodos son recursos y los bordes representan relaciones (por ejemplo, un ELB que apunta a una instancia EC2).
  • Se emplea el algoritmo de Dijkstra ponderado para calcular caminos de ataque desde Internet hasta los datos sensibles. Los pesos pueden basarse en factores como exposición pública, grupos de seguridad abiertos o políticas de bucket.

3. Interfaz con el agente de IA

  • El agente recibe solo los hashes de los recursos y una descripción resumida (tipo, zona, etiquetas). Gracias a la tokenización, el modelo nunca ve el ARN real.
  • Cuando el agente propone una corrección (p.ej., “remover regla inbound 0.0.0.0/0 del SG-123”), el motor MCP simula el cambio en el grafo y recalcula los caminos de ataque, devolviendo un “blast radius” estimado.
  • Si la simulación es satisfactoria, el operador puede aplicar la corrección usando Terraform, CloudFormation o la consola, manteniendo la separación entre IA y ejecución real.

4. Implementación práctica (pasos resumidos)

  1. Instalar MCP 
    npx u/emfirge/mcp install
  2. Configurar credenciales
    Exportar AWS_PROFILE que apunte a un perfil con el rol de solo lectura. 
    export AWS_PROFILE=read‑only‑role
  3. Iniciar el servidor 
    mcp serve --port 8080
  4. Conectar el agente – En la configuración del agente, indicar la URL http://localhost:8080 y la clave de sal para la tokenización.

Cuándo aplicar esta solución

  • Entornos con requisitos de compliance que prohíben la transmisión de ARN fuera del perímetro.
  • Pipelines CI/CD automatizados donde la IA genera código que modifica infraestructura.
  • Equipos que usan agentes de IA para revisión de seguridad y necesitan retroalimentación inmediata sin latencia de red.
  • Casos donde el rol de IAM disponible es de solo lectura y no se quiere escalar privilegios.

No aplicar si:

  • La infraestructura está completamente aislada y no necesita análisis dinámico.
  • No se dispone de un entorno local con suficiente capacidad de cómputo para ejecutar el motor (el grafo de grandes cuentas puede consumir varios GB de RAM).
  • La política de la organización prohíbe ejecutar software de terceros no firmado.

Código

# 1. Instalar el motor MCP (requiere Node.js >= 18)
npx u/emfirge/mcp install

# 2. Exportar credenciales de solo lectura
export AWS_PROFILE=read-only-role

# 3. Iniciar el servidor local en puerto 8080
mcp serve --port 8080

# 4. Generar token de sal (único por máquina)
export TOKEN_SALT=$(openssl rand -hex 16)

# 5. Ejecutar una petición de análisis (ejemplo con curl)
curl -X POST http://localhost:8080/analyze \
  -H "Content-Type: application/json" \
  -d '{
        "resourceHashes": ["a1b2c3d4...", "e5f6g7h8..."],
        "salt": "'"$TOKEN_SALT"'"
      }'

Verificación

  1. Conexión al servidor – curl http://localhost:8080/health debe devolver {"status":"ok"}.
  2. Tokenización correcta – Verificar que los hashes enviados no aparecen en los logs del servidor sin estar acompañados de la sal.
  3. Grafo generado – La respuesta del endpoint /graph debe contener nodos con campos type, region y hash. No debe haber campos arn ni resourceId.
  4. Simulación de fix – Enviar una petición a /simulate con una acción (p.ej., removeIngress). La respuesta debe incluir newBlastRadius y affectedPaths. Si el valor disminuye, la simulación funciona.
  5. Auditoría – Revisar los archivos de log del MCP; deben registrar solo hashes y acciones, sin datos sensibles.

Notas adicionales

  • Sal única por máquina: Cambiar la sal cada vez que se reinicia la máquina evita que un atacante reutilice hashes capturados.
  • Persistencia del grafo: En cuentas con miles de recursos, guardar el grafo en memoria puede agotar RAM. Considerar una base de datos ligera (SQLite) para cachear resultados entre ejecuciones.
  • Actualizaciones de permisos: Si el rol de solo lectura necesita nuevos permisos (p.ej., para nuevos servicios), añádalos con la mínima amplitud posible; el motor MCP solo consulta lo necesario.
  • Integración CI: En pipelines de GitHub Actions, montar el contenedor MCP como un job previo a la fase de generación de código por IA garantiza que la IA siempre trabaje con datos tokenizados.
  • Limitaciones de Dijkstra: El algoritmo ponderado asume que los pesos son estáticos durante la ejecución. Si la topología cambia rápidamente (autoscaling), volver a generar el grafo antes de cada simulación es esencial.