Detrás de mi asistente de seguridad IAM con Amazon Bedrock
· 11 min de lecturaTabla de contenidos
La guía técnica completa la publiqué en el blog de AWS en español, y el código vive en aws-samples/policy-security-assistant. Este post no repite ese paso a paso. Va al problema de fondo (por qué el mínimo privilegio importa, por qué cuesta acertarlo) y a cómo cambió el proyecto.
La IA empresarial rara vez se atasca en el modelo. Se atasca esperando permisos.
Casi toda conversación sobre ella gira en torno al modelo: cuál es más inteligente, cuál más barato, cuál tiene la ventana de contexto más grande. Tras cinco años acompañando a algunas de las empresas más grandes de mi región en su adopción de la nube (y últimamente de la IA generativa), te puedo decir que el cuello de botella casi nunca es qué tan inteligente es el modelo. Es algo mucho menos glamoroso: los permisos que necesita para siquiera hacer algo.
Lo vi tantas veces que terminé construyendo una herramienta para atacarlo. Esta es la historia de ese problema, y de lo que aprendí construyéndola.
El problema que veía repetirse
Un equipo de aplicaciones necesita permisos en AWS para que su carga de trabajo funcione. Se los pide al área de seguridad. Seguridad revisa la política IAM, encuentra que pide más de lo necesario, y la rechaza. El equipo ajusta, vuelve a pedir, y el ciclo se repite. Dos semanas después, el proyecto sigue esperando un permiso.
Nadie hace nada mal en esa historia. El desarrollador no es experto en mínimo privilegio; el ingeniero de seguridad no conoce la aplicación al detalle. Es una brecha de conocimiento de doble vía, y cuesta semanas. No es un problema de regulación ni de cultura: es un problema de traducción.
La pregunta que me hice: ¿y si una herramienta hiciera el primer filtro, para que la solicitud llegue a seguridad ya cerca del mínimo privilegio?
Por qué esto no es un detalle menor
Los permisos amplios no son una molestia administrativa: son la puerta de entrada de buena parte de los incidentes en la nube. Según el informe State of Cloud and AI Security 2025 de Tenable y la Cloud Security Alliance, las principales causas de brechas son fallas de identidad: permisos excesivos (31%), controles de acceso inconsistentes (27%) e higiene de identidad débil (27%). El problema se agrava con las identidades no humanas: el Cloud and AI Security Risk Report 2026 de Tenable encontró que el 52% de las organizaciones tiene identidades no humanas con permisos críticos excesivos (frente al 37% en las humanas), justo cuando los agentes de IA multiplican ese tipo de identidad.
El patrón se repite en los incidentes:
- Llaves de acceso de larga vida que nunca se rotan, a veces con permisos de administrador, viviendo en un servidor o una variable de entorno por años.
- Secretos y credenciales filtrados en repositorios (en el historial de git, un archivo de configuración, un notebook). Una llave de permisos amplios filtrada así es acceso directo.
- Saltos laterales desde aplicaciones de terceros: un rol que confía de más en un proveedor externo y termina siendo el trampolín al resto de la cuenta.
- Roles y políticas heredados que acumulan permisos “por si acaso” entre migraciones y que nadie recorta por miedo a romper algo.
- Defaults demasiado abiertos: el comodín
*que quedó desde el primer día porque “después lo afinamos”, y nunca se afinó.
El denominador común no es un atacante genial. Es un permiso que sobraba. Cuando una identidad solo puede hacer lo que necesita, una credencial filtrada deja de ser una catástrofe y pasa a ser un incidente acotado.
Y aun así, rara vez es prioridad
Lo que más me cuesta entender no es que el mínimo privilegio sea difícil. Es que, sabiendo el riesgo, muchas empresas no lo priorizan hasta que algo explota. La seguridad se ve como un costo que estorba la entrega, cuando es lo contrario: una brecha golpea los objetivos de negocio de forma directa (multas, confianza perdida, semanas de equipo apagando incendios en vez de construir). Proteger los datos no compite con el negocio; lo sostiene.
No es una idea abstracta para mí. Entre 2025 y 2026 descubrí, como usuario de sus servicios, fallas en dos empresas distintas de un sector altamente regulado, que manejaban registros confidenciales de personas: datos de los más sensibles que existen, expuestos más de lo que nadie querría. Las reporté directamente, y ambas corrigieron las fallas tras la alerta. En ninguno de los dos casos hubo mala intención: hubo prisas, deuda técnica y la suposición de que “alguien ya lo habría revisado”. Esa suposición es el problema: la seguridad rara vez falla por ignorarla a propósito; falla por omisión, mientras todos miran hacia la siguiente entrega.
El mínimo privilegio es una de las defensas más baratas contra esa omisión. No evita que te filtren una credencial, pero decide si esa filtración es un susto o un titular.
Por qué cuesta tanto acertarle
Y aquí está la trampa: aunque todos coincidan en que el mínimo privilegio es lo correcto, definirlo bien es difícil, y lo es en cualquier nube. Supongamos lo mejor, que la aplicación fue diseñada para hacer exactamente lo que debe, ni más ni menos. Aun así, traducir eso a una política de permisos correcta choca con varios muros:
- Granularidad. El control de acceso fino es potente, pero esa misma potencia exige precisión: hay muchísimas acciones posibles, y la que necesitas no siempre se llama como esperas. Una sola operación en la consola puede disparar varias llamadas a la API, cada una con su permiso. Saber el conjunto exacto exige leer documentación y probar.
- Recursos y condiciones. No basta con la acción; hay que acotar el recurso y agregar condiciones (una región, una etiqueta, un prefijo). Ese trabajo fino es el primero que se salta con prisa, y el que separa una política “que funciona” de una “de mínimo privilegio”.
- Las plataformas evolucionan. Aparecen servicios y capacidades nuevas todo el tiempo. Una política perfecta hoy puede quedar incompleta (o sobrar) meses después, sin que nadie la toque.
- El sesgo hacia lo amplio. Una política demasiado estrecha rompe la aplicación y genera un ticket; una demasiado amplia funciona en silencio. El incentivo diario empuja a pedir de más, y eso es justo lo que se acumula como riesgo.
Por eso pedimos a personas que escriban a mano políticas de mínimo privilegio para plataformas que evolucionan todo el tiempo. No escala.
Dónde ayuda la IA generativa — y dónde no
Un modelo de lenguaje resulta ser un traductor genuinamente bueno entre dos idiomas: “lo que la aplicación necesita hacer”, en lenguaje natural, y “cómo se ve eso como política IAM”, en JSON. Ahí hay valor real, y es la parte del problema en la que la IA generativa sí brilla.
Pero el modelo solo no basta. Pídele a un LLM una política IAM y con gusto te devolverá algo que se ve correcto y es sutil y peligrosamente incorrecto (una acción que no existe, un permiso más amplio del que pediste) con total seguridad. El arreglo no es un prompt más astuto. Es emparejar el paso generativo con algo a lo que el modelo no le pueda dar la vuelta: un validador determinista anclado a cómo funciona de verdad la plataforma. Librado a sí mismo, un modelo siempre suena seguro; el validador es lo que vuelve esa seguridad digna de confianza.
Esa es la apuesta detrás de la herramienta que construí.
Lo que construí
Un portal de autoservicio donde pegas una política IAM y recibes un análisis: validación de sintaxis, una revisión de qué tan bien cumple el mínimo privilegio y un puntaje del 1 al 10 con los puntos a mejorar. La idea: que el ida y vuelta con seguridad empezara desde un mejor punto de partida, no desde cero.
Terminó publicado en el blog oficial de AWS en español y como parte de aws-samples en GitHub.
Cómo cambió la arquitectura
La versión que describí en 2023 y la que está hoy en el repositorio comparten la intención y casi nada más. Vale contrastarlas, porque el cambio dice bastante sobre cómo evolucionó la IA generativa en AWS.
En 2023 la solución era simple a propósito: CloudFront servía un formulario desde S3, API Gateway invocaba una Lambda, y esa Lambda llamaba a Bedrock con el Claude de entonces. El despliegue era una plantilla de CloudFormation, había que habilitar el acceso al modelo a mano y empaquetar un layer de Lambda con una versión reciente de boto3 para que el SDK conociera la API de Bedrock. Hacía una sola cosa: analizar una política.
Hoy el proyecto es más ambicioso:
- Genera además de analizar. Describes en lenguaje natural lo que tu aplicación necesita y devuelve una política de mínimo privilegio. Si el pedido es demasiado amplio (“acceso total a EC2”), pide más detalle en vez de entregar algo inseguro.
- Conversa. Tras el primer análisis puedes pedirle que restrinja un recurso, agregue una condición o corrija un hallazgo, y refina la política contigo.
- Se apoya en una fuente de verdad. El modelo redacta, pero IAM Access Analyzer valida la política contra las reglas reales de la plataforma antes de devolverla.
- Cambió el motor, y con él llegó el servidor MCP. En 2023 una Lambda llamaba directo a Bedrock. Hoy los agentes corren con el Strands Agents SDK sobre Amazon Bedrock AgentCore, con Claude Haiku 4.5, y las Lambdas quedaron como adaptadores delgados. Ese mismo rediseño expuso el asistente como servidor MCP, para usarlo desde herramientas como Kiro o Claude Desktop. AgentCore encaja aquí mejor que la Lambda anterior: está pensado para agentes con sesiones largas y aisladas, no para el patrón petición-respuesta corto de Lambda y su tope de 15 minutos; la facturación se pausa mientras el agente espera al modelo (la mayor parte de cada interacción); y la lógica del agente vive en un runtime gestionado, con trazas y métricas hacia CloudWatch, clave cuando el comportamiento no es determinista y necesitas entender por qué respondió lo que respondió.
- Se desplegó con CDK en vez de una plantilla de CloudFormation a mano, y ganó las piezas que un demo no necesita pero algo cercano a producción sí: WAF delante de CloudFront y API Gateway, secreto de verificación de origen y registro de auditoría en DynamoDB.
El diagrama de hoy habla por sí solo: donde antes había cuatro cajas en línea, ahora hay agentes, validación, protección de borde y auditoría. Más capacidad, también más superficie que entender y mantener.
Lo que conviene llevarse
Más allá de esta herramienta, tres ideas sirven para cualquier proyecto que toque permisos.
La primera: revisa la frontera de permisos antes que el modelo. Si una iniciativa de IA o una migración se atasca, el cuello de botella casi nunca es técnico-elegante; es la brecha de traducción entre quien construye y quien protege. Ahí se pierden las semanas.
La segunda: el generador necesita un verificador. Fue la lección más importante del proyecto, y es la razón por la que IAM Access Analyzer está en el centro de la herramienta: el modelo propone, el validador contrasta contra las reglas reales de la plataforma. El patrón no es exclusivo de AWS; en cualquier nube la pregunta que vale es a qué puedes anclar el modelo para que no te entregue una política rota con total seguridad.
La tercera, práctica: esto es una demostración, no un reemplazo del juicio humano. El análisis y la generación automáticos son una sugerencia que acorta el camino, no que firma por ti. Antes de aplicar cualquier política, valídala con alguien de seguridad.
Si quieres montarla, el artículo de AWS y el repositorio tienen el detalle. El mínimo privilegio no es la parte glamorosa de la seguridad en la nube, pero decide cuánto duele cuando algo sale mal. Y el arreglo de fondo no es solo técnico: es lograr que quienes construyen y quienes protegen se entiendan un poco mejor. El modelo nunca fue la parte difícil.
Las opiniones aquí son mías y no representan a mi empleador.