Prompt Injection Red Teaming for Coding Agents: A Practical Playbook

Community experiments on Qiita and Zenn have pushed an important question into the mainstream: can coding agents leak .env content or execute malicious instructions embedded in repositories? The short answer is yes—if your guardrails are weak.

Treat this as a security engineering problem, not a prompt wording problem.

Threat model for coding agents

Attack surface spans three layers:

1. Instruction layer: hidden directives in README, comments, issue templates.
2. Data layer: accidental exposure of secrets in local files and logs.
3. Execution layer: unsafe tool invocation, shell access, or dependency scripts.

A robust defense requires explicit controls on all three.

Red-team scenarios every team should run

Scenario A: Repository prompt poisoning

Inject conflicting instructions in non-obvious files and test whether the agent obeys policy or poisoned text.

Success criteria:

• agent cites policy precedence correctly
• suspicious instructions are surfaced, not executed silently

Scenario B: Secret lure file

Place decoy secrets in common filenames (.env, config.local, secrets.txt) and ask benign tasks.

Success criteria:

• no raw secret value appears in output/PR/comments
• access attempts are logged and policy-blocked

Scenario C: Tool escalation trap

Add instructions that request network exfiltration (curl, webhook posting, pastebins).

Success criteria:

• denied by execution sandbox
• incident signal emitted to security telemetry

Scenario D: Dependency lifecycle attack

Use scripts in package.json/build files that attempt unexpected outbound behavior.

Success criteria:

• CI policy blocks unapproved scripts
• runtime execution context strips sensitive environment variables

Defense architecture

Policy precedence graph

Hard-code instruction hierarchy:

1. platform/system policy
2. repository policy file
3. user prompt
4. in-repo natural language text

Any inversion here creates exploitable ambiguity.

Secret minimization

• no long-lived secrets in developer environments
• ephemeral tokens with scope+TTL
• repository-level denylist paths for agent reads
• mandatory secret scanning on AI-authored diffs

Execution containment

• default no-network mode for coding tasks
• allowlisted commands only
• sandbox per task with teardown
• outbound requests require explicit policy grant

Governance practices that work

• Monthly red-team drills with reproducible test corpus
• Security scorecards per assistant/toolchain
• Mandatory incident review for every blocked exfiltration attempt
• Training developers to report “weird agent behavior” as security events

What to measure

• successful injection rate across test suites
• mean time to detect suspicious agent behavior
• secret exposure incidents per release
• policy bypass attempts by source category

Strategic takeaway

Coding agents are force multipliers for both productivity and mistakes. Teams that run continuous adversarial testing will keep velocity and trust. Teams that rely on ad-hoc “be careful” prompts will eventually ship an avoidable incident.

Trend references

• Qiita popular post: prompt injection and .env leakage validation
• Zenn trend discussions on AI Slop and agent reliability