MCP Delegated Code Edit Applied With Validation Gate Bypass
Some AI coding agents automatically write and apply code changes, but are supposed to run them through validation checks first. This rule flags cases where the agent applies a code edit and, in the same command, disables the check that was meant to catch problems before the change lands.
How the attack works
An AI agent (or a delegated worker process it spawns) is asked to make a code change. Instead of going through the normal patch-apply-then-validate sequence, it runs a single command that both writes the change to disk (patch, apply, in-place edit, or atomic rename) and passes a flag or environment variable that skips verification, such as --no-verify or a test-skipping variable. This can happen because a prompt injection reached the worker model, or because the validation gate logic itself has a bypassable weakness. The result is that the edit is committed without ever being reviewed by the safety check it was supposed to pass.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7b3f1c9e-2d64-4a1b-9f0e-8c5a4d2e6b71
- Severity
- High
Why it matters
An attacker who can influence the agent's instructions gets code changes written directly into the codebase without the review step meant to catch malicious or broken edits, increasing the chance that bad code ships silently.
What you can do
- →Review any AI-agent commit or apply commands that combine a file-write operation with a verification-skip flag, especially when the agent (not a human) issued the command.
- →Restrict which environment variables or CLI flags an AI agent is allowed to pass when invoking git, patch, or file-write utilities.
- →Separate the apply step from the validation step in your agent's tooling so one process cannot both write and disable review in a single call.
- →When investigating a hit, check whether a human explicitly requested the bypass (e.g. a known-broken pre-commit hook) versus whether the instruction came from agent-generated or externally supplied content.
Known benign look-alikes
- A developer explicitly asks the agent to commit with hooks disabled because the repository pre-commit hook is broken, slow, or requires a network resource (`git commit --no-verify`). This is the single most common benign hit.
- Bootstrap or container build steps run by the agent that set HUSKY=0 or SKIP_TESTS=1 for reproducible installs and then also touch a source file in the same shell line.
- A legitimate large refactor where the agent chains an in-place `sed -i` edit with an unrelated `--no-verify` commit in one compound command.
- Release/automation scripts invoked by the agent that pass `--skip-tests` to a packaging step while also moving generated source files into place.