Google adds human checks to its AI security agent as limits on automation tighten

Google Cloud has added new controls to CodeMender, its AI tool for finding and fixing software vulnerabilities, allowing businesses to isolate attack simulations in sandboxes or virtual machines and add human checks for local file writes and command execution ^[1]. Businesses can also choose to scan entire repositories or limit the tool to specific folders, and review AI-generated fixes before they are applied.

Think of it like giving a new intern the keys to the building. You want them to be useful, but you probably don't want them changing the production database on their first day. CodeMender is an AI agent that looks for vulnerabilities, simulates attacks to test them and writes patches. That's helpful, until the day it writes something unexpected. The new controls let you say which doors it can open, and which ones need a supervisor present.

Why this matters now

CodeMender is part of a wave of AI agents that don't just advise, they act. They scan code, run tests, write patches and, in some cases, deploy them. That is faster than waiting for a human to do it, but it also means a mistake can reach production before anyone notices.

Google's move is a response to that risk. The tool can now be told to run its attack simulations inside a sandbox or a VM, so a test that goes wrong doesn't touch live systems ^[1]. Businesses can also require manual approval before the AI writes to local files or executes commands, and they can limit which parts of a repository the tool is allowed to scan.

The changes don't make CodeMender slower at finding vulnerabilities. They make it safer to run, because the humans decide where the boundaries are.

The logging question

When an AI agent acts on its own, the question of what it did, and when, becomes harder to answer after the fact. Under Article 12 of the AI Act, high-risk AI systems must technically allow for the automatic recording of events over their lifetime, from 2 December 2027 for systems under Annex III ^[2]. That includes logging what the system did, which version was running and who, if anyone, reviewed it.

The rule says what to log. It doesn't say how you protect the logs, or how you show a year later that nobody has quietly edited them. That question matters more when the system is an agent, because agents don't just suggest, they change things.

CodeMender's new controls add approval steps, and those approvals are events worth recording. The question is whether the record of who approved what, and when, can be checked later by someone who doesn't work for you.

How a digital witness fits here

CodeMender's logs record what the tool scanned, which vulnerabilities it found, which fixes it proposed and whether a human approved them. That record is valuable if a fix later turns out to have caused a problem, or if an auditor asks what the AI was allowed to do on a given day.

The thing to seal is each action record as it is written: the scan scope, the vulnerabilities found, the proposed patch, the approval status and the timestamp. Sealing takes a fingerprint of the record, not the record itself, so the log stays in your systems. If the record is questioned later, anyone you share it with can check that the fingerprint still matches, which shows it hasn't changed since it was sealed.

The check works even if the person who kept the log could have edited it, because a change breaks the match. That is what makes it a witness: it doesn't take sides, and it doesn't forget.

What it doesn't do is show that the AI's decision was correct, or that the log is complete. It shows that the record you are looking at is the one written at the time.

You can seal action records through the REST API, the SDK or the MCP server. The first 2,000 witnesses a month are free. Read more in the documentation, or get started at WitniumChain.

How it would work

1. Your system sends a fingerprint of each action record to the witness service and gets a witness ID back.
2. The record and the witness ID are stored together in your logging system.
3. When an auditor or a customer asks what the AI did on a given day, you share the record and the witness ID, and they check the fingerprint.

The pattern: more power, more checkpoints

CodeMender is one tool, but the pattern is wider. As AI agents are given the power to act, the businesses running them are adding controls. Some of those controls are technical, like sandboxing. Some are procedural, like requiring approval before a change goes live. Some are about logging, so you can show what happened.

The AI Act doesn't require any of those steps for every AI system, but it does require logging for high-risk ones, and it is starting to shape how businesses think about the question even when the system doesn't fall into that category. The logic is simple: if something can act on its own, you need a way to show what it did.

Google's announcement doesn't mention the AI Act, and it probably doesn't need to. The controls it has added are the kind that businesses running security tools would want anyway, because a vulnerability scanner that accidentally breaks something is worse than one that finds nothing. The timing, though, is worth noting. As the rules around high-risk AI systems come closer, the tools that might fall under them are already being designed with checkpoints built in.

What this means for you

If you are running AI agents that scan code, propose changes or act in production systems, here are three questions to ask:

• Can the AI write to files or run commands without approval, and if so, is that what you want?
• Do you have a log of what the AI proposed, what was approved and when?
• If someone questions a change six months from now, could you show them the record and prove it hasn't been edited?

The new controls in CodeMender show that the first question is getting easier to answer. The second and third are next.

What to watch

Article 12 of the AI Act applies to high-risk AI systems from 2 December 2027 for systems under Annex III. That includes systems used for assessing people, and some systems used in critical infrastructure and law enforcement. If your AI falls into that category, logging what it does isn't optional.

Article 26 of the AI Act, about user obligations, also applies from 2 December 2027 ^[3]. That means businesses using high-risk systems have duties of their own, including monitoring how the system is used and keeping logs.

The Cyber Resilience Act's reporting requirements are expected to apply from late 2027, and they include a 24-hour deadline for early warnings about actively exploited vulnerabilities ^[4]. When the clock is running, having a clear record of when you became aware of a vulnerability, and what you did about it, matters.

Sources

1. Help Net Security, "Google Cloud introduces new security controls for AI agents", 5 November 2026, https://www.helpnetsecurity.com/2026/11/05/google-cloud-ai-agents-security-controls/
2. Article 12 of Regulation (EU) 2024/1689 (AI Act), European Commission AI Act Service Desk, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12
3. Article 26 of the AI Act, European Commission AI Act Service Desk, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26
4. Article 14 of Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex, https://eur-lex.europa.eu/eli/reg/2024/2847/oj