Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can a Coding Agent Be Tricked Into Pushing to a Public Repository?

Yes, if the token it holds can write to the destination: the instruction is one line in a README, an issue or a dependency file, and the agent follows it like any other step. Check the grant before the prompt: which repository it can write to, what the model reads on the page, and who approves the push.

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

For an organization whose code sits in private repositories, a push is the moment an agent stops reading and starts publishing. The instruction that gets it there is cheap: one line in a README, a comment on an issue, a note in a dependency's changelog, phrased as a step the task requires. Whether that line ends in a commit on a public fork depends on something the instruction does not control, which is the authority the agent already holds. A token limited to one repository gives the agent a destination and a boundary at once: it can write where the grant names, and the host refuses everywhere else. A classic token with broad scope lets it publish far wider.

That split starts with what a browser control covers, because the terminal and the repository page are different surfaces. An instruction travels from a file to a push, and what GitHub, Anthropic and Cognition document about the credentials involved shows what a repository-scoped grant does and does not stop. The worked record is a push to a public fork that fails on scope, the case a team can reproduce without a live attacker. The research record on injection and on leaked credentials explains why arranging that failure on purpose is worth the work.

Key findings

  • GitGuardian's test of Copilot found that "over 1,200 leaked at least one secret," the exposure that a push to a public repository creates for anything the model has read (GitGuardian, 2025).
  • GitHub's token documentation states that each fine-grained token "can be further limited to only access specific repositories for that user or organization," the setting that decides whether a push to a named fork can succeed (GitHub, Managing, 2026).
  • Wiz reports that it looked at 50 AI companies and found that "65% had leaked verified secrets on GitHub," the exposure a public repository creates for everything pushed to it (Wiz, 2025).
  • Least privilege governs the actions and credentials an agent holds and leaves ungoverned the content of the screen it reads, so a token limited to one repository still shows the model every field on the page, and only a control at the point of rendering decides what the model is shown (What Is Least Exposure?).
  • A vault protects the flows it is wired into and no others, with coverage equal to the integration list, so a repository page rendered outside that wiring shows the model the real values unless the page itself is rendered as tokens (Data Privacy Vault or Screen-Level Tokenization?).

What does a browser control cover when an agent pushes?

The title asks about a push, and a push happens somewhere. An agent driving a browser does it on a rendered page: the fork page, the file editor, the commit form, the pull request page, or a settings page where a deploy key or a webhook is added. A governed browser environment covers what an agent reads and does on those pages. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. That boundary matters here because most coding agents push from a shell, where git push runs with a credential in the environment or a helper, and no browser control sees the command.

The rendered-page case is not a niche. An agent asked to publish a fix clicks through the same commit form a person uses, and the destination it selects is a value on the page: a repository name, an owner, a branch, a remote address. Those values are what an injected instruction tries to change. A tether is a description of authority, not of capability (What Is a Tethered Agent?), and a grant names the repository the agent may write to. The page is where the agent chooses the repository it will write to now.

The worked record is a push to a public fork that fails on scope. It has two halves: the authority the agent holds, which is one repository, and the page it is working on, which offers a destination outside that repository. A team can run the record without an attacker: name a fork in a file, watch what the model receives, and see which step refuses.

How does a line in a repository become a push?

An injected push starts as content the agent was asked to read. A README in the repository, an issue comment, a review note, a changelog entry in a dependency: all of it is task context, and a model has no reliable way to mark one sentence as data and the next as an instruction. The study of browsing agents shows the class of trick: "untrusted web content can hijack agent behavior," and its findings include "prompt injection, domain validation bypass, and credential exfiltration" (Mudryi et al., 2025). The abstract reports no success rates, so the finding is qualitative. It says the route exists, not how often it works.

A benchmark of agent attacks is equally direct: "Our benchmark results reveal critical vulnerabilities in different stages of agent operation," and it reports "limited effectiveness" among current defenses (Zhang et al., 2025). Read together, the two papers describe a chain: content enters the context, the model treats part of it as a step, and a tool call carries the step out.

The tool call is where the push becomes possible. If the agent's job is to publish, the step looks ordinary: commit this, push to this remote, open a pull request against this fork. The authority to carry it out is separate, and that separation is the whole defense. Anthropic's documentation is explicit about where one boundary sits: "the boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can" (Anthropic, 2026). The prompt approves a command, not a destination that a page or a file supplied.

For the record on this page, the injected line sits in a repository's contributing notes and names a fork as the place to send a fix. Nothing in it is remarkable, which is why the grant, not content inspection, has to do the work.

What do the vendors themselves say?

The documentation pages describe where a credential sits and what it can reach, and each is useful for one property a buyer can check. None is about a public fork. Read together, they cover three places a token can live: on a vendor's servers for a cloud session, in a credential store with a scope, and in the runner of a workflow. None of them describes the fourth place, which is the screen an agent reads before it acts.

Anthropic documents custody for cloud sessions: "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM," and "the VM holds a short-lived credential scoped to that session" (Anthropic, 2026). The page attributes that arrangement to Anthropic-hosted cloud sessions, not to a local session, and a coding agent pushing from a laptop is the local case. Cognition's Devin guide lists organization, personal, repository and session scopes, and says that "In the browser, Devin types the value directly" (Cognition, 2026). That keeps a value out of a shell variable. Whether the model sees the value it types is not described in the pages reviewed.

GitHub's Actions page adds the fork boundary: "secrets are not passed to the runner when a workflow is triggered from a forked repository" (GitHub, Using, 2026). That protects the runner. It says nothing about what a push puts in a public history.

Dimension What the documentation states What a buyer should verify
Repository reach A fine-grained token can be limited to specific repositories Which repositories the agent's token covers, and whether any other grant reaches a fork
Workflow token A read-only GITHUB_TOKEN default is recommended Whether the workflow asks for write, and who can change that
Cloud session GitHub credentials stay off the session VM and the VM holds a short-lived credential Whether the custody covers the session the agent actually runs in
Credential scopes Organization, personal, repository and session, with browser typing What the model is shown when a value is typed on a page
Fork boundary Credentials are not passed to a runner triggered from a fork What the public history holds after the push
Page content No documented control over what the model reads What the model received on the screen before it acted

What does a repository-scoped grant actually stop?

Scope is the part of the answer an agent cannot talk its way past. A fine-grained token can be limited to specific repositories, which lets a team name the one repository the agent may write to. A token scoped that way gives the agent no credential for a fork outside the list, so a push to the fork has nothing to authorize it. The write fails where the credential is checked, which is the host, not the model. GitHub's page adds that "Personal access tokens (classic) are less secure" (GitHub, Managing, 2026).

Two limits follow. First, the grant bounds the destination and not the content: a token limited to one repository still lets the agent read everything in it, and a model that has read a file can repeat it anywhere it may write. Second, a token that can change settings, add a deploy key or publish a package is a publishing tool inside the repository, and OWASP's non-human identity list describes secret leakage as the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" (OWASP, 2025).

Workflow tokens are the same argument with a safer default. GitHub's secure use reference says "It's good security practice to set the default permission for the GITHUB_TOKEN to read access only for repository contents," a default that would stop a push from a workflow and that says nothing about a token a person issued (GitHub, Secure, 2026). AWS's advice against creating root access keys rules out the durable top-level credential, and a long-lived token that can reach everything is the same shape at a smaller scale (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).

What does a public fork expose once the push lands?

The exposure is not the branch a reviewer sees; it is the history behind it. A public fork is indexed, cloned and mirrored within minutes, and a force-push later does not recall the copies. Wiz's report on 50 AI companies found that "Almost two-thirds of the AI companies analyzed had a verified secrets leak," a measurement of how common the destination is (Wiz, 2025). The report does not say how many of the 50 lacked a GitHub presence, so the share is among companies that had one.

GitGuardian's test of Copilot measures the other half, how readily a model produces a value it has seen. The post estimated that "Copilot generates 2702/900 = 3.0 valid secrets for one prompt on average," though it does not confirm whether the extracted credentials were still active (GitGuardian, 2025). For a pushed repository the two halves meet: the model repeats a value into a file and the file goes public.

Volume turns an accident into a pattern. GitGuardian's data, as reported by Help Net Security, counted "28,649,024 new secrets exposed in public GitHub commits across 2025," with commits co-authored by an AI coding agent leaking credentials at roughly double the baseline rate and "24,008 unique secrets exposed in MCP configuration files" (How Do You Let an AI Agent Manage API Keys Without Reading Them?). One push can carry an environment file, a test fixture with a live key, or a config that names an internal host.

GitHub's fork rule, quoted above, protects the runner and not the public history. The exposure is the commit, which is why the destination and the content both matter: the grant decides whether the push can land, and the screen decides what the model has to put in it.

What does a governed environment change?

A governed environment acts on the screen before the model does. Values chosen by policy are replaced with consistent tokens for the whole run, so a repository name, an owner, a branch and a remote address reach the model as REPO_001 and BRANCH_002. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and a push to a public fork is consequential. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

The instruction can still arrive, and the model can still decide to follow it. What it cannot do is name the attacker's repository as a destination, because the destination it holds is a token that resolves only for the repository a person approved. If the agent tries to publish to a fork outside the grant, there is no real address to resolve, and the approval step has nothing to approve. The record then shows what the screen said, which action was attempted and who approved what.

Adjacent designs show the same three properties in different places. Meta's design uses surrogate tokens the agent does not see, a separate component that approves network egress, human approval before sensitive actions and a complete activity log, all of which are one vendor's design for its own agent rather than a property any page inherits (What Would an Enterprise Version of Meta Muse Need?). Skyflow's tokenization exchanges a value for a pseudorandom token with the original held apart, which protects a data flow it is wired into and not a repository page rendered outside that wiring (see RedactSure vs Skyflow: 2026 Comparison & Alternative).

Methodology and limitations

This page rests on two research preprints on prompt injection and agent attack benchmarks, vendor documentation from GitHub, Anthropic and Cognition, OWASP's non-human identity guidance, two vendor research posts from GitGuardian and Wiz, and existing RedactSure research pages. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from vendor research are cited as reported, not independently measured. The figures are the vendors' own, not independent measurements.

RedactSure did not test any of the named products hands-on. "Not described in the pages reviewed" means the vendor pages recorded for this article do not state the behavior, not that the vendor does not implement it. Vendor features change and the page carries its date, so a release after October 21, 2026 should be treated as unreviewed until the test below is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The worked record describes a record type, a push to a public fork blocked by scope, and not an organization.

Determinations about whether a repository permission, a token lifetime or a public exposure meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test on the organization's own repository with its own token, repeated after each change to the grant or the repository's visibility, and the written answer belongs with the run that produced it.

What the record shows

The evidence points one way. The instruction is cheap, and the research record says agents can be hijacked by content they read, so the useful control removes the authority a line would need rather than telling the model to ignore the line. A repository-scoped token does that at the host: the push to a fork outside the grant has no credential behind it. It does not change what the model reads on the page, which is why a second control sits at the render layer, where the destination becomes a token and a named person approves the push. RedactSure's environment is built on that second control. To reproduce it as a test, name one agent, one repository and one public fork, ask the agent to publish a fix with the fork named in a file, and write down what the model received and which destination the host refused.

Frequently asked questions

Can a coding agent be tricked into pushing to a public repository?

Yes, if the credential it holds can write there. The instruction can arrive in a README, an issue, a dependency file or a page the agent reads, and a model has no reliable way to treat one sentence as data and the next as an order. The push then looks like the task it was given. The deciding factor is the grant, not the wording: a token limited to specific repositories has no credential for the public destination, so the write fails where the host checks it.

What does a one-line instruction look like?

It looks like ordinary project guidance: a note that fixes go to a named fork, that a release branch lives at a particular remote, or that patches should go through a mirror. The agent has been asked to publish something, and the line tells it where. Nothing in the line has to look malicious, which is why scanning content for suspicious phrases is a weak control. The line matters because the agent holds a credential that can act on it, and no wording fixes that.

Does a repository-scoped token stop the push?

It stops the write to any repository the token does not cover. A fine-grained token can be limited to specific repositories, and the host refuses a write the credential has no permission for, so a push to a public fork outside the grant fails at that check. It does not stop the agent from reading everything in the repository it can reach, and it does not stop a second credential from carrying the content out. List every grant the agent holds, including any beyond the one you issued.

What can the agent leak without pushing anything?

Anything it read and is allowed to write elsewhere. A token scoped to one repository still lets the agent put content in an issue, a pull request description or a file in that same repository, and a public issue is as public as a fork. If a second grant covers another repository or a package registry, that grant is another exit. The push is the loud version of the failure; the quiet one is a paste into a public issue.

How would a team test its own setup?

Create a test repository, a test fork and a token scoped to the test repository only. Ask the agent to publish a harmless file, with the fork named in a file the agent will read. Then check three things: whether the model received the fork's real name, whether the push was attempted, and whether the host refused it. Repeat with a broader token to see the difference, and keep the transcript beside the grant so the next reviewer can check both without rerunning the test.

What should a security team ask for in writing?

Which repositories the agent's credential can write to; what permissions ride on it and how long it lives; what the model reads on a repository page before it acts; who approves a push and where that approval is recorded; and what stops a publish to a destination outside the grant. Treat any answer the documentation does not support as unanswered until a test run confirms it, and file the run's record with the grant it used, dated.

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 an Injected Push Inside the Grant

An agent that reads a repository reads its instructions too, and repository scope stops the write at the host while leaving open what the model read first.

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

Before: the commit form shows the fork's real owner and name. Inside: the same page renders REPO_001, the model cannot name the fork, and the repository resolves only when a person approves the push to the repository the grant names.

RedactSure is deploying now with enterprise and government customers. Anthropic states that an approved Bash command can still write anywhere the account can.

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

See it on your own workflow

An injected push needs the agent to know where to push. Bring a repository task your team delegates and see, with test values, what the model reads on the commit form and which repository a person approves. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.