← Todos los insights

Análisis de casoEnfoque: España y Latinoamérica3 min de lectura

Agentes de remediación cloud de Tamnoon nunca tienen credenciales. La decisión de diseño que vale copiar

AWS publicó cómo Tamnoon construyó agentes que investigan hallazgos en la nube, califican su seguridad y planifican correcciones en Bedrock, con ejecución separada y acceso controlado por el cliente.

Escuche este artículo · 4 min

Narración completa del artículo, generada con IA.

Un par de pinzas de plata antiguas sobre una superficie pálida, en duotono La Madre, junto a las palabras Modelo sin credenciales
Foto: barnesfoundation (rawpixel, CC0)

El agente más seguro que cambia infraestructura de producción es uno que no puede cambiarla. Eso suena a contradicción hasta que se separa el decidir del hacer, que es exactamente lo que hace el diseño de Tamnoon.

AWS publicó la arquitectura de Tamnoon el 14 de octubre. Tamnoon vende remediación de seguridad cloud: toma hallazgos de herramientas de seguridad cloud y corrige las malas configuraciones detrás de ellos. Su sistema de IA, que llama a los modelos Claude de Anthropic en Amazon Bedrock, investiga cada hallazgo, decide si una corrección es segura y escribe la remediación. Según el post, “la IA nunca tiene credenciales cloud”. La ejecución se realiza en un entorno separado y aislado, con credenciales de corta duración y alcance por tenant bajo una confianza que el cliente controla.

Cuatro agentes, una puerta tras otra

El trabajo se divide en cuatro agentes especializados, y cada etapa reduce lo que el siguiente puede hacer.

Del hallazgo al cambio, con la credencial fuera del modelo01Investigar:plan de sololectura,verificado porun juez02Calificarseguridad:SAFE, RISKY oAWAITING DATA03Planificar:backup,remediar,verificar,rollback04Generarcódigo, luegoun revisorseparadoaprueba05Ejecutar enaislamientocon acceso decorta duraciónRazonamiento del modelo, sin credenciales cloudEjecución, confianza controlada por el cliente
  1. Investigar: plan de solo lectura, verificado por un juez
  2. Calificar seguridad: SAFE, RISKY o AWAITING DATA
  3. Planificar: backup, remediar, verificar, rollback
  4. Generar código, luego un revisor separado aprueba
  5. Ejecutar en aislamiento con acceso de corta duración

Razonamiento del modelo, sin credenciales cloudEjecución, confianza controlada por el cliente

Resumido del post de AWS. Solo la última etapa puede cambiar la nube del cliente, y no contiene ningún modelo.

Investigación reúne contexto y produce un plan que se valida como estrictamente de solo lectura, verificado por una capa de LLM como juez. Calificación de seguridad construye una cadena de evidencia por activo y califica cada hallazgo como SAFE, RISKY o AWAITING DATA; el post la describe como deliberadamente conservadora, degradando cuando no está segura. Planificación se ejecuta solo en hallazgos calificados como seguros, y cada paso sigue backup, remediar y verificar, con guía de rollback. Generación de código convierte los pasos del plan en remediación ejecutable después de que un guardrail de entrada filtra por relevancia e inyección de prompt, y un agente revisor separado debe aprobar cada artefacto.

Tres decisiones que sostienen el diseño

Las credenciales viven donde el modelo no está. Si un atacante manipula el agente de investigación a través de una etiqueta de recurso envenenada o una línea de log manipulada, el peor resultado es un plan malo, que las siguientes puertas pueden atrapar. No es un bucket eliminado. Este es el patrón que seguimos encontrando en despliegues serios: el agente de red de Microsoft nunca tiene la credencial de ejecución, y la investigación de Zenity sobre AgentCore mostró qué pasa de otra manera: el rol cloud del agente decide el daño.

“No lo sé” es una respuesta válida. AWAITING DATA es un resultado de primera clase. La mayoría de los diseños de agentes fuerzan un veredicto; este permite que la etapa de seguridad se niegue a decidir, y enruta los hallazgos RISKY y AWAITING DATA a los ingenieros cloud de Tamnoon. Las acciones SAFE pueden ejecutarse automáticamente a través de un workflow de aprobación con un registro de auditoría completo.

Cada cambio lleva su propio deshacer. Backup y rollback son parte del formato del plan, no una ocurrencia tardía en un runbook.

Las versiones de los modelos están fijadas a identificadores con fecha, lo que también hace que el sistema sea testeable cuando un proveedor retira un modelo.

Lea los resultados con su fuente

Tamnoon reporta más de una reducción del 90% en exposición cloud crítica en 90 days, “con cero problemas de producción”. La propia tabla de resultados del post dice “hasta un 90%”, y otras cifras en él provienen de la investigación de Tamnoon. Estos son resultados reportados por el proveedor, no una auditoría, y dependen de la configuración y los ajustes de aprobación de cada cliente.

Qué preguntar a cualquier agente de remediación

Ya sea que usted compre un servicio como este o construya uno, la arquitectura le da las preguntas:

  1. ¿Qué componente tiene credenciales de producción, y hay algún modelo en ese componente?
  2. ¿Puede la etapa de seguridad decir “no hay suficientes datos”, y qué pasa entonces?
  3. ¿Quién decide qué clases de hallazgos se ejecutan sin una persona, y dónde está escrito eso?
  4. ¿Cada cambio viene con su propio backup, verificación y rollback?
  5. ¿El revisor que aprueba el código generado es independiente del que lo escribió?

Un proveedor que responde la primera pregunta con “el agente tiene un rol de mínimo privilegio” no ha separado el decidir del hacer. Solo ha hecho el hacer más pequeño.

¿Tiene un caso de uso de IA detenido entre el prototipo y la producción?

Cuéntenos qué quiere poner en marcha. Le respondemos con próximos pasos honestos.

Conversemos sobre un caso de uso