Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Is It Safe to Let an AI Agent Browse Docs While I Am Logged Into GitHub?

Reading the docs is safe; the open GitHub session in the same browser profile is not, because a page in those docs can tell the agent to use it. Run the agent in a profile with no GitHub login, give it a scoped token it never reads, and test which profile it attaches to.

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

A documentation site is about the least sensitive thing an agent can read, so the risk for a developer sits elsewhere: in what else the browser profile holds while the agent reads them, and for most developers that is a signed-in GitHub tab, a saved password or both. An agent that drives the same profile inherits that session without typing anything, and the instructions that steer it come partly from the pages it reads. This page separates the two halves of the question: what an agent in a profile can reach, and what a page in the docs can make it do with that reach. It takes one record scenario, a developer reading library documentation in one profile while GitHub is open in another, and uses it to test the separate-profile advice against the vendor documentation for two browser agent frameworks. It then asks what the leak record says about where GitHub credentials end up, and what a governed environment changes on the pages the agent reads. Does Claude in Chrome Use Your Saved Logins and Open Sessions? asks the same question of one vendor's extension; this page asks it of the profile itself.

Key findings

  • Mudryi, Chaklosh and Wojcik report that their findings on browsing agents "include prompt injection, domain validation bypass, and credential exfiltration" and that "untrusted web content can hijack agent behavior," which is the mechanism by which a docs page reaches an open session (Mudryi et al., 2025).
  • Browser Use's sensitive data template states that "the LLM only sees placeholders (x_user, x_pass), we filter your sensitive data from the input text," a control over values the developer hands the agent and not over a session already open in the profile (Browser Use, 2026).
  • GitHub tells users to treat access tokens like passwords and documents fine-grained tokens that can be "limited to only access specific repositories," so a scoped token is the documented substitute for a session that carries the whole account (GitHub, Managing, 2026).
  • A governed environment replaces values chosen by policy with consistent tokens before any model reads the screen, so a page that shows a token, a key or a repository secret shows the model a placeholder. Real values resolve only at the approved destination at the moment of an approved action, so the model never needs to hold them to finish the task (What Is Least Exposure?).
  • Wiz examined 50 AI companies and found that "65% had leaked verified secrets" in public repositories, the record a signed-in session lets an agent add to (Wiz, 2025).

What does an agent in my browser profile inherit?

Everything the profile holds. A browser profile is a bundle of cookies, saved passwords, open tabs and extensions, and an agent attached to it drives the browser as the person would. If GitHub is signed in, the agent does not need the password, the two-factor code or a token: the session cookie answers every request. That is the whole of the risk in this question, and the docs are only the delivery route for an instruction.

The scope of the answer matters. A governed browser environment covers what the agent reads and does on a rendered page, which includes dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A coding agent that pushes through a git command on the developer's machine is outside this page; a browser agent that opens github.com in the same profile the person uses is inside it.

The tether is the useful way to think about the inherited session. A tethered agent goes anywhere its supervisor could go and does real work there, across applications, at machine speed; the tether describes authority, not capability (What Is a Tethered Agent?). With GitHub signed in, the supervisor's authority includes creating tokens, adding deploy keys, changing repository visibility and inviting collaborators, and the token pages the agent could reach carry password-equivalent material (What Can an AI Agent See in Your GitHub Settings?). Least privilege governs actions and credentials and not the content of the screen, so even a scoped session shows the model every page it can open.

What do the vendors themselves say?

Browser Use's sensitive data template says "the LLM only sees placeholders (x_user, x_pass), we filter your sensitive data from the input text" and that "real values are injected directly into form fields after the LLM call," which governs credentials the developer passes in and not a GitHub session that was already open when the agent attached (Browser Use, 2026). The same page advises "Use Browser(allowed_domains=[...]) to restrict navigation," the control that matters most here: an agent allowed only the docs domain cannot carry the profile's session to github.com. It also says "Set use_vision=False to prevent screenshot leaks."

Skyvern's credentials documentation says "the model that drives the browser gets placeholders, not your values" and that connected vaults such as 1Password, Bitwarden and Azure Key Vault are read at run time, which covers a login Skyvern performs and not a tab the person signed into before the run (Skyvern, 2026). It adds that "a typed value can still show up in later screenshots and page text, so turn on Mask Secrets in an agent's settings to hide it there too," so a placeholder at input does not by itself clear the value from what the model later sees. A control over a session the person opened before the agent attached is not described in the pages reviewed for either framework, so the control is the profile, not the product.

Dimension Browser Use and Skyvern, per their documentation What a buyer should verify
Typed credentials Placeholders to the model; real values injected after the model call Which fields the placeholder covers on the sites in use
Pre-existing session Covered by domain restriction in Browser Use; otherwise not addressed Which profile the agent attaches to, by test
Screenshots use_vision off, or Mask Secrets on Whether the setting is on in the deployed configuration

How can a documentation page reach my GitHub session?

Through the agent's instructions. A browsing agent reads page text as part of its context, and the study in the key findings shows that text can steer it, with credential exfiltration among the outcomes. A documentation site is untrusted web content in that sense, whether the page is a community comment, a hijacked package README or a third-party mirror of the docs.

In the record scenario the chain is short. The agent is asked to find the right configuration flag in a library's docs. A page in those docs, or a comment on it, contains an instruction to open github.com, create a personal access token and paste it into a form. If GitHub is signed in within the same profile, each step succeeds without a password prompt, and the agent reports that it found the flag. The same three conditions, access to private data, exposure to untrusted content and the ability to communicate externally, form the lethal trifecta in the analysis that named it, which notes that even a request to load an image can carry stolen data (Is It Safe to Let AI Agents Read External Web Pages?).

Detection helps and does not close the chain. Meta's LlamaFirewall describes PromptGuard 2 as "a universal jailbreak detector that demonstrates clear state of the art performance" and reports that its alignment checker "shows stronger efficacy at preventing indirect injections in general scenarios than previously proposed approaches" (Chennabasappa et al., 2025). Progent, a privilege-control approach, reports that it "significantly reduces attack success rates while maintaining high utility" (Shi et al., 2026). Reduced is the operative word in both. A session the agent never held is the only version of the scenario in which a missed injection collects nothing.

What does a separate profile change, and what does it not?

A separate profile removes the session from the agent's reach. The record scenario is the docs in one profile and GitHub in another: the agent attaches to a profile that has never signed into github.com and holds no saved password for it. An instruction in the docs to open GitHub then lands on a login page, and the agent has nothing to type.

What it does not change is the agent's reading, or the question of how the agent reaches GitHub when the task needs it. The documented answer is a token the agent uses but does not hold. GitHub advises choosing "the minimal permissions necessary for your needs" and says personal access tokens (classic) "are less secure" (GitHub, Managing, 2026). A fine-grained token for one repository, read-only, with a short lifetime, bounds what an injected agent can do in a way an inherited session does not.

Hosted sessions show the pattern at full strength. Anthropic's Claude Code documentation states that for its cloud sessions "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM. The VM holds a short-lived credential scoped to that session" (Anthropic, 2026). Firecracker's design documentation says it "is designed to assure secure isolation using multiple layers" and that "all egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level" (Firecracker, 2026). A separate profile is the small version of the same idea.

Setup Reach on GitHub What a docs page can make it do
Same profile, signed in The whole account Create tokens, change settings, push
Separate profile, no login Nothing Open a login page
Separate profile, scoped token One repository until expiry What the token allows

What does the leak record say about where GitHub credentials end up?

In repositories, and from well-resourced teams. GitGuardian, studying whether Copilot could surface real credentials, found that in its sample "over 1,200 leaked at least one secret" and that Copilot generated "3.0 valid secrets for one prompt on average" (GitGuardian, 2025). Neither figure is about browsing agents or says whether the credentials were still active. They set the baseline: public repositories already hold many leaked credentials, and an agent with push access to a signed-in account can add to them.

GitHub's own controls act on that push. In GitHub's words, push protection "acts as a frontline defense mechanism by scanning code for hardcoded secrets at the time of the push" (GitHub, Push, 2026). It does not see a token an agent typed into a form on another site. For Actions, GitHub advises setting the default GITHUB_TOKEN permission "to read access only for repository contents," pinning actions "to a commit SHA in your workflow files," and auditing "how secrets are used, to help ensure they're being handled as expected" (GitHub, Secure, 2026). Those habits translate to a browser agent: read-only by default, a pinned destination, and an audit of use.

The pattern repeats outside GitHub. AWS strongly recommends not creating access keys for the root user, which rules out the simplest way an agent might be given durable top-level power (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?), and a pipeline guide for S3 and GitHub settles authentication with OIDC (How to Set Up S3 and GitHub With Cowork or Dots). A signed-in session is the opposite of each: durable, top-level and unscoped.

What does a governed environment change?

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 tokens for the whole run, so the model works on placeholders. 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 tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this question it changes what the model reads when the task does reach GitHub. If the agent opens a token page, a repository secrets page or a settings page with a webhook secret shown, the model sees TOKEN_001 and not the string, and a docs page that tells it to copy the value out gets a placeholder. If the task needs a token used, the real value resolves at github.com at the moment a named person approves the action, and the approval and the token-only screen are both in the record. The separate profile and the governed environment work on different halves of the problem: the profile keeps the session out of the agent's reach, and the environment keeps the values on any page it is allowed to open out of the model's context.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a git push from a shell on the developer's machine is a separate control, and the choice of profile remains the developer's own.

Methodology and limitations

This page rests on three research preprints on browsing agents and agent defenses, vendor documentation from Browser Use, Skyvern, Anthropic, GitHub and the Firecracker project, two vendor research reports on leaked credentials, and existing RedactSure research pages. Sources were read between October 20, 2026 and October 21, 2026. Quoted facts are cited to the page that states them, and the leak figures are cited as the publishers report them, not as independently measured. The preprint abstracts cited here report no success rates or quantitative results, and the page does not supply any; the evaluations named in them were not re-run.

RedactSure did not test Browser Use, Skyvern or any browser extension hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader. Vendor features change, and the page carries its date. The tables summarize the documentation as read and are not configuration guides. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record scenario, a developer with library documentation in one profile and GitHub in another, and not an organization. The three-row setup table is reasoning about profiles and token scopes, not a measurement.

Determinations about whether a configuration 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 of the organization's own setup: attach the agent, open github.com, and record whether a login page or the account appears, repeated after each release of the agent and the browser.

What the record shows

The question answers itself once the two halves are separated. The docs are low-risk content; the session in the same profile is a credential the agent inherits without typing, and the research record shows that page content can steer an agent toward it. The two frameworks reviewed document placeholders for credentials they are handed and a domain restriction, not a control over a session that was open before they attached. GitHub documents the substitute, a fine-grained token scoped to specific repositories with minimal permissions, and the leak record shows why an unscoped session is worth removing. A separate profile removes the session; a scoped token bounds the return; a governed environment keeps the values on any page the agent does open out of the model. As a test before relying on that advice, a developer should pick one agent and one docs task, attach the agent, type github.com, and write down whether it was signed in.

Frequently asked questions

Is it safe to let an AI agent browse docs while I am logged into GitHub?

Reading the docs is safe. Being logged into GitHub in the same profile is the risk, because the agent inherits the session and a page in the docs can instruct it to use that session. Give the agent its own profile with no GitHub login, and if the task needs GitHub, give it a fine-grained token scoped to one repository rather than your account. Before trusting any setup, open github.com in the agent's profile and see whether it is signed in.

Does a browser agent use my open GitHub session automatically?

If it attaches to the profile that holds the session, yes, because the cookie answers every request and no password is typed. The pages reviewed for Browser Use and Skyvern describe placeholders for credentials the agent is handed and a domain restriction in Browser Use, not a control over a pre-existing session. Which profile an agent attaches to depends on the product and its configuration, so check the attach behavior of the one in use by test rather than by assumption.

What can a docs page actually make the agent do?

Whatever the agent's reach allows. Research on browsing agents demonstrates that untrusted web content can hijack agent behavior, with credential exfiltration among the findings. With GitHub signed in, that reach includes creating tokens, changing settings and pushing. With a separate profile and no login, it includes opening a login page and nothing more. The injection is the same in both cases; what differs is the value of what it finds, which is the variable the developer controls.

Is a separate browser profile enough on its own?

It removes the session, which is the main risk in this question. It does not change what the agent reads on the docs, and it does not help once the task needs GitHub, which is where a scoped token comes in. GitHub documents fine-grained tokens limited to specific repositories with minimal permissions and short lifetimes. Treat the profile as the first control, the token scope as the second, and a control over what the model reads on any page it opens as the third.

Should I use a fine-grained token or just sign in?

A fine-grained token, scoped to the repositories the task needs with the minimal permissions and a short lifetime, which GitHub's own documentation recommends over classic tokens it describes as less secure. Signing in gives the agent the whole account for as long as the session lasts. A token bounds what an injected instruction can do to one repository and a listed set of permissions. Keep the token where the agent uses it without reading it, such as a vault read at run time.

How does push protection fit in?

Push protection scans code for hardcoded credentials at the time of a push, so it catches a token committed into a repository the account can write to. It does not see a token an agent reads off a settings page and types into a form on another site, and it does not stop a push that contains no credential pattern. It is a control on one exit, the commit, and a complement to the profile and token-scope controls rather than a replacement for either of them.

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 GitHub Token Off the Page the Agent Reads

A docs page can steer an agent toward an open GitHub session, and the frameworks reviewed substitute placeholders only for credentials they are handed.

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

Before: the agent, reading a library's docs, follows an injected instruction to open github.com, creates a personal access token, reads it and pastes it elsewhere. Inside the governed environment: the token page renders TOKEN_001, the injection collects a placeholder, and the real value resolves at github.com only on a named person's approval.

RedactSure is deploying now with enterprise and government customers. Wiz found that 65 percent 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

Browsing documentation while signed in to GitHub puts your token one injected link away from the agent. Bring a documentation task your agent runs and see, with test values, what an injection would collect. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.