AWS MCP Server: el agente que terminó 47 instancias EC2
AWS MCP Server entregó acceso a tus APIs de AWS a agentes de inteligencia artificial en mayo de 2026, y con él llegó un incidente de seguridad con credenciales en AWS MCP Server que ya generó incidentes reales: un dev le pidió a Copilot “limpiar instancias EC2 viejas” y el agente terminó 47 instancias en tres regiones, incluyendo una que procesaba conciliaciones de pagos. La factura de AWS ese mes: USD 14.000, contra los USD 3.200 habituales.
En 30 segundos
- AWS MCP Server salió a disponibilidad general en mayo de 2026 y permite que agentes IA (Copilot, Claude) ejecuten comandos sobre tu infraestructura AWS en lenguaje natural.
- No expone API keys directas, pero delega permisos a través de roles IAM, lo que puede ser igual de peligroso si ese rol tiene demasiados permisos.
- El incidente más documentado hasta ahora: un agente terminó 47 instancias EC2 tras recibir una instrucción ambigua de “limpieza”, generando USD 10.800 en pérdidas extra.
- Las tres configuraciones más riesgosas son: roles IAM con permisos de administrador, ausencia de CloudTrail, y credenciales hardcodeadas en el entorno.
- Se puede usar de forma segura, pero requiere roles con permisos mínimos, monitoreo activo y validación de comandos antes de ejecutar acciones destructivas.
El riesgo real: el caso de los USD 14.000
Ponele que un dev de tu equipo quiere hacer limpieza de recursos. Le dice a Copilot Cloud Agent: “terminá las instancias EC2 que no se están usando.” El agente interpreta “no se están usando” como “bajo tráfico de red en las últimas 24 horas”. Ejecuta. 47 instancias caen en us-east-1, eu-west-1 y ap-southeast-2.
Una de esas instancias procesaba reconciliaciones de pagos en un job que corría de madrugada, sin tráfico visible de día. La factura ese mes fue USD 14.000, contra los USD 3.200 normales. Este caso específico fue documentado en una revisión técnica publicada el 26 de mayo de 2026, basada en el primer walkthrough práctico de AWS MCP Server que circuló en la comunidad de desarrollo japonesa.
Lo que hace que el caso sea relevante no es que el agente “se equivocó” en algún sentido técnico. Ejecutó exactamente lo que le pidieron. El problema es que la instrucción era ambigua, el rol IAM tenía permisos para terminar instancias en todas las regiones, y no había ningún mecanismo que obligara al agente a confirmar antes de ejecutar acciones destructivas irreversibles.
¿Qué es AWS MCP Server? La definición sin adornos
AWS MCP Server es un servidor que implementa el Model Context Protocol (MCP) para exponer capacidades de AWS a agentes de IA. MCP es un estándar abierto que define cómo los agentes (Claude, Copilot, Cursor) pueden descubrir y ejecutar herramientas externas de forma estructurada. Según la documentación oficial de AWS, el MCP Server es el componente central del AWS Agent Toolkit, disponible a partir de mayo de 2026.
En términos prácticos: cuando Copilot Cloud Agent se conecta al AWS MCP Server, recibe un catálogo de herramientas disponibles (listar recursos, describir configuraciones, modificar ajustes, terminar instancias). Después traduce tus instrucciones en lenguaje natural a llamadas concretas a esas herramientas, que a su vez disparan las APIs de AWS.
Sin consola. Sin CLI. Sin Terraform. Eso es exactamente lo que lo hace atractivo y, al mismo tiempo, lo que concentra el riesgo. Cubrimos ese tema en detalle en cómo cada plataforma CI/CD maneja credenciales.
Cómo funciona la autenticación: dónde viven los permisos
Acá viene lo bueno: AWS MCP Server no expone tus API keys directamente al agente. La autenticación usa IAM roles y SigV4 (el sistema de firma de requests de AWS), con soporte para OAuth 2.1 en los flujos de autorización delegada.
Pero “no expone keys directas” no significa que el agente no tenga permisos. Cuando configurás el MCP Server, le asignás un rol IAM. Ese rol define qué puede hacer el agente en tu cuenta de AWS. Si el rol tiene permisos de administrador, el agente tiene permisos de administrador. La diferencia entre “tener una API key con acceso total” y “tener un rol IAM con acceso total” es técnicamente real pero prácticamente irrelevante para el daño que puede causar.
La recomendación del tutorial japonés que inició este ciclo de análisis era correcta: usar un rol con alcance acotado. El problema es que “acotado” requiere que alguien se siente a pensar exactamente qué permisos necesita el agente, algo que en la práctica se omite cuando el objetivo es llegar rápido a la demo.
Las 3 configuraciones que generan incidentes
1. Roles IAM con permisos de administrador
El error más común. Alguien configura el MCP Server en desarrollo con un rol que tiene la política AdministratorAccess porque “es más fácil para probar”. Ese rol termina en producción porque nadie lo revisó. El agente puede hacer cualquier cosa en tu cuenta: crear usuarios IAM, modificar políticas de seguridad, vaciar buckets S3, terminar instancias.
Una política IAM segura para un agente de gestión de instancias EC2 se ve así (describe y lista, nunca terminate ni modify):
| Permiso | Seguro (read-only) | Peligroso (admin) |
|---|---|---|
| EC2 describe instances | Sí | Sí |
| EC2 terminate instances | No | Sí |
| EC2 modify instance | No | Sí |
| IAM manage users | No | Sí |
| S3 delete objects | No | Sí |
| CloudTrail read logs | Sí | Sí |
En gestión segura de secretos en tuberías de CI/CD profundizamos sobre esto.
2. Sin auditoría CloudTrail/CloudWatch
Si un agente ejecuta una acción destructiva y no tenés CloudTrail activado, no sabés qué pasó hasta que alguien nota que algo falta. CloudTrail registra todas las llamadas a APIs de AWS, incluyendo quién las hizo, cuándo y desde qué IP. Con MCP, eso significa que cada acción del agente queda trackeada al ARN del rol IAM que usaste. Sin eso, el diagnóstico post-incidente es prácticamente imposible.
3. Credenciales hardcodeadas en el entorno
Algunos setups de MCP Server (especialmente los que siguen tutoriales de YouTube de dudosa procedencia) configuran las credenciales como variables de entorno estáticas o directamente en archivos de configuración. AWS recomienda explícitamente usar IAM roles en lugar de credenciales hardcodeadas, usando instance profiles o roles de ECS task si el servidor corre en AWS, y credenciales temporales via STS si corre fuera.
Incidentes documentados: no es paranoia
El caso de los USD 14.000 no es el único. En febrero de 2026, incidentes de disponibilidad de AWS involucraron agentes de IA con permisos excesivos, según el análisis publicado en Segu-Info. Los detalles exactos no están todos disponibles públicamente, pero el patrón común es consistente: agentes con roles demasiado permisivos ejecutando acciones a escala que ningún humano haría manualmente.
Amazon Q Developer, el asistente de desarrollo propio de AWS, también generó reportes de acciones no esperadas cuando los usuarios le dieron acceso a entornos con políticas IAM amplias. ¿Alguien verificó de forma independiente el alcance total de esos incidentes? Todavía no, al menos no en publicaciones auditadas.
Lo que sí está documentado es el patrón: instrucción ambigua + rol con muchos permisos + sin confirmación previa = acción destructiva a velocidad de máquina.
Configuración segura paso a paso
Si vas a usar AWS MCP Server, este es el mínimo que tenés que tener antes de conectar un agente a producción:
- Rol IAM con permisos mínimos: definí exactamente qué servicios y acciones necesita el agente. Empezá con solo lectura (
Describe*,List*,Get*) y agregá write solo donde sea indispensable y con condiciones explícitas. - Condiciones en las políticas IAM: podés restringir por región, por tag de recurso, o por horario. Un agente que solo necesita trabajar con instancias tagueadas como
Env=Devno debería poder tocar nada conEnv=Prod. - CloudTrail habilitado en todas las regiones: no opcional. Logs a S3 con retención mínima de 90 días y alertas en CloudWatch para eventos críticos (terminateInstances, deleteObjects, deleteTable).
- Validación de comandos destructivos: si tu arquitectura lo permite, implementá un paso de confirmación antes de que el agente ejecute acciones irreversibles. Algunos frameworks de agentes soportan un “human-in-the-loop” explícito para este tipo de operaciones.
- Límites de presupuesto en AWS Budgets: configurá alertas en USD para detectar anomalías de costo antes de que escalen. No previene el daño, pero lo detecta rápido.
Para entornos en donweb.com u otros proveedores cloud que expongan APIs compatibles, los mismos principios de permisos mínimos aplican: cualquier integración MCP debería tener su propio rol o usuario con acceso acotado al servicio específico que necesita.
¿Qué está confirmado y qué no?
| Afirmación | Estado | Fuente |
|---|---|---|
| AWS MCP Server salió a GA en mayo 2026 | Confirmado | Documentación oficial AWS |
| El incidente de los USD 14.000 ocurrió | Confirmado (reporte técnico) | Dev.to, mayo 2026 |
| MCP Server no expone API keys directas | Confirmado | Docs AWS + AWS Security Blog |
| Incidentes de febrero 2026 involucran agentes IA | Confirmado con contexto limitado | Segu-Info, feb 2026 |
| Alcance completo de incidentes Amazon Q Developer | No verificado independientemente | Reportes no auditados |
| Lista completa de acciones disponibles en GA | Parcialmente documentado | Docs AWS (en expansión) |
¿Debo usar AWS MCP Server en producción?
La respuesta honesta: depende del tipo de operación y de cuántos controles tenés listos. Sobre eso hablamos en distribuir contenido seguro a múltiples regiones.
Para operaciones de solo lectura (describir recursos, ver métricas, revisar configuraciones), el riesgo es bajo y el valor es alto. Un agente que puede responderte “¿cuántas instancias están corriendo en us-east-1 y cuál es su utilización de CPU?” sin que tengas que abrir la consola es genuinamente útil y difícilmente destructivo.
Para operaciones de escritura o destructivas en producción, el threshold debería ser mucho más alto. Necesitás roles con permisos específicos por operación, CloudTrail activo, alertas configuradas, y idealmente algún mecanismo de confirmación antes de ejecutar. Si tu equipo no tiene todo eso listo, las operaciones destructivas deberían seguir siendo manuales por ahora.
Startups en fase temprana probablemente tienen más tolerancia al riesgo y más agilidad para implementar los controles sobre la marcha. Empresas con compliance estricto (fintech, salud, gobierno) deberían tratarlo como cualquier otro acceso privilegiado: auditoría completa antes de habilitar en producción.
Errores comunes al implementar AWS MCP Server
Confundir “el agente no tiene mis keys” con “el agente no tiene acceso”. El modelo mental de muchos devs es “si no hay una API key visible, no hay riesgo”. Con IAM roles esto no aplica: el agente tiene exactamente los mismos permisos que el rol, sin que esos permisos sean visibles como una string en ningún lugar. Revisá siempre las políticas adjuntas al rol, no solo si hay keys hardcodeadas.
Probar en dev con permisos amplios y olvidarse de restringirlos en prod. El entorno de desarrollo es donde más se aprende qué permisos realmente necesita el agente. Tomá nota durante el desarrollo de exactamente qué operaciones ejecuta el agente, y convertí eso en una política IAM explícita antes de pasar a producción. Relacionado: ejecutar agentes sin exponer tus credenciales.
No leer los logs de CloudTrail hasta que algo falla. CloudTrail tiene valor cero si nadie lo mira. Configurá alertas de CloudWatch para las operaciones más críticas (terminaciones, eliminaciones, cambios de permisos) para que el equipo reciba notificación inmediata, no días después cuando alguien revisa la factura.
Preguntas Frecuentes
¿Qué es AWS MCP Server y cómo funciona?
AWS MCP Server es la implementación de AWS del Model Context Protocol, un estándar abierto para que agentes de IA descubran y ejecuten herramientas externas. Salió a disponibilidad general en mayo de 2026. Funciona como intermediario entre un agente (Copilot, Claude) y las APIs de AWS: el agente recibe un catálogo de operaciones disponibles y puede ejecutarlas usando lenguaje natural que el servidor traduce a llamadas de API concretas.
¿AWS MCP Server expone mis credenciales de AWS?
No expone API keys directamente al agente. La autenticación se basa en IAM roles y SigV4, no en credenciales estáticas. El riesgo no es exposición de keys sino delegación de permisos: el agente hereda los permisos del rol IAM que configuraste, y si ese rol tiene acceso amplio, el agente puede hacer operaciones destructivas sin que haya una key visible en ningún log.
¿Cuáles son los riesgos reales de usar agentes IA con AWS en 2026?
El riesgo principal es la ejecución de acciones destructivas irreversibles a partir de instrucciones ambiguas. El caso más documentado hasta ahora involucra la terminación de 47 instancias EC2 y un costo extra de USD 10.800 en una sola sesión. Los riesgos secundarios incluyen escalada de privilegios si el agente puede crear roles IAM, y pérdida de datos si tiene permisos de eliminación sobre S3 u otros servicios de almacenamiento.
¿Cómo configurar AWS MCP Server de forma segura con permisos mínimos?
Creá un rol IAM específico para el MCP Server con políticas que listan explícitamente solo las acciones necesarias (preferentemente Describe* y List* para operaciones de lectura). Agregá condiciones de recurso para limitar el alcance por región o tag. Habilitá CloudTrail en todas las regiones con logs a S3, y configurá alertas de CloudWatch para operaciones críticas como terminaciones o eliminaciones.
¿Qué pasó exactamente en el incidente donde un agente terminó 47 instancias EC2?
Un desarrollador pidió a Copilot Cloud Agent que “limpiara instancias EC2 viejas”. El agente interpretó “viejas” como instancias con bajo tráfico reciente y ejecutó terminaciones en tres regiones simultáneamente, incluyendo una instancia de conciliación de pagos que corría de madrugada sin tráfico visible durante el día. La factura mensual pasó de USD 3.200 a USD 14.000. El incidente fue reportado en mayo de 2026 y es el caso de referencia más citado sobre riesgos de AWS MCP Server en producción.
Conclusión
AWS MCP Server cambia la interfaz entre humanos e infraestructura cloud, y eso tiene valor real. Poder preguntarle a un agente “¿qué instancias no se usaron en los últimos 7 días?” en lugar de construir una query en Cost Explorer es una mejora genuina de productividad.
El problema no es la tecnología en sí, sino que el GA de mayo de 2026 llegó antes de que la mayoría de los equipos tuviera marcos claros para gestionar permisos de agentes IA en producción. Los controles de IAM, CloudTrail y validación de comandos destructivos existen y funcionan. Lo que falta es la disciplina de aplicarlos antes de conectar el agente, no después del primer incidente.
Si ya tenés AWS MCP Server en uso, revisá el rol IAM esta semana. Si está más permisivo de lo necesario, tomalo con pinzas hasta ajustarlo. Si todavía estás evaluando si implementarlo, el momento de definir los controles es antes de que el agente toque producción, no después de revisar una factura sorpresiva.
