Última traducción del sistema de seguridad: secretos que el agente usa sin ver, cifrado cuya llave controlas, filtrado declarativo en el punto único, y la mitad que nadie pospone dos veces — evidencia inmutable con detección activa. El marco de dos columnas cierra la serie; las piezas de Azure, con su rasgo local: la detección más empaquetada de las tres nubes.

Pieza	En AWS	En GCP	En Azure
Almacén de secretos	Secrets Manager	Secret Manager	Key Vault
Llaves propias	KMS + CMK	Cloud KMS + CMEK	Key Vault + CMK
Guardrails del diálogo	Bedrock Guardrails	Model Armor	Content Safety (Prompt Shields)
Caja negra	CloudTrail	Cloud Audit Logs	Activity logs + diagnostic settings
Detección	GuardDuty	Security Command Center	Defender for Cloud (+ plan de IA)
Perímetro de datos	(se arma)	VPC Service Controls	(se arma: endpoints + policy + Defender)

La tesis del módulo

Tres piezas se traducen con los ojos cerrados — Key Vault con el patrón del borde, las llaves propias para el honeypot, los logs al workspace central — y dos definen el sabor Azure: Content Safety trae los Prompt Shields (el detector de inyección directa e indirecta como servicio) más la detección de groundedness, y Defender for Cloud empaqueta la postura y las amenazas con un plan específico para cargas de IA — el vigilante que ya conoce a los agentes. Lo que Azure no trae con nombre propio es el perímetro de GCP: se compone con las piezas de siempre.

Las traducciones, rápido

Key Vault: secretos, llaves y certificados con acceso por managed identity y cada lectura auditada. El patrón de la serie sin enmiendas: la herramienta lee el secreto en el borde — vía managed identity, jamás en el prompt ni el historial — y el test estructural (“¿puede el agente imprimir la credencial?”) debe dar el mismo “no”. Con el private endpoint del módulo 4, el vault ni siquiera es alcanzable fuera de la red.
CMK (customer-managed keys): tus llaves en Key Vault cifrando Cosmos, Blob, los servicios de IA — doble puerta y auditoría de uso. El honeypot del módulo 6 (y el hilo conversacional del Agent Service del módulo 9) las lleva en cuanto hay datos de clientes. Tercera nube, mismo argumento, cero novedades — la mejor clase de cero novedades.
La caja negra: los activity logs (el plano de control: quién creó, cambió, borró qué) más los diagnostic settings (el registro por servicio: accesos a datos, operaciones — se activan para lo sensible, como los data access logs de GCP) fluyendo todos a un Log Analytics workspace central en la suscripción de seguridad — el lugar que el admin comprometido no alcanza y que el módulo 11 consultará con KQL. La evidencia inmutable de la serie, con la ventaja de que su destino es directamente el motor de consultas de la operación.

Content Safety: Prompt Shields y groundedness

El guardrail declarativo de esta casa — integrado en el flujo del Agent Service (módulo 9) y disponible como servicio para el camino propio:

Prompt Shields: el detector especializado de inyección de prompt — directa (el usuario ataca) e indirecta (el ataque viene en los documentos/correos que el agente lee: el vector número uno de la trifecta para agentes que procesan contenido ajeno, como nuestro clasificador). Que el escudo distinga ambos vectores es la finura local relevante.
Filtros de contenido por categoría y umbral, en entrada y salida — la tabla estándar del género.
Groundedness detection (en vista previa): ¿la respuesta se apoya en las fuentes entregadas? — el detector de alucinación declarativo, pariente del de Bedrock y del Armor.
Task adherence (en vista previa): la pieza pensada para agentes — detecta cuando el uso de una herramienta se desalinea de lo que el usuario pidió (prematuro, no solicitado, fuera de tarea). Es la primera vez en la serie que un guardrail administrado mira las acciones y no solo el diálogo; sigue siendo detección, no el control duro de RBAC.
La PII no vive aquí: Content Safety no detecta ni enmascara datos personales — eso es Azure AI Language (detección y redacción de PII), que se llama desde la misma capa de acceso — y la distinción de la serie sigue intacta: filtrar PII hacia el modelo no sustituye la política de PII en persistencia (módulo 6) ni el gobierno de datos del tenant (Purview, para cuando la clasificación de datos corporativa entra en escena).

La advertencia de siempre, tercera estampa: el guardrail filtra el diálogo — no gobierna herramientas, ni egress, ni retención. Una capa entre seis.

Cuidado — el idioma importa: al escribir esto, groundedness detection y la detección de material protegido funcionan solo en inglés; Prompt Shields y los filtros de contenido sí están entrenados y probados en español, entre otros idiomas. Para una plataforma que conversa en castellano, el detector de alucinación declarativo de Azure todavía no es una opción: el grounding se verifica con tus propios evals (curso de Evals) hasta que el servicio lo cubra.

Defender for Cloud: el vigilante empaquetado

El rasgo local de detección: Defender for Cloud une la postura (configuraciones peligrosas, recomendaciones priorizadas, secure score) y la protección de cargas — con un plan específico para servicios de IA (threat protection for AI services, GA desde mayo de 2025): detección de jailbreaks e inyecciones en el tráfico de modelos, credenciales anómalas, patrones de abuso — integrado con los Prompt Shields y reportando al mismo panel. Es GuardDuty + Security Hub con el módulo de IA ya cableado: para una plataforma de agentes, encenderlo es de las mejores relaciones señal/esfuerzo del curso. La lectura de la serie no cambia: la anomalía conductual de una managed identity — llama lo que nunca llamó, a horas que no le tocan — es la firma del agente comprometido, y el vigilante la ve sin reglas artesanales.

Ojo — el perímetro se compone: Azure no tiene el VPC-SC de GCP como pieza única; el equivalente funcional se arma con lo ya construido: private endpoints con acceso público denegado en cada servicio de datos (módulo 4), Azure Policy exigiendo ese par en toda la jerarquía (módulo 1), el egress por FQDN cerrando la salida, y Defender vigilando el conjunto. Cuatro piezas tuyas contra una ajena — mismo resultado si la disciplina existe, y la policy es lo que la vuelve estructural en vez de voluntaria.

   PREVENCIÓN Y DETECCIÓN — EL MAPA (AZURE)

  prevención (que no pase)      detección (saberlo)
  ┌────────────────────────┐   ┌─────────────────────┐
  │ managed id. mín. (m2)  │   │ activity logs +     │
  │ private endpoints +    │   │ diagnostic settings │
  │ egress FQDN     (m4)   │   │ a workspace central │
  │ Key Vault borde (m10)  │   │ (KQL, mód. 11)      │
  │ CMK             (m10)  │   │ Defender for Cloud  │
  │ Content Safety  (m10)  │   │ + plan de IA        │
  │ TPM + budgets   (m7-8) │   │                     │
  └───────────┬────────────┘   └──────────┬──────────┘
              │       se diseñan JUNTAS   │
              └────────────┬──────────────┘
                           ▼
              incidente contenido + evidencia

Errores comunes

El secreto fuera del borde, última llamada. Si el modelo puede leerlo, la inyección puede pedirlo — en Azure, con Prompt Shields y todo. El escudo detecta intentos; el patrón del borde hace que no haya nada que robar.
Diagnostic settings apagados en lo sensible. El plano de control se loguea solo; los accesos a datos, no. Cosmos, Blob, Key Vault y los servicios de IA con diagnósticos al workspace central — el día uno.
Content Safety como sistema completo. Filtra el diálogo. La identidad, el egress, las llaves y la retención son capas propias — el resumen no existió en ninguna nube.
Defender sin el plan de IA. El vigilante genérico sin el módulo que entiende jailbreaks y tráfico de modelos es el perro sin olfato para tu carga principal. El plan se enciende con la plataforma.
El workspace de logs en la suscripción que vigila. Evidencia alcanzable por el comprometido, tercera edición. Suscripción de seguridad, acceso mínimo, retención definida.
Buscar “el VPC-SC de Azure” y rendirse. No hay pieza única; hay composición exigible por policy. La disciplina compuesta vale lo mismo que el servicio con nombre — si la policy la hace obligatoria.

La frase para llevarse

“Key Vault en el borde, llaves propias en el honeypot, logs al workspace que nadie del incidente alcanza — y las dos piezas locales trabajando juntas: Prompt Shields distinguiendo la inyección directa de la que viene en los documentos, y Defender con su plan de IA mirando el tráfico de modelos. El perímetro no tiene nombre propio en Azure: se compone y se exige por policy.”

Qué viene

Módulo 11: operación autónoma — el cierre técnico de la serie. Azure Monitor y Application Insights (el APM más maduro de las tres casas), KQL como el lenguaje que interroga todo lo que este módulo centralizó, las alarmas con action groups — y la aprobación asíncrona con las dos herramientas del módulo 3: Durable Functions esperando el evento humano con timer de timeout, o Logic Apps con el conector de aprobaciones que manda el correo con botones. La doctrina completa, en su tercera y más cómoda implementación.

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