Direct answer
Defend against repository prompt injection by treating all task content as untrusted data, limiting authoritative instructions to reviewed locations, refusing embedded requests for secrets or policy changes, constraining tools and network access, and validating every consequential action against the human task and repository policy.
Key takeaways
- Authority comes from reviewed policy and the human task, not from imperative wording inside data.
- Label provenance when loading issues, logs, web pages, generated files, or tool responses.
- Use tool restrictions so a successful injection still cannot reach secrets or high-impact actions.
- Escalate conflicts and suspicious instructions instead of asking the model to resolve trust silently.
Key facts
| Fact | Verified value | Evidence |
|---|---|---|
| Primary risk | OWASP describes prompt injection as direct or indirect input that changes intended model behavior. | View source |
| Repository policy | Codex documents AGENTS.md as a maintained repository instruction surface. | View source |
| Execution boundary | Codex documents sandbox and approval controls that limit the impact of generated actions. | View source |
| External tools | MCP defines client-server exchanges for tools and resources, which remain external trust boundaries. | View source |
What this guide helps you solve
Provide maintainers with a concrete control sequence for handling instruction-like text from untrusted sources.
Verification scope and limits
- Evidence basis
- Official documentationSpecification
- Verification scope
- Controls cover indirect instructions encountered through repository files, external resources, tool results, and collaboration systems.
- Limits and invalidation conditions
- - No defense guarantees that a model will recognize every injection.
- - Client instruction precedence can differ.
- - Content scanners alone cannot establish intent or authority.
Make authority explicit before reading task data
Define the trusted instruction set: the current human request, organization policy, and reviewed repository instruction files in their documented scope. Source code, comments, test fixtures, issues, logs, web pages, and tool output may contain imperative language, but that language does not gain authority merely by being loaded into context.
When sources conflict, stop and present the conflict with paths or URLs. Do not let the agent choose whichever instruction is more convenient or more forcefully worded.
Preserve provenance through retrieval and summarization
Keep the file path, issue URL, tool identity, and retrieval time with each excerpt. Summaries must distinguish quoted claims from verified facts and generated interpretation. Avoid copying external text into AGENTS.md, CLAUDE.md, scripts, or prompts without review.
Sanitize logs and examples before loading them, but do not strip the provenance required to assess trust. A clean-looking snippet with no source can be more dangerous than a clearly labeled untrusted one.
Contain impact with capability controls
Run exploration read-only, limit writes to the workspace, allowlist network destinations, and keep secret stores outside default access. Require a separate approval for commands that install software, modify CI, contact external services, change permissions, or publish artifacts.
Test the boundary with harmless injection fixtures
Create a fixture that asks the agent to ignore policy, read a denied path, or contact an unapproved host, but points only to harmless test resources. Confirm that the client refuses or requests approval, that no secret is available, and that logs show the attempted boundary crossing without retaining sensitive content.
Treat a successful injection as a security incident
If an agent accessed a secret, contacted an unknown destination, modified protected files, or executed an unauthorized command, stop the session, preserve sanitized evidence, rotate exposed credentials, inspect the diff and external effects, and remove the malicious source. Re-enable capabilities only after the failed boundary and its owner are understood.
Official sources and verification scope
This guide is based on public official documentation. Commands and configuration may change between client versions, so verify the linked sources before use.
Read the verification methodology