Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can a GitHub Issue Hijack My Coding Agent?

Yes, when the agent treats the issue text as its task, because anyone who can file an issue then supplies instructions the agent may follow. Check who can file issues in the repository and what the agent's token and workflow permissions allow.

A credential reference travels from a browser record through a bounded route to a separate API destination.

A maintainer who assigns issues to a coding agent lets text written by someone else set the agent's work. When a team hands an issue to an agent, the title, the body and the comments become the task, and a model has no reliable way to separate the part a maintainer meant from a line a visitor typed. This page asks whether that channel alone, with no poisoned file and no stolen account, is enough to redirect an agent. It reads what GitHub documents for Copilot coding agent and for the Actions workflows an agent is likely to edit, what Anthropic documents for Claude Code, and what the research record says about injection through content a model retrieves. The example is an issue that asks for a new CI step, because a workflow file is where a changed instruction becomes a change in what runs with the repository's token. The recorded GitHub pages describe limits on where an agent can act and how much one task can produce. They do not record which words of an issue the model is shown. Can a README Hijack My Coding Agent? covers the file channel, Can a Pull Request Comment Hijack My Coding Agent? covers the review channel, and What Can a Hijacked Coding Agent Do With My GitHub Token? covers what follows once an agent obeys.

Key findings

  • Greshake et al. describe attacks that "enable adversaries to remotely (without a direct interface) exploit LLM-integrated applications," and an issue tracker fits that description: the adversary needs no access to the agent, only a place where text will be read (Greshake et al. et al., 2023).
  • OWASP states that "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files" (OWASP, 2025).
  • GitHub's documentation states that Copilot "can only make changes in the repository specified when you start a task" and "can open one pull request per task," limits on where a task writes that do not govern what the model reads (GitHub, Copilot, 2026).
  • A governed environment replaces the values an agent would otherwise read with consistent tokens before any model reads the screen, so an instruction that arrives inside an issue finds tokens and not records (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination, at the moment of an approved action, so an issue that talks an agent into sending a value elsewhere collects a token (What Is Least Exposure?).

What does a governed browser environment cover when an agent reads an issue?

The scope of a governed browser environment is the rendered page: what an agent reads and does on dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An issue reaches an agent by two routes, and only one of them sits inside that scope. A person who opens the issue in the GitHub web interface and asks a browser agent to read it, or to act on it, is working on a rendered page. A coding agent that a team hands the issue to receives the task from the platform, edits files and runs tests in its own environment, and opens a pull request, which is the terminal and API territory the scope sentence excludes. This page treats both routes as ways a stranger's text becomes a task, and says which controls apply to which.

The example record is one issue asking for a new CI step. The body reads like an ordinary request: add a lint job, run it on every push, upload the results. A further line, in the body or in a comment under it, is addressed to the agent. The maintainer sees one request. The agent receives a single block of text in which the maintainer's intent and the stranger's line carry the same standing, which is the exposure to untrusted content that forms one of the three conditions in the lethal trifecta (What Is the Lethal Trifecta for AI Agents?). Browsing agents show the same pattern: researchers "demonstrate how untrusted web content can hijack agent behavior," with findings that include "prompt injection, domain validation bypass, and credential exfiltration" (Mudryi et al., 2025).

What does the research say about text an agent reads but did not write?

Indirect prompt injection is the research name for the channel. Greshake et al. reveal "new attack vectors, using Indirect Prompt Injection" and report that such attacks "can act as arbitrary code execution, manipulate the application's functionality" (Greshake et al. et al., 2023). OWASP's entry lists a remedy that is access rather than detection: "Restrict the model's access privileges to the minimum necessary for its intended operations" (OWASP, 2025).

Detectors exist, and the record on them is thin. The LlamaFirewall paper describes "PromptGuard 2, a universal jailbreak detector that demonstrates clear state of the art performance," and its abstract reports an approach that "shows stronger efficacy at preventing indirect injections in general scenarios than previously proposed approaches" (Chennabasappa et al., 2025). The abstract gives no quantitative results, so a team cannot read a miss rate from it, and a comparison with earlier approaches is not a statement about what gets through.

An issue also stays. Once filed, the same text is read by every run that opens it, so one miss by a detector repeats for as long as the issue is open. A coding agent working a repository already holds private data and a way to communicate, and the issue supplies the third condition of the lethal trifecta, exposure to untrusted content. The practical response is to plan for the miss and bound what the agent can reach, which the sections below take in turn.

What can an issue asking for a new CI step change?

A CI step is a change to a workflow file, and a workflow runs with whatever the repository has granted it. GitHub's secure use reference states that "It's good security practice to set the default permission for the GITHUB_TOKEN to read access only for repository contents" (GitHub, Secure, 2026), a limit on what a new job can write that says nothing about what an agent reads before it writes the job. The same page advises to "Pin references to actions to a commit SHA in your workflow files" (GitHub, Secure, 2026), which bears on this request because a requested step usually names an action written by someone else, and the reference is part of what a reviewer approves.

On credentials, GitHub's page states that "secrets are not passed to the runner when a workflow is triggered from a forked repository" (GitHub, Using, 2026). That rule is about forks. It is a reason to ask where an agent's change will run, and which credentials exist there, before an issue is allowed to produce a workflow.

One control acts at the moment of the push. Push protection "acts as a frontline defense mechanism by scanning code for hardcoded secrets at the time of the push" (GitHub, Push, 2026). It addresses a hijacked agent that writes a credential into code, and it does not address a value the agent sends somewhere other than a push.

What do the vendors themselves say?

GitHub documents where a Copilot task can write and what it can produce, and Anthropic documents where a Claude Code command can write and how credentials are held in its hosted sessions. Neither page, as recorded, describes the words of an issue the model is shown. Which issue text Copilot reads as its task is not described in the pages reviewed.

Dimension Vendor, per its documentation What a buyer should verify
Copilot coding agent, reach and environment Copilot "can only make changes in the repository specified when you start a task" and "can edit files and run tests and linters in an ephemeral cloud development environment" (GitHub, Copilot, 2026) Which issue text becomes the task; the page does not describe the firewall, credentials or token permissions
Copilot coding agent, rules "repository administrators can add Copilot as a bypass actor to enable access" (GitHub, Copilot, 2026) The repository's rule settings, read next to the agent's own limits
Claude Code, local commands "The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can" (Anthropic, 2026) What an approved command can reach on the developer's machine
Claude Code, hosted sessions "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM" (Anthropic, 2026) The page describes this for Anthropic-hosted sessions only, not local ones

Each row is a limit on action or custody. None describes a control over which values the model is shown on a page it opens, which is the question an injected issue turns on.

How far can a token reach if the agent obeys an issue?

An obeyed issue is bounded by the credentials the agent holds. GitHub tells users to "Treat your access tokens like passwords" (GitHub, Managing, 2026), and the token pages an agent opens carry password-equivalent material (What Can an AI Agent See in Your GitHub Settings?). Three limits are set when a token is created. A fine-grained token "can be further limited to only access specific repositories for that user or organization," the page advises teams to "choose the minimal permissions necessary for your needs," and it notes that "Infinite lifetimes are allowed but may be blocked by a maximum lifetime policy set by your organization or enterprise owner" (GitHub, Managing, 2026). A long-lived token is therefore a choice the organization can forbid, and a hijacked agent should not be holding one.

Custody can move the token out of the agent's reach. In Anthropic-hosted sessions the VM "holds a short-lived credential scoped to that session," and the same documentation concedes that "no system is completely immune to all attacks" (Anthropic, 2026).

Scope, expiry and custody bound what an obeyed issue can do with a token. They do not change what the model read on the way there, and a pipeline that authenticates by OIDC, which How to Set Up S3 and GitHub With Cowork or Dots covers, does not change what an agent reads on the pages it opens. What Can a Hijacked Coding Agent Do With My GitHub Token? takes the token question on its own.

What does a governed environment change?

A governed environment is a control placed between a rendered page and the model. It substitutes consistent tokens for the values a policy names before any model reads the screen, so the agent works on ACCT_001 and ENDPOINT_001 through the whole run. Real values resolve only at the approved destination, at the moment of an approved action, and a named person approves each consequential action, such as a submission or a change to a record. Every screen the agent saw as tokens, every action and every approval is written to an exported record that the organization's own monitoring can hold.

Applied to an issue, the control does not read the issue and judge it. A hostile line and a harmless line arrive the same way, and the environment makes no attempt to tell them apart. What it changes is what a redirected agent holds when the line arrives: tokens for the account identifiers, endpoints and settings values on the pages it opened, and no authority to send a real value anywhere without a person's approval. An instruction to include those values in a step, a comment or a request then produces tokens, and the destination form resolves the real value only after approval.

The limits follow from the scope. The control covers the rendered page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a coding agent that receives an issue through the platform and works in a shell is governed by the controls reviewed above: repository scope, token scope, expiry, review of the pull request. The two sets answer different questions. Platform and workflow settings answer where an agent can act. A governed environment answers what it was shown when it acted.

Methodology and limitations

This page rests on vendor documentation from GitHub and Anthropic, research preprints on indirect prompt injection and agent guardrails, the OWASP standard entry on prompt injection and RedactSure's own research pages, each read for the facts recorded about that page. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quotations are attributed to the page they appear on, and a source is cited only for the facts recorded from it. RedactSure's own pages are cited as its own statements, not as independent evidence.

RedactSure did not test any agent, repository or workflow hands-on, and nothing here reports a measured rate for issue-borne injection. "Not described" means not described in the pages reviewed: GitHub's firewall and credentials documentation for Copilot coding agent, and the pages on how an issue is assigned to the agent, were not among them, so this page does not state what they say. Quoted phrases are taken from the recorded wording of each page and are not reconstructed from memory. Vendor features change and the page carries its date. RedactSure statements describe current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, an issue asking for a new CI step, and not an organization.

Determinations about whether a configuration meets a legal or contractual duty belong to counsel, assessors and the organization's own security and compliance officers. A reader who needs one should treat this page as a reading list and a set of questions, and confirm each vendor statement against the current documentation before relying on it. Where this page says that a vendor does or does not describe something, it means the pages reviewed, on the dates shown.

What the record shows

An issue is untrusted text placed where an agent takes its instructions, and the research record treats that as a known channel. The documentation reviewed bounds the agent's reach: one repository, one pull request per task, a read-only default token, narrowly scoped and expiring credentials. It does not record a control over which words of the issue, or which values on the pages the agent opens afterward, the model is shown. The first set of controls limits the damage of a successful hijack, while a control placed before the model limits what a hijacked agent holds. One named agent and one task, such as an issue asking for a new CI step, are enough to test it: list which tokens, repositories and pages the stranger's line could reach, and what the model would receive from each.

Frequently asked questions

Can a GitHub issue hijack my coding agent?

It can when the agent treats the issue's text as its task. The title, body and comments reach the model as one block, and the research record on indirect injection says text from an outside source can redirect behavior. The documented limits on repository, branch and pull request bound the result, not the reading. A harmless instruction hidden in a test issue, on a repository with no real credentials, shows whether your agent follows it before a stranger finds out.

Does it matter whether the repository is public or private?

It changes who can file the issue, not what the agent does with it. On a private repository the author is a colleague or a compromised account; on a public one the set of possible authors is larger. The documentation reviewed ties no agent behavior to the author, so the safe assumption is that any author's text is untrusted. Visibility is a question about likelihood, not about exposure, and a private repository is not a reason to relax the token scope.

Does pull request review stop an issue-driven change?

Review is where a person sees the change, and GitHub documents that Copilot "can open one pull request per task," so each task ends in one place to look. A reviewer reads a diff, though, not what the agent was told or which values it read before writing the change. The documentation also records that administrators can add Copilot as a bypass actor, so confirm which rules apply to the agent's pull requests before counting review as a control.

Should the agent's token be read-only?

Where the work allows it, yes. GitHub's secure use reference advises a default token permission of read access only for repository contents, and its token page advises minimal permissions and notes that infinite lifetimes may be blocked by policy. A read-only, expiring token limits what an obeyed issue can change. It does not stop a hijack that only needs to read, so scope the repositories as well, and pair the permission with an expiry the organization enforces.

Is Claude Code exposed to the same channel?

Any agent that reads an issue, whatever the vendor, receives text it did not write. Anthropic's documentation says a Bash command you approve "can still write anywhere your user account can" and that "no system is completely immune to all attacks." In its hosted sessions, GitHub credentials stay on Anthropic's servers. Ask whether your sessions are hosted or local before relying on that custody, because the page describes it for hosted sessions only.

What should a team ask for in writing before handing issues to an agent?

Four things: who can file an issue the agent will read; the token's scope, repository list and expiry; whether the agent's workflow changes need approval from a named person; and what the model receives from the pages it opens. The first three are settings a team can read today. The fourth is the one the vendor pages reviewed do not record, so ask for it in the vendor's own words and keep the reply with the date it was given.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Limits What a Redirected Agent Holds When an Issue Gives the Orders

A maintainer's request and a stranger's line reach the model as one block of text, and the documentation above limits only where the agent writes.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Take an issue asking for a new CI step and a browser agent that follows it to the deployment environment page. Before: the model receives an account identifier and an endpoint address, and the stranger's line has it print both in the new step. Inside the governed environment: the model receives ACCT_001 and ENDPOINT_001, and the real values resolve only in the settings form a named reviewer approves.

RedactSure is deploying now with enterprise and government customers. Indirect injection can "manipulate the application's functionality," and "no system is completely immune to all attacks."

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

An issue can only redirect an agent toward values the model has read. Bring an issue-driven task your team runs and see, with test values, what a redirected agent would receive on the deployment settings page. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.