El módulo de seguridad de AWS dejó el sistema completo: secretos que el agente usa sin ver, cifrado cuya llave controlas, filtrado declarativo en el punto único, y la mitad no negociable — evidencia inmutable con detección encima. El marco de dos columnas (prevención/detección) y el patrón de inyección en el borde viajan intactos. GCP traduce la mayoría y aporta una pieza que merece el título de joya.

Pieza	En AWS	En GCP
Almacén de secretos	Secrets Manager	Secret Manager
Control de llaves de cifrado	KMS + CMK	Cloud KMS + CMEK
Guardrails del diálogo	Bedrock Guardrails	Model Armor
Perímetro anti-exfiltración de datos	— (se arma con red)	VPC Service Controls
Caja negra de acciones	CloudTrail → cuenta seguridad	Cloud Audit Logs → proyecto central
Detección de amenazas	GuardDuty	Security Command Center

La tesis del módulo

Tres piezas se traducen solas — Secret Manager, CMEK, Audit Logs — y dos definen el sabor GCP: Model Armor filtra el diálogo de cualquier modelo (no solo los de la casa) desde una política central, y los VPC Service Controls dibujan un perímetro alrededor de los servicios de datos que hace estructuralmente inviable la exfiltración vía APIs de Google — la jaula que en AWS armabas con endpoints y políticas, aquí es un servicio con nombre. Prevención y detección se diseñan juntas; eso tampoco cambió.

Las traducciones directas (rápido y sin repetir)

Secret Manager: mismo patrón de inyección en el borde — la herramienta lee el secreto al usarlo con su service account, el modelo jamás lo ve, cada acceso queda auditado. El test de arquitectura (“¿puede tu agente imprimir la credencial si se lo piden con astucia?”) se aplica igual y debe dar el mismo “no” estructural.
CMEK (customer-managed encryption keys): el CMK de esta nube — tus llaves en Cloud KMS cifrando Firestore, GCS, discos; doble puerta (recurso + llave) y auditoría de cada uso. El honeypot del historial (módulo 6) las lleva en cuanto hay datos de clientes; sin cambios en el argumento.
Cloud Audit Logs: el diario de lo que tus agentes hicieron — admin activity logs siempre encendidos, data access logs que activas para los servicios sensibles (hazlo: leer el historial es exactamente lo que quieres auditado). El patrón organizacional es el mismo de AWS: los logs fluyen a un proyecto central de seguridad (módulo 1: la carpeta seg/) donde el admin del proyecto comprometido no alcanza — evidencia que no se puede borrar desde el lugar del incidente.

Model Armor: el guardrail que no pregunta la marca del modelo

Model Armor es el filtrado declarativo de GCP para el diálogo con LLMs: detección de inyección de prompt y jailbreak, filtros de contenido por categoría y umbral, detección y enmascaramiento de PII, y filtrado de URLs maliciosas — aplicado a prompts y respuestas. Dos propiedades de arquitectura lo distinguen de su primo de AWS:

Es agnóstico del modelo — por API: tu capa de acceso (la librería única o el proxy del módulo 7) llama a Model Armor para sanear el prompt antes de enviarlo y la respuesta antes de devolverla, sea el modelo Gemini, Claude, Llama o uno fuera de Vertex. Si tu plataforma es multi-modelo, la política de contenido vive en un solo lugar de verdad, no en un guardrail por catálogo.
Se declara en el punto único, con letra chica: las plantillas se centralizan y los floor settings (umbrales mínimos que toda plantilla debe cumplir) se fijan a nivel de organización, carpeta o proyecto. La integración transparente — Model Armor interceptando la API de Gemini sin que tu código lo llame — al escribir esto cubre solo modelos Gemini, se activa por proyecto y existe en un puñado de regiones de Europa y Asia (ninguna de América). Para la plataforma de este curso, el filtro va en tu capa de acceso, no en la magia del servicio.

La advertencia del curso de AWS se copia con orgullo: el guardrail filtra el diálogo, no gobierna la plataforma — no reemplaza IAM, ni egress, ni la política de datos en persistencia. Una capa entre seis.

VPC Service Controls: la joya

La pieza sin equivalente integrado en AWS. Un perímetro de servicio (service perimeter) encierra un conjunto de proyectos y servicios de Google (Storage, Firestore, BigQuery, Vertex…) con una regla brutal: las APIs de esos servicios solo responden dentro del perímetro. Un atacante con credenciales válidas robadas — el escenario donde IAM ya perdió — intenta leer tu bucket desde fuera: la API misma lo rechaza, porque la llamada no viene del perímetro. La exfiltración vía servicios de Google deja de ser un problema de permisos y pasa a ser estructuralmente inviable.

Para la plataforma de agentes es la tercera jaula, independiente de las otras dos:

   LAS TRES JAULAS INDEPENDIENTES (GCP)

  ┌─────────────────────────────────────────┐
  │ perímetro VPC-SC: las APIs de datos     │
  │ solo responden desde adentro            │
  │  ┌───────────────────────────────────┐  │
  │  │ red: privado + egress lista corta │  │
  │  │  ┌─────────────────────────────┐  │  │
  │  │  │ IAM: service account mínima │  │  │
  │  │  │        ┌─────────┐          │  │  │
  │  │  │        │ agente  │          │  │  │
  │  │  │        └─────────┘          │  │  │
  │  │  └─────────────────────────────┘  │  │
  │  └───────────────────────────────────┘  │
  └─────────────────────────────────────────┘

Cuidado — el perímetro es potente y ceremonioso: VPC-SC rompe todo acceso legítimo que no declaraste (el laptop del desarrollador, el SaaS que lee un bucket, la integración de turno) y sus reglas de excepción (ingress/egress rules del perímetro) exigen mantenimiento adulto. La adopción sana es por etapas: el modo dry-run primero (loguea lo que bloquearía, sin bloquear), los proyectos de datos sensibles después, la plataforma entera al final. Es la pieza de la escala “producción con datos regulados” — no del piloto de la semana uno.

Security Command Center: el vigilante

El techo de detección: postura (configuraciones peligrosas, permisos anómalos, llaves expuestas) y amenazas activas sobre los logs — el rol de GuardDuty más el de los servicios de postura de AWS, en un panel organizacional. Para agentes, la misma lectura de siempre: la anomalía conductual de una service account (llama APIs que nunca llamó, a horas que no le tocan) es la firma del agente comprometido, y el vigilante la ve sin reglas artesanales. Se enciende a nivel organización y sus hallazgos entran al mismo circuito de alarmas-con-acción del módulo 11.

Errores comunes

La llave en el contexto, ahora en GCP. El test no cambia de nube: si el modelo puede leer la credencial, una inyección puede pedirla. Secret Manager + borde, siempre.
Data access logs apagados en los servicios sensibles. Vienen apagados por defecto (volumen); el historial del agente sin auditoría de lectura es el honeypot sin cámaras. Se encienden para Firestore/GCS/BigQuery sensibles el día uno.
Model Armor como estrategia completa. Filtra el diálogo. IAM, egress, perímetro y persistencia siguen siendo capas propias — el resumen no existe en ninguna nube.
VPC-SC en big bang. Encender el perímetro sobre todo un viernes rompe integraciones legítimas que nadie listó. Dry-run, datos sensibles, expansión — en ese orden.
Auditoría en el proyecto del incidente. Logs que el admin comprometido puede tocar no son evidencia. Proyecto central de seguridad, como la cuenta central de AWS.
Toda la inversión en prevenir. El estribillo final del módulo de AWS aplica letra por letra: sin Command Center y anomalías, apuestas a la prevención perfecta. No existe.

La frase para llevarse

“Traduce Secret Manager, CMEK y los audit logs sin pensar; piensa en las dos piezas con personalidad: Model Armor declara la política de contenido una vez para cualquier modelo, y VPC Service Controls convierte la exfiltración vía APIs de Google en algo que la infraestructura no permite — la tercera jaula, para cuando IAM y la red ya perdieron.”

Qué viene

Módulo 11: operación autónoma. Cloud Monitoring, Logging y Trace como el stack de observabilidad (con las log-based metrics como truco local), las mismas alarmas-que-exigen-acción, y la aprobación asíncrona traducida: Workflows con callbacks como el waitForTaskToken de esta nube — el agente que pide permiso, espera dormido sin facturar, y el timeout conservador que ya es doctrina de la serie.

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