Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Skyflow LLM Privacy Vault Work for Browser Agents?
No. Skyflow's pages describe a vault that tokenizes what an application sends it, while a browser agent reads the rendered page of software that was never wired to call it, so check what the model receives on that screen and who approves the release.
An accounts payable agent opens a vendor invoice in the finance application the organization runs, reads the vendor name, the invoice number and the remit-to account, then submits it for approval. None of that work passes through a data vault, because the finance application was bought rather than built against one, and its invoice page is drawn from its own store.
Skyflow's vault is designed for the other path: an application calls it, its SDKs collect a value, and the original is held in an isolated store while a token stands in for it. The LLM Privacy Vault applies that pattern to model calls, for flows built against the vault. A browser agent reads the page the application renders, and what it draws enters the model's context with the rest of the run.
The difference matters at the point of payment. A remit-to account is the field invoice fraud changes, and a model that has read it can repeat it in a summary or the next form it fills. A team that bought a vault can ask whether it covers the screen, and the answer turns on where the product applies its control, not on how strong that control is.
Key findings
- For the vault to reach a browser agent, the values the invoice page draws would have to be replaced with consistent tokens before any model reads it, with real values released only at an approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each invoice submission and a record of what the model received on every screen, exported to the organization's monitoring (How Do You Send an AI Agent's Activity Record to Microsoft Sentinel or CrowdStrike Falcon?).
- Skyflow's tokenization page places collection in an SDK the application calls and tokens in the company's database; it does not state that values on a rendered page are replaced before a model reads them (Skyflow, Tokenization, 2026).
- Skyflow's LLM Privacy Vault offers "a secure framework for handling sensitive inputs and outputs," which describes flows built against the vault rather than a browser session a model works (Skyflow, Protect LLMs, 2026).
- A measured study of web agents found that they "are prone to inadvertent use of unnecessary sensitive information," the exposure an invoice page creates (Zharmagambetov et al., 2025).
- A vault tutorial shows the other custody model: "Token lifetime is reduced from days or weeks to minutes," and a wrapper script "exports it as VAULT_TOKEN, and launches the agent," which puts the token in the agent's process environment (HashiCorp, 2026).
Where does Skyflow's control sit when an agent opens an invoice screen?
Two paths reach the same invoice, and only one passes a vault.
The first is the integration path. An application calls Skyflow when it has a value to protect: "Skyflow provides SDKs that can help you securely collect sensitive data client-side," its tokenization page says, and the token is then "stored in the company's operational database while the original data is stored in a secure, isolated data store," with Connections helping a team "use tokenized data in downstream APIs" (Skyflow, Tokenization, 2026). The LLM Privacy Vault applies that placement to a model call: the application sends its prompt to the vault, the vault substitutes the values, and the model receives the substituted text.
The second path is the screen. The agent opens the invoice queue and reads the page the application renders. No SDK sits between that page and the model, and no vault access request runs when the browser paints a field.
The difference is a matter of path: a filter at an API reaches the fields an integration sends and does not by itself reach a value that appears only on a rendered page (Screen-Level Tokenization vs API Filtering for AI Agents).
So the control sits at the boundary of an application that calls it.
Across 86 AI security and data protection products, none describes, in its public documentation, reversible tokenization of what an agent reads on a screen; the vaults in that set are documented as sitting inside pipelines an application calls, the path an invoice screen never takes (How Many AI Security Products Control What an AI Agent Sees?).
What does a browser agent receive from a screen the vault never sees?
The page, field by field. An agent that opens the vendor invoice reads the vendor name, the invoice number, the remit-to account, the amount and the payment terms, and each value enters the model's context as text. A browser agent captures the page it works, so a field the application displays is a field the model receives.
The OWASP list for agentic applications names "Agent Goal Hijack" and "Tool Misuse" among its top risks, and an invoice screen is where both land (What Is the OWASP Top 10 for Agentic AI?). A line of text that tells the agent to change the remit-to account is a goal hijack with a form attached.
Stripe's documentation shows the same shape with a shorter window: a live key is displayed "one time," so the page that creates it is the page where an agent reads it (Can an AI Agent Manage My Stripe Keys Safely?).
Substitution need not break the work: consistent pseudonyms, restored afterward, "reduce semantic utility errors by a factor of 5 compared to baseline techniques" (Serenari and Lee, 2025). An agent can chase an invoice whose vendor reads VENDOR_001 and whose account reads ACCT_001, and a clerk reviewing the run sees the same tokens.
What do the vendors themselves say?
De-identification describes inputs rather than a browser: "De-identification locates sensitive information like PII, PHI, and PCI from text, PDFs, images, and audio files and then redacts that information with tokens" (Skyflow, De-identify, 2026). The inputs are content the application submits, not a page an agent reads.
| Dimension | Skyflow, per its documentation | What a buyer should verify |
|---|---|---|
| Where the control sits | "Skyflow provides SDKs that can help you securely collect sensitive data client-side" (Skyflow, Tokenization, 2026) | Whether the invoice application calls the vault at all |
| What it covers | "De-identification locates sensitive information like PII, PHI, and PCI from text, PDFs, images, and audio files and then redacts that information with tokens" (Skyflow, De-identify, 2026) | Whether the page an agent reads is one of those inputs |
| What the model receives | "Guardrails for AI interactions control LLM inputs and outputs" (Skyflow, De-identify, 2026) | Whether the guardrail sits on the model call the agent makes |
| The record | "enforcing granular policies on every data access request in real time with minimum latency" (Skyflow, Governance, 2026) | Whether the record shows the page the agent read |
Every row acts on a request to the vault, and none describes a rendered page.
What does a credential vault hold that a page never touches?
The class is easiest to see in a vault built for credentials rather than for records. Its designs bound the values the store itself issues or holds, with a lifetime, a scope and a policy on each retrieval. AWS's AgentCore Identity blog describes the shape for its token vault, built to "Securely store OAuth 2.0 Access and Refresh tokens, API keys, and OAuth 2.0 client secrets," with the agent retrieving them under its own workload token (Douglas III, 2025).
Each design answers three questions about a value the store controls: who may fetch it, for how long, and from where. A value on a rendered page answers none of them: a console that prints an API key in full keeps no lease, and the key is in the model's context for the rest of the run (What Happens When an AI Agent Can See API Keys in a Console or Settings Page?). Skyflow's governance page draws the same boundary from its side, since a policy governs access to the vault, which is a retrieval and not a render.
A vault is the right place for a credential a task needs to use, and a screen control is the right place for a value a task needs to see, which is why the two are bought for different jobs. Neither one covers the other's ground.
What should a team ask for in writing about the screens agents read?
Four commitments decide whether the screen path is covered, and each one is a question a buyer can put to a vendor in writing.
First, whether the application the agent works calls the vault. A bought invoice system is covered only if someone integrated it.
Second, where a real value is released. The point is concrete: a private adapter outside the agent's sandbox holds the credential, makes the call and returns only the result (What Is a Private Adapter for AI Agents?). A release into the model's context is a different design from a release into a form.
Third, what the model receives from a rendered screen: whether the values the page displays are replaced with consistent tokens before the model reads them, or whether the model sees the account number as the application drew it.
Fourth, who approves the action and what record follows it. The obligation does not change with the tool: "FINRA intends for its rules and guidance to be technologically neutral," so an agent reading a screen sits under the same supervision duties as a person doing the work (FINRA, 2024). The record should let a supervisor see what the model read, not only that a rule existed. Ask each question before the pilot, and keep the answer beside that run's transcript.
What does a governed environment change?
A governed environment changes three things on the invoice path.
First, the render. Values chosen by policy are replaced with consistent tokens before any model reads the page, so the invoice shows VENDOR_001 and ACCT_001 for the whole run. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. The token is stable, so the agent can still match the invoice to the purchase order.
Second, the release. Real values resolve only at approved destinations, at the moment of an approved action, so the account number reaches the payment instruction a person approved, not the transcript.
Third, the record. A named person approves each payment, submission and record change, and every screen as tokens, every action and every approval lands in a record that exports to the organization's own monitoring.
A filter added to the run is not the same as a value that never reached the model: adaptive attacks bypassed 12 published defenses with "attack success rate above 90% for most" (Nasr et al., 2025).
None of this replaces a vault, so a team running agents in bought applications usually needs both controls, at different points in the same run. The comparison for this vendor sets the two placements out row by row (RedactSure vs Skyflow: 2026 Comparison & Alternative).
What the record shows
On the invoice path, the control that decides exposure sits where the page is rendered, and the record that proves it names the person who released the value. Skyflow's pages describe a vault that applications call: collection through an SDK, an original in an isolated store, a token in the operational database, and a policy on each access request. Those controls govern what reaches the vault and stop at the boundary of an application that calls it. Placement decides the answer here, and the strength of either design does not change it. A team can check its own case in an afternoon. Pick one agent task that reads a vendor invoice, run it with a test record, and compare the fields the page displayed with the fields the vault logged. If the account number appears in the first and not the second, the screen path is ungoverned.
Methodology and limitations
This page rests on Skyflow's documentation for tokenization, governance, de-identification and the LLM privacy pattern, HashiCorp's agent permissions tutorial, AWS's AgentCore Identity blog, FINRA's regulatory notice, and three research papers. Vendor pages were read between October 21, 2026 and October 23, 2026, and each Sources line carries the date for its page.
No product on this page was tested for it, and "not described in the pages reviewed" means the pages recorded here, not a claim about what a vendor cannot build. Vendor features change, so the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a vendor invoice in a finance application, not an organization.
Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Does Skyflow LLM Privacy Vault work for browser agents?
No. The vault tokenizes data an application sends it: a value collected through its SDKs, a document submitted to its de-identification API, a token exchanged in a downstream call. A browser agent does not send the page it reads anywhere. It opens the invoice in a finance application the team bought, reads what that page draws and acts on it, so the vault holds nothing for that screen and its policies never run.
Does the vault see the screen a browser agent reads?
No. The vault sees what an application or a pipeline sends it, and a rendered page is not one of those inputs. Skyflow's tokenization page describes collection through its SDKs and a token exchanged in downstream APIs, and its de-identification page covers text, PDFs, images and audio submitted to its APIs. The invoice page is drawn by the finance application from its own record, after any vault call has already finished.
What does the model receive from an invoice page that never calls the vault?
Whatever the page displays. The vendor name, the invoice number, the remit-to account, the amount and the payment terms all enter the model's context as text, along with any note the page shows. Research on web agents finds they are prone to using sensitive information they do not need for the task. Nothing in that path separates a field the agent needs from a field it can merely see.
Where is a real value released, and who approves it?
At the destination the workflow names, at the moment a person approves it, if the environment is built that way. In a vault design, a release is a call the application makes and a policy checks, so there is no approver at that step. A payment instruction needs a person's name against it, and the release has to be tied to that approval rather than to the task.
What record shows what the agent read on the screen?
A vault record will not. The governance page describes "enforcing granular policies on every data access request in real time with minimum latency," and the access request it governs is a retrieval from the vault, not a page an application renders (Skyflow, Governance, 2026). The record that answers the screen question lists what the model received, screen by screen, with the action and the approver beside it. Ask for that export before the pilot.
Can a team make the vault cover a screen it cannot rebuild?
Only by putting a control between the page and the model. An application the team cannot change will not call the vault, and no policy on a vault request reaches a page drawn from the application's own store. The practical route is an environment that renders the page with tokens and releases real values only at approved destinations. Ask a vendor to show one screen before and after.
How RedactSure Covers a Page the Vault Never Reaches
A browser agent reads a page the vault was never asked about, so the invoice's account number reaches the model anyway. Skyflow's tokenization page puts collection inside SDKs an application calls, a control over the application and not over the page it draws (Skyflow, Tokenization, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the page draws the vendor's name, the invoice number and the remit-to account, and the model reads all three. Inside the governed environment, it draws VENDOR_001 and ACCT_001 for the whole run, and the real account number resolves only into the payment instruction a named approver releases.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
An invoice agent that reads a remit-to account puts the value in every summary it writes. Bring one invoice task and see, with test values, the page as the model receives it, the approval and the record. Book a demo