Google Cloud pone identidad y registro a los agentes: MCP empieza a parecer infraestructura gobernable
Google Cloud publicó el 12 de junio de 2026 la disponibilidad general de Agent Identity y la preview pública de Agent Registry. Para builders, la señal útil es que el problema ya no es conectar un MCP server, sino saber qué agente puede descubrirlo, invocarlo y auditarlo.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Google Cloud dejó una señal importante el 12 de junio de 2026: Agent Identity llegó a disponibilidad general y Agent Registry entró en preview pública. La noticia no suena tan vistosa como un modelo nuevo, pero para equipos que ya conectan herramientas por MCP es una pieza más seria: identidad separada para agentes, catálogo central y permisos visibles.
El cambio importa porque muchas pruebas de agentes nacen con credenciales humanas, servidores MCP sueltos y listas de tools copiadas entre proyectos. Eso funciona para un demo. En producción, se vuelve deuda de seguridad.
Qué anunció Google
Las release notes de Google Cloud mencionan dos piezas juntas. Agent Identity ayuda a que un agente se autentique de forma segura contra MCP servers, recursos cloud, endpoints y otros agentes, actuando como sí mismo o en nombre del usuario final. Agent Registry funciona como catálogo central para guardar, descubrir y gobernar agentes, MCP servers, tools y endpoints dentro de Google Cloud.
La documentación de Agent Registry lo ubica como el pilar de gobernanza de Gemini Enterprise Agent Platform. No es solo un listado bonito: permite consultar recursos como Agent, McpServer y Endpoint, y plantea tres objetivos claros:
- descubrir y reutilizar capacidades ya existentes;
- conectar por protocolos estándar como MCP y A2A;
- aplicar límites de seguridad e identidad sobre una flota de agentes.
Por qué esto sí cambia el diseño
La consulta probable no es masiva, pero sí cualificada: Google Agent Identity MCP, Google Agent Registry, MCP server governance, agent identity IAM. No hay herramienta SEO conectada aquí, así que la demanda se infiere por el release oficial, la documentación nueva y el crecimiento de MCP como forma estándar de conectar agentes a sistemas reales.
El patrón que conviene adoptar es simple: no uses la cuenta de una persona como identidad operativa del agente. Google recomienda crear una identidad separada para producción, darle permisos mínimos y usar atributos de IAM para evitar operaciones de escritura en recursos importantes cuando no hagan falta.
Ese punto es enorme para Latinoamérica, donde muchos equipos adoptan agentes con presupuestos pequeños y poca plataforma interna. Si el primer agente ya nace con identidad propia, permisos acotados y registro central, después es mucho más fácil auditar quién llamó qué tool y con qué alcance.
Checklist para probarlo sin abrir demasiado
Yo empezaría con una prueba de bajo riesgo:
- crea una identidad de agente separada, no una credencial personal;
- registra un solo MCP server con tools de lectura;
- asigna roles mínimos para descubrir e invocar;
- evita permisos
Owner,EditoroVieweramplios; - revisa logs antes de permitir acciones de escritura.
La arquitectura se parece más a gobernar microservicios que a instalar un plugin. Un registry ayuda a descubrir qué existe. Una identidad ayuda a decidir quién puede tocarlo. El runtime del agente sigue necesitando prompts, evals y revisión humana.
Esta noticia conecta bien con la guía de function calling y herramientas: el problema maduro no es darle más tools al agente, sino darle las tools correctas con límites verificables.
La lectura corta
Google está moviendo MCP hacia una capa de plataforma: identidad, catálogo, permisos y gobernanza. Para builders, eso cambia la pregunta. Ya no basta con "¿puedo conectar esta API al agente?". Ahora toca preguntar: ¿qué identidad usa, dónde se descubre, quién lo aprueba y cómo sé qué hizo?