Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Stop a Browser Agent From Seeing the Token It Creates?

Only by changing what the browser renders to the agent: a control at the render layer detects the token as the page reveals it, stores it under your key and shows the agent a reference. Profile hygiene and allowlists do not help, because the token appears on an allowed page in your own profile.

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

Security teams that let a browser agent create a token carry an exposure at the moment of reveal: the agent reads the page that prints the new value, and nothing above the page can stop that read. The answer to the title question is a single control placed at the point where the page is drawn: the new value is recognized as it appears, replaced in the agent's view with a reference, and kept under the organization's own key so that the real string is released only to the destination a person has approved. The controls most teams reach for first, a clean browser profile, a separate account and a list of permitted sites, govern where the agent may go and what it may hold on disk. They do not govern what the model receives from a page the agent is allowed to open, and the token page is exactly such a page. This page works through one record type, a token settings page on a developer platform where an agent has just clicked "generate." Neither the vendor documentation nor the research record reviewed here covers what that page renders to the model, so the team that approved the agent should place the control there itself. What Can an AI Agent See in Your GitHub Settings? covers the settings pages themselves; this page takes only the moment a token is born.

Key findings

  • A study of browsing agents reports findings that "include prompt injection, domain validation bypass, and credential exfiltration" and demonstrates "how untrusted web content can hijack agent behavior," which places the token page within reach of content the agent did not ask for (Mudryi et al., 2025).
  • OWASP's non-human identity list defines NHI2 Secret Leakage as the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores," and a model's context is such a store (OWASP, 2025).
  • HashiCorp's Vault documentation describes response wrapping, in which "a new single-use token is generated with the TTL supplied by the client," a design that moves a credential through a holder that never reads it; the page covers delivery from Vault and not what a browser shows (HashiCorp, Response, 2026).
  • Anthropic documents that in its cloud sessions GitHub credentials "never enter the session VM" and that the VM "holds a short-lived credential scoped to that session," a custody design for one credential that does not describe what a browser page renders (Anthropic, 2026).
  • A governed environment replaces a credential with a consistent token before any model reads the screen, so the agent that created the value works with a reference and never holds the string (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, so the token reaches the service that needs it and not the transcript, the log or the next page (What Is the PII Wall?).

What does a governed browser environment cover when a token is created?

The scope needs stating at the outset, because the answer on this page is narrower than the word "agent" suggests. A governed browser environment covers what the agent reads and does on a rendered page: dashboards, consoles, settings pages and sign-up forms, including the page that displays a newly generated token. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A coding agent that creates a token by calling an API from a shell is outside this page; a browser agent that clicks through a settings page is inside it.

The record type is a token settings page. The agent is asked to set up a deployment and needs a token for it. It opens the settings page in a browser, names the token, picks a scope and clicks the button. The page then does what every such page does: it prints the value once, with a warning that it will not be shown again, and the agent reads it. From that moment the value is in the model's context, where it can be repeated in a reply, pasted into a configuration file, written to a log or sent to any site the agent later visits.

The moment of reveal is the whole problem. The agent needed the page to create the token, so the page was permitted. The agent needed to be signed in, so the profile held a session. Every control that acts before the page, at the account, the profile or the allowlist, has already said yes by the time the value appears. What Can an AI Agent See in Your GitHub Settings? notes that the platform tells users to treat tokens like passwords, so the page the agent reads holds password-equivalent material. The question is what the agent is shown at that moment, and only a control at the render layer answers it.

Why do profile hygiene and allowlists not help?

Each of the usual controls answers a different question than the one asked here. A fresh browser profile with no saved passwords limits what the agent inherits. A dedicated account with narrow permissions limits what the agent can do, the pattern described in Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?, where the guidance to use the most powerful account only when needed applies with more force to an agent. An allowlist of sites limits where the agent can go. All three are worth having. None of them changes a single character of what the token page renders.

Control Question it answers What it does at the moment of reveal
Clean browser profile What does the agent inherit from earlier sessions? Nothing; the token is created in this session
Dedicated account, least privilege What can the agent's identity do? Nothing; the account was permitted to create the token
Site allowlist Where can the agent navigate? Nothing; the settings page is on the list
Render-layer substitution What does the model receive from the page? Replaces the value with a reference before the model reads it

Least privilege still matters, because it bounds what a leaked token can do. The federal control catalog treats it as a standing requirement, and applying it to an agent means the account, the permitted actions and the visible data are each held to what the task requires (How Does Least-Privilege Access Reduce Risk With AI Agents?). OWASP lists overprivileged identities as NHI5 on the same list that carries secret leakage as NHI2 (OWASP, 2025). The two risks are separate, and a control for the second one is what this page is about.

What do the vendors themselves say?

HashiCorp's Vault documentation introduces response wrapping with the sentence "To help address this problem, Vault includes a feature called response wrapping," so an intermediary carries a single-use wrapping token rather than the credential; the page concerns delivery from Vault, not a browser page (HashiCorp, Response, 2026). HashiCorp's agent tutorial says "token lifetime is reduced from days or weeks to minutes," while its wrapper script exports the delegated token as an environment variable before launching the agent, so the agent process holds the raw value (HashiCorp, Secure, 2026).

OpenAI's Codex documentation states that "locally, Codex uses an OS-enforced sandbox that limits what it can touch (typically to the current workspace)" and that "by default, the agent runs with network access turned off"; these govern files and commands, and the page does not say how a credential is handled locally (OpenAI, 2026).

Anthropic's Claude Code security page states that "the boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can," and, for its cloud sessions, that GitHub credentials "are stored encrypted on Anthropic's servers and never enter the session VM"; the custody design covers Anthropic-hosted sessions, not a browser page (Anthropic, 2026).

Microsoft's managed identities documentation states that "managed identities eliminate the need for developers to manage these credentials," which removes the token page from an Azure workflow and not from a third-party platform that prints a value (Microsoft, 2026). A control over what a browser page renders to a model is not described in the pages reviewed.

What does the research record say about browser agents and credentials?

The research on browsing agents treats credential exposure as a demonstrated outcome and not a hypothetical one. Mudryi, Chaklosh and Wojcik report findings that "include prompt injection, domain validation bypass, and credential exfiltration," and show "how untrusted web content can hijack agent behavior" (Mudryi et al., 2025). An agent that holds a fresh token in context and then reads a page it did not write can be told what to do with the token.

Two defensive lines of work show where the field has placed its controls. Meta's LlamaFirewall includes PromptGuard 2, described as "a universal jailbreak detector that demonstrates clear state of the art performance," and the authors report it "shows stronger efficacy at preventing indirect injections in general scenarios than previously proposed approaches" (Chennabasappa et al., 2025). Progent puts privilege control on tool calls, and its authors report that it "significantly reduces attack success rates while maintaining high utility" (Shi et al., 2026). Both act on the instruction or the action, and neither changes what the model was shown on the page before the input arrived.

The supply chain record gives the destination side. Sonatype reported that "56% of the malware discovered in Q1 2025 was related to data exfiltration," which it called "a dramatic increase from 26% in Q4 2024" (Sonatype, 2025). The figure covers packages, not browser agents, and gives no number for credential theft. It shows what the code a project pulls in is mostly for, which a freshly read token would meet next. Material reaching an agent exactly as it reaches a user is the pattern described for employee data in How Do You Stop an AI Agent From Seeing Employee Personal Information?.

How do you change what the browser renders to the agent?

The answer is one mechanism with three parts, and each part is checkable. First, detection at the render layer: when the settings page prints the new value, the environment recognizes it as a credential before the model reads the screen, by the field it appears in and by the shape of the string. Second, substitution: the model's view carries a reference such as TOKEN_01 in place of the value, and the same reference stands for the same value for the whole run, so the agent can paste it into a configuration form or name it in a reply without ever holding the string. Third, custody and release: the real value is stored under the organization's own key, and it is resolved only at the destination a named person has approved, at the moment of the approved action.

The record scenario reads like this. The agent clicks "generate." The page renders the token. The model receives TOKEN_01. The agent pastes TOKEN_01 into the deployment settings form on a second permitted page. A person approves the submission. The form reaches the service with the real value, the agent's transcript shows TOKEN_01 throughout, and the record of the run shows the page as the model saw it, the action and the approver's name. The same shape governs an API key the agent must manage without reading, the case worked through in How Do You Let an AI Agent Manage API Keys Without Reading Them?, where a report of GitGuardian data counted tens of millions of credentials exposed in public commits in one year.

Three checks tell a team whether a vendor's control is this one. Does the model's transcript for a token-creation run contain the token, or a reference? Does the reference stay consistent across pages in the run? And does the real value leave custody only on an approved action, with a record of who approved it? A control that fails the first check is acting somewhere other than the render layer, and the hygiene table above says where.

What does a governed environment change?

A governed environment is a control class that acts where a page is rendered, before any model reads it. Values chosen by policy, including a credential that appears for the first time, are replaced with consistent tokens for the whole run, so the model works on references. 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 the token page, it changes the one thing the other controls leave alone. The agent still creates the token, because the task requires it, and the page still prints the value, because the platform requires that. What differs is the agent's view: the value never enters the model's context, so there is nothing to repeat, paste, log or hand to a hostile page. The profile, the account and the allowlist keep their jobs, which are to bound where the agent goes and what its identity can do, and the render-layer control adds the job none of them had.

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 from a shell or an SDK is outside it and stays with the sandbox, the permission rules and the credential store a team configures for its coding agent. For a token created on a page, the control sits in the one place the page cannot route around.

Methodology and limitations

This page rests on three research preprints on browsing agents and agent defenses, vendor documentation from HashiCorp, OpenAI, Anthropic and Microsoft, OWASP's non-human identity list, one vendor research release on malicious packages, 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 press and vendor releases are cited as reported, not as independently measured.

RedactSure did not test any of the named products hands-on. "Not described in the pages reviewed" means those pages and nothing broader, and it is used once in the body, for a control over what a browser page renders to a model. Vendor features change, and the page carries its date; a reader should treat a release after that date as unreviewed until the test below is repeated. The research preprints are cited for their stated findings and not for success rates, which the abstract pages do not give. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a token settings page on a developer platform, and not an organization.

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 on the reader's own platform, with a disposable token, of what the model's transcript holds after a creation run, repeated after each release of the agent or the environment.

What the record shows

The question has one answer and several non-answers. A browser agent that creates a token reads the page that prints it, and the profile, the account and the allowlist have all consented by then. The vendor documentation reviewed describes custody designs for credentials in transit and in a cloud session, sandboxes for files and commands, and identities that remove the credential from an Azure workflow; none of it describes what a browser page renders to a model. The research record shows credential exfiltration as a demonstrated outcome for browsing agents, and defenses that act on the input or the action rather than the view. The one control that answers the question acts at the render layer, which is where a governed environment places it. A disposable token gives a team a direct test: have the agent create one, then read the transcript, and if the string is there, the control is somewhere else.

Frequently asked questions

How do I stop a browser agent from seeing the token it creates?

By changing what the page renders to the agent. A control at the render layer recognizes the new value as the settings page prints it, replaces it in the model's view with a reference such as TOKEN_01, and stores the real value under your own key. The agent pastes the reference where the token is needed, a person approves the submission, and the real value reaches only that destination. Nothing that acts before the page, at the profile or the allowlist, does this.

Does a clean browser profile help?

It helps with a different problem. A profile with no saved passwords and no open sessions limits what the agent inherits from earlier work, which matters for the sign-in pages covered elsewhere. It does nothing at the moment a token is created, because the token belongs to this session and this page. Keep the clean profile for what it is good at, and add a render-layer control for the reveal, since the two address different moments in the same run.

Does a site allowlist help?

No, because the settings page is on the list. An allowlist governs where the agent may navigate, and the agent must reach the token page to do the task it was given. Once there, it reads whatever the page draws. The allowlist still limits where a stolen token could be sent by the agent itself, so keep it narrow and review it when the task changes. Treat it as a bound on destinations and not as a control on what the model is shown.

What about a vault that wraps the credential?

HashiCorp's response wrapping moves a credential through an intermediary that holds a single-use wrapping token with a client-supplied TTL, and its agent tutorial shortens token lifetime to minutes. Both are custody designs for credentials delivered from Vault. A token generated on a third-party settings page never passes through Vault on its way to the screen, so wrapping does not reach it. Shorter lifetimes shrink the damage window rather than the exposure, which is still useful.

Can prompt injection defenses cover this?

They cover the input, not the view. Detectors such as the one in LlamaFirewall flag a hostile instruction, and privilege controls such as Progent limit what a tool call may do. Both act after the model has read the page, so a token already in context is already exposed to whatever instruction gets through. The research record shows credential exfiltration as a demonstrated outcome for browsing agents, so the exposure needs a control of its own alongside any control on the instruction.

What should a security team ask a vendor in writing?

Ask for the model's transcript from a run in which the agent created a disposable token, and check whether the string appears. Ask whether the reference stays the same across pages in the run, who approves the action that releases the real value, and what record shows the page as the model saw it. A vendor whose answer describes the sandbox, the account or the allowlist has answered a different question than the one about the page, so ask again.

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 Hides a Token From the Agent That Created It

The profile, the account and the allowlist have all approved by the time the settings page prints the value, and the custody designs reviewed cover stores only.

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

Before: the agent clicks generate, the page prints the value, and the model holds it, to repeat, paste or hand to a hostile page. Inside the governed environment: the model receives TOKEN_01, pastes it into the deployment form, the named person approves the submission, and the real value reaches the service alone.

RedactSure is deploying now with enterprise and government customers. HashiCorp's agent tutorial exports the delegated token into the agent's environment.

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

See it on your own workflow

A token the agent just created is the easiest one for it to leak. Bring a token setup your team performs 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.