CodeMender overview
Stay organized with collections
Save and categorize content based on your preferences.
The launch of advanced AI models has triggered widespread concern regarding code vulnerabilities. As attackers gain access to new capabilities for generating exploits, security teams are under immense time pressure to proactively find and fix vulnerabilities before they can be exploited.
CodeMender is an AI code security agent that can find, verify, and fix deep vulnerabilities in your codebase. CodeMender wraps a fine-tuned harness around an LLM, using Google DeepMind-engineered prompts, skills, and orchestration logic to turn the model into an agentic system specialized in code security.
How it works
CodeMender is designed to handle the scale and diversity of modern corporate environments, where code spans numerous languages and system types:
Find vulnerabilities by scanning your codebase using an LLM guided by the agent, leveraging specialized tools and prompt engineering to focus the model on security flaws. Alternatively, you can import a list of vulnerabilities from external security scanning tools.
Verify vulnerabilities by building the code and attempting to exploit found vulnerabilities to verify whether they are exploitable. This helps prioritize confirmed vulnerabilities and reduces the false positive rate.
Fix vulnerabilities by generating and testing a patch that is compatible with the language of your codebase.
During all three stages, you can provide context to CodeMender to ensure it accounts for the nuances of your application and threat model. This combination of an LLM with CodeMender's fine-tuned harness provides higher-quality results versus using an LLM alone to find and fix vulnerabilities.
System architecture
From a user perspective, the CodeMender system consists of two components:
Agent: A hosted multi-agent system that runs the core business logic and reasoning.
Client: A client running on your machine, acting as both a CLI (to issue commands and view outputs) and a daemon (to execute commands on behalf of the agent, such as navigating the codebase and verifying vulnerabilities and patches).
Supported languages and frameworks
CodeMender supports top vulnerability types across all major programming languages: C/C++, Go, Java, Python, TypeScript / JavaScript, Rust, and Ruby. Additionally, it has broad support for standard libraries within these languages, as well as common enterprise frameworks (such as HTML/CSS, Django, Flask, React, Spring Boot, and Express).
Supported vulnerability types cover a wide spectrum of software security flaws across application logic, data handling, memory management, and authentication control flows.
To specify a model when running CodeMender CLI commands, see Specifying the model.
Track token usage
CodeMender surfaces token consumption in two places: a live status line while a command runs, and a one-line summary when a command completes successfully. Counts cover input, output, and total tokens for the current session.
Live status line
While cm find, cm fix, cm verify, or cm session resume is running, pass the --compact flag to display a rolling status line that updates as the agent works:
cmfind./src/auth/--compact
The status line reports cumulative session totals:
Tokens:40kin/12kout/60ktotal
Resumed sessions continue counting from where the prior run left off. The total count may include the model's internal reasoning tokens, so it can exceed in + out.
Exit summary
When a command finishes successfully and at least one tool step was executed, CodeMender prints a one-line summary with elapsed time and token totals:
The following sections outline CodeMender's security model, data retention policies, and access controls:
What data is sent to the cloud?
When using CodeMender, the local CLI tool mediates access to your code, ensuring that your full source code repositories are never uploaded to Google's servers and are not independently cloned by the hosted agent.
Instead, the data sent to the Google-hosted agent is strictly localized and consists of:
Targeted file contents or code snippets, vulnerability information, proposed patches, and command execution results.
Metadata, diagnostics, errors, and usage telemetry (such as tokens consumed and command duration).
Your customer source code is never used to train the underlying model weights.
What is the retention policy?
CodeMender uses a strict, short-term data retention policy:
7-day maximum retention: Session data, including code snippets and tracking states, is retained for up to 7 days in Gemini Enterprise Agent Platform storage to allow users to seamlessly resume interrupted scans. After 7 days, it is automatically deleted (see Zero Data Retention).
Explicit deletion: Customers do not have to wait 7 days; they can trigger an immediate cleanup of all session data by calling DeleteInteraction.
Ephemeral findings: Vulnerability findings and patches are not stored in long-lived databases, but rather accumulate in-memory during the pipeline.
Who can access the data?
CodeMender is designed with a "Zero-Data-Access" approach regarding human visibility:
No human access: No human groups or Google engineers have access to read customer data in the production environment.
No operator visibility: Even for production debugging and error tracking, Google operators are restricted and do not have visibility into customer source code context or transient session states.
Strict isolation: All data is logically isolated and access-controlled by organization and customer billing-project to protect tenant privacy within our shared infrastructure.
VPC Service Controls (VPC-SC): To further protect your environment, CodeMender's architecture fully supports VPC Service Controls (VPC-SC). This lets you define a secure security perimeter around your Google Cloud resources, helping to mitigate any data exfiltration risks while your localized data is sent to the cloud reasoning engine.
Get started with the CLI
Set up the CLI tool and initialize your workspace to start scanning.
Prerequisites
Before you initialize the CodeMender CLI, ensure your environment is prepared correctly:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-07-23 UTC."],[],[]]
