Securing AI Agents on Google Cloud: Agent Identity, Agent Registry, and Agent Gateway Explained

An AI agent that can read email, query databases, and call APIs is, from a security point of view, a new kind of employee: one that works at machine speed, never sleeps, and can be tricked by text. Traditional controls weren’t designed for that. Shared service accounts hide which agent did what, and API keys get copied into places they shouldn’t.

Google’s answer on Gemini Enterprise Agent Platform is three building blocks: Agent Identity (who the agent is), Agent Registry (which agents and tools are approved), and Agent Gateway (what traffic is allowed). This guide explains each one, how they fit together, the gotchas in Google’s documentation, and a practical security checklist.

These controls matter most when agents work with the data your people keep in Google Workspace, Microsoft 365, and other systems.

Table of contents

Open Table of contents

• The Four Questions of Agent Security
• Agent Identity: One Principal per Agent
• Agent Registry: The Approved Catalog
• Agent Gateway: The Policy Enforcement Point
• Detection and Posture
• A Reference Architecture
• Anti-Patterns to Avoid
• Agent Security Checklist
• Conclusion

The Four Questions of Agent Security

A useful way to frame agent governance is four questions. They work as a structure for any agent program:

---

Agent Identity: One Principal per Agent

What it is

Agent Identity gives each agent deployed to Agent Runtime its own identity, tied to the agent’s lifecycle. Google positions it as a more secure principal than service accounts:

The principal format

principal://TRUST_DOMAIN/NAMESPACE/AGENT_NAME

The trust domain is agents.global.org-ORGANIZATION_ID.system.id.goog for projects in an organization, or agents.global.proj-PROJECT_NUMBER.system.id.goog otherwise.

Turning it on

Agent Identity is opt-in per runtime, so existing infrastructure-as-code keeps working with service accounts. Ways to enable it:

• Python SDK: create the runtime with identity_type set to AGENT_IDENTITY, using the v1beta1 API version
• Agents CLI: agents-cli deploy --agent-identity
• ADK: add .agent_engine_config.json containing "identity_type": "AGENT_IDENTITY" before running adk deploy

Default and recommended roles

By default, agents get roles/aiplatform.agentContextEditor and roles/aiplatform.agentDefaultAccess, covering their own logging, metrics, model access, sessions, memories, and sandboxes. Google recommends adding roles/aiplatform.expressUser, roles/serviceusage.serviceUsageConsumer, roles/browser and, if the agent reads secrets, roles/secretmanager.secretAccessor, then granting only the extra access each agent’s tools need.

You can grant to a single agent principal, or use principalSet bindings to cover all agents in a project or organization. Use deny policies or Principal Access Boundary policies to put hard limits on what any agent can reach.

For agent-to-agent calls, the calling agent’s identity needs roles/agentregistry.viewer and roles/aiplatform.user on the sub-agent.

Token binding

A Google-managed Context-Aware Access policy is on by default. It binds certificate-bound (mTLS) tokens to the agent’s runtime, so a token stolen from logs or memory can’t be replayed elsewhere. It fails with “Context-Aware Access requirements are not met.” You can opt out with GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES=False, but Google strongly discourages it.

The redeploy gotcha

Deleting and recreating an agent creates a new reasoningEngines resource, and a new principal. IAM grants on the old principal don’t carry over, which can silently break access in blue-green, ephemeral, or Terraform pipelines. Google’s mitigations:

• After deploying, read the new identity from spec.effectiveIdentity and reapply bindings in the same pipeline
• Put baseline permissions on project-wide principalSet bindings

Build this into your deployment pipeline from day one.

Audit logs

With Cloud Logging enabled, logs show which agent accessed a resource. For user-delegated actions, they show both the user and the agent; for autonomous actions, the agent alone. That’s the accountability trail auditors will ask for.

Limitation: agent identities can’t be granted legacy Cloud Storage bucket roles (legacyBucketReader, legacyBucketWriter, legacyBucketOwner). Use modern IAM roles.

---

Agent Registry: The Approved Catalog

Agent Registry is a central catalog for storing, discovering, and governing agentic components:

Why it matters for security:

• Discovery prevents sprawl. Teams reuse an approved agent instead of building a fifth copy with broader permissions.
• Gateway policies reference it. Agent Gateway queries the registry and evaluates IAM and content policies before routing traffic.
• Agent Studio uses it. Agents built visually can only attach MCP servers and remote sub-agents from the registry (see our Agent Studio guide).

On the Gemini Enterprise side, Google made Agent Registry governance and agent identity viewing generally available in June 2026.

---

Agent Gateway: The Policy Enforcement Point

Agent Gateway sits at the network entry and exit of agent interactions: between users and agents, agents and tools, and agents and other agents.

Traffic modes

Policy types

For MCP traffic, the gateway parses requests, so policies can allow or block specific tools on a server, not just the whole server.

Limits and gotchas

• Each gateway instance governs up to 5,000 registry resources
• Each gateway can be associated with up to two registries (one global, one regional or multi-regional)
• Changing an agent’s gateway binding archives all its revisions on Agent Runtime (see our Agent Runtime guide)
• Gaps in coverage for Gemini Enterprise: ingress mode isn’t supported, and Google says direct communication between Gemini Enterprise agents (see our A2A guide) and between agents and data connectors, including the custom MCP server, doesn’t trigger gateway policy enforcement (see our MCP guide)
• Turning on Agent Gateway for Gemini Enterprise routes all its traffic through the gateway, including LLM calls, straight away, and policies can take up to 15 minutes to apply

Close those gaps deliberately. They’re where real-world agent incidents are most likely to start.

---

Detection and Posture

Identity, registry, and gateway prevent bad things. These features help you spot them:

Send findings to the same SOC workflow as your other cloud alerts.

---

A Reference Architecture

1. Build agents with ADK or Agent Studio; store code in Git
2. Deploy to Agent Runtime with Agent Identity enabled
3. Register each agent, MCP server, and tool in Agent Registry
4. Route all agent traffic through Agent Gateway, with default-deny IAM Unified Access Policies
5. Inspect traffic with Model Armor and, where useful, Semantic Governance rules
6. Contain data with VPC Service Controls and Private Service Connect
7. Observe with Cloud Logging, Cloud Trace, and Agent Observability
8. Detect with Agent Threat Detection and the Security Command Center dashboard
9. Publish approved agents to employees in Gemini Enterprise

---

Anti-Patterns to Avoid

---

Agent Security Checklist

For the Workspace side of the same discipline, our security hardening guide covers OAuth app controls and admin roles. Agents that work inside Workspace itself need the same care: Gemini coworker agents get their own Workspace accounts, and our coworker agents guide sets out an admin policy for them.

---

Conclusion

Agents need the same security fundamentals as people and services (identity, least privilege, approved resources, network controls, and audit) adapted to how agents actually behave. Agent Identity gives every agent its own attested principal with runtime-bound tokens; Agent Registry gives you one catalog of approved agents and tools; Agent Gateway enforces default-deny policies and Model Armor inspection on the traffic in between.

Watch the documented gaps (new principals when an agent is recreated, and direct agent and connector traffic in Gemini Enterprise that the gateway doesn’t police) and close them on purpose. With those controls in place, you can let agents work with the data in your Google Workspace and Google Cloud environments without losing sight of who did what.

---

Official Google documentation:

• Agent Identity with Agent Runtime
• Agent Gateway overview
• Agent Registry overview
• Introducing Gemini Enterprise Agent Platform

Related reading:

• Agent Runtime: Deploy and Scale AI Agents: where Agent Identity is enabled.
• MCP Servers in Gemini Enterprise: routing MCP traffic through the gateway.
• Google Workspace Admin Security Hardening Guide: security fundamentals on the Workspace side.
• Google Workspace Password Policy and 2SV Enforcement: the human-identity controls agent identity builds on.
• Gemini Coworker Agents: governing agents that have their own Workspace accounts.