Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Can an AI Agent See in Your GitHub Settings?

An agent working in GitHub settings sees whatever the pages render: account emails, SSH key titles and fingerprints, token names and scopes, organization members and any newly created token shown once on screen. Check which of those values reach the model as plain text and whether the actions GitHub guards with sudo mode wait for a person.

A viewing cone from an abstract ring illuminates settings cards containing key, tag, and account symbols.

An agent working in GitHub settings sees whatever the pages render: account emails, SSH key titles and fingerprints, token names and scopes, organization members and any newly created token shown once on screen. Check which of those values reach the model as plain text and whether the actions GitHub guards with sudo mode wait for a person. Developers hand agents GitHub tasks every day: set up a deploy key, create a token for a pipeline, add a collaborator, change a repository's visibility. Each task runs through settings pages that GitHub itself treats as sensitive enough to demand a fresh password before changes, and each page shows the agent more than the task needs. The agent reads identity and credential material as a matter of course, and it acts on pages where one change can let a new person or system into the account. This page states what a browser control covers for a developer and what it does not, walks through what a settings page renders, sets out how GitHub's own documentation treats those pages, describes what changes when an agent inherits that view, shows what a tokenized settings page looks like, and lists the claims a buyer should refuse. It builds on the question of what an agent sees when it takes a screenshot.

Key findings

  • GitHub tells users to treat access tokens like passwords, and documents fine-grained tokens that can be limited to specific repositories, so the token pages an agent reads carry password-equivalent material (GitHub, 2026).
  • GitHub requires re-authentication in sudo mode for actions like adding SSH keys because each action could allow a new person or system to access the account, a classification an agent workflow should inherit (GitHub, 2026).
  • Secret exposure on GitHub is measured at scale: 28,649,024 new secrets were exposed in public commits across 2025, and commits co-authored by an AI coding agent leaked secrets at roughly double the baseline rate (Help Net Security, 2026).
  • An environmental injection attack on generalist web agents reached up to 70 percent success in stealing users' specific personal information, and a settings page that renders emails and key material is a target of that kind (Liao et al., arXiv, 2025).
  • GitHub's security log lists all actions performed within the last 90 days, recording what was done but not what a model saw (GitHub, 2026).
  • Deciding what the model should see for a given piece of work, rather than what the page happens to show, is the design question a settings page makes concrete (What Should the AI See for This Piece of Work?).

What does a governed browser environment cover on GitHub, and what does it not?

The scope has to be drawn before the pages are described. A governed browser environment covers what an agent reads and does on a rendered page. On GitHub that means the settings pages: the personal account's emails, SSH and GPG keys, developer settings and token lists; a repository's settings for collaborators, secrets, deploy keys and visibility; an organization's member list, team pages and security settings; and the dialogs that display a newly created token or key once. It also covers the ordinary pages around them, such as pull requests and issues, when the agent reads them in the browser. On every one of those pages the environment decides which values the agent sees and which actions it may take.

It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP servers. A developer who asks an agent to run git from a shell, edit a workflow file in an editor, call the GitHub API from a script or operate a GitHub MCP server is working outside the browser, and a browser control makes no claim about those paths. Nothing on this page implies that a control on rendered pages governs a shell. The distinction matters here more than on most topics, because the measured secret leakage on GitHub comes largely through commits and configuration files (Help Net Security, 2026), which are the shell and editor paths. The settings pages are a different exposure: not secrets written into code, but credentials and identities read off a screen and actions taken on it. A developer should review the two separately and ask each vendor which path a given safeguard applies to.

What does a GitHub settings page actually render?

Take a single record type: the settings area of a developer account that belongs to an organization, as it renders after sign-in. The emails page lists every address on the account, including the backup address, and marks which are verified and which is primary. The SSH and GPG keys page lists each key by title, fingerprint and date last used. The developer settings page lists personal access tokens by name, with their scopes, expiry and the repositories they reach. When a new token or key is created, a dialog displays the secret once, with a note that it will not be shown again. The organization pages list members with their roles and two-factor status, and the repository settings pages list collaborators, deploy keys, and secrets by name.

Every one of those values is text on a page, and an agent that works the page reads it. GitHub's own guidance says to treat access tokens like passwords (GitHub, 2026), and the token creation dialog is the one place where the password-equivalent value is rendered. The emails page is identity material. The key fingerprints and token names are a map of which systems can reach the account and through what. The member list is the organization's roster with roles attached. The pages were designed for the account holder, not for a reader that keeps a transcript.

A screenshot-based agent sees the same material as pixels rather than text, and it sees all of it, as the earlier page on what an agent sees in a screenshot describes. The question for a developer is not whether the agent can see these values but which of them the task needs. Creating a deploy key needs the repository and the key to be added; it does not need the account's backup email or the organization's member list, both of which are a click away on the same settings area.

How does GitHub itself treat these pages?

GitHub's documentation already classifies the settings area as sensitive. Sudo mode requires the user to re-authenticate before certain actions, such as adding an SSH key, because each action could allow a new person or system to access the account (GitHub, 2026). Fine-grained personal access tokens can be limited to only access specific repositories (GitHub, 2026), which is the platform's own least-privilege mechanism for the credentials an agent might create.

GitHub control, per its documentation What it protects What it leaves for the agent workflow
Sudo mode re-authentication Actions that could admit a new person or system Who, in an agent run, supplies the re-authentication and approves the action
Fine-grained tokens scoped to repositories Reach of a created credential Whether the agent creates a broad token when a narrow one would do
Security log of the last 90 days A record of actions under the account What the model saw on screen; retention beyond 90 days
Secret scanning Secrets committed to repositories Secrets rendered on settings pages and read, not committed

The security log lists all actions performed within the last 90 days (GitHub, 2026), so a change an agent makes is recorded under the account, though the log shows the action and not the screen. Secret scanning, which GitHub documents for repository content (GitHub, 2026), addresses the commit path; a token read once from a dialog was never committed, so the exposure happened at the render layer.

What changes when an agent inherits that view?

Three things change. First, the reader keeps a transcript: a model that reads the emails page holds every address in its context for the rest of the run. Second, the reader can be instructed by the page. OWASP describes prompt injection, in which content the model reads is treated as instruction, as the leading risk for LLM applications (OWASP, 2025), and a README, an issue comment or a pull request description is content an agent reads on the way to a settings task. The environmental injection study measured what follows: an attacker-shaped page led web agents to disclose a user's specific personal information with up to 70 percent success (Liao et al., arXiv, 2025).

Third, the scale of exposure is already measured for the adjacent path. GitGuardian's figures, as reported, put new secrets exposed in public GitHub commits across 2025 at 28,649,024, with 24,008 unique secrets in MCP configuration files and commits co-authored by an AI coding agent leaking at roughly double the baseline rate (Help Net Security, 2026). Those numbers describe the shell and editor path, not the browser, but they establish that agents handling credentials leak them at measurable rates. OWASP's sensitive information disclosure entry describes the mechanism, confidential data entering a model's context through its inputs (OWASP, 2025), and a settings page is an input.

The title question therefore has two answers. What can the agent see? Everything the page renders. What should it see? The fields the task requires. The gap between the two is the exposure, and what AI agent visibility should let security teams see argues that closing it, and recording that it was closed, is what visibility for agents means.

What does a tokenized settings page look like?

The alternative is to change what the page shows the model rather than to trust the model with the page. In a tokenized run, the agent sees each email address as EMAIL_001, EMAIL_002; each key fingerprint as KEY_001 with its title intact; token names and scopes readable, since the agent needs those to choose a narrow token; organization members as USER_001 onward with roles intact; and the token creation dialog with the secret as TOKEN_001. The same value maps to the same token for the whole run, so the agent can tell that the collaborator it is adding is the same USER_007 who appears in the team list.

The structure survives, so task logic that matches a repository to a collaborator still works, and the values the agent does not need never enter the model's context, so there is nothing for an injected instruction to extract. The token shown once in the creation dialog resolves to its real value only at the approved destination, such as the pipeline's secret store, at the moment the named person approves the action.

The approvals follow GitHub's own classification. The actions GitHub protects with sudo mode, because each could admit a new person or system (GitHub, 2026), are the actions that wait for a named person in the agent run: adding a key, creating a token, adding a collaborator, changing visibility. That is where the zero trust principle of deciding each request at a policy enforcement point (NIST, 2020) lands on a concrete page. When a policy stops an action, the developer needs to see why (How to see exactly why a security policy blocked an action?); setting up S3 with GitHub using OIDC rather than keys shows one such workflow end to end.

What does a governed environment change?

In a governed environment, the agent still navigates the same GitHub settings pages, but the emails, key fingerprints and newly minted tokens on them reach the model as consistent tokens, and the actions GitHub itself guards with sudo mode wait for a person.

The mechanism is a class of control that sits between the rendered page and the model. Sensitive values on the screen, including account emails, key material and the one-time display of a new token, are replaced with consistent tokens before any model reads them, so the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, including adding keys, creating tokens and changing organization membership. Every screen as the model received it, in token form, every action and every approval is recorded and exported to the organization's own logging.

This answers the title question with a different page than the one GitHub renders. GitHub tells users to treat access tokens like passwords (GitHub, 2026), and a model that never received the token string cannot leak it, by injection or by mistake. GitHub's security log lists actions for 90 days but not what a model saw (GitHub, 2026); the environment's record supplies the screens as tokens alongside the action and the named approval, the record the buyer was told to ask for.

The control covers the rendered page and not the terminal, the IDE or the filesystem; a token pasted into a shell or committed from a working copy is outside it, and the account's permissions and sudo mode are unchanged.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design places the agent's browser session inside a governed environment in the customer's cloud and substitutes values at the render layer before any model reads the screen, so the GitHub emails page arrives with each address as EMAIL_001, the keys page with each fingerprint as KEY_001, the member list as USER_001 onward and a newly created token as TOKEN_001, with the same token for the same value across every page of the run. Real values resolve only at approved destinations at the moment of an approved action, such as a pipeline's secret store receiving the token. A named person confirms the tokenization policy for the workflow and approves every payment, submission and record change, which on GitHub includes the actions the platform itself guards with sudo mode, under Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no integration with GitHub, and leaves the developer's permissions unchanged.

Deployments are in pilot. A pilot on one real settings task, such as creating a scoped token for a pipeline, would show the token dialog as the model received it, the scopes the agent chose and the named approval that released the action. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on GitHub's own documentation of personal access tokens, the security log, sudo mode and secret scanning, on press reporting by Help Net Security of GitGuardian's 2025 secrets sprawl figures, on the peer-reviewed environmental injection study by Liao et al. (ICLR 2025), on the OWASP Top 10 for LLM Applications entries on prompt injection and sensitive information disclosure, on NIST Special Publication 800-207 on zero trust architecture, and on RedactSure research pages on screenshots, visibility, policy explanations and GitHub workflows. All sources were read as of October 16, 2026.

No hands-on testing of any named product was performed, and no agent was run against a GitHub account for this page. The sudo mode page cited is for GitHub Enterprise Server 3.8; other GitHub products may differ. Where this page says a behavior is not described, it means not described in the pages reviewed, not that a product lacks the behavior; vendor documentation is read as a statement of design intent rather than as test evidence. The leakage figures quoted describe public commits, not settings pages, and are cited for scale. GitHub's pages and settings layouts change, and the page carries its date for that reason. Statements about RedactSure describe its current design, with deployments in pilot. The developer account, settings pages and token dialog described here are record types, not any organization's account, and no customer or prospect is described.

Whether a given agent's access to a GitHub account, its token scopes and its approval gates meet an organization's security policy and contractual obligations is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

GitHub settings pages render identity and credential material as ordinary text, because they were built for an account holder to read, and GitHub's own documentation marks the actions on them as consequential enough to demand a fresh password. An agent inherits the full view and adds two things a person does not bring: a transcript that keeps every value, and a susceptibility to instructions planted in the pages it reads along the way, measured at up to 70 percent in the study cited. The structural answer is to tokenize the values at render so the model works with EMAIL_001 and TOKEN_001 while the task logic survives, and to hold the sudo-level actions for a named person, which is the design RedactSure describes. The test is to name one agent and one settings task and ask to see the token creation dialog exactly as the model received it.

Frequently asked questions

Does an agent see my email addresses when it works in GitHub settings?

If it navigates to the emails page, yes, in full, including the backup address and verification status, because the page renders them as text for the account holder. Most settings tasks do not need that page, but the agent decides where to navigate, and a page it reads is a page in its context. Whether those addresses arrive as plain text or as tokens depends on the environment the agent works in, not on GitHub, which renders the page the same way for every reader.

Is a fine-grained token safe for an agent to create?

Safer than a classic token, because GitHub documents that fine-grained tokens can be limited to specific repositories. The remaining questions are who chose the scopes, whether the agent picked the narrowest set the task allowed, and where the token went after the dialog displayed it. A scoped token that was read by the model and carried in its context is scoped and disclosed at once; the scope limits the damage without preventing the reading.

Does GitHub's security log record what an agent did?

It lists all actions performed within the last 90 days under the account, so changes an agent made appear there with timestamps. It does not record which pages the agent read, what values were on them, or who approved each action in the agent's workflow. For a complete record of an agent run, the screens as seen, the actions and the named approvals have to be kept elsewhere, in a store the organization controls and retains for as long as its own policy requires rather than 90 days.

Does secret scanning catch a token an agent read from a dialog?

No. Secret scanning, as GitHub documents it, detects secrets in repository content such as commits. A token displayed once in a creation dialog and read by a model was never committed anywhere, so there is nothing for scanning to find. The exposure happened when the page rendered the value to a reader that keeps a transcript, and only a control at the render layer, acting before the model reads the dialog, addresses that path.

Does a browser control govern an agent running git in my terminal?

No. A governed browser environment covers what the agent reads and does on rendered pages, including GitHub's settings, repository and organization pages. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP servers. The measured leakage through commits and MCP configuration files is on those paths, and it needs its own controls; a browser control makes no claim about it.

Which GitHub settings actions should wait for a person in an agent run?

The ones GitHub itself protects with sudo mode, because each could allow a new person or system to access the account: adding SSH keys, creating tokens, adding collaborators and similar changes. GitHub's judgment about what is consequential is a sound starting list, and an agent workflow that pauses for a named approval on exactly those actions inherits a classification made by the platform rather than inventing one.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

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.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.