Las exposiciones críticas en la nube se acumulan más rápido de lo que los equipos de seguridad pueden cerrarlas. Las plataformas de protección de aplicaciones nativas de la nube (CNAPP), los proveedores de nube y los escáneres de postura generan más hallazgos de los que cualquier equipo puede priorizar, y el riesgo se acumula en la brecha entre lo detectado y lo corregido. La mayoría de los hallazgos permanecen sin atender, no porque sean difíciles de corregir. Alguien debe investigar el contexto, identificar al propietario, confirmar que la corrección no romperá la producción y luego hacerlo a un volumen que supere la capacidad del personal.
En esta publicación, compartimos cómo Tamnoon construyó Tami, un orquestador agéntico de remediación en la nube sobre Amazon Bedrock, para cerrar esa brecha. Tami investiga de forma autónoma los hallazgos ingeridos desde CNAPP y fuentes nativas de la nube y evalúa si la remediación es segura. Luego genera y orquesta la corrección con salvaguardas y gobernanza siempre que un cambio toque la nube de un cliente. El enfoque logró una reducción de más del 90 por ciento en la exposición crítica en la nube en 90 días sin problemas de producción.
Acerca de Tamnoon
Tamnoon es una plataforma de remediación de seguridad en la nube con IA que trabaja junto a las CNAPP. Su asistente de IA, Tami, ayuda a expertos humanos en seguridad en la nube a investigar, priorizar y remediar de manera segura configuraciones erróneas y problemas en entornos de clientes en AWS, Azure, Google Cloud y otros proveedores de nube.
Tamnoon se integra con las CNAPP y las herramientas nativas de la nube que los equipos ya utilizan y convierte sus hallazgos en correcciones validadas y seguras para producción. La mayor parte del trabajo, incluida la investigación, la priorización y la planificación de la remediación, ocurre antes de que algo toque un entorno en vivo, lo que hace que la remediación automatizada sea confiable a escala.
Desafíos de la remediación de seguridad en la nube
Un ingeniero de seguridad puede pasar horas investigando un solo hallazgo. A menudo, este se remonta a la misma causa raíz que docenas de otras alertas.
- El volumen de alertas supera al personal: las CNAPP y los escáneres generan miles de hallazgos. Los equipos no pueden priorizarlos todos, por lo que las exposiciones críticas quedan sin resolver mientras el riesgo se agrava durante meses.
- La investigación es manual y repetitiva: cada hallazgo requiere recopilar contexto sobre quién es el propietario del recurso, qué depende de él y si la corrección es segura. Esto consume horas del tiempo de ingenieros senior, repetido en cada elemento del backlog.
- El temor al impacto en producción bloquea la automatización: los equipos dudan en automatizar la remediación porque no pueden arriesgarse a tumbar la producción. Sin la confianza de que una corrección es segura, nada avanza.
- Priorización reactiva: sin una forma de agrupar hallazgos relacionados o puntuar la confianza de la remediación, los equipos trabajan las alertas linealmente en lugar de abordar las causas raíz que resuelven muchos problemas a la vez.
La solución de Tamnoon aborda todo el pipeline desde la ingesta de hallazgos hasta la corrección validada. La plataforma trata estos desafíos como problemas interconectados y no aislados.
Descripción general de la solución
Tamnoon lo lleva desde el hallazgo inicial hasta la ejecución de la corrección. La plataforma ingiere hallazgos de CNAPP, proveedores de gestión de postura de seguridad en la nube (CSPM) y otras herramientas de seguridad, y los normaliza en un esquema unificado. Luego los enriquece con contexto de activos y exposición, y los prioriza. A partir de ahí, la capa agéntica toma el control mediante un conjunto de agentes de IA especializados, cada uno ejecutándose en una arquitectura serverless basada en eventos en AWS, de modo que cada etapa escala de forma independiente y falla de manera segura.
Arquitectura agéntica en Amazon Bedrock
La plataforma delega el trabajo a cuatro agentes especializados, cada uno responsable de una fase distinta del pipeline de remediación:
- Un agente de investigación se basa en entrenamiento con millones de entornos reales de nube de clientes para determinar el contexto y filtra ese contexto a través de una capa de validación de modelo de lenguaje extenso (LLM) como juez. Razona sobre el objetivo de remediación, el alcance operativo y la verificación específica del proveedor de nube, produciendo pasos de investigación de solo lectura y un plan de investigación completo.
- Un agente de puntuación de seguridad construye una cadena de evidencia por activo, combinando los resultados de la verificación automatizada con los hallazgos de los analistas. Clasifica la remediación de cada hallazgo como SAFE, RISKY o AWAITING DATA con un sesgo deliberadamente conservador. Ante la duda, degrada la clasificación.
- Un agente de remediación se activa solo para los hallazgos que el agente de seguridad ha considerado seguros. Razona sobre el orden, las dependencias y las condiciones, y luego produce un plan de remediación en el que cada paso sigue una estructura de respaldo, remediación y verificación, e incluye orientación para la reversión.
- Un agente de generación de código convierte los pasos del plan en remediación ejecutable, pero solo después de que una salvaguarda de entrada filtre la relevancia y la inyección de instrucciones. Cada artefacto pasa por un bucle automatizado de generación y revisión en el que un agente revisor independiente debe aprobar el resultado.
Por qué Amazon Bedrock
Cuando el equipo de Tamnoon se propuso construir Tami, la elección de la plataforma de modelo fundacional (FM) iba a moldear todo lo que viniera después. Los agentes de remediación de Tamnoon no realizan todos el mismo tipo de trabajo. Algunos llevan a cabo un razonamiento investigativo profundo para comprender la causa raíz de un hallazgo de seguridad. Otros se encargan de la validación de alto volumen, verificando correcciones propuestas de forma rápida y económica. Otros más revisan el código generado, equilibrando la calidad frente al costo en cada tarea. Asignar cada uno de estos trabajos al modelo adecuado, sin tener que ensamblar una integración distinta para cada uno, era un requisito fundamental.
Ese requisito es lo que hizo de Amazon Bedrock la opción natural. A través de una única API, cada agente puede invocar el modelo fundacional que mejor se adapte a su tarea. Los modelos más capaces se encargan del razonamiento más difícil. Los modelos más eficientes asumen el trabajo repetitivo de alto rendimiento. Los modelos orientados a revisión optimizan el equilibrio entre la calidad del resultado y el costo. Al tratarse de una sola integración en lugar de muchas, los modelos pueden ser reemplazados o actualizados a medida que evoluciona el panorama, sin tener que reconfigurar la arquitectura cada vez.
La sobrecarga operativa a escala fue otro factor en la decisión. A medida que crecía el volumen de solicitudes, Tamnoon quería evitar construir y mantener su propia lógica para distribuir el tráfico entre capacidad regional. Amazon Bedrock Cross-Region inference se encarga de esto automáticamente. Enruta automáticamente las solicitudes de inferencia a la región de AWS óptima dentro de un límite geográfico definido, manteniendo el rendimiento sin requerir ningún código de enrutamiento personalizado para funcionar.
La seguridad fue la consideración final y, para una empresa de seguridad en la nube, no era negociable. Con Bedrock, la inferencia se ejecuta dentro del propio entorno de AWS de Tamnoon bajo permisos delimitados por AWS Identity and Access Management (IAM). Los datos confidenciales de los clientes nunca salen del límite de confianza. Eso dio al equipo la confianza de que la plataforma que sustenta Tami cumplía el mismo estándar que Tamnoon exige a su propio servicio.
Cómo Tamnoon se integra con las CNAPP y las herramientas de seguridad en la nube
Tamnoon se sitúa aguas abajo de las herramientas de detección que los equipos de seguridad ya utilizan. Las CNAPP como Wiz, CrowdStrike, Palo Alto Cortex, Upwind, SentinelOne, Orca y Cyera, junto con servicios nativos de la nube como AWS Security Hub y Amazon GuardDuty, son la fuente de verdad sobre lo que está mal en el entorno. Tamnoon se conecta mediante integraciones basadas en API y normaliza los hallazgos en un formato común, de modo que una configuración errónea se ve igual sin importar si provino de Wiz o de GuardDuty. Las herramientas de detección siguen siendo la base. Tamnoon proporciona la remediación de extremo a extremo que viene después.
Por cada hallazgo que analiza, Tami asigna un Indicador de Confianza de Remediación (RCI) de SAFE, RISKY o AWAITING DATA. Esa calificación indica a los equipos qué se puede automatizar y qué necesita primero revisión humana.
Figura 1: Tamnoon en acción
Arquitectura de AWS de Tamnoon
Tamnoon se ejecuta completamente dentro de sus propias cuentas de AWS, aisladas por entorno. Los usuarios acceden a la plataforma a través de un único punto de entrada seguro construido sobre Amazon API Gateway, con el cifrado gestionado por AWS Certificate Manager y el inicio de sesión a cargo de Amazon Cognito. Todo lo que está detrás de ese punto de entrada se ejecuta en redes privadas distribuidas en múltiples zonas de disponibilidad, por lo que la plataforma principal nunca está directamente expuesta a internet.
Dentro de ese entorno, Tamnoon combina dos tipos de cómputo. Amazon Elastic Kubernetes Service (Amazon EKS) ejecuta los servicios siempre activos detrás del panel de control, mientras que AWS Lambda impulsa el trabajo basado en eventos de recopilar hallazgos, analizarlos y ejecutar remediaciones. Un conjunto de servicios de mensajería y flujos de trabajo de AWS, incluidos Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS) y AWS Step Functions, coordina estos pasos para que grandes volúmenes de hallazgos se procesen de manera confiable y en paralelo, sin que un único registro defectuoso detenga al resto.
La capa de IA se ejecuta en Amazon Bedrock. Amazon Bedrock AgentCore, una plataforma para crear, conectar y optimizar agentes a escala con cualquier framework o modelo, ofrece a los agentes de Tamnoon una forma gobernada de tomar medidas en lugar de un acceso ilimitado. Amazon Bedrock Guardrails revisa luego tanto la solicitud como el código generado antes de que algo avance. Los servicios de soporte se encargan del resto de la plataforma: bases de datos administradas y caché para el estado, Amazon Simple Storage Service (Amazon S3) para los playbooks y artefactos, y AWS Secrets Manager para las credenciales, de modo que las claves confidenciales nunca residan en el código de la aplicación.
Del lado del cliente, todo lo que está a la izquierda del límite de AWS Cloud es lo que los clientes conectan a Tamnoon. Pueden vincular sus propias cuentas de AWS, Azure y Google Cloud, conectar las herramientas de seguridad de las que provienen sus hallazgos, y conectar los destinos donde desean recibir los resultados, como Slack, Jira, ServiceNow y GitHub.
Figura 2: Arquitectura de AWS de Tamnoon
Cómo Tamnoon mantiene cero problemas en producción
Cero problemas en producción es una realidad para los clientes de Tamnoon, y no es casualidad. La autonomía en Tamnoon se sitúa dentro de una arquitectura de seguridad de defensa en profundidad, donde cada capa asume que la anterior podría pasar algo por alto.
Todo comienza antes de que siquiera se redacte alguna corrección. No se escribe ninguna remediación hasta que una evaluación de seguridad independiente, centrada en el alcance y deliberadamente sesgada hacia la precaución, concluye que el cambio es seguro de realizar. A partir de ahí, la plataforma traza una línea divisoria estricta entre leer y escribir. Los pasos de investigación se validan como estrictamente de solo lectura, de modo que el trabajo de comprender un problema nunca pueda alterarlo. Solo la ruta de remediación tiene permiso para cambiar algo, y cada cambio que realiza incluye sus propios pasos de respaldo, verificación y reversión.
Esa disciplina se refuerza con una autocrítica constante. Cada paso de generación se acompaña de un paso de reflexión que verifica el resultado e introduce su crítica de nuevo en la regeneración, de modo que el sistema siempre está revisando su propio trabajo en lugar de confiar en él sin más. Esas recomendaciones también se mantienen ancladas a la realidad. El resultado del agente se valida con los resultados de la automatización, los comentarios de los usuarios y datos de entrenamiento procedentes de alertas reales ya resueltas, y cuando el modelo no puede llegar por sí solo a un resultado preciso, se incorpora a un humano al proceso.
La última salvaguarda está en el momento de la ejecución. La IA nunca posee credenciales de nube. En cambio, la ejecución se gestiona a través de credenciales de corta duración y con alcance por tenant, bajo una confianza controlada por el cliente, que se ejecutan en un entorno aislado y separado de los agentes que planifican el trabajo. Envolver todo esto está la gobernanza humana: las remediaciones fluyen por un flujo de trabajo de aprobación con un registro de auditoría completo, y cada capacidad de la IA se valida internamente antes de llegar jamás a un cliente.
Seguridad de los datos y cumplimiento
Tami razona sobre datos sensibles de clientes: cargas útiles de alertas, identificadores de recursos, configuraciones erróneas y contexto de remediación. Esos datos deben permanecer dentro del límite de confianza de AWS, ejecutarse con el mínimo privilegio y seguir siendo auditables. Estandarizar en Amazon Bedrock hace eso posible.
El contenido sensible permanece dentro de AWS
Cada carga de trabajo de Tami invoca a Anthropic Claude en Amazon Bedrock a través de la ChatBedrockConverse interfaz, en lugar de llamar a un endpoint de LLM de terceros. Esa única decisión pone toda la cadena de suministro de IA bajo un único servicio nativo de AWS, lo que tiene consecuencias reales en cómo se manejan los datos de los clientes. La inferencia se ejecuta por completo dentro de la propia cuenta de AWS de Tamnoon en Regiones comerciales de EE. UU., por lo que los datos nunca salen de AWS. Para obtener información sobre la disponibilidad de modelos por Región, consulte Modelos admitidos por Región de AWS en Amazon Bedrock. Como Bedrock no retiene ni entrena con prompts ni completaciones, los datos de los clientes nunca llegan a un proveedor externo en primer lugar.
Ese límite se mantiene incluso a medida que las cargas de trabajo escalan. La inferencia multirregión de Bedrock enruta automáticamente las solicitudes a Regiones dentro del límite geográfico de EE. UU., aumentando el rendimiento disponible para la aplicación. La computación detrás de ello también permanece privada. Cada servicio se ejecuta como una función de AWS Lambda conectada a una nube privada virtual (VPC), en subredes privadas con un grupo de seguridad explícito, sin ingreso público y con un egreso estrechamente controlado.
Proteger lo que llega al modelo
Las cargas útiles pueden contener detalles sensibles, por lo que Tami aplica Amazon Bedrock Guardrails a cada solicitud y respuesta. La política se aplica en la capa de Bedrock, lo que significa que cubre los tres servicios de manera uniforme y que la lógica de prompt de ninguna función individual puede eludirla. Ese único punto de aplicación hace varias cosas a la vez.
Primero, protege los datos sensibles. La PII y el contenido similar a secretos se enmascaran antes de persistirse o mostrarse, de modo que nada sensible permanezca donde no corresponde. También protege contra la inyección de prompts, algo importante porque Tami razona sobre hallazgos no confiables que un usuario no autorizado podría influenciar. El filtrado en la capa de guardrail impide que una carga útil manipulada secuestre el modelo o exfiltre contexto. Por último, los temas denegados y los filtros de contenido mantienen la salida del modelo acotada a la remediación de seguridad y a nada más. Cada intervención se registra junto con AWS CloudTrail, ofreciendo a los clientes empresariales un rastro claro de evidencia de gobernanza.
Acceso con mínimo privilegio
El acceso en toda la plataforma se realiza a través de un rol de ejecución de IAM dedicado por servicio, de modo que cada función solo pueda alcanzar lo que necesita y nada más. Ese principio se aprecia más fácilmente en cómo Tami interactúa con Amazon Bedrock. Su único permiso de Bedrock es bedrock:InvokeModel, con alcance a ARNs específicos de perfiles de inferencia y modelos fundacionales. No tiene capacidad para administrar, entrenar ni exportar modelos.
La misma disciplina se extiende a todas las demás dependencias. El acceso a AWS Secrets Manager está limitado a los dos secretos que una función realmente usa, el acceso a SQS está confinado a su propia cola de entrada, y las escrituras en Amazon CloudWatch están restringidas por namespace. No hay roles amplios y genéricos en ningún lugar del diseño. Las funciones se adjuntan únicamente a las políticas administradas AWSLambdaBasicExecutionRole y AWSLambdaVPCAccessExecutionRole , y a nada más amplio que eso.
Aislamiento multi-tenant y gobernanza
Mantener a los tenants separados es un requisito fundamental, y se aplica desde la primera llamada. Las llamadas de servicio a servicio usan credenciales de cliente OAuth2 a través de Cognito, con alcance por aplicación, y el trabajo se procesa de a un mensaje de SQS a la vez con su contexto de tenant adjunto. Como resultado, una única invocación solo toca jamás los datos de un tenant.
Gran parte de esta garantía proviene de tratar toda la plataforma como código. Las políticas de IAM, la ubicación de red, los IDs de modelo y las alarmas viven todos en plantillas versionadas de AWS CloudFormation y SAM, de modo que cada permiso y versión de modelo es revisable en el control de código fuente, sin cambios manuales en la consola que se desincronicen. Las versiones de modelo en particular están ancladas a identificadores con fecha, por ejemplo claude-sonnet-4-5-20250929, lo que significa que un cambio de modelo es siempre un cambio de código explícito y revisado en lugar de una actualización silenciosa.
Esa transparencia continúa en tiempo de ejecución. Cada llamada de inferencia queda en AWS CloudTrail, atribuible al rol que la invocó, y la decodificación determinista con la temperatura establecida en cero mantiene la puntuación y la planificación consistentes de una ejecución a otra. El manejo de fallos se rige con el mismo rigor. Cada servicio tiene una cola de entrada con redrive, una función de manejo de errores, una cola de mensajes muertos y alarmas de CloudWatch sobre tiempos de espera agotados y profundidad de DLQ conectadas al equipo de guardia. Los fallos están contenidos y son observables, y nunca se descartan silenciosamente.
Resultados e impacto
Tami ha analizado más de 14 millones de alertas de nube en la base de clientes de Tamnoon, una cifra registrada en el informe 2026 State of Cloud Remediation de Tamnoon. Las decisiones que toma Tami reflejan patrones aprendidos de estos entornos reales.
Para un cliente típico, los resultados se manifiestan rápido, generalmente en un plazo de 90 días.
| Métrica | Antes | Después |
| Exposición crítica en la nube | Se acumula durante meses a medida que las alertas superan la capacidad del personal | Reducción de hasta el 90% en 90 días (fuente) |
| Eficiencia de remediación | Miles de alertas sin procesar, sin priorización clara | Eficiencia de hasta 100x mediante la agrupación por causa raíz (fuente) |
| Problemas de producción | Los equipos evitan la automatización por el riesgo | Cero problemas de producción en millones de cargas de trabajo |
| Tiempo de los ingenieros | Horas por hallazgo, repetidas en todo el backlog | Más de 13,000 horas ahorradas por semana en toda la base de clientes (fuente) |
Las cifras de compresión y de cero problemas provienen de la investigación de Tamnoon. El patrón es consistente: menos exposiciones abiertas, mucho menos trabajo manual y ningún tiempo de inactividad derivado de las correcciones mismas.
Conclusión
Construir un agente capaz de razonar sobre un hallazgo en la nube es la parte sencilla. Construir uno en el que confiarías para actuar en producción es la parte difícil. Amazon Bedrock es un servicio totalmente administrado que proporciona acceso a modelos fundacionales de alto rendimiento junto con las herramientas para crear aplicaciones agénticas: orquestación, uso de herramientas y salvaguardas, a través de una única API. Esa combinación importa aquí por una razón específica: actuar sobre infraestructura de nube en producción exige tanto un razonamiento sólido como límites de seguridad estrictos.
Cuatro cosas lo hacen posible:
- Tus exposiciones realmente se cierran: Tamnoon opera sobre infraestructura de nube en vivo, no sobre tickets ni automatización de flujos de trabajo. El backlog disminuye en lugar de desplazarse lateralmente.
- La autonomía escala sin riesgo de producción: Cada acción propuesta lleva una calificación de confianza. Las acciones SAFE pueden ejecutarse automáticamente, mientras que las acciones AWAITING DATA o RISKY involucran a los ingenieros de nube integrados de Tamnoon.
- Funciona sobre el stack que ya compraste: Tamnoon funciona sobre CNAPPs populares y herramientas de seguridad en la nube. Cada herramienta de detección que ya pagas empieza a rendir porque sus hallazgos finalmente se cierran.
- La capacidad del equipo escala sin crecer: La adopción rápida y segura de la IA fronteriza significa más exposiciones cerradas por analista, sin aumentar la plantilla.
Próximos pasos
Para comenzar con una arquitectura similar, considera lo siguiente:
- Explore Amazon Bedrock y los modelos disponibles a través de él.
- Revise la documentación de Amazon Bedrock para planificar su arquitectura.
- Reserve una demo con Tamnoon para descubrir cuánta de su exposición crítica en la nube puede cerrar en los próximos 90 días.
