The Era of AI Finding and Fixing Vulnerabilities — What Clients Must Define in Maintenance Contracts

"We receive notifications when vulnerabilities are detected, but the decision on whether to patch them is tossed back to us, and everything stalls." We frequently hear this concern from organizations operating systems built under custom development several years ago. Diagnostic reports arrive monthly. Yet with dozens of items listed, teams cannot tell which ones pose real threats or how many days remediation will take. Lacking clarity, internal approvals stall, and the identical list arrives the following month.

This bottleneck occurs because the gap between detection and remediation has historically required manual human labor. In late July 2026, an announcement aimed at bridging this exact gap using automation was made.

CodeMender does not stop at detection

CodeMender, announced by Google Cloud, is an AI agent that detects software vulnerabilities, validates whether attacks actually succeed inside a sandbox, and automatically generates remediation patches for reproducible exploits (Google Cloud Launches AI Agent Autonomously Handling Vulnerability Detection, Sandboxed Risk Verification, and Remediation — Publickey). As of July 2026, it is available in preview.

The difference from traditional static analysis tools lies in this verification phase. Static analysis flags numerous potentially insecure code patterns, but cannot determine whether execution paths can realistically be triggered. This floods teams with sprawling issue lists that engineers eventually ignore. CodeMender tests proof-of-concept (PoC) exploits in a sandbox, treating confirmed exploits as high-priority issues.

Supported languages include C, C++, Go, Java, Python, Rust, and TypeScript, covering flaws like memory corruption, injection vulnerabilities, cryptographic weaknesses, and insecure data handling. For vulnerabilities that pass sandbox verification, remediation is delivered directly into developer workflows as code diffs.

Google positions CodeMender as a tool to relieve the maintenance burden on open-source software. The initiative aims to automatically supply verified patches to libraries maintained by small teams that underpin thousands of applications.

What changes for the client

Assuming that AI fixing vulnerabilities will make maintenance cheaper is a mistake. What changes is not the cost, but where the process bottlenecks.

Previously, the bottleneck was not knowing how to write the fix. Moving forward, the bottleneck shifts to who approves the proposed patches. A continuous stream of automated patch proposals significantly increases the review burden on approvers.

Furthermore, applying code patches invariably carries the risk of unintended side effects. Modifying code to close a vulnerability frequently breaks existing application behavior. A patch that is correct from a security standpoint may be unacceptable from a business operations standpoint.

Consequently, the questions clients must be prepared to answer boil down to three:

1. Who reviews incoming patch proposals, and who authorizes deployment?
2. If an applied patch triggers a defect, which party bears responsibility?
3. When a decision is made to skip a vulnerability, where is that rationale documented?

The third question is the one most easily overlooked. Deciding to skip a patch will inevitably be scrutinized later. What was the rationale, when was it decided, and who made the call? Without proper documentation, productive post-incident discussions are impossible.

What to stipulate in maintenance contracts

These are not technical dilemmas; they are questions of contractual agreement and operational policy. Establishing them before adopting tooling prevents disputes.

Define distinct tiers for patch approval. Funneling every patch through the same approval pipeline buries critical fixes in daily administrative queues. In practice, three tiers are sufficient: patches approved for immediate deployment, patches requiring prior approval, and patches not to be applied. These criteria can be mapped along two axes: external reachability and impact on business logic.

Establish who executes testing in staging environments. Pushing patches directly to production without testing is dangerous, even if machine-generated. Clients and development partners must agree in advance on who runs verification in staging environments and how much review time is allocated.

Explicitly define the scope of coverage. Scope heavily dictates workload depending on whether maintenance covers only proprietary code or extends to third-party dependencies. For vulnerabilities in dependencies, patches cannot simply be applied to proprietary code. Teams face distinct decisions: waiting for an upstream release, bumping version numbers, or migrating to an alternative package.

For managing dependency update workflows, see Dependabot Waiting Three Days by Default: Restructuring Dependency Update Operations; for an overview of software supply chain threats, refer to 2026 Supply Chain Attack Summary. To see real-world consequences of unpatched vulnerabilities, examine the case study in Six Months After React2Shell: How CVSS 10.0 Flaws Still Persist on Neglected Sites.

Can AI-generated patches be trusted blindly?

The answer to this question is a definitive no. However, the reason is not simply that AI is untrustworthy.

Mechanisms like CodeMender that validate exploitability in sandboxes significantly improve accuracy in determining genuine threats, proving more consistent than human visual inspection. The challenge lies in the subsequent step: assessing whether the fix breaks business logic.

Machines cannot deduce business context from raw source code. Whether rejecting a specific input value is appropriate depends on how that data is used in actual business operations, and only the client's team understands that operational reality. This creates a natural division of labor: AI excels at evaluating threat exploitability, while humans must evaluate business impact.

For this reason, maintenance agreements must designate an internal client lead empowered to approve patch applications. That individual does not need to parse technical intricacies; they only need to know how the feature and input data are utilized in actual business practice.

For details on structuring review workflows for AI-written code, consult our guide: Who Reviews the Security of AI-Generated Code?.

What to verify next

Ask your maintenance provider if any identified vulnerabilities were deferred without remediation over the past year across your active systems. If so, verify where the justification for each deferral is documented.

If no records exist, that is where operational work must begin. Before onboarding new tools, establish where decisions are recorded and designate who holds approval authority. Automated detection and remediation deliver value only when built upon this organizational foundation.

GleamHub accepts consultations on system maintenance structures and security response design through our consultation desk for development, AI, and automation. Because the optimal setup varies depending on requirements, we provide individual estimates. Please reach out via Contact Us.

Sources

• Google Cloud preview release of "CodeMender": AI autonomously executes everything from code vulnerability detection to in-sandbox risk validation and remediation — Publickey (July 28, 2026)
• Now in preview: Find and fix software vulnerabilities with CodeMender — Google Cloud Blog
• CodeMender: AI Agent for Code Security — Google Cloud
• Google gives developers an AI bug hunter that also writes patches — Help Net Security (July 24, 2026)