Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Capture a Token the Moment It Appears on Screen?

With a browser control that recognizes the credential as the page renders, encrypts it to a key the agent does not hold and substitutes a token before the agent's view is built; nothing that runs after the agent has read the page can take the value back. Check which component builds the view and what the first frame contained.

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

For a team running a browser agent against token settings pages, exposure is decided in a single frame: the one in which a settings page draws a newly generated token. A credential appears on screen once in a form that matters, and if a browser control recognizes the string in that frame, stores it under a key the agent cannot use and draws a placeholder in its place, the agent's view never contains the value. If the control runs any later, after the view has been assembled and the model has read it, the value is already in context and every later step is cleanup rather than capture. The scope is the render frame, which is a browser event, so the terminal, the IDE and direct API calls are outside it. Within that scope the page reads the research record on what a model does with a value it has read, then what GitHub, HashiCorp and Firecracker document, each of which acts at a different boundary. It lays out capture at render time step by step against one record type, the render frame in which a fine-grained token first appears on a token settings page, with a timeline table, and it closes with a test a team can run on its own agent and a neutral statement of the control class.

Key findings

  • A study of prompt injection against agentic coding editors reports that "attack success rates can reach as high as 84% for executing malicious commands," so a credential already in the model's view is reachable by whoever controls the next page it reads (Liu et al., Your, 2026).
  • GitGuardian's test of GitHub Copilot across public repositories found that "over 1,200 leaked at least one secret" (GitGuardian, 2025).
  • GitHub's push protection documentation states that "push protection acts as a frontline defense mechanism by scanning code for hardcoded secrets at the time of the push," which is capture at the commit boundary, after the credential has been typed into a file (GitHub, Push, 2026).
  • HashiCorp's documentation states that "to help address this problem, Vault includes a feature called response wrapping," a way to deliver a credential to its consumer without exposing it to the intermediary that carried it (HashiCorp, 2026).
  • A governed environment that replaces a credential with a consistent token before any model reads the screen is the only control that acts in the render frame itself, so the agent works with GITHUB_TOKEN_01 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 a token captured at render reaches the one field a named person approved and nothing else the agent writes (What Can an AI Agent See in Your GitHub Settings?).

What does a governed browser environment cover when a credential first renders?

The scope comes first because "on screen" means one thing here. A governed browser environment covers what an agent reads and does on a rendered page: dashboards, consoles, settings pages and sign-up forms, including the token settings page where a new credential is drawn for the first time. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A credential that arrives as an environment variable in a shell, a line in a file the agent reads, or a JSON field in an API response never passes through a render frame, and a browser control cannot capture it. Those routes belong to sandboxes, credential stores and permission rules.

The record type for this page is the render frame in which a fine-grained personal access token first appears on a token settings page. The sequence is short. The agent clicks the generate button, the server returns the page, the browser lays it out, and a text node containing the token becomes part of the document. The agent's view is built from that document, as a screenshot, an accessibility tree or a DOM serialization, and the model reads the view. There is one moment between the text node existing and the view being built, and that moment is the only place a capture can happen before the model has the value. GitHub tells users to treat access tokens like passwords, so the page in that frame carries password-equivalent material (What Can an AI Agent See in Your GitHub Settings?).

Every established layer of the security stack finishes its work before a page renders, because until recently nothing but a person read a rendered page (What Is Render-Layer Tokenization?). The question in the title is therefore about a layer that did not need to exist until an agent started reading screens, and the sections that follow describe what it has to do and when.

Why is capture too late once the agent has read the page?

Because a model reproduces what it has read. GitGuardian's test reported that "Copilot generates 2702/900 = 3.0 valid secrets for one prompt on average," a measure of how readily a model reproduces a value it has read (GitGuardian, 2025). The post does not confirm whether the extracted credentials were still active, so the figure is cited for the pattern and not for a live-key rate. A token that enters the context during one page load can be repeated in a summary, written to a transcript, or pasted into a configuration file.

The second reason is that the context is attackable. The study of coding editors that reached 84 percent success for malicious commands did so through content the agent read, which is the same channel a token settings page uses. Agent Security Bench reports that "our benchmark results reveal critical vulnerabilities in different stages of agent operation" (Zhang et al., 2025). The same benchmark found "limited effectiveness shown in current defenses," which is the record a buyer should weigh against any promise to catch a leaked credential after the fact (Zhang et al., 2025). Its abstract does not say which defense did best or by how much.

Post-hoc controls therefore race the model. The benchmark by Liu, Jia, Geng and colleagues ran "a systematic evaluation on 5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks" (Liu et al., Formalizing, 2024). The authors describe the work as "a common benchmark for quantitatively evaluating future prompt injection attacks and defenses," which is a yardstick for defenses that act after the model has read the page (Liu et al., Formalizing, 2024). None of those defenses change what the model was shown; a capture in the render frame removes the value from the contest.

What do the vendors themselves say?

The vendor pages reviewed describe captures at three boundaries, none of them the render frame.

Dimension Per the vendor documentation What a buyer should verify
GitHub Actions add-mask on the log; GITHUB_TOKEN read-only by default Whether the value existed in the job before the mask
HashiCorp Vault Response wrapping, single-use token with a client-supplied TTL Delivery from a vault, not what a page renders
Firecracker Isolation in multiple layers; guest egress filtered at the host Where data can go, not what the model reads inside the guest

GitHub's credentials documentation tells workflow authors to "mask all sensitive information that is not a GitHub secret by using ::add-mask::VALUE," a mask applied to the log after the value has already existed in the job (GitHub, Using, 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 limit on what a captured token can do rather than on whether it is captured (GitHub, Secure, 2026).

With response wrapping, "a new single-use token is generated with the TTL supplied by the client," so the intermediary holds a token that unwraps once and the credential itself stays out of its view (HashiCorp, 2026). That is the closest documented relative of capture at render, but it describes delivery from a vault, not a page, and gives no default or maximum TTL. Firecracker's design document states that "Firecracker is designed to assure secure isolation using multiple layers," isolation of the process rather than of the values a page renders inside it (Firecracker, 2026). The same document states that "all egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level," a control on where data goes and not on what a model inside the guest reads (Firecracker, 2026). A render-time capture is not described in the pages reviewed.

How does capture at render time work, step by step?

Capture at render has five steps on the record type above, and the order is the mechanism.

First, the browser control sits between the document and the view. It is part of the environment that draws the page, not a plugin the agent calls, so it sees the text node at the moment it is laid out. Second, it recognizes the credential by policy: the shape of a token, the field it appears in, the page it appears on. Third, it encrypts the value to a key held by the environment and not by the agent, and stores it against a stable name such as GITHUB_TOKEN_01. Fourth, it draws the name in place of the value, so the view that reaches the model, whether screenshot, tree or serialization, contains GITHUB_TOKEN_01 and never the string. Fifth, when the agent later submits the name to an approved destination, a credentials field in a deployment console for instance, the environment resolves the real value into that one field at the moment a named person approves the action.

Every other documented mechanism sits later on the timeline. Push protection reads the file at the push, log masking reads the job output, and scope limits and audits govern a token already captured by someone. A credential store removes the value from the agent's process and says nothing about the page, which is why a key the agent manages through a console still needs a page-level control (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

Moment on the timeline Mechanism What the model has by then
Text node laid out, view not yet built Render-time capture and substitution A token name only
View built and read Transcript or output filter The value, in context
Value typed into a file Push protection at the push The value, in context and on disk
Job emits output add-mask on the log The value, in the job and the context
Token used Scope limit, audit The value, already captured

How should a team test that the credential was captured before the view was built?

Name one agent, one token settings page and one disposable token, generate it through the agent and keep three things: the view the model received for the frame in which the token appeared, the transcript, and the field where the token was later used. The view decides the question. If the view contains the string, the capture ran after the view was built or not at all. If it contains a name such as GITHUB_TOKEN_01, check that the same name appears on every later page that displays the token, since a capture that covers the generation frame and not the list of existing tokens leaves a second frame open.

Then test the resolution step: have the agent place the name into an approved field and confirm the real value arrived there and nowhere else, that a person approved the action, and that the transcript still shows the name.

The wider record shows why the test is worth an hour. Wiz's exposure report states "we looked at 50 leading AI companies and found that 65% had leaked verified secrets" in public repositories (Wiz, 2025); the report does not state how many of the 50 lacked a public code presence. GitHub also advises teams to "audit how secrets are used, to help ensure they're being handled as expected," an after-the-fact review that presumes a record of each use exists (GitHub, Secure, 2026). A console that shows access keys to the agent shows them to the model the same way (What Happens When an AI Agent Can See API Keys in a Console or Settings Page?), and a policy that only lives inside approved tools governs a minority of actual use (How Do You Keep Data Access Policies Consistent Across AI Tools?), so the test should be repeated on each console the agent touches.

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 such as GITHUB_TOKEN_01. 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 page's question, it is the only class that acts in the render frame. Capture at render changes the input, so there is no value to filter, scan or mask afterward. The agent that generated the token, the agent that lists tokens on a later page and the agent that pastes the name into a deployment field all see the same name, and a successful injection against any of them collects a name that is worthless outside the environment that issued it. The record is the second change. Push protection and log masking produce alerts; a governed environment produces a statement of what the model saw in each frame and the name of the person who approved each resolution. The sibling page How Do I Stop a Browser Agent From Seeing the Token It Creates? covers the profile and allowlist controls that do not reach the frame.

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 that arrives in a shell variable stays with the sandbox and credential store a team configures for its coding agent, and centralized credential management of the kind AWS documents for its agents is the matching control for that route (Does AWS Bedrock Keep Company Credentials Away From Agents?).

Methodology and limitations

This page rests on three research preprints on prompt injection against coding editors, benchmarked injection defenses and agent security, vendor documentation from GitHub, HashiCorp and Firecracker, two vendor research posts from GitGuardian and Wiz, and existing RedactSure research pages. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from research posts are cited as reported, not as independently measured. The five-step mechanism in the fourth section is a description of the control class, not of any vendor's product.

RedactSure did not test any of the named products hands-on. "Not described" means not described in the pages reviewed, and a vendor may document a behavior elsewhere. The vendor pages concern workflow logs, pushes, token scope, vault delivery and process isolation; none concerns a browser view, and the timeline table places them by what each page states about when its mechanism runs. Vendor features change, and the page carries its date; a reader should treat a release after that date as unreviewed until the test in the fifth section is repeated. The research preprints are cited for the findings their abstract pages state and not for rates those pages do not give; the coding editor study's abstract gives no trial counts or tool versions, and the benchmark abstracts report no result figures beyond those quoted. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, the render frame in which a fine-grained token first appears on a token settings page, and not an organization.

Determinations about whether a credential workflow meets a 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 agent against a disposable token on its own settings page, repeated after each release.

What the record shows

The title has one answer with a timing condition. A credential is captured the moment it appears on screen only by a control that sits between the document and the agent's view, recognizes the value in the frame where it is first drawn, stores it under a key the agent does not hold, and draws a name in its place. The vendor record describes captures at the push, in the log, at the vault and at the process boundary, each sound and each later than the frame. The research record shows why later is too late: models reproduce values they have read, injection through content reaches high success rates, and benchmarked defenses that act after reading show limited effectiveness. A governed environment of the kind RedactSure builds is the one class that acts in the frame. A team should run this test with one agent and one token settings page: generate a disposable token through the agent, then compare it with what the view the model received contained on the frame the token appeared.

Frequently asked questions

How do I capture a token the moment it appears on screen?

With a control inside the component that builds the agent's view. It has to see the text node when the page is laid out, recognize the credential by policy, encrypt it to a key the agent cannot use and draw a stable name such as GITHUB_TOKEN_01 where the value would have been. Anything that runs on the view, the transcript or the log is already behind the model. The place to look is the frame, and the question to ask is who builds the view from it.

Can a transcript filter or output classifier do the same job?

No. Both run after the model has read the page, so the value is in context when they act, and the benchmarks reviewed here report limited effectiveness for defenses at that point. A filter can stop one copy of the string from reaching one log; it cannot stop the model from using the string in the next step, repeating it in a summary or following an injected instruction to send it elsewhere. Treat those tools as a second layer behind a render-time capture, not as a substitute for it.

Does GitHub's push protection capture the credential early enough?

It captures it at the push, early for a repository and late for an agent. The value was typed into a file before the scan ran, so it was in the model's context before it was in the file. Push protection stops the commit from leaving; it does not change what the agent read on the settings page, and it never sees a token the agent does not write to a file. Keep it on, and treat an alert from it as evidence that an earlier capture was missing.

Is a vault with response wrapping the same thing?

It is the nearest relative. Response wrapping gives the carrier a single-use token and keeps the credential out of the carrier's view, the principle capture at render applies to a page. The difference is the surface: a vault delivers a credential it already holds to a client that asked for it, while a settings page draws a credential the server just made into a document the agent is about to read, and only a control in the browser sees that frame. Use both, each on its own route.

What should the agent see after the capture?

The same name on every page for the rest of the run. The generation frame, the token list, the confirmation banner and any field the agent pastes into should all show GITHUB_TOKEN_01, and the real value should appear only in the one destination field a named person approved, at the moment of approval. The transcript and any file the agent writes should carry the name as well. A capture that covers the first frame and not the later ones has moved the exposure rather than removed it.

Does this cover a token my coding agent gets in the terminal?

It does not. A governed browser environment covers the rendered page; a token exported as a shell variable, read from a file or returned by an API call never passes through a render frame. Those routes belong to the sandbox, the credential store and the permission rules a team configures for its coding agent, and the vendor guidance on token scope and credential use applies to them in full. Sort each token by the route it arrives on before choosing the control.

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 Captures a Token in the Frame That First Draws It

A credential is capturable once, in the frame where the settings page first draws it, and push protection, log masks and token scopes all act later.

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 returns with the token, and the string enters the model's view and the transcript. Inside the governed environment: the token is recognized at layout, encrypted to the customer's key and drawn as GITHUB_TOKEN_01 before the view is built; the real value enters one deployment field when a named person approves.

RedactSure is deploying now with enterprise and government customers. GitGuardian measured Copilot at 3.0 valid credentials per prompt.

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

See it on your own workflow

A token replaced after the page reaches the model is already in its context. Bring a task that generates a token and see, with test values, what the model reads when the page first shows it. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.