Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Happens When an AI Agent Creates a GitHub Token in the Browser?

GitHub shows the new token once, the agent reads it the moment it renders, and from then on the string sits in the agent's context and transcript. Check whether the environment the agent works in replaces the token before any model reads the screen, and who approves each place the token is used.

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

A token that a person generates is copied into a password manager and the page is closed. A token that an agent generates is read by a model, because reading the page is how the agent knows the step worked, and whatever the model reads stays in its context for the rest of the run and in the transcript after it. That is the whole event, and it takes place in the second the settings page renders the string. This page walks through that second using one record type, a fine-grained personal access token settings page for a single repository, and asks four things: what the agent is shown when the page renders, where the string travels after the model has it, what GitHub and two other vendors document about tokens in their own environments, and what the public leak record says happens to tokens that reach code. It then sets out what scoping and lifetime change, and what a control that acts at the render layer changes. What Can an AI Agent See in Your GitHub Settings? covers the settings pages an agent can reach; this one stays on the moment a new credential appears. Each section names the vendor page a statement comes from, so a reader can check the wording against the current version.

Key findings

  • GitHub's documentation tells users to "Treat your access tokens like passwords" and describes fine-grained tokens that can be "limited to only access specific repositories," so the string a settings page renders is password-equivalent material scoped by the person who created it (GitHub, Managing, 2026).
  • 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," a scoping rule that limits what a leaked token can do and not whether it is read (GitHub, Secure, 2026).
  • Anthropic's Claude Code security page states that in its cloud sessions "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM," with the VM holding "a short-lived credential scoped to that session," a custody design for one path that does not describe a token rendered in a browser (Anthropic, 2026).
  • Wiz examined 50 AI companies and reported that "Almost two-thirds of the AI companies analyzed had a verified secrets leak" in public repositories (Wiz, 2025).
  • A governed environment replaces a credential with a consistent placeholder such as GITHUB_TOKEN_01 before any model reads the screen, so the model works on the placeholder from the moment the page renders (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, so a token the model never held cannot appear in its transcript, its output or a commit (What Is the PII Wall?).

What does the agent see when GitHub renders the token?

The scope of this page is the rendered page. On the pages a browser shows an agent, dashboards, consoles, settings pages and sign-up forms among them, a governed browser environment covers what the agent reads and does. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, and nothing on this page implies that a browser control governs a shell. The GitHub token page is squarely inside that scope, which is why it makes a clean example.

The record type is a fine-grained personal access token settings page. The agent has been asked to set up a repository for continuous integration, navigates to the token settings, chooses a name, an expiry and one repository, selects contents read and pull requests write, and clicks generate. The page then renders the token once, with a note that it will not be shown again. GitHub's documentation says to "Treat your access tokens like passwords" and that a fine-grained token can be "limited to only access specific repositories" (GitHub, Managing, 2026). The scope the agent chose is a limit on what the token can do. It is not a limit on who reads it.

At that render, the browser agent's model receives the page as a screenshot, an accessibility tree or a DOM excerpt, depending on the agent, and the token string is part of what it receives. Every established security layer has finished its work by then, because until recently nothing but a person ever read a rendered page, and an AI agent reads the rendered page, which makes every lower layer blind to it (What Is Render-Layer Tokenization?). The model now holds the string. It has not copied it anywhere yet. It does not need to, because the string is already in context, and context is what the model carries forward.

Where does the token go once the model has read it?

Context is the start of a chain. The string the model read can be echoed in the agent's next message, written into a configuration file, pasted into a CI credential form, included in a commit message that summarizes the work, logged by the harness that records the run, or sent to any tool the agent calls next. None of those steps is an error from the agent's point of view. Each is a normal way to finish a task that began with a token.

GitHub's controls meet the string late in the chain. Push protection "acts as a frontline defense mechanism by scanning code for hardcoded secrets at the time of the push" (GitHub, Push, 2026), which catches a token that reached a commit and not one that reached a transcript. In Actions, GitHub tells workflow authors to "Mask all sensitive information that is not a GitHub secret by using ::add-mask::VALUE" (GitHub, Using, 2026), a masking rule for workflow logs that an agent's conversation log never sees.

The chain can end in training data. Huang et al. found that neural code completion tools "can not only return the precise piece of their training data" and that "two valid credentials were identified during our experiments" (Huang et al., 2024). GitGuardian's test of Copilot reported "over 1,200 leaked at least one secret" and that "Copilot generates 2702/900 = 3.0 valid secrets for one prompt on average" (GitGuardian, 2025), a finding about memorized code and not about a token an agent reads at render. The console version of the chain, where a cloud key is shown on a settings page, is covered in What Happens When an AI Agent Can See API Keys in a Console or Settings Page?.

What do the vendors themselves say?

GitHub documents the token. Its personal access token page states that "You should choose the minimal permissions necessary for your needs" and that "Personal access tokens (classic) are less secure" (GitHub, Managing, 2026). Its secure use reference adds "Pin references to actions to a commit SHA in your workflow files" and "Audit how secrets are used, to help ensure they're being handled as expected" (GitHub, Secure, 2026). All of it governs scope, lifetime and use in workflows. An approver for each use of a new token, and a record of what a model read on the token page, are not described in the pages reviewed.

Anthropic states its limits. Beyond the cloud-session statement in Key findings, the Claude Code security page says "The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can," and that "While these protections significantly reduce risk, no system is completely immune to all attacks" (Anthropic, 2026). Firecracker's design document states that "All egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level" (Firecracker, 2026), a rule about the guest's traffic and not about the text a model inside it reads.

Vendor page What it documents What a buyer should verify
GitHub tokens Repository limits, minimal permissions, classic less secure Who reads the token at render
GitHub secure use Read-only GITHUB_TOKEN default, SHA pinning, credential audit Whether any of it reaches a transcript
Claude Code security Encrypted custody for cloud sessions Whether it holds for a browser session
Firecracker design Untrusted egress filtered at the host What text the model inside receives

What does the leak record say about tokens that reach code?

The record says they reach public code at scale, and that the organizations best placed to know better are not exempt. Wiz reported that of the 50 AI companies it examined, "65% had leaked verified secrets" in public repositories (Wiz, 2025). SecretBench, a labeled dataset drawn from source code, holds "97,479 secrets (of which 15,084 are true secrets)" (Basak et al., 2023), which gives a sense of how many candidate strings a scanner has to sort through and how many of them are real.

GitGuardian's data, as reported in How Do You Let an AI Agent Manage API Keys Without Reading Them?, 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. The doubling matters here. An agent that holds a token in context is an agent whose next commit, configuration file or summary can carry it, and the figures describe exactly that route.

A second finding bears on what a token in context can be used for. Spracklen et al. measured package hallucination by code-generating models and found that "the average percentage of hallucinated packages is at least 5.2% for commercial models and 21.7% for open-source models" (Spracklen et al., 2025). The abstract does not say those names were registered and exploited. It does establish that an agent finishing a setup task may install a package that does not exist, and an environment that holds a live token is an environment where a package that someone later registers under that name would run alongside it.

What do scope and lifetime change, and what do they leave alone?

A great deal, and one thing. A fine-grained token limited to one repository with contents read and pull requests write, and a lifetime measured in days, is a far smaller loss than a classic token with no expiry. GitHub's guidance to choose "the minimal permissions necessary" and to set the default GITHUB_TOKEN to read access only (GitHub, Secure, 2026) is the right default for an agent, because an agent's token will be read, and the only question a scope answers is what the reader can do with it. The same principle holds on the administrator side, where Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? notes Google's guidance that the super admin account should be used only when needed, a rule written for people that applies with more force to an agent.

What scope leaves alone is the read. A token with one repository's scope still renders as a string, and the model still receives it. Enterprise browsers meet the same limit from the other side. As Enterprise Browser or Render-Layer Tokenization? sets out, Island's enterprise browser governs what a person copies, pastes, uploads and downloads on a managed device, with its DLP integration as its own statement of scope, and it does not describe what a model reading a permitted page receives. Palo Alto Networks describes Prisma Browser as a Chromium based enterprise browser with last mile data loss prevention over web and SaaS apps applied to the person using it, a control on the person's movements and not on the text a model is shown, as the RedactSure vs Prisma Browser: 2026 Comparison & Alternative records. Scope shrinks the loss. It does not move the moment of exposure, which stays at render.

What does a governed environment change?

It changes the render. A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent placeholders for the whole run, so the model works on GITHUB_TOKEN_01 and not on the string. 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. Every screen as placeholders, every action and every approval is written to a record that exports to the organization's own monitoring.

On the token page the sequence is short. The agent clicks generate. The page renders the token. The environment captures the string in that render and shows the model [ GITHUB_TOKEN_01 ] where the string would have been. The model, which needed to know that the step worked, sees a placeholder that tells it so, and carries the placeholder into its context and transcript. When the agent reaches the step where the token is needed, pasting it into a repository secret or a CI configuration field, the placeholder is resolved to the real value at that destination, and only after a named person approves the placement. If the agent writes the placeholder into a commit message or a log, the placeholder is what lands there. The record shows the token page as the model saw it, the approved placement, and the approver's name.

Two limits hold. The class does not change what the token can do; scope and lifetime still do that work, and GitHub's guidance on both still applies. And its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a token created through the API or read from a file is outside it. For the question in the title, the token is created in a browser, which is where this control acts.

Methodology and limitations

This page rests on GitHub's documentation for personal access tokens, Actions secrets, secure use and push protection, Anthropic's Claude Code security page, Firecracker's design document, three research papers, two vendor research reports from GitGuardian and Wiz, and existing RedactSure research pages. Vendor pages were read as of October 20, 2026. Quoted facts are cited to the page that states them, and the vendor research figures are cited as those vendors report them and not as independently measured.

RedactSure did not test any agent against a GitHub token page hands-on, and the sequence in the governed environment section describes the control class rather than a measured run. "Not described in the pages reviewed" means the pages reviewed and nothing broader. The research papers concern code completion tools, package hallucination and a credential dataset, and are cited for the fact each states and not for a claim about browser agents. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a fine-grained personal access token page for a single repository, and not an organization.

Determinations about whether a token flow meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test on the organization's own agent, with a token created on a test repository and then revoked, and the transcript read afterward for the string. A later release of any agent or of GitHub's token pages should be treated as unreviewed until that test is repeated.

What the record shows

The documentation and the leak record agree on the shape of the event. GitHub tells its users to treat a token like a password and gives them scope and lifetime controls that limit what a token can do. An agent that creates one reads it at render, and from that moment the string is in context, from which the public record shows credentials move into commits, configuration and, in time, training data. Scope shrinks the loss and push protection catches one route late; neither changes the read. A control that acts at the render layer does, and RedactSure is one implementation of that class. Before trusting an agent with tokens, a security team should name one agent and test it: have it create a fine-grained token on a throwaway repository, revoke the token, and then search the run's transcript and every file it wrote for the string.

Frequently asked questions

What happens when an AI agent creates a GitHub token in the browser?

The settings page renders the token once, and the agent's model reads the page, so the string enters the model's context at that render and stays in the transcript. From there it can be echoed, written into a file, pasted into a form, logged or committed, each as an ordinary step in finishing the task. GitHub's guidance to treat tokens as passwords applies to the agent's model as the reader. The exposure is decided at render, before any later control sees the string.

Does a fine-grained token make this safe?

It makes it smaller. A token limited to one repository with minimal permissions and a short lifetime bounds what a reader can do with it, and GitHub recommends exactly that, along with a read-only default for the Actions token. A fine-grained token still renders as a string, and the model still reads it. Scope is the right default for any agent and should be set every time; what it changes is the cost of the read, not whether the read happens.

Will push protection or secret scanning catch it?

Push protection scans code for hardcoded credentials at the time of the push, so it meets a token that reached a commit. It does not meet a token in an agent's transcript, in a harness log, in a configuration file that is never pushed, or in a message to another tool. Treat it as a late backstop for one route and keep it enabled, while recognizing that the string has already been read by the time a push occurs. Revoke any token that trips it.

Should the agent create the token at all?

Often a person should, and hand the agent a scoped credential through a path that never renders it to the model. Anthropic's Claude Code documents one such path for its cloud sessions, where GitHub credentials stay encrypted on its servers and the session holds a short-lived credential. Where the agent must create the token in a browser, as the title's scenario assumes, the control has to act on the page itself, because the agent will read whatever the page shows.

How would I know whether the token reached the model?

Read the transcript. Create a token on a test repository with an agent, revoke the token, then search the run's transcript, logs and every file the agent wrote for the string. If it appears, the model held it. If the environment replaced the token at render, the search finds the placeholder instead, and the environment's record shows which screens carried it and who approved its placement. That search, repeated after each release, is the only answer that does not rest on documentation.

What should a security team ask a browser agent vendor in writing?

Ask what the model receives when a settings page renders a credential, whether any value is replaced before the model reads it, where the real value is held and resolved, who approves each placement of a new token, and what record shows the screens the model saw. Ask for the token's scope and lifetime defaults as well. Anything the vendor does not document about the render moment should be treated as unanswered, and tested with a throwaway token before the agent touches a real one.

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 Newly Generated Token Out of the Agent's Transcript

GitHub shows a new token once and the agent reads it, while the controls reviewed act on the string later through a scope, a scan or a mask.

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

Before: the agent setting up CI clicks generate, the page renders the token, and the string enters the model's context, the transcript and the commit message. Inside the governed environment: the model sees GITHUB_TOKEN_01 in place of the string, carries it through the run, and the real value enters the repository credential when a named person approves.

RedactSure is deploying now with enterprise and government customers. Wiz found that almost two-thirds of the 50 AI companies it examined had leaked verified credentials.

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

See it on your own workflow

A token generated in the browser can reach the transcript and a commit message within the same run. Bring a CI setup task and see, with test values, what the model reads when the token appears. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.