El módulo 2 de AWS estableció el patrón que gobierna la serie: el agente es un principal con identidad propia, permisos por tarea y cero llaves de larga vida — la política es la jaula que el prompt no puede alucinar. Nada de eso cambia en GCP. Lo que cambia son las piezas y una filosofía de asignación que merece atención propia.

Concepto	En AWS	En GCP
Identidad de workload/agente	Rol IAM (se asume)	Service account (se adjunta o se impersona)
Documento de permisos	Policy JSON (allow/deny/condition)	Rol (lista de permisos) + binding (quién lo tiene y dónde)
Permisos mínimos	Políticas a medida	Roles predefinidos granulares (o custom)
Credenciales temporales	STS al asumir rol	Tokens de la service account / impersonation
Humanos	Identity Center (SSO)	Cloud Identity / Google Workspace
CI/CD externo sin llaves	Federación OIDC	Workload Identity Federation

La tesis del módulo

En GCP la pregunta de permisos se invierte: AWS pregunta “¿qué puede hacer esta identidad?” (la política vive en el principal); GCP pregunta “¿quién puede hacer qué sobre este recurso o esta rama de la jerarquía?” (el binding vive en el recurso y se hereda hacia abajo). El resultado práctico es el mismo — el agente con su service account mínima — pero el camino del error es distinto: en AWS el permiso de más se otorga; en GCP, se hereda sin que nadie lo escriba en el proyecto donde aparece.

Las piezas, en diferencial

Service account: la identidad de workload. A diferencia del rol de AWS (que se asume por sesiones), la service account se adjunta al cómputo (este Cloud Run corre como esta SA) o se impersona (una identidad genera tokens de otra, con permiso explícito y auditado — el equivalente funcional de asumir un rol). El patrón de la plataforma es idéntico al de AWS: una service account por agente, jamás la default del proyecto.
Roles y bindings: un rol de GCP es una lista de permisos con nombre (roles/aiplatform.user, roles/pubsub.subscriber); un binding dice “esta identidad tiene este rol en este ámbito” — y el ámbito puede ser un recurso, un proyecto, una carpeta o la organización. GCP trae cientos de roles predefinidos granulares: el mínimo privilegio suele armarse combinando predefinidos, con roles custom como excepción y los roles basic (Owner/Editor/Viewer) como anti-patrón directo — Editor en un proyecto es el Action: "*" de GCP.
La herencia: el binding otorgado en la carpeta prod/ aplica a todos sus proyectos, presentes y futuros. Es la bendición (administras en un lugar) y la trampa del título: los permisos efectivos de tu agente son la suma de los bindings de toda su cadena jerárquica, incluidos los que alguien otorgó tres niveles arriba el año pasado. En AWS, para saber qué puede un rol lees sus políticas; en GCP, miras el recurso y toda su ascendencia.

Ojo — audita hacia arriba: la pregunta “¿qué puede hacer la service account del agente?” se responde en GCP con el análisis de la cadena completa (la consola y las herramientas de policy analyzer existen para esto). El incidente típico no es un binding malicioso: es el roles/editor otorgado en una carpeta “temporalmente” que convirtió a todos los agentes de abajo en superusuarios. La revisión periódica de bindings heredados es al IAM de GCP lo que la caza de Action: "*" es al de AWS.

   LOS PERMISOS EFECTIVOS SE HEREDAN HACIA ABAJO

  organización ──► binding: roles/viewer
        │
        ▼
  carpeta prod/ ──► binding: roles/editor ("temporal")
        │
        ▼
  proyecto agente-triaje ──► binding: roles/aiplatform.user
        │
        ▼
  ┌──────────────────────────────────────────┐
  │ SA del agente — permisos efectivos:      │
  │ viewer + EDITOR + aiplatform.user        │
  │ el editor heredado no se ve en el        │
  │ proyecto: se audita hacia arriba         │
  └──────────────────────────────────────────┘

Sin llaves, versión GCP

La regla de oro de AWS — cero llaves de larga vida en el camino del agente — tiene en GCP un matiz reforzado: las service accounts pueden exportar llaves JSON, y esa llave JSON es exactamente el anti-patrón (eterna, copiable, exfiltrable por inyección si el agente puede leerla). La práctica correcta:

Cómputo en GCP: la service account adjunta provee tokens automáticamente. Cero llaves, cero configuración.
Impersonation para saltos: cuando un servicio necesita actuar como otro (el orquestador que dispara al agente), impersonación con permiso explícito — auditada en cada uso, como el AssumeRole de AWS.
Todo lo externo (CI/CD, otras nubes): Workload Identity Federation — la identidad externa verificable (el token OIDC de GitHub Actions) se intercambia por credenciales temporales. Y las organization policies pueden prohibir la creación de llaves JSON en toda la jerarquía — el guardrail que convierte la buena práctica en física. Actívala.

El test del módulo de AWS aplica intacto: si tu diseño necesita pegar una llave donde el agente pueda leerla, el diseño está mal — en cualquier nube.

El confused deputy no se quedó en AWS

El agente multiusuario con una service account potente al servicio de cualquier prompt es el mismo problema en GCP. Las herramientas: impersonation por sesión con service accounts acotadas, o validación dura en la capa de herramientas — y la teoría de la intersección sigue siendo la referencia. Sin cambios; solo se recuerda.

Errores comunes

Usar la service account default del proyecto. Viene con permisos amplios y la comparten todos los servicios del proyecto que no declaren la suya: es el rol Dios por omisión. Una SA por agente, siempre.
Otorgar roles basic (Editor/Owner). Editor es el comodín de GCP. Los predefinidos granulares existen precisamente para no usarlo; si un predefinido no calza, rol custom — nunca el basic.
Exportar llaves JSON de service accounts. La llave eterna y copiable que la plataforma no necesita: cómputo con SA adjunta, impersonation para saltos, federación para lo externo — y la organization policy que prohíbe crearlas.
Leer permisos solo en el proyecto. Los bindings heredados de carpetas y organización son invisibles si miras solo el nivel del recurso. La auditoría sube la jerarquía completa o no es auditoría.
Traducir “rol de AWS” por “rol de GCP”. El rol de AWS es una identidad; el de GCP, una lista de permisos. El equivalente del rol-identidad de AWS es la service account. Confundirlos hace ilegible cualquier conversación de diseño.
Repetir bindings proyecto por proyecto. Si el mismo binding aparece en diez proyectos, pertenecía a la carpeta. La herencia es la herramienta — usarla bien es tan importante como auditarla.

La frase para llevarse

“Misma jaula, otro cerrajero: el agente en GCP es una service account mínima, sin llaves JSON jamás, con impersonation auditada para los saltos y federación para lo externo. La novedad está en la herencia — tus permisos efectivos incluyen lo que alguien otorgó tres niveles arriba — así que audita hacia arriba, no solo hacia el recurso.”

Qué viene

Módulo 3: cómputo — Cloud Run como filosofía. Las tres preguntas del cómputo (duración, entorno, forma del trabajo) ya las sabes hacer; en GCP la respuesta converge con una fuerza inusual hacia un solo servicio: Cloud Run, con sus services (tráfico), sus jobs (tareas efímeras) y las functions montadas encima. El módulo más corto de traducir de la serie — y el que muestra a GCP en su mejor versión.

Arquitectura GCP — Módulo 2: identidad y service accounts