Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Can a Hijacked Coding Agent Do With My GitHub Token?

A hijacked agent can do whatever the token it holds allows, so the reach of the token is the blast radius. Check which repositories and permissions each agent's token carries, and whether the agent needs to hold the token at all.

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

When a coding agent is talked into doing something its owner never asked for, the practical issue for the team that issued its token is how far the agent can reach. That reach is set before the attack, by the token the agent was given. A token acts for the account that created it, within the repositories and permissions it carries, so a narrow token produces a small incident and a broad one produces a large incident, whatever the attacker's skill. This page reads GitHub's own documentation on personal access tokens, Actions secrets and push protection, research on credential leakage, and a study of browsing agents, and asks what each says about the size of the blast radius. The example is a record type: a classic token compared with a token limited to one repository. Can a GitHub Issue Hijack My Coding Agent? covers how an instruction arrives through an issue, and Can a Pull Request Comment Hijack My Coding Agent? covers the comment route. This page starts after the hijack, with the token already in the agent's hands and the question of how much it can do with it.

Key findings

  • A token an agent holds is a password the agent can repeat, and GitHub's guidance is blunt: "Treat your access tokens like passwords" (GitHub, Managing, 2026).
  • The repository list is the first bound on the damage, since a fine-grained token can be "further limited to only access specific repositories for that user or organization" (GitHub, Managing, 2026).
  • The type of token matters before any other setting, because GitHub states that "Personal access tokens (classic) are less secure." (GitHub, Managing, 2026).
  • Tokens often end up where they should not be: Wiz examined 50 AI companies and "found that 65% had leaked verified secrets" (Wiz, 2025).
  • A governed environment shows an agent tokens in place of real values before any model reads the screen, so a hijacked agent repeats a token that means nothing outside the environment (What Is Least Exposure?).
  • Real values resolve only at the destination a named person approved, so the blast radius of the agent is set by the approvals on record and not by the grant behind them (What Is a Tethered Agent?).

What does a governed browser environment cover when an agent holds a GitHub token?

A governed browser environment covers what the agent reads and does on a rendered page. A GitHub settings page, a token creation screen and a repository page are all rendered pages. The terminal, the IDE, the local filesystem, direct API calls and MCP are outside it, and an agent that calls the GitHub API with a token from its own environment is acting outside that scope. This page therefore separates two questions that are easy to run together: what a token allows, which is a property of the grant, and who gets to see the token, which is a property of where it appears.

The example record is a classic token and a token limited to one repository, each held by an agent that has been hijacked. Neither case needs an exotic attack. The agent reads content that carries an instruction, and the instruction tells it to use what it holds. In the classic case, what it holds is the broader of the two grants, and GitHub itself calls that kind of token less secure. In the one-repository case, the grant names one repository, and the damage stays inside it. The attacker's skill is the same in both. The difference is entirely in the size of the grant the owner chose before the incident.

A hijack of this kind is recorded for browsing agents in general. The authors of one study write that "we demonstrate how untrusted web content can hijack agent behavior" (Mudryi et al., 2025). What the abstract does not report is a success rate, so it supports the existence of the path and not its frequency.

What can a hijacked agent do with a classic token?

It can do what the token's permissions allow, on every repository the token covers, because the token carries the owner's authority and does not question the purpose of a request. The documentation does not list the operations an attacker would choose, and this page does not guess at them. What it records is the framing: tokens are to be treated like passwords, and the classic kind is less secure. A password does not know who is typing it. A token does not know whether the instruction behind a request came from the person who created it or from a page the agent opened a minute ago.

Two further settings widen the window. GitHub notes that "Infinite lifetimes are allowed but may be blocked by a maximum lifetime policy" (GitHub, Managing, 2026), so a token created once can remain usable long after the task that justified it ended. An organization's policy may cap that lifetime, and a person creating a token for an agent should not assume that it does. The second setting is the list of permissions. GitHub advises users to "choose the minimal permissions necessary for your needs" (GitHub, Managing, 2026), which is advice a classic token, with its coarse grouping, makes harder to follow.

The practical reading is simple. A classic token held by an agent is a standing grant to everything the owner's grant covers, available to anyone who can steer the agent for as long as the token lives. The question to ask about any agent is which token it holds, what that token covers and when it expires.

What do the vendors themselves say?

GitHub documents three controls that bear on a token's blast radius, and each page states its own limit. The personal access token page describes repository limits and lifetimes and says nothing about coding agents. The Actions guidance covers the default permission of the workflow token and does not describe how an agent that holds a personal token should be bounded. The push protection page covers credentials in pushed code and does not describe tokens an agent reads on a page. What any of the three pages record about an agent that reads a token on a rendered screen is not described in the pages reviewed.

Dimension GitHub, per its documentation What a buyer should verify
Personal access tokens Fine-grained tokens can be "further limited to only access specific repositories for that user or organization" (GitHub, Managing, 2026) Whether the agent's token is fine-grained and which repositories it names
Workflow token It is good practice to "set the default permission for the GITHUB_TOKEN to read access only" for repository contents (GitHub, Secure, 2026) Whether the default is set, and whether any workflow raises it
Push protection Works by "scanning code for hardcoded secrets at the time of the push" (GitHub, Push, 2026) What it covers beyond code, and what happens to a token shown on a page

Each row bounds a grant or catches a leak at a particular moment. None of them decides what the agent sees on the settings page where a token is displayed.

How far does a fine-grained token limit the damage?

It limits it to the repositories the token names and the permissions it was given, which is the strongest control that sits on the token itself. A hijacked agent holding a one-repository token can act only inside that repository. The people who depend on the other repositories keep them, because the grant never reached them. This is the property that makes the choice of token type the most useful single decision in the whole chain.

It does not limit what happens inside the named repository, and it does not change how a token is stored or displayed. GitHub's own page notes that the token's repository list is a limit on the grant, and the same page says nothing about coding agents. A fine-grained token that sits in an agent's context is still a credential the agent can repeat, and the repository it names is still exposed to anyone who can steer the agent. For that reason the useful comparison is not classic against fine-grained in the abstract but classic against a one-repository grant for a stated task, with an expiry.

The workflow token follows the same logic. GitHub's Actions guidance says it is good practice to "set the default permission for the GITHUB_TOKEN to read access only" for repository contents (GitHub, Secure, 2026), so that a workflow starts with the least and raises it deliberately. The same page advises teams to "Audit how secrets are used" (GitHub, Secure, 2026), which is how a team learns after the fact what a token did. Auditing records an incident. It does not shrink one.

Where does the token sit, and who can read it?

The size of the grant is half of the blast radius. The other half is how many places the token appears. GitHub's secrets guidance says to "Mask all sensitive information that is not a GitHub secret" (GitHub, Using, 2026), because a value printed into a log is a value anyone with access to the log can read. It also states that "secrets are not passed to the runner when a workflow is triggered" from a forked repository (GitHub, Using, 2026), which keeps a credential away from untrusted code in that one case.

Scale is the reason to care. A labeled dataset of source code reports "containing 97,479 secrets (of which 15,084 are true secrets)" (Basak et al., 2023), which shows that credentials in code are common enough to build a research dataset from. GitGuardian reports that Copilot generates "3.0 valid secrets for one prompt on average" (GitGuardian, 2025), though the page does not confirm whether the extracted credentials were still active. The mechanism behind this step is described in What Is Render-Layer Tokenization?. What Can an AI Agent See in Your GitHub Settings? records that the token pages an agent reads carry password-equivalent material, and How Do You Let an AI Agent Manage API Keys Without Reading Them? takes up the moment a key is displayed.

What does a governed environment change?

A governed environment is a control 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 with a stand-in such as TOKEN_001 through the whole run. Real values resolve only at an approved destination, at the moment of an approved action, and a named person approves each consequential action. Every screen the agent saw as tokens, every action and every approval is written to an exported record that the organization's monitoring can hold.

Applied to the blast radius, it changes who holds the grant. A hijacked agent can still be instructed to use the token, but the token it holds is a stand-in with no meaning outside the environment. The real grant stays behind the approval step, so the operations an attacker can trigger are the operations a person approved, not the operations the token allows. That is a smaller set than the grant on any token type reviewed above.

The limits follow from the scope. The control covers the rendered page. A token the agent reads from an environment variable, a file in the tree or a direct API call is outside it, and the controls above, fine-grained scope, short lifetimes, a read-only default for the workflow token and push protection, carry that part of the problem. The two sets answer different questions. Those controls size the grant. A governed environment decides whether the agent holds it.

Methodology and limitations

This page rests on GitHub's vendor documentation on personal access tokens, Actions secrets, workflow permissions and push protection, research preprints on browsing agents and credential datasets, vendor research from Wiz and GitGuardian, and RedactSure's own research pages, each read for the facts recorded about that page. RedactSure's own pages are cited as its own statements, not as independent evidence. Vendor pages were read as of October 20, 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. Where a page says nothing about a point, this page says so and does not fill the gap.

RedactSure did not test any agent, token or repository hands-on, and nothing here reports a measured rate for hijacked agents misusing tokens. "Not described" means not described in the pages reviewed. The operations a token allows are named by GitHub's permission model, which this page did not enumerate, so it makes no claim about specific operations. 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, a classic token compared with a one-repository grant, 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.

What the record shows

The blast radius of a hijacked coding agent is the grant behind the token it holds, and the record shows how that grant is bounded: a fine-grained token limited to named repositories, a classic token that GitHub calls less secure, lifetimes that may be infinite, a read-only default for the workflow token and push protection for code. Each limits the grant or catches a leak, and none changes what an agent sees on a page where a token is displayed. Take a single task, such as updating a repository setting, and test this by asking which token the agent holds, which repositories it names, when it expires and whether the model would see the real value on any page it opens.

Frequently asked questions

What can a hijacked coding agent do with my GitHub token?

It can do what the token's permissions allow, on the repositories the token covers. GitHub tells users to treat access tokens like passwords, and a password does not know who is typing it. The documentation does not list specific operations an attacker would choose, so this page does not either. The reach depends on the token type, the repositories it names and its lifetime, and each of those is a choice the owner made before the hijack. Find out which token your agent holds and write down what it covers.

Is a fine-grained token safe for an agent?

It is safer than a classic token, because it can be limited to specific repositories and GitHub calls the classic kind less secure. It is not safe in itself, since an agent that holds it can still repeat it, and the repository it names is still exposed. Treat it as a smaller grant for a stated task, set an expiry that matches the task, and keep a record of what it was used for so that a later review can compare the use with the intent.

Should the token have an expiry?

Yes. GitHub notes that infinite lifetimes are allowed but may be blocked by an organization's maximum lifetime policy, so a token made for one task can outlive it by years. A short lifetime limits how long a stolen value works. It does not limit what the value can do while it works, so pair the expiry with a narrow repository list and ask who revokes the token when the task ends, and who is told if it is used after that.

Does push protection stop a token leaking?

It catches hardcoded credentials in code at the time of a push, according to GitHub's description. A token an agent reads on a settings page and repeats elsewhere is a different route, and the documentation reviewed does not describe it. Use push protection as one layer, and ask separately where else an agent could write a value it has read, such as a comment, a commit message or a log, and whether anything reviews those writes before they leave.

What should the workflow token default to?

GitHub advises setting the default permission for the workflow token to read access only for repository contents, and raising it for a workflow that needs more. That keeps a workflow, or an agent that triggers one, from starting with write access it does not need. Check the repository and organization defaults for the workflow token, and look for workflows that raise them without a stated reason, since an agent that can edit a workflow can ask for more than the default.

How does a governed environment change the answer?

It changes what the agent holds. The model works with a stand-in token, and the real value resolves only at a destination a named person approved, so a hijacked instruction can trigger only what was approved. It covers the rendered page and not the terminal, the IDE, the local filesystem, direct API calls or MCP, so those still need scoped, short-lived tokens. Test it on one settings page your agent reads, and ask what the model holds when the page loads.

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 Keeps a Hijacked Agent From Holding the Real Token

The reviewed controls bound a grant and catch a leak afterward, but none removes the token from the page, so a hijacked agent still carries a usable credential.

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

Take an agent that opens a token creation page and a repository settings page. Before: the model holds a classic token, and a hijacked instruction can use it anywhere that token reaches. Inside the governed environment: the model holds TOKEN_001, and a one-repository grant resolves only at the destination a named reviewer approves.

RedactSure is deploying now with enterprise and government customers. Wiz found that 65% of the AI companies it examined had leaked verified credentials on GitHub.

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

See it on your own workflow

A hijacked agent can use a token anywhere that token reaches, not only where the task needed it. Bring a GitHub task and see, with test values, what the model holds and which destination a reviewer approves. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.