Google Cloud gives AI agents their own identities and tighter network limits

What Google announced

Google Cloud has laid out a wider set of security features for companies that run AI agents, meaning software that takes actions on a person's behalf rather than only answering questions. As Tech Wire Asia reported, the updates cover how agents prove who they are, where they can connect, and how the code behind them is checked for flaws. Google presented them at its Cloud Security Summit and in a blog post.

The stated reason is that autonomous systems reaching into company applications and data create new risks. Google pointed to the OWASP Foundation's 2025 Top 10 for Agentic Applications, which lists identity and privilege abuse, tool misuse and insecure communication between agents. It also noted that the US standards body NIST published proposed design principles in October 2026. Those principles recommend that each agent have a distinct identity and that delegated permissions be restricted.

Every agent gets its own ID

The core idea is to stop agents from sharing one all-purpose login. Google's Agent Identity assigns each agent its own cryptographic identity, built on a standard called SPIFFE, instead of a shared service account (a generic login used by software). An agent can act under its own credentials or on behalf of a user, and permissions are set through IAM, the policy system that decides who may do what in Google Cloud.

Auth Manager handles the secrets. It became generally available in August 2026 and stores credentials in a Google-managed vault governed by IAM policies. It also automates OAuth 2.0 (the common "sign in with" permission process) and refreshes tokens a user has delegated. Google says this means fewer repeated consent prompts and less exposure of the credentials agents use.

Two companion pieces round this out. Agent Registry is a catalogue of the tools and destinations agents may use. Agent Gateway enforces access rules and inspects traffic when an agent connects to them.

A preview feature adds JSON Web Token support. It issues standard OpenID Connect tokens, so an agent can authenticate to services on Amazon Web Services, Microsoft Azure, on-premises systems and Model Context Protocol (MCP) servers without long-lived API keys. MCP is a common way for agents to plug into outside tools. Long-lived keys are risky because anyone who steals one can keep using it.

Fencing in the network and the conversation

Google also tightened the network side. Rules in VPC Service Controls, which draw protective perimeters around cloud resources, can now reference IAM roles for both incoming and outgoing traffic. When a rule names a role, it allows only the operations that role's permissions cover. These rules work alongside existing IAM policies, and Google says they help block unauthorised access and data exfiltration, meaning data leaking out of a protected area. Workload Identity Federation support for GKE, Google's managed Kubernetes service, is available in preview.

For what agents say, Google described a custom topic detector in Model Armor, its service for screening what goes into and comes out of AI models. It is in preview. Administrators write prompt-based rules that classify an agent's conversations as on-topic or off-topic. Google named healthcare, insurance and retail as likely uses, where a company wants an agent to stay within permitted subjects.

Finding and fixing flaws in agent code

The other half of the announcement is about vulnerabilities. Through Wiz, which Google owns, customers can discover and map their AI agents and the infrastructure behind them. Wiz studies an application's purpose, abilities and permissions, then combines that with infrastructure data in its Security Graph to spot possible attack paths and threats while the software runs.

Wiz's AI Static Application Security Testing, or AI SAST, entered public preview in October 2026. It reads application code, looks for weaknesses in business logic, and ties its findings to what is actually deployed. Wiz's October 2026 technical report gave an example: an AI agent's API accepted any bearer token (a pass that proves identity) as valid. According to Wiz, its Red Agent testing tool used that gap to pull sensitive customer, employee and financial data through the agent, even though the underlying database had its own access controls.

Wiz's Green Agent can then investigate such findings and draft fix plans. Google also updated CodeMender, an AI security agent that finds vulnerabilities and writes patches. It is in preview and supports several AI models, including Gemini 4 Argon. It can scan a folder, a whole repository, or only files changed since the last scan, so developers can adjust coverage and cost. Testing and exploit simulation can run in an operating-system sandbox or an isolated virtual machine, with human approval needed for certain local file changes and commands. Google says hundreds of customers have used it since the July 2026 preview began.

IDC's Katie Norton said in Google's announcement: "Detection without remediation only adds to developer workloads."

Where the gaps still are

Several of these features are still previews, and the source gives no pricing. It also does not report independent results on how well the controls work. Google's list of supported platforms varies between its summary and its documentation, so check which services your agents actually run on.

Google also expanded the link between Wiz Defend and Google Security Operations, its security-monitoring product. The two share a data model, so security teams can investigate a threat from either one. The integration includes two-way synchronisation, a dedicated Wiz Content Pack, and investigation analysis from Wiz's Blue Agent inside Google Security Operations.