AWS Agent Toolkit: cómo usar MCP con agentes de código sin abrir demasiado la cloud

#aws #ai #devops #security

AWS Agent Toolkit convierte una noticia reciente en una decisión duradera: cómo dar acceso cloud a agentes de código sin entregarles una llave maestra.

El 6 de mayo de 2026 AWS anunció la disponibilidad general de AWS MCP Server y lo situó dentro de Agent Toolkit for AWS. La noticia no es solo que exista otro servidor MCP. La señal técnica es que un proveedor cloud grande está intentando empaquetar documentación actual, llamadas autenticadas, skills y controles de auditoría en una capa pensada específicamente para agentes de código.

La noticia que sí importa

Eso cambia el debate. Hasta ahora, muchos equipos conectaban agentes a AWS de forma artesanal: CLI local, credenciales amplias, snippets de documentación, scripts sueltos y mucha confianza en que el modelo no hiciera algo raro. AWS propone una interfaz más estrecha: pocas herramientas, IAM, CloudTrail, CloudWatch, documentación recuperada en tiempo real y ejecución Python aislada para operaciones multi API.

Como guía evergreen, la pregunta no es si debes instalarlo hoy. La pregunta es qué arquitectura mínima necesitas antes de dejar que Claude Code, Codex, Cursor, Kiro o cualquier cliente MCP razone sobre infraestructura real.

Qué incluye AWS Agent Toolkit

El repositorio oficial de AWS describe el toolkit como un conjunto de MCP servers, skills, plugins y rules files para ayudar a agentes de IA a construir, desplegar y gestionar aplicaciones en AWS. Los plugins empaquetan configuración del MCP Server y skills para herramientas concretas. En el momento de la documentación revisada, AWS menciona plugins para Claude Code y Codex, y configuración directa para otros agentes compatibles con MCP.

La parte más importante es el AWS MCP Server gestionado. AWS documenta herramientas de conocimiento como aws___search_documentation, aws___read_documentation, aws___retrieve_skill y aws___recommend; herramientas de API como aws___call_aws y aws___suggest_aws_commands; y una herramienta aws___run_script para ejecutar Python en un entorno sandbox con acceso AWS.

Ese diseño intenta resolver dos problemas clásicos. Primero, el modelo no sabe qué APIs, regiones o servicios nuevos existen después de su fecha de entrenamiento. Segundo, dar al agente una shell local con AWS CLI y credenciales amplias mezcla demasiadas capacidades en un único permiso difícil de auditar.

Por qué no basta con conectar el MCP

MCP estandariza cómo un agente descubre e invoca herramientas, pero no garantiza que el uso sea seguro en producción. Un paper reciente sobre patrones de producción con MCP resume tres huecos frecuentes: propagación de identidad, presupuestos adaptativos para herramientas y semántica de errores estructurada. Traducido a cloud: necesitas saber quién pidió cada operación, cuánto puede gastar o tardar una cadena de llamadas, y cómo se recupera el agente cuando una API falla.

AWS cubre parte de esa brecha con IAM context keys, CloudTrail y métricas en CloudWatch. Eso permite separar acciones humanas de acciones iniciadas vía MCP y escribir políticas específicas para agentes. Por ejemplo, un usuario puede tener permisos amplios en su rol humano, pero el camino MCP puede restringirse a lectura o a un subconjunto de acciones mutables.

La conclusión práctica es incómoda pero necesaria: instalar el servidor es la parte fácil. El trabajo serio está en políticas, scopes, logs, budgets, revisión de prompts de proyecto y pruebas de reversibilidad.

Modelo mental: tres carriles de permiso

Para adoptar este tipo de toolkit sin abrir demasiado la cloud, separaría tres carriles. El carril de documentación no requiere credenciales y permite al agente buscar guías, APIs, disponibilidad regional y best practices. Ese carril debería estar permitido casi siempre porque reduce alucinaciones y código obsoleto.

El carril de inspección usa credenciales, pero solo para leer estado: listar recursos, revisar configuración, consultar métricas, validar regiones o analizar costes estimados. Aquí el riesgo sube porque el agente ve información interna, pero todavía no cambia infraestructura. Es el mejor punto de partida para un piloto real.

El carril de mutación crea, modifica o elimina recursos. Ese carril debe entrar tarde, con entornos no productivos, políticas explícitas, aprobación humana y límites de coste. Si el primer piloto ya permite call_aws mutante contra producción, el problema no es MCP: es gobernanza.

run_script no es una shell local

La herramienta run_script es una de las piezas más interesantes porque permite que el agente agrupe varias llamadas AWS, filtre resultados y compute respuestas en un solo viaje. AWS explica que se ejecuta server side en un sandbox, hereda permisos IAM y no tiene acceso de red general ni al sistema de archivos local.

Eso no la convierte en inocua. Un script con permisos de lectura puede enumerar inventario sensible. Un script con permisos de escritura puede cambiar muchos recursos rápido. Pero sí mejora el diseño frente a entregar una terminal local completa: reduces superficie, haces la operación más observable y evitas que el agente mezcle AWS, filesystem local, secretos del repo y comandos arbitrarios en el mismo espacio.

Mi regla sería permitir run_script primero para consultas agregadas de lectura: inventario, compliance básico, comparativas regionales, costes estimados o checks de configuración. Para mutaciones, exigiría PR de infraestructura, plan revisable y despliegue separado.

Coste y contexto

AWS insiste en que el toolkit puede reducir tokens porque mantiene corta la lista de herramientas y recupera skills/documentación bajo demanda. Eso importa. Un agente con 40 herramientas genéricas y documentación pegada en el prompt no solo cuesta más; también tiene más oportunidades de elegir mal.

Lo que conviene comprobar

La documentación actual en tiempo real también cambia la calidad de respuestas. En el anuncio de GA, AWS usa el ejemplo de servicios recientes como S3 Vectors para mostrar que un modelo con cutoff anterior puede responder con opciones antiguas si no consulta documentación viva. Para equipos cloud, esa diferencia se nota en APIs nuevas, servicios regionales, CDK constructs y cambios de pricing.

Aun así, el ahorro de tokens no debe ocultar coste cloud real. Si un agente puede crear recursos, el coste importante puede aparecer en AWS Billing, no en el proveedor de modelos. Por eso las tareas de despliegue deben pedir estimación, tags, teardown y límites antes de ejecutar.

Riesgo supply chain

El ecosistema de herramientas para agentes crece rápido. Un estudio sobre 177.000 herramientas MCP observó que las herramientas de acción ganaron peso con el tiempo, y otro paper sobre tool cloning encontró duplicación elevada en repositorios MCP y Skills. Eso tiene implicaciones directas: no basta con contar integraciones; hay que revisar procedencia, mantenimiento, permisos y similitud con plantillas vulnerables.

En ese contexto, que AWS publique un toolkit oficial y soportado reduce una parte del riesgo de procedencia, pero no elimina el riesgo operativo. Sigues teniendo que revisar versión, proxy local, configuración del cliente, credenciales, scopes de IAM y reglas de proyecto.

La decisión razonable no es 'solo oficiales' ni 'cualquier MCP vale'. Es una allowlist pequeña, con owners claros y revisión periódica. Las herramientas que pueden tocar cloud deben tratarse como dependencias de infraestructura, no como extensiones decorativas del editor.

Checklist de piloto

Empieza con un entorno sandbox o una cuenta AWS de desarrollo sin datos sensibles.
Activa primero documentación y skills; retrasa acciones mutables.
Crea una política IAM específica para el camino MCP con permisos de solo lectura.
Usa context keys o condiciones equivalentes para separar acciones humanas y acciones del agente.
Etiqueta recursos creados por flujos de agente y define una rutina de teardown.
Revisa CloudTrail y métricas CloudWatch después de cada sesión piloto.
Prohíbe secretos de producción en prompts, logs y rules files del agente.
Define qué comandos o herramientas requieren confirmación humana explícita.
Mide coste: tokens, tiempo humano, recursos AWS creados y cambios aceptados.
Documenta un rollback antes de permitir mutaciones reales.

Un flujo de trabajo razonable

Un flujo conservador sería pedir al agente que investigue arquitectura usando documentación actual y lectura de infraestructura existente. Después debe proponer un plan en texto: servicios, permisos, coste estimado, riesgos, cambios CDK o CloudFormation y estrategia de reversión.

La implementación debería vivir en Git como cualquier otro cambio de infraestructura. El agente puede generar CDK, Terraform o CloudFormation, pero el despliegue debe pasar por revisión, tests, scanning y CI/CD. Si el agente ejecuta APIs directamente, que sea para tareas pequeñas, reversibles y dentro de un entorno no productivo.

La meta no es que el agente despliegue más rápido por sí solo. La meta es que llegue a una propuesta mejor informada, con menos documentación obsoleta, menos IAM demasiado amplio y más evidencia para el reviewer.

Conclusión

AWS Agent Toolkit y AWS MCP Server son relevantes porque convierten el acceso cloud para agentes en una arquitectura explícita: herramientas pequeñas, documentación viva, IAM, auditoría y skills mantenidas. Eso es mucho mejor que pegar credenciales en un flujo improvisado y esperar que el modelo se porte bien.

La adopción responsable empieza por lectura y documentación, sigue con inspección de solo lectura y solo después entra en mutaciones acotadas. Si tu equipo no puede explicar permisos, logs, coste y rollback, todavía no está listo para dejar que un agente opere infraestructura real.

Regla operativa

Activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable.