Security & Identity

What's new in IAM: Security, governance, and runtime defense

May 6, 2026

Abhishek A Hemrajani

Senior Director, Product Management, Google Cloud Security

Try Gemini Enterprise today

The front door to AI in the workplace

The AI era demands a fundamental shift in security, and that includes identity and access management (IAM). Traditional controls simply aren’t built for autonomous AI agents that interact with sensitive data at machine speed, a reality we address with our new IAM advancements for the agentic enterprise era.

Engineered as built-in Google Cloud capabilities to secure the rapidly-expanding world of AI agents, at Google Cloud Next we introduced a new security and governance paradigm for managing agent identity and access. This comprehensive framework focuses on foundational Agent Identity and an Agent Gateway with Identity-Aware Proxy, while integrating robust agent access management, agent guardrails, and runtime defense to enable a secure cloud environment for your organization.

\"https://storage.googleapis.com/gweb-cloudblog-publish/images/Diagram_02.max-2200x2200.png\"

Security and governance for agents.

Agent Identity

AI agents require verifiable identities to operate securely and with accountability. Agents on Google Cloud can now receive a dedicated Agent Identity: a new, first-class principal type distinct from human identities or generic service accounts.

Built on the open Secure Production Identity Framework For Everyone (SPIFFE) standard, these identities are cryptographically protected, strongly attested, and automatically provisioned. Agent Identity allows you to recognize agents whether they are operating autonomously or on behalf of a user.

With Agent Identity, agents are recognized as an independent identity type, allowing you establish strong governance and agent-specific authorization rules.

To support this, we are announcing the following updates:

\n
Agent Identity for Agent Runtime is now generally available, and Agent Identity for Gemini Enterprise Agent Platform is in preview, granting first-class identity to agents across these platforms.
\n
\n
Agent Identity Auth Manager is in preview, streamlining complex OAuth flows for agents acting on behalf of users by securely handling credentials and tokens.
\n
\n
Certificate Manager support for Agent Identity certificates is also in preview, providing a single pane of glass for managing all agent-related certificates.
\n

Agent Gateway

Agent Gateway enables policy enforcement for all agent-to-agent and agent-to-tool connections. Because AI agents behave non-deterministically, all agent traffic on Google Cloud can now be routed through the Agent Gateway. This centralized flow allows you to enforce strict policies that prevent agents from accessing unauthorized or undesired third-party endpoints.

To extend Zero Trust enforcement to agents and AI systems, the following capabilities are also available in preview:

\n
Identity-Aware Proxy (IAP) for Agents: IAP integrates with Agent Gateway, providing default-on, identity-centric security. It enforces granular access control policies using IAM, based on agent identities and rich contextual attributes derived from the model context protocol (MCP).
\n
\n
Context-Aware Access (CAA) for Agents: CAA evaluates contextual signals such as device health, IP address, and location for agent identities before granting access to resources.
\n

Agent access management

Managing agent access and the operations they can perform is critical to address dormant permissions. Our defense-in-depth approach to agent access management ensures agents only have the privileges they need. To help enforce least privilege access, Agent Identity is now fully supported across Google Cloud's policy, monitoring, and governance solutions.

\n
IAM Allow and Deny policies for Agent Identity are now generally available, letting you control which agents can access specific resources.
\n
\n
Principal Access Boundary (PAB) for Agent Identity is now in preview. PAB acts as a protective additional layer, setting hard limits on the resources a specific agent or group of agents can never access, regardless of other permissions they might inherit.
\n
\n
Unified Access Policy (UAP) for Agent Identity is coming soon. These new access policies act as a rulebook for AI agents, allowing granular control over agent access to tools, APIs, and resources. Policies can be based on the Agent Identity, the effect (allow or deny), the operation, and specific conditions. They can even mandate human-in-the-loop (HITL) approvals for sensitive actions, ensuring critical decisions have human oversight.
\n

All these policy types support the new Agent Identity nomenclature, including hierarchy-aware constructs built on SPIFFE's trust domain and namespace model. This means you can govern agents individually or as groups using the same familiar policy mechanisms already in use for human and service account identities.

Agent guardrails

Beyond providing strong access management capabilities, we must also ensure that AI agents can not exfiltrate data at runtime or pull in unauthorized external data. VPC Service Controls (VPC-SC) support for Agent Identity as first-class principals in ingress and egress rules is now in preview, allowing you to prevent data exfiltration and letting you control the data traversing in and out of your perimeter.

Additional enterprise-wide guardrails are available to enforce that only specific resource configurations are allowed in your cloud environment:

\n
Organization Policies: Administrators can enforce constraints, such as restricting agent creation to specific regions or preventing agents from creating public IP addresses.
\n
\n
Custom Organization Policies: Cloud administrators can tailor constraints to unique agent behaviors and compliance requirements.
\n

To help enterprises continuously monitor and secure AI agents, our new Agent Security dashboard for Agent Platform, in preview, offers agentless discovery, vulnerability scanning, runtime threat detection, and graph-based risk discovery.

Key capabilities of this platform include:

\n
Agent security posture: Provides secure-by-design templates and Google-recommended controls for building agentic applications.
\n
\n
Agent vulnerability scanning: Identifies weaknesses in agent packages and skills, catching flaws before deployment.
\n
\n
Agent asset discovery: Delivers an organization-wide inventory of all AI agents and their associated assets. The inventory process will soon differentiate between shadow AI agents and sanctioned AI agents in your organization.
\n

Collectively, these capabilities help to ensure that agents are secure by design and continuously monitored.

Runtime defense

While agent access management and guardrails can help you manage permissions and prevent data exfiltration, runtime defense controls can provide an additional protection layer addressing runtime security risks and ensuring AI agents function as intended.

Model Armor provides real-time protection for user, model, and agent interactions to protect against runtime risks such as prompt injection, tool poisoning, and sensitive data leakage across Google Cloud services and Gemini Enterprise Agent Platform. It now provides inline protection for Agent Gateway, Agent Runtime, Google Cloud MCP servers, Langchain (in preview) and Firebase (generally available) to help developers add runtime guardrails and sanitization of agent traffic and interactions without the need to change code.

These integrations expand Model Armor's existing inline protections for Agent Platform models, Gemini Enterprise, Apigee, Google Kubernetes Engine inference gateway and load balancers, as well as API interfaces.

Beyond agents: Additional IAM capabilities announced at Next '26

We’re rolling out a comprehensive suite of new capabilities to manage identity, access, and governance at scale. We’re simplifying user provisioning with SCIM support for Workforce Identity Federation, streamlining Gemini Enterprise onboarding, and ensuring strong machine identities with Managed Workload Identity.

We’re also making access management smarter and more secure with the general availability of Gemini-powered IAM Role Picker, Fine-Grained Access Control for BigQuery, and enhanced Privileged Access Manager insights. To mitigate access risks and further strengthen security, we have introduced a VPC Service Controls violation analyser, integrated Identity-Aware Proxy with Cloud Run, mandated multi-factor authentication for specific cohorts, and extended Context-Aware Access to service accounts.

To help you organize and centralize control over your expanding cloud footprint, Custom Organization Policy now supports over 130 Google Cloud products and services.

Learn more

These updates represent a significant leap in how we help you manage your agentic cloud ecosystem, but what hasn’t changed is our commitment to building a secure foundation for your organization. We continue to fortify Google Cloud’s security platform, ensuring that you have a robust and trustworthy environment for all your workloads, including those powered by AI.

By centralizing control and automating identity governance, you can scale your AI initiatives with the confidence that your most critical data remains protected.To learn more, view the Next '26 session recording for an overview of these announcements. For a closer look at how to implement these security best practices in your own organization, please check out our documentation.

Security & Identity

Next ‘26: Redefining security for the AI era with Google Cloud and Wiz

Today at Google Cloud Next, we’re showcasing how we can help you defend against threats at machine speed, protect AI and multicloud environments, and secure cloud workloads at scale.

By Francis deSouza • 11-minute read

$\"https://storage.googleapis.com/gweb-cloudblog-publish/images/GCN26_102_BlogHeader_2436x1200_Opt_3_Dark.max-900x900.jpg\"$

Posted in

Security & Identity

$\"https://storage.googleapis.com/gweb-cloudblog-publish/images/17_-_Security__Identity_NrORvDT.max-700x700.jpg\"$

Security & Identity

Google named a Leader in the External Threat Intelligence Service Forrester Wave™

By Jayce Nichols • 4-minute read

$\"https://storage.googleapis.com/gweb-cloudblog-publish/images/Cloud_CISO_Perspectives_header_4_Blue.max-700x700.png\"$

Security & Identity

Cloud CISO Perspectives: How Google monitors AI threats and advances AI defenses

By Sandra Joyce • 10-minute read

$\"https://storage.googleapis.com/gweb-cloudblog-publish/images/17_-_Security__Identity_NrORvDT.max-700x700.jpg\"$

Security & Identity

Introducing new session management tools with native, granular controls

By Senzeni Mpofu • 3-minute read

$\"https://storage.googleapis.com/gweb-cloudblog-publish/images/Mantis.max-700x700.jpg\"$

Security & Identity

Getting started with Mantis, our open-source bug finding-and-fixing harness

By Nick Galloway • 3-minute read

\n \n \n \n \n \n\n

\n \n \n \n \n \n \n \n \n \n

\n \n \n\n \n\n \n

\n Agent Identity overview\n \n \n

\n \n\n \n \n \n \n

\n\n \n \n \n \n \n\n

Agent Identity provides a strongly attested, cryptographic identity for each agent that is based on the SPIFFE standard. With Agent Identity, your agent can securely authenticate to MCP servers, cloud resources, endpoints, and other agents, acting either on its own behalf or on behalf of an end user. Agent Identity uses the agent's own credential and Agent Identity auth manager. You can use the auth manager to create and manage auth providers, which are the specific configurations used to acquire, manage, and secure API keys, OAuth client IDs, OAuth client secrets, and delegated end-user OAuth tokens.

Unlike service accounts, agent identities are not shared by multiple workloads\nby default, can't be impersonated, and don't allow developers to generate\nlong-lived service account keys. Access tokens generated for Google Cloud\nare cryptographically bound to the agent's unique X.509 certificates to prevent\ntoken theft.

\n\n

Agent Identity works with Agent Registry and Agent Gateway to help secure and govern AI agents. Agent Identity provisions cryptographic identities and manages credentials, Agent Registry catalogs the tools and destinations in your environment, and Agent Gateway enforces access policies and inspects network traffic when agents call those destinations.

\n\n

When Agent Identity is used with Agent Gateway and Gemini Enterprise,\nend-user credentials, such as those provisioned by Gemini Enterprise connectors,\nare encrypted by the auth manager and decrypted at the gateway, ensuring\nthat the agent can never access the raw credential.

\n\n

The following services support Agent Identity:

\n\n

Gemini Enterprise Agent Platform Runtime (Agent Runtime)
Gemini Enterprise
Cloud Run

\n\n

Authentication models

\n\n

To authenticate with various tools and services, Agent Identity supports several authentication models. The model that an agent uses depends on the authentication method offered by the target resource and whether the agent acts on its own authority or on behalf of an end user.

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Authority	Authentication method	Target resource	Use case and solution
User-delegated authority	OAuth 2.0 (3-legged)	External tools and services	When an agent acts on behalf of a specific user (for example, to\n access a user's Jira tasks or GitHub repositories). You configure a\n 3-legged OAuth auth provider in Agent Identity auth manager\n to manage user consent and tokens. For more information, see\n Authenticate using 3-legged OAuth with\n auth manager.
Agent's own authority	Cloud-based identity (Agent Identity)	Google Cloud services	When an agent hosted on Google Cloud needs to access other\n Google Cloud services using its own identity. For more\n information, see Authenticate\n using an agent's own identity.
OAuth 2.0 (2-legged)	External tools and services	Recommended for machine-to-machine authentication with external\n services that support OAuth. You configure a 2-legged OAuth\n auth provider in Agent Identity auth manager to handle\n client credentials and access tokens. For more information, see\n Authenticate using 2-legged OAuth with\n auth manager.
API key	External tools and services	For external services that require a cryptographic key or password for\n authentication. You configure an API key auth provider in\n Agent Identity auth manager to help securely store and manage the\n keys. For more information, see\n Authenticate using API key with\n auth manager.
HTTP basic auth	External tools and services	Uses plaintext passwords. This method is not recommended. You\n can store passwords similar to API key. For more information,\n see Authenticate using API\n key with auth manager.

\n\n

Core components

\n\n

Agent Identity involves several key components that together help provide\nsecure authentication and authorization.

\n\n

SPIFFE-based identity

\n\n

Each agent is assigned a unique identity string, or SPIFFE ID, based on the\nSPIFFE standard. This identity is strongly\nattested, tied to the agent's lifecycle, and mapped directly to the resource URI\nwhere the agent is hosted.

\n\n

The identity follows this format:

spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

For example:

spiffe://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent

When an agent identity is used in an IAM allow policy, the\nprincipal identifier follows this format:

principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Examples:

Vertex AI Agent Engine (organization): principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
Vertex AI Agent Engine (project without an organization): principal://agents.global.proj-9876543210.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
Gemini Enterprise: principal://agents.global.org-123456789012.system.id.goog/resources/discoveryengine/projects/9876543210/locations/global/collections/default_collection/engines/my-test-agent

The identifiers use the following:

TRUST_DOMAIN: The trust domain for your resource hierarchy:\n
- For projects in an organization: agents.global.org-ORGANIZATION_ID.system.id.goog
- For projects without an organization: agents.global.proj-PROJECT_NUMBER.system.id.goog
\n
SERVICE: The short name of the Google Cloud service (for example, aiplatform or discoveryengine).
RESOURCE_PATH: The full path to the resource that hosts the agent.

\n\n

Because the agent itself is the principal, you grant permissions directly to\nthis identifier to control which resources the agent can access.

\n\n

Identity and permission lifecycle

\n\n

You must manage the IAM bindings for your agent identities. Deleting an agent doesn't remove the IAM bindings that reference its principal. These bindings remain in your policies as inactive grants, and you must manually remove them as part of decommissioning an agent.

\n\n

An agent's identity is derived from the ID of the resource that hosts it, such as the reasoningEngines resource ID. If you delete an agent and deploy a replacement, even with the same display name, code, and configuration, the new agent receives a new resource ID and therefore a new principal identifier. Existing IAM bindings that referenced the previous identity don't apply to the new principal. You must grant the required roles to the new principal.

\n\n

Agent credentials

\n\n

Agent credentials provide cryptographic proof of an agent's identity. The\nsystem supports X.509 certificates and Google Cloud access tokens. An\nX.509 certificate is auto-provisioned and managed on the agent to help support stronger\nauthentication.

\n\n

By default, agent identities use mutual TLS (mTLS) with X.509 certificates when communicating directly with Google Cloud APIs. When agents interact across the Agent Gateway, they also use Demonstrating Proof of Possession (DPoP), creating double-bound credentials for end-to-end security. This double binding means that agents authenticate using mTLS for first-party access to the gateway and use DPoP for interactions beyond the gateway.

\n\n

Agent Identity auth manager

\n\n

Agent Identity auth manager is a centralized credentials vault and\nauthentication broker that simplifies outbound tool authentication for your\nagents. It lets agents authenticate using an API key or OAuth client ID and\nsecret, or on behalf of a user through OAuth delegation using end-user access\ntokens. Within the auth manager, you configure auth providers that define the\nauthentication type and credentials for specific third-party applications.

\n\n

Access to Agent Identity auth manager is governed by IAM, and the agent\nuses its own Agent SPIFFE ID to authenticate to the auth manager. All end-user\naccess events are also attributable to the agent's SPIFFE ID, enabling\neasy governance.

\n\n

Agent Identity auth manager automates OAuth credential acquisition, such as\nopening a dialog for user sign-in and consent. It also provides visibility into\nend-user access and allows for access revocation, ensuring better governance\nover user-delegated permissions.

\n\n

For more information, see the\nAgent Identity auth manager\noverview.

Security and governance

\n\n

Agent Identity is fully integrated with Google's policy systems like IAM, Principal Access Boundary (PAB), and VPC Service Controls, which allow for enhanced security and governance. It\nalso integrates with audit logging to ensure accountability and provide clear\naudit logs both when the agent is acting as itself and when it is acting on\nbehalf of an end user.

\n\n

Context-Aware Access: By default, a Google-managed Context-Aware Access\npolicy helps secure agent credentials by\nenforcing mTLS and DPoP token\nbinding. This approach ensures that certificate-bound tokens cannot be replayed outside\ntheir trusted runtime environment.
IAM integration: Support for standard IAM allow\npolicies and deny policies.
Principal Access Boundary (PAB): A PAB limits the resources an agent\ncan access, regardless of other permissions.
VPC Service Controls: Support for perimeter protection and principal usage:\n
- Perimeter protection: You can add the Agent Identity API (agentidentity.googleapis.com) and the Agent Identity Credentials API (agentidentitycredentials.googleapis.com) to a service perimeter to help control access to these APIs. To use these APIs within a service perimeter, clients must route requests through the Restricted VIP (restricted.googleapis.com).
- Ingress and egress rules: Support for using agent identities as principals in ingress and egress rules to allow access to resources protected by a service perimeter.
\n

\n\n

How Agent Identity works

\n\n

Agent Identity authenticates and authorizes agent actions through a workflow\ndesigned to help enhance security:

\n\n

Identity assignment: When you deploy an agent, Google Cloud\nassigns it a unique SPIFFE identity and an X.509 certificate. Each\nX.509 certificate is valid for 24 hours, and Google Cloud\nautomatically keeps it current to maintain security.
Credential acquisition: The method that agents use to acquire\ncredentials depends on what they are trying to access. The following are\nsome examples:\n
- Access Google Cloud services: The agent requests a\n bound access token. This token is cryptographically bound to the\n agent's unique X.509 certificate to help prevent token theft. For\n more information, see\n Security and governance.
- Access external tools: The agent uses\n Agent Identity auth manager to retrieve the required\n credentials (such as API keys or OAuth tokens) from an\n auth provider. Auth manager supports both\n user-delegated authority and the\n agent's own authority.
\n

\n\n

Benefits of Agent Identity

\n\n

Agent Identity improves security over standard service accounts.

\n\n

Strong isolation: Unlike service accounts, agent identities are not\nshared by multiple workloads by default, can't be impersonated, and don't\nallow developers to generate long-lived service account keys.
Credential security: Default Context-Aware Access policies make bound tokens\nunreplayable, helping to protect against token theft and account takeover.\nWhen Agent Identity is used with Agent Gateway and Gemini Enterprise,\nend-user credentials, such as those provisioned by Gemini Enterprise\nconnectors, are encrypted by the auth manager and decrypted at the gateway,\nensuring that the agent can never access the raw credential.
Least-privilege approach: Provides per-agent identities instead of\nshared service accounts to eliminate over-permissioned agents.
Reduced friction: Automates complex OAuth flows and manages API keys\nfor simpler tool integration.
Improved observability: Provides clear audit logs. When an agent acts\non a user's behalf, logs show both the agent's and user's identities.

\n\n

Limitations

\n\n

Cloud Storage legacy bucket roles: You cannot grant agent\nidentities legacy bucket roles (for example,\nstorage.legacyBucketReader).

\n\n

What's next

\n\n

\n\n\n \n \n\n \n \n \n\n \n

\n\n \n \n \n \n \n \n \n \n \n\n \n\n \n \n \n \n\n

What's new in IAM: Security, governance, and runtime defense

Abhishek A Hemrajani

Try Gemini Enterprise today

Agent Identity

Agent Gateway

Agent access management

Agent guardrails

Runtime defense

Beyond agents: Additional IAM capabilities announced at Next '26

Learn more

Next ‘26: Redefining security for the AI era with Google Cloud and Wiz

Related articles

Google named a Leader in the External Threat Intelligence Service Forrester Wave™

Cloud CISO Perspectives: How Google monitors AI threats and advances AI defenses

Introducing new session management tools with native, granular controls

Getting started with Mantis, our open-source bug finding-and-fixing harness

\n Agent Identity overview\n\n \n \n \n \n\n \n \n Stay organized with collections\n \n \n \n Save and categorize content based on your preferences.\n \n \n \n \n \n

Authentication models

Core components

SPIFFE-based identity

Identity and permission lifecycle

Agent credentials

Agent Identity auth manager

Security and governance

How Agent Identity works

Benefits of Agent Identity

Limitations

What's next

\n Agent Identity overview\n \n \n