Google's Sec-Gemini v3 Leads a Full Security Stack Built for AI Agents

Google unveils Sec-Gemini v3, CodeMender, open-source CAPSEM, and two new open standards to secure the agentic era from code to commerce

·
·
Google's Sec-Gemini v3 Leads a Full Security Stack Built for AI Agents
  • Sec-Gemini v3: Google's specialized cybersecurity agent, now in trusted tester access for government and enterprise, automates incident investigation, forensics, and malware analysis at machine speed.
  • CodeMender: An AI agent from Google DeepMind that autonomously finds, patches, and validates code vulnerabilities; submitted 72 real patches to open-source projects in testing, now integrating into Google Cloud Agent Platform.
  • CAPSEM open-sourced: A secure runtime that isolates each AI agent in its own VM, keeping credentials out of reach even if the agent is compromised via prompt injection.
  • DBSC now GA: Device Bound Session Credentials are live in Chrome 146 on Windows, cryptographically binding session cookies to device hardware so stolen cookies become instantly useless.
  • AP2 protocol: An open standard with 60+ partners (Mastercard, PayPal, Coinbase) that uses cryptographically signed Mandates to authorize and audit agent-initiated payments under $100.
  • Architecture shift: Google is framing agentic security as a full stack (runtime isolation + autonomous patching + hardware-bound sessions + payment authorization), not a single feature.

The shift from AI assistants to AI agents changes the security surface entirely. An agent that can browse the web, write code, call APIs, and initiate payments is not just a smarter chatbot. It is a new class of software principal, and the existing security playbook was not written for it. At I/O Connect India 2026, Google announced a coordinated set of tools and open standards aimed squarely at this gap: Sec-Gemini v3, CodeMender, CAPSEM, DBSC, and AP2. Together they form something closer to a security architecture than a product release.

The problem no one solved yet

Traditional security treats safety as a final checkpoint before shipping. The agentic era changes that responsibility: software can now interpret intent, use tools, and take action autonomously. That means a compromised agent does not just leak data. It can take actions, make purchases, and propagate damage across systems at machine speed. The threat model is fundamentally different, and Google's argument is that security must be baked into the underlying architecture, not bolted on afterward.

There is also a supply-side problem. As agents write more code, that code needs to be secured at the same speed and scale it is being produced. AI-generated codebases are growing faster than human reviewers can audit them. The tools announced here are a direct response to that asymmetry.

Sec-Gemini v3: the defender's co-pilot

Sec-Gemini v3 is Google's specialized cybersecurity agent, now being brought to trusted government and enterprise testers including Flipkart. It can reason across complex security data and help security operations teams automate tasks like incident investigation, digital forensics, and malware analysis at machine speed.

Effectively powering SecOps workflows requires state-of-the-art reasoning capabilities and extensive current cybersecurity knowledge. Because Sec-Gemini is constantly ingesting updated Google threat intelligence, it can provide up-to-date answers on security topics in close to real time, factoring in whether a CVE for a software vulnerability has been updated in the past few days with a new patch. The model is trained on highly curated, security-specific data streams, not general web text, which is what makes it useful for incident response rather than just trivia.

Access to Sec-Gemini v3 is currently limited to a trusted tester program. The repository on GitHub hosts SDKs and a CLI for Sec-Gemini, described as an experimental cybersecurity-focused AI from Google. You can explore the Sec-Gemini GitHub repo and request access at secgemini.google.

CodeMender: from finding bugs to fixing them

Most security tooling stops at detection. CodeMender goes further. CodeMender is an AI code security agent originally developed by Google DeepMind. Leveraging Agent Platform capabilities and advanced Gemini models, it autonomously identifies vulnerabilities within your code, then recommends precise fixes, securely tests them, and can apply patches and necessary changes across dependent systems, with your approval.

The workflow it follows is worth understanding in detail:

  • Scanning a codebase to identify potential vulnerabilities
  • Locating the root cause of the flaw
  • Generating candidate fixes
  • Validating patches with automated analysis or testing
  • Submitting fixes for human review before deployment
  • Attempting proactive hardening, where it rewrites related code to remove entire classes of vulnerabilities instead of fixing a single bug instance

During a six-month testing period, CodeMender generated and submitted 72 security patches to open-source projects, including large repositories containing millions of lines of code. That is not a demo. It is a real-world track record against production software.

The honest caveat: there is no published data on false positive rates, regression rates, or fix accuracy on proprietary codebases. Enterprises will ask for those metrics before serious adoption, and Google has not provided them yet. Several Gemini Enterprise customers are already testing CodeMender, with broader availability to follow. You can learn more about CodeMender on Google Cloud.

CAPSEM: an open-source sandbox for agents

Even a well-behaved agent can be weaponized through prompt injection, where malicious content in the environment hijacks the agent's instructions. CAPSEM (Capabilities Security for Agents) is Google's answer to that threat at the runtime level.

CAPSEM places each AI agent inside an isolated virtual machine, strictly restricting what the agent can access and keeping raw credentials entirely outside its reach. If an agent is compromised or encounters a malicious prompt, the wider system remains fully protected. Think of it as a permission boundary enforced at the OS level, not just the application level. Google's Privacy and Security Research team developed it and has now open-sourced it, making it available for any team building agentic systems.

DBSC: making stolen cookies worthless

Session cookie theft is one of the most effective attack vectors in the modern threat landscape. Infostealer malware steals cookies, and because those cookies often have long lifetimes, attackers can access accounts without ever needing a password. Constella's 2026 Identity Breach Report documented that infostealers processed 51.7 million packages in 2025, a 72% year-over-year increase, and that these packages are particularly lethal because they contain live session cookies that allow adversaries to bypass MFA entirely.

Device Bound Session Credentials (DBSC) is the hardware-level fix. DBSC cryptographically ties the authentication session to a specific device. The idea is to render cookies worthless even if they get stolen by malware. It does this using hardware-backed security modules, such as the Trusted Platform Module (TPM) on Windows and the Secure Enclave on macOS, to generate a unique public/private key pair that cannot be exported from the machine.

Public availability is currently limited to Windows users on Chrome 146, with macOS expansion planned in an upcoming Chrome release. DBSC was developed through the W3C process and adopted by the Web Application Security Working Group. Google worked with Microsoft on the standard's design.

The limitation to be aware of: DBSC does nothing about malware already running on the device. Local malware can use the live session in place, or steal authentication artifacts DBSC does not cover, including refresh tokens, Primary Refresh Tokens, and saved credentials. It closes one important door, not every door.

AP2: a trust layer for agent-initiated payments

As agents gain the ability to make purchases on behalf of users, existing payment infrastructure hits a fundamental assumption problem. Traditional payment systems assume a human is directly clicking "buy" on a trusted surface, but autonomous agents break this assumption. How does a merchant verify that an agent is acting within the scope the user actually authorized?

Google announced the Agent Payments Protocol (AP2), an open protocol developed with leading payments and technology companies to securely initiate and transact agent-led payments across platforms. AP2 launched with 60+ partners including Mastercard, PayPal, Coinbase, American Express, and Salesforce.

The core mechanism is a chain of cryptographically signed contracts called Mandates:

  • Intent Mandate: captures what the user asked for (e.g., "find me running shoes")
  • Cart Mandate: specifies the exact transaction details the agent selected
  • Payment Mandate: authorizes the actual fund transfer

Each mandate is independently verifiable and prevents post-approval modification. AP2 provides strong guarantees over what is executed. However, it does not constrain how decisions are made during mandate construction. That last point matters: AP2 secures the transaction record, but a prompt-injected agent could still construct a fraudulent mandate if not caught upstream. It is a necessary layer, not a complete solution.

The protocol can be used as an extension of the Agent2Agent (A2A) protocol and Model Context Protocol (MCP). The full spec is available at Google Cloud's AP2 announcement and on GitHub under Apache 2.0.

What this means for the field

The real shift here is not any single tool. It is the recognition that agentic security requires a stack, not a feature. You need runtime isolation (CAPSEM), autonomous vulnerability remediation (CodeMender), a specialized threat intelligence layer (Sec-Gemini), hardware-bound session management (DBSC), and a cryptographic payment authorization protocol (AP2). Each layer addresses a different attack surface that emerges specifically because agents act autonomously.

The industry assumption that needs updating is that security reviews happen at deployment time. Google is simultaneously building the tooling for agents to write code at scale and the security infrastructure to govern what those agents produce. That pairing of agentic development with agentic remediation is the new baseline. Teams building on agent infrastructure today should treat CAPSEM, DBSC, and AP2 not as optional hardening but as foundational plumbing for anything that touches real users or real money.

Comments

avatar