What are the signs that an AI agent has been manipulated through a malicious GitHub issue?

Why This Matters for Security Teams

A malicious GitHub issue is not just a noisy prompt injection attempt. In an agentic workflow, the issue can become a delivery mechanism for scope creep, data exfiltration, and unintended code changes if the agent is allowed to read repositories, open branches, or act on untrusted text without strong task boundaries. The real risk is that the agent will treat attacker-written instructions as operationally valid.

That is why current guidance for agentic systems emphasizes both OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework: the issue is not simply bad input, but adversarial input reaching a tool-using identity with real privileges. NHIMG’s research on Analysis of Claude Code Security shows how quickly code-focused agents can be pushed into unsafe repository actions when the workflow assumes the issue text is trustworthy. The same pattern appears across agent tooling, where a prompt, issue, or comment is enough to redirect the agent’s next action.

Security teams should treat these events as a sign that the agent’s authorisation boundary has failed, not merely that the model “made a mistake.” In practice, many teams only notice the manipulation after a private file has already been read or a public commit has already been published.

How It Works in Practice

Malicious issues usually work by embedding instructions that are more specific, more urgent, or more task-shaped than the legitimate request. The agent may first summarise the issue, then follow hidden steps such as reading extra files, checking secrets, creating a branch, or posting a reply that includes copied material. The warning signs are usually behavioural, not linguistic.

Teams should watch for a chain of actions that does not match the declared issue scope:

• The agent accesses private or unrelated repository paths while handling a public bug report.
• The agent opens a pull request or commit with content that was never requested by the user.
• The agent quotes private code, internal comments, or secrets in a README, issue reply, or changelog.
• The agent changes tone from triage to execution without a human approval step.

For detection and governance, NIST’s NIST AI Risk Management Framework is useful for structuring oversight, while NHIMG’s OWASP NHI Top 10 helps frame the identity and privilege side of the problem. The practical control is to bind the agent to a narrow workload identity, require request-time policy checks, and isolate public issue handling from private repository access unless a separate approval path is triggered. These controls tend to break down when the agent has broad write access to repositories and issue data because attacker instructions can then flow directly into real execution.

Common Variations and Edge Cases

Tighter issue handling often increases triage overhead, requiring organisations to balance faster automation against stronger review and isolation controls. That tradeoff becomes visible when teams want the agent to resolve simple GitHub issues quickly but still prevent it from acting on hostile content.

Best practice is evolving, but several edge cases are clear. A public issue is not automatically benign just because it is visible to everyone, and a private issue is not automatically safe if the agent is reading cross-referenced content, linked snippets, or copied stack traces from untrusted sources. Some environments also blur the line between code review, support triage, and autonomous remediation, which makes a single “safe” workflow hard to define. In those cases, the agent should be allowed to classify and recommend, but not to execute privileged repository actions without fresh authorisation.

The most important distinction is between a useful agent response and a manipulated one. A genuine response stays aligned with the issue’s declared objective; a manipulated response starts reaching into unrelated files, hidden context, or downstream actions. NHIMG’s reporting on AI Agents: The New Attack Surface report reinforces that many organisations still lack visibility into what agents actually access, which makes these edge cases difficult to spot before damage occurs. Where repositories, CI/CD systems, and issue trackers are tightly coupled, the guidance breaks down fastest because a single malicious issue can trigger both data exposure and public code changes in one workflow.

Related resources from NHI Mgmt Group

• What are the signs that an AI assistant's command approval model is failing in practice?
• What are the signs that a browser extension campaign is turning malicious?
• How should teams reduce the risk of exposed AI credentials being abused?
• What steps should security teams take to prevent Shadow AI risks?