An agent working on code naturally reads files, pull requests, build logs and documentation. These are legitimate sources of task data, but they can also contain attacker-controlled text that tells the model to run commands, open links or expose secrets. The essential defensive boundary is between instructions granted by an authorized user and untrusted material encountered while performing the task.
What the tool actually does
The attack path often begins in innocuous-looking locations: a README excerpt, package installation output, test failure log, issue comment or external documentation page. If a model obeys those strings as higher-priority commands, ordinary retrieval can become unauthorized action. Agent tool privileges determine how damaging that confusion can be.
A practical workflow and what to verify
Build a safe internal test with a synthetic repository comment that instructs the agent to modify an unrelated harmless file. The legitimate task is to fix a small parser bug. Check whether the assistant reports the suspicious instruction or follows it. Never run the test against production data, public services or real secrets; the objective is to validate your boundary, not to exfiltrate information.
Limits and failure modes
Prompt wording alone is not a reliable defense because the agent may encounter novel formats or indirect tool outputs. Automatic shell approvals, network egress and broad repository permissions can amplify risk. Even a correct-looking patch may include malicious dependency changes or altered CI configurations.
Data governance, approvals and security
Treat retrieved text as evidence rather than authority. Combine scoped credentials, allowlisted file paths, read-only reconnaissance, tool-call approval, network restrictions, protected CI configuration and branch reviews. Audit rejected tool calls as well as accepted ones, and ensure a human can reconstruct which data source preceded an action.
Who should use it—and alternatives
Choose tools based on observable guardrails and tested failure modes, not merely whether they mention “prompt injection protection.” The general agent threat model belongs with AI 07; this guide is specifically about code repositories and developer-tool permissions.
Documented scope and evidence date
This article reports the development workflow documented in the linked first-party sources accessed on 25 October 2026. It is not a hands-on product test or an independent performance claim. Client behavior, account entitlements and supported countries can differ across releases. Exact per-seat charges, quotas, trial allowances, API-model versions, and deployment guarantees are intentionally not supplied without a dated, tier-specific verification. For engineering procurement, capture the installed client version and active contract as separate evidence.
Acceptance checklist before production
- Check the exact editor, extension or CLI version in the actual installation, and the applicable sign-in or admin policy.
- Give the task a clear behavioral acceptance criterion and specify files, branches, credentials and networks outside its permitted scope.
- Use a disposable branch/worktree and preserve the baseline; do not rely on an agent summary as proof of test execution.
- Review the diff, new packages, build scripts and CI configuration, then rerun targeted and regression tests in a trusted environment.
- Require normal peer review and release approvals; keep a record of external code/context processors before using confidential repositories.
Sources & Further Reading
- https://code.claude.com/docs/en/permissions (official publisher documentation; accessed 25 October 2026)
- https://openai.com/index/running-codex-safely/ (official publisher documentation; accessed 25 October 2026)
- https://docs.github.com/en/copilot/responsible-use/chat (official publisher documentation; accessed 25 October 2026)