A user can legitimately ask an agent to fix issue 123 while an attacker controls the text of issue 123. If the issue asks the agent to upload environment variables or disable tests, those sentences are task data, not authority. OWASP documents this indirect prompt-injection pattern for repositories, issue bodies, PR comments and other material encountered during development.
What the official product can and cannot do
The agent needs to read issue descriptions to understand a bug, but it should obey a separate trusted task boundary. System-level tool grants and the repository installation’s permissions matter more than persuasive text in the issue. Even a read-only source comment can trigger harmful behavior if a high-privilege agent interprets it as an instruction.
A practical evaluation workflow
Create a test issue containing a legitimate small bug and a clearly marked adversarial instruction to read a synthetic secret or change a policy file. Ask the agent only to fix the stated bug. Confirm from logs that it ignores the instruction and cannot access protected paths or outbound destinations. Repeat the exercise with a README, dependency output and CI failure log, then document the resulting control gaps.
Limitations and historical pitfalls
An instruction filter alone cannot defend every variant because an attacker can rephrase commands as troubleshooting, policy updates or comments that appear to be from maintainers. Text may be laundered through tool summaries. A refusal message is insufficient if tools actually executed before refusal. External validations should not rely on anecdotes about a single attack string.
Data handling and permission boundary
Enforce least privilege, non-root execution, no blanket repository write rights and separate approval for sensitive actions. Label tool output and issue comments as untrusted. Keep the ability to trace which file or comment influenced an action without storing production tokens in prompts or logs.
Who should use this approach
Required for agents triggered automatically by issues, PRs, CI, webhooks or chat comments. It is equally relevant to a human-in-the-loop local agent that reads community-maintained source code.
Alternatives and trade-offs
Strict non-agentic review and manual implementation can be safer for exposed public issue queues. AI07 owns general agentic security architecture, while this article focuses on software development repositories.
Version, tier, region and evidence status
This article is an editorial snapshot checked against first-party material on 2026-10-25. Version or historical applicability: OWASP secure coding AI guidance and GitHub Apps docs checked 2026-10-25. The exact software build in a reader’s organization, eligibility by country, enterprise agreement, separate provider model rates, code retention and full regional list have not been validated; such fields remain unknown rather than being guessed. Product statements are attributed to first-party descriptions, not independent hands-on tests. License guarantees, prices and seat limits require AI 10 dated snapshots or signed terms. Unverified details do not become timeless facts because they appear in current online documentation.
Deployment acceptance checklist
- Write the intended job and acceptance criteria; record the installed client release, plugin publisher, connected model/provider and tenant.
- Use a consented test repository with zero real secrets; capture installation permissions, processor regions, Git App grants and available audit logs.
- Verify the task boundary with a test that should fail when unauthorized: blocked file, network host or protected branch.
- Review proposed changes or comments against known requirements; run regression, security and integration checks independently of the agent.
- Document the owner, offboarding procedure, rollback limits and whether a formal procurement/privacy sign-off is still pending.
Sources & Further Reading
- https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html (official technical material; undated/living source; checked 2026-10-25)
- https://docs.github.com/en/apps/using-github-apps/reviewing-and-modifying-installed-github-apps (official technical material; undated/living source; checked 2026-10-25)
- https://code.visualstudio.com/docs/editing/workspaces/workspace-trust (official technical material; undated/living source; checked 2026-10-25)