Google Cloud expands AI agent security and identity controls

What changed

On November 4, 2026, Google Cloud used its Cloud Security Summit to announce a material expansion of its controls for AI agents and machine-speed security operations.¹ The date matters here for context: A November 9 announcement was follow-on coverage, not the original event, while CodeMender itself had previously preview on July 21.²³ This was therefore not the launch of an entirely new security portfolio. But it was an important combination of added safeguards, availability changes and integrations spanning software remediation, agent identity, model protection and security operations.

CodeMender, Google Cloud's agentic vulnerability-remediation system, just gained isolated vulnerability verification and exploit simulation in an operating-system sandbox or virtual machine. Google also added human checks for actions such as writing to a local file system or executing commands, alongside scanning modes covering an entire repository, a folder or only changed files.¹ Independent reporting corroborated those controls and distinguished the November expansion from CodeMender's earlier preview release.⁴⁵

The significance is not simply that CodeMender can scan more selectively. The product design places boundaries around what an agent may inspect, execute and change. Sandboxed verification limits where potentially dangerous activity occurs, while human checks create explicit intervention points before consequential operations. Google said hundreds of customers had used CodeMender since the July preview, but that adoption figure remains a vendor-attributed claim rather than independent evidence of production maturity.¹

Google Cloud also designated Auth Manager as generally available. Its documentation describes the service as a centralized credential vault and authentication broker through which agents can use API keys and OAuth-based workflows.⁶ By contrast, Agent Identity support for JSON Web Tokens and the Model Armor custom topic detector were announced in preview, not general availability.¹⁴ That difference should remain visible in enterprise evaluations: the announcement brought together controls at materially different stages of maturity.

The update extended beyond Google's own control surfaces. Google and Wiz announced a shared data model, bidirectional synchronization between Wiz Defend and Google Security Operations, Blue Agent analysis inside Google Security Operations, and integration with Google Threat Intelligence.¹ Wiz separately confirmed that status, severity and comments can synchronize bidirectionally and that Blue Agent analysis is available within Google Security Operations.⁷ Taken together, the verified event is an expansion of an agent-security stack—not a single product launch—and its components range from generally available credential management to preview identity and policy features.

Why it matters

The CIO approach to AI agents now has to move beyond comparing model quality, task completion and unit economics. Autonomous software can obtain credentials, call APIs, inspect repositories, execute commands, change files and participate in operational workflows. Those capabilities make an agent an enterprise actor with an identity, an authority envelope and an execution context. The relevant architecture decision is consequently not just which model performs best, but which platform can govern the resulting actions.

Google Cloud's update provides concrete evidence of that shift. Auth Manager centralizes credential storage and brokers authentication rather than requiring each agent implementation to handle secrets independently.⁶ CodeMender separates exploit verification from the surrounding environment and inserts human checks before selected writes or commands.¹ The Wiz integrations synchronize operational fields across security systems rather than treating agent findings as isolated outputs.⁷ These are different products, but they address interconnected questions: Who is the agent? What may it access? Where may it execute? Which actions require approval? How does evidence move into the security operating model?

The analytical inference is that these questions should become architectural gates, not downstream security reviews. A model can be capable enough for a use case while the surrounding control plane remains unsuitable for production. Conversely, a platform with centralized authentication and isolated execution may still require limited deployment if critical identity or policy capabilities remain in preview. Google Cloud's own mixed availability designations illustrate why CIOs should assess controls individually rather than assigning one maturity label to an entire agent platform.¹⁵

This changes procurement as well as risk governance. A conventional software assessment often treats identity integration, logging and administrative controls as platform attributes. Agentic systems require a more granular evaluation because authority can vary by task and because execution can produce direct operational consequences. CIOs need evidence about credential custody, token support, approval paths, sandbox boundaries, scan or action scope, and the destination of security telemetry. They also need to know which of those controls are generally available and which remain previews.

Interoperability becomes part of the same decision. The Google-Wiz work shows that the operational value of an agent depends partly on whether its findings and state can enter existing workflows with consistent status, severity and comments.¹⁷ Bidirectional synchronization is especially relevant because an agent's output is not the end of a security process. Analysts may change severity, add context or alter status in another system, and those decisions need to remain visible across the workflow. The inference for CIOs is that integration quality should be measured by preservation of control state and human judgment, not merely by whether one product can send an alert to another.

The result is a new evaluation hierarchy. Model capability remains necessary, but it is no longer sufficient. Production readiness depends on whether machine identity, credential brokerage, execution isolation, approval controls and synchronized telemetry operate together at the required maturity level. An enterprise that selects an agent platform before defining those requirements risks allowing the model decision to determine its security architecture by default.

Frontier take

The control plane—not the model—will be the durable point of enterprise differentiation for AI agents.

That assertion follows from the structure of Google Cloud's November update. The most consequential changes do not primarily make a model more intelligent. They govern how autonomous activity is authenticated, constrained, reviewed and incorporated into security operations. Auth Manager addresses credential custody and authentication brokerage; CodeMender's new controls address execution boundaries and approval; Model Armor and Agent Identity extend policy and identity coverage; and the Wiz integrations address shared operational context.⁶¹⁷

CIOs should therefore reject a binary distinction between an approved model and an unapproved model. The more useful unit of governance is an agent operating profile: a defined identity, credential set, permitted resources, execution environment, human-control points and telemetry path. The same underlying model may be acceptable for read-only analysis in one profile and unacceptable for command execution or repository modification in another. This is an analytical framework, not a claim that Google's current portfolio resolves every element.

Availability status is central to that framework. Auth Manager reached general availability, while JWT support for Agent Identity and the Model Armor custom topic detector remained in preview at announcement.¹⁴ A CIO should not let the presence of a generally available broker erase a dependency on a preview identity feature. Nor should an isolated execution option be treated as proof that every connected tool, action or workflow receives the same boundary. Controls must be traced end to end against the intended operating profile.

The strategic implication extends beyond Google Cloud and Wiz. Autonomous software creates a durable identity and execution surface regardless of vendor. The winning enterprise architecture will be the one that can change models or agent applications without rebuilding credential custody, approval policy, isolation and operational evidence each time. Google Cloud's update is important because it makes that architectural contest more explicit.

Three moves for CIOs

— Create an authority register for agents, not merely a model inventory For every production candidate, record the agent's machine identity, credential source, permitted APIs and repositories, token or key type, execution boundary, approval points and telemetry destinations. Attach a maturity designation to each dependency—generally available, preview or otherwise—and approve the complete operating profile rather than the model in isolation.
- Decision trigger: Require this register before any agent receives non-public credentials, invokes an enterprise API, accesses a repository, or can write files or execute commands.
- Why now: Google Cloud's announcement combines a generally available authentication broker with preview identity and policy capabilities, demonstrating that one agent workflow can depend on controls at different maturity levels.¹⁶ An authority register exposes those mismatches before a pilot becomes a production dependency.
— Tie autonomy levels to verifiable execution boundaries Define staged autonomy levels that separately authorize reading, recommending, modifying and executing. Require isolated verification for exploit simulation or similarly consequential activity, and preserve a human approval step for local writes and command execution until the organization has evidence that the relevant boundary, rollback and review mechanisms meet its risk standard.
- Decision trigger: Move an agent to a higher autonomy level only when its requested action exceeds read-only analysis and the isolated environment, approval path and action scope have all been tested against the intended workflow.
- Why now: CodeMender's sandbox or virtual-machine verification, scoped scanning and human checks show that action boundaries can be designed into the agent lifecycle rather than added after deployment.¹⁴ CIOs can now make those mechanisms explicit promotion criteria instead of relying on broad assurances about human oversight.
— Test whether security integrations preserve decisions, not just alerts Run a workflow-level interoperability test in which an agent creates a finding, a human changes its severity or status in another system, comments are added, and the final state is reconciled across platforms. Include the required bidirectional fields and conflict-handling expectations in procurement and architecture reviews.
- Decision trigger: Mandate the test whenever an agent-generated finding will cross a product boundary or when multiple systems can update status, severity, ownership or analyst commentary.
- Why now: Google and Wiz are emphasizing a shared data model and bidirectional synchronization of operational fields, while Wiz confirms synchronization of status, severity and comments.¹⁷ That makes preservation of human judgment and workflow state a practical buying criterion, not an abstract integration preference.

Google Cloud expands agent-security controls as machine identity becomes core infrastructure

Take the argument with you.

What changed

Why it matters

Frontier take

Three moves for CIOs

Sources