La seguridad no llega en el módulo 10 — llegó en el 2 (identidad mínima), el 4 (red cerrada y egress), el 6 (el historial como honeypot) y el 8 (freno de gasto). Lo que este módulo agrega son las capas que faltan para que la plataforma sea un sistema seguro y no una colección de piezas prudentes: secretos, cifrado, filtrado administrado de contenido, y — la mitad que todos posponen — detección y evidencia. El curso de Seguridad de IA cubre el modelo de amenazas y las técnicas de ataque/defensa del lado del modelo; este módulo cubre su encarnación en servicios AWS.

El marco mental para ordenar las piezas es el clásico de dos columnas: prevención (que no pase) y detección (saber cuándo pasó igual). Las plataformas inmaduras invierten todo en la primera; las que sobreviven auditorías e incidentes, en ambas.

La tesis del módulo

La seguridad de la plataforma se completa con cuatro piezas: secretos que el agente usa sin ver (Secrets Manager), cifrado cuyo control decides tú (KMS), filtrado de contenido declarativo en el punto único (Guardrails) — y la mitad no negociable: evidencia inmutable de todo lo que pasó (CloudTrail) con detección activa encima (GuardDuty). Para agentes autónomos, la detección pesa doble: cuando nadie mira al sistema trabajar, los logs son los únicos testigos.

Secretos: el agente usa llaves que jamás ve

El módulo 2 dejó la regla (cero llaves de larga vida en el camino del agente) y una pendiente: las credenciales hacia fuera de AWS — la API key del CRM, el token del servicio de correo. Para eso existe Secrets Manager: el almacén administrado de secretos con cifrado, control de acceso por IAM, rotación automática y auditoría de cada lectura.

El patrón de arquitectura importa más que el servicio: el secreto se inyecta en el borde, no se entrega al contexto. El código del agente (la capa de herramientas) lee el secreto de Secrets Manager en el momento de usarlo — con su rol, auditado — y lo pone en el header de la llamada saliente. El secreto jamás entra al prompt, jamás se escribe en el historial, jamás es “texto que el modelo puede leer”. La diferencia no es cosmética: un agente cuyo contexto contiene una API key está a una inyección de prompt de exfiltrarla; un agente cuya herramienta usa la key en el borde no puede filtrar lo que nunca vio.

Ojo: esto convierte una pregunta de seguridad en un test de arquitectura de tu harness: ¿puede tu agente imprimir la credencial si se lo piden con astucia? Si la respuesta no es un “no” estructural (porque la credencial vive fuera del alcance del modelo), el diseño está mal — sin importar cuántos filtros anti-inyección pongas delante.

KMS: cifrado es fácil; el control de la llave es la decisión

Casi todo servicio AWS cifra en reposo por defecto o con un clic. La decisión real de KMS (Key Management Service) es quién controla la llave:

Opción	Qué es	Cuándo
Llaves administradas por AWS	El servicio cifra con llaves que AWS gestiona por ti	El default razonable para todo lo no sensible
Customer managed keys (CMK)	Llaves tuyas en KMS: tú defines su política, rotación y quién las usa; cada uso queda auditado	Los datos sensibles de la plataforma: historial de sesiones, memoria del agente, buckets de documentos

La razón para CMK en la plataforma de agentes es doble. Primero, la política de llave es otra capa de deny: acceder al historial exige permiso sobre la tabla y sobre la llave — dos puertas independientes (defensa en profundidad, tercera aparición). Segundo, auditoría de uso: cada descifrado queda en CloudTrail — “quién leyó datos de sesiones y cuándo” deja de ser una pregunta incontestable. El honeypot del módulo 6 se cifra con CMK; no es negociable en cuanto hay datos de clientes.

Guardrails de Bedrock: el filtro declarativo en el punto único

Los guardrails conceptuales de la landing zone (componente 6) tienen en AWS su versión administrada: Bedrock Guardrails — políticas declarativas de filtrado que se aplican a la entrada y la salida del modelo:

Temas denegados: de qué no habla el sistema (asesoría legal, competidores), declarado en lenguaje natural.
Filtros de contenido: umbrales por categoría (odio, violencia, prompt attacks) para entrada y salida.
Filtros de PII: detectar y bloquear o enmascarar datos personales — la pieza que implementa administrada una parte del componente 5 (ofuscación) para el tráfico hacia/desde el modelo.
Grounding y relevancia: umbrales que marcan respuestas no apoyadas en el contexto entregado — el detector de alucinación declarativo.

Dos propiedades de arquitectura los hacen valiosos más allá de su lista de funciones. Primera: son configuración, no código — la política de contenido de la plataforma vive declarada, versionada y auditable, igual que las políticas IAM (el mismo giro de “del prompt a la declaración” de la clase de gobernanza). Segunda: se exigen en el punto único — una condición IAM (bedrock:GuardrailIdentifier, disponible desde marzo de 2025) en el rol de cada agente rechaza toda invocación al modelo que no lleve el guardrail de la plataforma: todos los agentes pasan por el filtro sin que cada equipo lo reimplemente, y ninguno puede omitirlo.

Cuidado — el guardrail administrado no es el sistema de seguridad: filtra el diálogo con el modelo. No gobierna qué herramientas ejecuta el agente (eso es IAM + diseño de herramientas), no controla el egress (módulo 4), no protege el historial (KMS + acceso). Y el enmascaramiento de PII hacia el modelo no sustituye la política de PII en persistencia (módulo 6). Es una capa — útil, barata, declarativa — dentro de la defensa en profundidad, no su resumen.

La mitad olvidada: detección y evidencia

CloudTrail es la caja negra: el registro de cada llamada a API en la cuenta — quién (qué rol), qué acción, sobre qué recurso, cuándo, desde dónde. Para una plataforma donde los actores son agentes, CloudTrail es literalmente el diario de todo lo que tus agentes hicieron — no lo que dijeron (eso está en el historial del módulo 6 y los logs del 11), sino lo que hicieron: qué invocaron, qué leyeron, qué escribieron. Dos decisiones de arquitectura: se envía a la cuenta de seguridad de la organización (módulo 1 — el trail que el admin de la cuenta comprometida no puede borrar: evidencia inmutable), y se enciende la validación de integridad. El audit log encadenado de la clase de gobernanza tiene aquí su implementación de infraestructura.

GuardDuty es el vigilante: detección administrada de amenazas que analiza CloudTrail, logs de red y DNS buscando patrones — credenciales usadas desde lugares anómalos, llamadas API inusuales, instancias hablando con destinos maliciosos. Para agentes autónomos su valor es de nuevo la simetría: actividad anómala del rol de un agente (de pronto llama APIs que nunca llamó, a horas que no le tocan) es exactamente la firma de un agente comprometido o desbocado — y GuardDuty la ve sin que escribas reglas.

   PREVENCIÓN Y DETECCIÓN — EL MAPA DEL MÓDULO

  prevención (que no pase)      detección (saberlo)
  ┌────────────────────────┐   ┌─────────────────────┐
  │ IAM mínimo      (m2)   │   │ CloudTrail: todo    │
  │ red + egress    (m4)   │   │ lo que se HIZO      │
  │ secretos borde  (m10)  │   │ (inmutable, cuenta  │
  │ cifrado CMK     (m10)  │   │ de seguridad)       │
  │ guardrails      (m10)  │   │ GuardDuty: anomalía │
  │ freno de gasto  (m8)   │   │ sobre los rastros   │
  └───────────┬────────────┘   └──────────┬──────────┘
              │       se diseñan JUNTAS   │
              └────────────┬──────────────┘
                           ▼
              incidente contenido + evidencia
              (módulo 11: responder y operar)

Errores comunes

La API key del CRM en el contexto del agente. Si el modelo puede leerla, una inyección puede pedirla. Secreto en Secrets Manager, inyectado por la herramienta en el borde — el modelo trabaja con llaves que jamás ve.
Cifrado “activado” sin decidir la llave. El checkbox de cifrado con llave de AWS protege del disco robado, no del acceso indebido con credenciales válidas. Los datos sensibles de la plataforma llevan CMK: segunda puerta + auditoría de cada uso.
Guardrails como estrategia completa de seguridad. Filtran el diálogo; no gobiernan herramientas, egress ni persistencia. Una capa entre seis, no el sistema.
Reimplementar el filtro de PII en cada agente. El punto único existe (guardrail exigido por condición IAM en cada rol); N implementaciones artesanales del mismo filtro son N oportunidades de que una falle.
CloudTrail en la misma cuenta que protege. Evidencia que el comprometido puede borrar no es evidencia. Trail hacia la cuenta de seguridad, con integridad validada — el día que lo necesites, será tarde para configurarlo.
Toda la inversión en prevenir, nada en detectar. El presupuesto de seguridad que ignora GuardDuty y las anomalías apuesta a que la prevención será perfecta. No lo será; la pregunta es si te enterarás en minutos o en la auditoría.

La frase para llevarse

“El agente usa secretos que jamás ve, los datos sensibles llevan llave propia con cada uso auditado, el filtro de contenido se declara una vez en el punto único — y todo lo que la plataforma hace queda escrito donde nadie puede borrarlo. Prevención sin detección es optimismo; para agentes que trabajan solos, los logs son los únicos testigos.”

Qué viene

Módulo 11: operación autónoma. La plataforma está construida y blindada; falta aprender a operarla sin vivir dentro: observabilidad con CloudWatch y X-Ray (qué medir de un agente además de CPU), las alarmas que distinguen ruido de incendio, y el patrón estrella del curso — la aprobación asíncrona con Step Functions: cómo un agente autónomo pide permiso para lo irreversible, espera dormido sin gastar, y qué pasa cuando el aprobador no responde. Supervisar sin estar: la definición operativa de autonomía.

Arquitectura AWS — Módulo 10: seguridad de la plataforma