The repository had no malicious code. No obfuscated payloads. No suspicious imports. The final payload was fetched at runtime from a DNS record, invisible to every static scanner, code reviewer, and dependency auditor in the pipeline. This is the Clean Repo attack, and it exploits a fundamental architectural trust gap that no single vendor has fully solved.

I’ve spent the last few weeks digging into this attack surface, the defenses that actually work, and the ones that don’t. Here’s what I found and exactly how to protect your agents before setup scripts run.

How the Clean Repo Attack Works

The attack chain has five stages, and the critical insight is that none of them look malicious in isolation.

Stage 1: Trust Assumption. The developer clones a repository and points their AI coding agent at it. The agent reads project files — README.md, AGENTS.md, CLAUDE.md, .cursorrules, setup.py, requirements.txt — as trusted instructions. These files originate from an untrusted external source, but the agent has no built-in mechanism to distinguish “instructions from the project” from “instructions from the developer.”

Stage 2: Setup Execution. The agent follows the documented setup flow. It runs pip install -r requirements.txt, which installs legitimate packages. It runs the initialization script. Everything looks normal.

Stage 3: Error Fabrication. The setup script produces an error message that looks like a routine configuration issue. The error message is designed to trigger the agent’s helpfulness reflex — the agent sees a problem and wants to fix it.

Stage 4: Payload Delivery. The agent runs the “suggested fix” from the error output. The fix makes a DNS TXT record query. The response contains a base64-encoded payload that the agent decodes and executes. Because the payload is fetched at runtime, no static analysis tool ever sees it.

Stage 5: Compromise. The payload opens a reverse shell. The attacker now has access under the developer’s own user account — source code, browser sessions, API keys, GitHub tokens, AWS credentials, SSH material, everything.

The Mozilla 0DIN PoC targeted Claude Code, but the technique generalizes. A January 2026 systematic review on arXiv analyzed 314 prompt-injection payloads across 70 MITRE ATT&CK techniques and found success rates as high as 84% for malicious command execution against GitHub Copilot and Cursor. The attack is not vendor-specific — it exploits how every AI coding agent processes project files.

Why Traditional Defenses Fail Here

Most teams’ first instinct is to add a warning banner: “This repository contains files that will influence your AI agent.” That’s what Anthropic added to Claude Code after the 0DIN disclosure. It’s not enough.

The arXiv review found that most published defenses achieve less than 50% mitigation against sophisticated adaptive attacks. Attackers tune payloads to evade detection. A warning banner that a developer clicks through becomes a ritual, not a safeguard. Filtering rules get bypassed by encoding tricks. Static scanners miss runtime-fetched payloads by definition.

The problem is architectural. AI coding agents are designed to be helpful — to read project context, follow instructions, and execute setup steps autonomously. That helpfulness is the attack surface. You can’t fix it with a single banner or a regex filter.

The 10-Layer Defense-in-Depth Framework

After reviewing the Mozilla 0DIN research, the Lushbinary production playbook, the arXiv systematic review, and the OWASP Top 10 for LLMs, I’ve settled on a 10-layer defense framework. No single layer is sufficient, but together they provide meaningful protection.

Layer 1: Pre-Scan Repositories Before Agent Execution

This is the most critical pre-setup defense. Before any AI coding agent reads or executes commands from a repository, scan it for prompt injection indicators.

I run a pre-flight scanner that checks four things:

• AGENTS.md / CLAUDE.md / .cursorrules for instruction override patterns — embedded shell commands, DNS query patterns, base64-encoded payloads
• setup.py / package.json for unexpected network calls or suspicious post-install hooks
• README.md for embedded shell commands disguised as documentation
• Dependency URLs for typosquatting or domain lookalikes

If any trigger fires, block execution and flag the repository for manual review. This catches the obvious attacks and forces attackers to work harder.

Layer 2: Sandboxed Execution with Network Isolation

Even if an injection succeeds, the sandbox limits the blast radius. I run all agent actions in Docker containers with these flags:

docker run --rm \
  --network=none \
  --read-only \
  --tmpfs /tmp:size=100m,noexec,nosuid \
  --memory=512m \
  --cpus=1 \
  --security-opt=no-new-privileges \
  --cap-drop=ALL \
  -v /workspace:/workspace:ro \
  my-agent-image

The key flags are --network=none (the Mozilla 0DIN attack required a DNS query — no network, no payload delivery) and --read-only (the agent can’t write malicious files to the host). For stronger isolation, gVisor or Firecracker microVMs add a kernel-level security boundary.

Layer 3: Instruction Hierarchy with Content Boundary Markers

Establish a clear precedence order: system prompt > application logic > user input > external data. Modern models like GPT-5.5 and Claude Opus 4.7 support explicit instruction hierarchy through API parameters.

I wrap all external content in delimiters:

The model should never override system-level constraints based on content from lower-priority sources. This is the most effective model-level defense, but it requires the model to respect the hierarchy — not all models do consistently.

Layer 4: Least-Privilege Agent Configuration

Agents should not inherit full developer credentials. I run agents under constrained service accounts with scoped permissions:

• Read-only access to specific repositories, not the entire filesystem
• No write access to production systems
• No access to credential stores or secret managers
• Tool allowlist — only permit known-safe tools (file read, code search, linting)
• Shell command allowlist — block dangerous operations: curl to external hosts, eval, exec, base64 decode

The principle is simple: the agent should have exactly the permissions it needs for its task and nothing more. If an injection succeeds, the attacker inherits only those limited permissions.

Layer 5: Approval Gates for High-Risk Actions

Require explicit human approval before:

• File writes to new locations
• Shell commands with network destinations
• Package installs from untrusted sources
• Credential access

This is the ultimate backstop. Even if all automated defenses fail, a human reviewer can catch malicious actions before they execute. The trick is calibrating which actions require approval — too many gates and developers develop approval fatigue and click through everything. I gate only the high-risk actions and use rate limiting to prevent fatigue.

Layer 6: Canary Tokens in Repositories

Embed fake credentials and API keys in repositories as canary tokens. If an agent accesses or exfiltrates these tokens, the security team is immediately alerted.

I deploy Thinkst Canarytokens in README files, configuration files, and environment variable templates. When a canary fires, I investigate the agent’s activity, review execution logs, and rotate any real credentials that might have been exposed. This provides early warning of successful prompt injection before the attacker achieves their objective.

Layer 7: Runtime Defenses — StruQ and SecAlign

Academic research has produced two promising runtime defenses. StruQ separates instruction channels from data channels architecturally, achieving less than 2% attack success in controlled studies. SecAlign uses preference optimization to fine-tune models to reject injection attempts, reducing attack success from 96% to 2%.

These are emerging techniques — not yet production-ready in most toolchains — but they’re worth evaluating if you’re building custom agent infrastructure. The ETDI (Enhanced Tool Definition Interface) proposal adds cryptographic identity for tools with immutable versioning and OAuth 2.0 scopes, which would make tool-poisoning attacks significantly harder.

Layer 8: Audit Logging and Anomaly Detection

Log every agent-executed action: file reads and writes, shell commands, network requests, API calls. Establish a baseline per agent — normal tool call frequency, typical file access patterns, expected network destinations.

When an injection succeeds, it often produces anomalous patterns: a sudden spike in tool calls, access to files the agent never normally reads, network requests to unknown destinations. ML-based anomaly detection can flag these deviations in real time. I use this as a safety net — it catches what the other layers miss.

Layer 9: Rate Limiting

Per-session and per-minute tool call caps prevent an attacker from exfiltrating large amounts of data even if they compromise the agent. If the agent normally makes 50 tool calls per session and suddenly makes 500, something is wrong. Rate limiting buys time for the anomaly detection layer to trigger.

Layer 10: Human-in-the-Loop Governance

The final layer is organizational. Shadow AI — unsanctioned agent tooling that teams adopt without IT or security oversight — dramatically increases risk because it bypasses every governance control. The CyberUnit analysis of the Mozilla 0DIN attack makes this point clearly: the defense is not to ban tools but to bring them into the light. Known, scoped, monitored, governed.

I maintain an inventory of every AI coding agent in use, its permissions, its integrations, and its escalation path. When a new tool appears, it goes through a security review before anyone points it at production code.

Putting It All Together

The Clean Repo attack is not a theoretical vulnerability. It’s a demonstrated exploit with a published proof of concept, and the underlying technique generalizes across every major AI coding agent. The arXiv review found 84% success rates against Copilot and Cursor. The OWASP Top 10 ranks prompt injection as the number one LLM vulnerability, affecting 73% of production deployments.

The defense is not a single product or a configuration flag. It’s a layered approach that starts before the agent ever reads a file and continues through execution, monitoring, and governance. Pre-scan repositories. Sandbox execution. Enforce instruction hierarchy. Limit permissions. Gate high-risk actions. Deploy canaries. Log everything. Rate limit. And govern the whole thing.

I’ve been running this framework for the last month across my agent deployments. It’s not perfect — no defense against adaptive prompt injection ever will be — but it’s raised the bar significantly. The Mozilla 0DIN attack would be stopped at Layer 1 (pre-scan detects the DNS query pattern in the setup script) and Layer 2 (network isolation prevents the DNS TXT query). That’s the standard I’d hold any production agent deployment to.

For more on related attack surfaces, see my guides on Agentjacking Mitigation (securing Sentry, Datadog, and Jira integrations) and Agent Skills Supply Chain Security (securing SKILL.md files and marketplace updates). The Clean Repo attack, agentjacking, and supply chain poisoning are all variations on the same theme: agents trust the data they receive, and that trust is the vulnerability.