Deja de pegar claves de acceso de AWS en tus archivos .env.
Todos hemos pasado por eso. Es tarde, estás depurando un error de permisos de Lambda y tu asistente de IA sigue inventando nombres de servicios o ARNs con IDs de cuenta imaginarios. Quieres que el modelo vea tus recursos reales para que deje de alucinar y empiece a solucionar problemas. Por desesperación, tomas una clave de acceso, la sueltas en un archivo de entorno y se la pasas al agente. Funciona. Sientes un alivio. Luego llega la mañana y te das cuenta de que ese secreto está en tu historial de la shell, en el scrollback de la terminal o, peor aún, en un commit que acabas de subir a un repositorio compartido.
Este es exactamente el desastre que el Model Context Protocol fue diseñado para prevenir.
MCP crea un puente estándar entre tu agente de IA y sistemas externos. En lugar de entregar credenciales sin procesar y esperar que el agente no las filtre, te conectas a través de un servidor controlado que gestiona la autenticación, delimita los permisos y mantiene tus claves fuera de la ventana de chat por completo.
Para AWS, actualmente tienes dos servidores MCP oficiales para elegir. Elegir el incorrecto dejará a tu agente ciego o le dará demasiado acceso con muy poca supervisión.
Conoce la diferencia: Conocimiento vs. Manos
La primera opción es el AWS Knowledge MCP Server. Piensa en él como un ingeniero senior que se ha memorizado toda la biblioteca de documentación de AWS pero no tiene credenciales de inicio de sesión para tu cuenta. Es de solo lectura por diseño, haciendo referencia a la documentación oficial de AWS para fundamentar al agente en la sintaxis real de la API, nombres de servicios correctos y las mejores prácticas actuales.
No necesitas una cuenta de AWS para usarlo. No lo conectas a tu infraestructura. Lo activas cuando estás esbozando un diagrama de arquitectura, aprendiendo un nuevo servicio como ECS o EventBridge, o validando si una llamada de API en particular todavía se comporta como recordabas de hace dos años. Evita que el agente adivine. Si le pides que escriba Terraform para una política de bucket de S3, conocerá los campos reales y los valores válidos porque está extrayendo información de la fuente, no de datos de entrenamiento que se cortaron el año pasado.
La segunda opción es el AWS MCP Server (Managed). Este le da manos a tu agente, no solo memoria. Con la autenticación adecuada, puede inspeccionar tus logs de CloudWatch, listar tus buckets de S3, leer los esquemas de tus tablas de DynamoDB, verificar las políticas de IAM adjuntas a un rol o comprobar qué grupos de seguridad están abiertos a internet. Opera en tu cuenta real, lo que lo hace potente para la resolución de problemas de producción o la refactorización de infraestructura en vivo.
El servidor Managed rechaza las claves de larga duración. Se autentica a través de OAuth mediante un inicio de sesión en el navegador, o a través de la AWS CLI usando la firma SigV4. Cada llamada a una herramienta ocurre con tokens de corta duración, cada acción deja un rastro en CloudTrail y el agente opera estrictamente dentro de los límites de IAM que definas. No puede deambular fuera de sus permisos porque está sujeto al mismo motor de políticas que gobierna a cualquier otro usuario o rol de AWS en tu organización.
Aquí está la regla de oro que debes recordar: un servidor le da conocimiento a tu agente, el otro le da manos. Usa el servidor Knowledge cuando estés estudiando o diseñando. Usa el servidor Managed cuando estés operando o reparando.
Por qué AWS recomienda el servidor Managed para la mayoría de las tareas
AWS ahora impulsa a la mayoría de los usuarios hacia el único Managed MCP Server en lugar de ejecutar ambos en paralelo. El servidor Managed ha absorbido el contexto de documentación que proporcionaba el servidor Knowledge, por lo que gestiona tanto el material de referencia como las acciones de la cuenta en vivo bajo un único endpoint.
Ejecutar ambos servidores simultáneamente puede, de hecho, degradar la experiencia. El agente recibe definiciones de herramientas superpuestas y puede confundirse sobre si debe realizar una búsqueda de documentación de solo lectura o una llamada de API en vivo contra tu cuenta. Esa vacilación produce respuestas más lentas y errores ocasionales en la selección de herramientas. Consolidar todo en el servidor Managed simplifica tu configuración y mantiene al agente enfocado.
Configuración del servidor Managed con OAuth
Poner en marcha el servidor Managed toma unos cinco minutos, pero los pasos importan porque esta es una conexión en vivo a tu cuenta.
Paso 1: Prepara tu identidad de IAM
Cree o seleccione un rol o usuario de IAM dedicado. No utilice su cuenta Root. Adjunte la política administrada llamada AWSMCPSignInOAuthAccessPolicy a este. Esta política solo otorga los permisos necesarios para iniciar el flujo de inicio de sesión OAuth para el acceso a MCP. Por sí sola, no otorga amplios derechos administrativos. Las capacidades reales que tendrá su agente estarán determinadas por el resto de las políticas de IAM que adjunte a esa identidad. Si desea que el agente lea los registros de CloudWatch pero que nunca toque IAM o la facturación, cree una política personalizada que permita logs:DescribeLogGroups y logs:FilterLogEvents y nada más.
Paso 2: Configure su cliente
Agregue la URL oficial del servidor AWS MCP a la configuración de su cliente. Esto funciona con Claude Desktop, Claude Code y Kiro. En su archivo de configuración de MCP, registre el endpoint del servidor para que el cliente sepa a dónde dirigir las llamadas a herramientas relacionadas con AWS.
Paso 3: Autentíquese a través de su navegador
La primera vez que el agente intente invocar una herramienta de AWS, su sistema operativo abrirá una ventana del navegador. Inicie sesión con la misma identidad de IAM que preparó en el Paso 1. El flujo de OAuth devuelve un token de corta duración al servidor MCP. No verá una clave secreta. No tendrá que pegar nada en un archivo de configuración. El token se actualiza automáticamente y expira rápidamente.
Paso 4: Verifique el límite de confianza
Una vez autenticado, abra CloudTrail y confirme que las acciones aparezcan bajo la identidad que creó. Debería ver eventos como ListBuckets o DescribeInstances vinculados a ese usuario o rol de IAM específico. Si ve actividad de la cuenta Root, cometió un error y debe revocar la sesión de inmediato.
Si OAuth no se ajusta a su flujo de trabajo, el servidor Managed también admite la autenticación SigV4 a través de sus credenciales existentes de AWS CLI. Ese camino evita la ventana emergente del navegador, pero aun así se beneficia de que el servidor MCP gestione la firma y la administración de la sesión en lugar de exponer credenciales sin procesar al agente.
Hábitos de seguridad que realmente importan
Un servidor MCP es tan seguro como la identidad de IAM que hay detrás de él.
Comience con el privilegio mínimo. Su agente no necesita AdministratorAccess para corregir una integración de API Gateway mal enrutada. Otorgue exactamente los permisos de lectura o escritura requeridos para la tarea actual, y rótelos o revóquelos cuando el trabajo haya terminado. Si está utilizando un rol, establezca una duración de sesión corta. Si está utilizando un usuario, habilite MFA siempre que sus herramientas lo permitan.
Nunca autorice como el usuario Root. Root elude las políticas de control de servicios y disfruta de acceso sin restricciones en toda la cuenta. Si el agente interpreta mal un prompt e intenta eliminar recursos, querrá que esa solicitud sea bloqueada por una política de límite (boundary policy). Root no tiene tales salvaguardas.
Finalmente, trate al agente como a un nuevo pasante que sigue las instrucciones a la perfección pero carece de sentido común. Ejecutará lo que usted le pida, de forma literal e inmediata. Si le dice "limpiar los grupos de seguridad no utilizados", podría terminar con el que está conectado a su base de datos de producción porque coincidía con los criterios amplios que le dio. Revise cualquier comando destructivo antes de confirmarlo, especialmente cuando el agente tenga acceso de escritura.
La conclusión real
No es necesario sacrificar la seguridad por la utilidad. El Managed AWS MCP Server permite que su asistente de IA vea su infraestructura real, corrija sus propias alucinaciones y opere dentro del mismo marco de IAM que rige al resto de su equipo. Obtiene contexto en vivo sin exponer secretos en archivos de entorno. Configure el flujo de OAuth, asegure los permisos y deje que el agente trabaje con los ojos abiertos y las manos atadas a sus políticas.