Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Skyflow Tokenize Data Before the Agent Reads the Screen?
No. Skyflow tokenizes values an application sends to its vault or API, so check what draws the screen the agent reads: where the application stores a Skyflow token the page shows a token, and where it stores a real value the model receives the real value.
A CRM holds a customer's Social Security number, an agent opens the record to change a mailing address, and the model receives what the page draws: the number in full, or a token such as SSN_001. Skyflow's tokenization sits in the vault an application calls, so the record an agent reads is protected only as far as the application that draws it. That gap decides what a security team verifies before an agent works a bought system, and it turns on the screen rather than on the vault.
The record on the screen depends on what the application stored. Where the CRM stores a Skyflow token in the Social Security field, the page draws a token and the model works the record as SSN_001. Where the CRM stores the number, the page draws the number and the model receives it. Screen-Level Tokenization vs API Filtering for AI Agents sets the two placements beside each other for the same record, and a security team should settle the question before an agent touches a customer record.
Key findings
- For an agent to work a CRM record as SSN_001, the value would have to be replaced on the rendered screen before the model receives it, which is a control on the display rather than on the data an application sends to a vault (What Is Render-Layer Tokenization?).
- It would also require a named person approving each record change and a record of what the model received, since a policy on a vault request supplies neither; OpenAI's governance paper calls human approval "a standard way to limit egregious failures" (Shavit et al., 2023).
- The pages reviewed stop at the data layer: no Skyflow page describes a token placed on the screen of a bought application before a model reads it (Skyflow, Tokenization, 2026).
- Skyflow's tokenization page states that "Tokens are pseudorandom and don't have exploitable value" and that they are "stored in the company's operational database while the original data is stored in a secure, isolated data store" (Skyflow, Tokenization, 2026).
- Skyflow's page for AI flows offers "a secure framework for handling sensitive inputs and outputs," a pattern for a request the application sends rather than for a page an agent opens (Skyflow, Protect LLMs, 2026).
- Swapping identifiers for consistent pseudonyms and restoring them afterward "reduces semantic utility errors by a factor of 5 compared to baseline techniques," the measured case for one token per value across a whole run (Serenari and Lee, 2025).
What does Skyflow tokenize before a model reads a record?
Skyflow tokenizes values that an application sends to it. Its tokenization page describes a scheme for applications built against the vault: "Skyflow provides SDKs that can help you securely collect sensitive data client-side," the token replaces the original in the operational database, and "Skyflow Connections help you use tokenized data in downstream APIs" (Skyflow, Tokenization, 2026). Nothing in that path runs when a browser paints a record for an agent.
A token in this sense is not a credential the agent holds. HashiCorp's Vault tutorial shows the other meaning: "Token lifetime is reduced from days or weeks to minutes" and a wrapper script "exports it as VAULT_TOKEN, and launches the agent," so the agent's process carries a short-lived credential (HashiCorp, 2026). That token authorizes a call. It does not change what a page renders, and a vault that issues it is not tokenizing the record the agent reads.
Both are called tokenization. One replaces a value at the data layer, the other scopes a credential at the process layer, and neither reaches a screen the organization did not build. A team that buys a vault and expects the CRM page to change has bought a control for a path its agent does not take. What Tools Tokenize Data Before an LLM Sees It? places the vault, the gateway and the render-layer control side by side as placements rather than quality tiers.
Of 86 AI security and data protection products reviewed for that screen step, none describes, in its public documentation, reversible tokenization of what an agent reads on a screen; the vaults in the set are documented as sitting inside a pipeline a team builds, not in the record as it is drawn (How Many AI Security Products Control What an AI Agent Sees?).
What does an agent receive when a CRM screen renders?
The agent opens the customer record the way a service representative does, and the browser draws the fields the CRM holds: the name, the address, the Social Security number, the note. The model receives the text of that page, so the question is what the application stored, not what a vault holds. If the CRM stores a Skyflow token in the Social Security field, the page draws the token. If it stores the number, the page draws the number, and the model receives it in full.
A published example shows the shape of a rendered account page: the university knowledge base says "The Account Summary page provides a high-level view of your student account, including:" the total owed, any holds and a payment portal (North Carolina Central University, 2026). An agent reading the same page receives the same values, and no vault stands between the drawing and the model.
The record type here is a CRM that stores real Social Security numbers, the common case in a system bought before agents. Filtering at the API covers the fields an integration sends, and it does not by itself cover a value that appears only on a rendered screen (Screen-Level Tokenization vs API Filtering for AI Agents).
What do the vendors themselves say?
The pages describe a data privacy vault, and they are specific about placement. The tokenization page describes collection and exchange inside an application built against the vault, and the de-identification page extends that work to files: "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).
| 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 application in the workflow calls the SDK |
| What AI flows receive | "a secure framework for handling sensitive inputs and outputs" (Skyflow, Protect LLMs, 2026) | What the model receives on a screen the vault never sees |
| Where the original lives | An isolated store holds the original, separate from the operational database | Whether a real value also sits in the operational database |
| Who approves | "Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC)" (Skyflow, Governance, 2026) | Whether a person approves a payment or record change |
| The record | Policy decisions on every data access request, with role and attribute rules | Whether the record shows what the model saw on the screen |
The pages agree on one point: the control acts on data an application hands the vault, and every benefit depends on the application calling it. The screen of a platform the organization did not build is outside that placement, which is a limit of where the control sits rather than a defect in the vault. A control on the rendered screen covers that read, and it is a different placement.
Who approves the release of a real value?
On Skyflow's pages, a policy answers: access to the vault is granted or refused by role and attribute rules on each request, which controls retrieval and does not put a person's name against a specific action; for a record change or a payment the name is what an auditor asks for (Skyflow, Governance, 2026).
OpenAI's governance paper makes the case for the person: human approval "is a standard way to limit egregious failures," and "Actions that can only be reviewed after the fact should be more easily reversible" (Shavit et al., 2023).
The record type shows where the question lands. An agent opens the CRM record, reads SSN_001 and proposes a change to the address; a person has to approve that change, and the approval needs to point at the token the model saw and the real value the change would touch. In a regulated workflow the obligation follows the data rather than the tool: FINRA states that it "intends for its rules and guidance to be technologically neutral," so a rule that governs a representative's change to a customer record applies when an agent makes it (FINRA, 2024). Work on financial services records shows the same shape (How Can AI Agents Process Personally Identifiable Information in Financial Services?).
What would a buyer ask a vendor to show in writing?
Ask what the model receives from a rendered screen, field by field, before a contract is signed. The answer separates a control on data from a control on reading.
- Where the value is replaced: on the page, before the model reads it, or in a call the application makes.
- What the model receives for the record: the number, or SSN_001, and whether the token stays the same for the run.
- Who approves a change: a named person, outside the model, per action.
- What the record holds: the screen the model read, its tokens, the action and the approver.
- What happens to clear text: the fields the application stores and draws without a token.
Each answer is checkable in a pilot of one workflow. A vendor describes a placement, and one customer record, opened by one agent, shows whether that placement covers the screen and what the model received.
An answer to all five in writing is a description of a placement. What Tools Tokenize Data Before an LLM Sees It? sets the categories beside each other, and What Is the PII Wall? describes why the gap between them persists. The last item is the one that decides a pilot: a team can tokenize every field it collects and still hand an agent a record drawn with the real number.
What does a governed environment change?
A governed environment changes what the model can receive, not only where data is allowed to go. The agent works in a session of its own, and the page it reads is drawn with consistent tokens: the customer appears as CUST_014, the Social Security number as SSN_001, and the same token follows the value across every screen in the run. Real values resolve only at approved destinations at the moment of an approved action, a named person approves every payment, submission and record change, and the environment exports a record of each screen, action and approval to the customer's system.
The placement is what separates this from a vault. A vault tokenizes a value an application sends it; a governed environment tokenizes the page an agent reads, in an application it did not build and cannot change. The categories are placements, not quality tiers, and a team can run both. The record is the part a security team can review after the run, screen by screen. The comparison for a data privacy vault sets the two beside a claims record (RedactSure vs Skyflow: 2026 Comparison & Alternative), and the browser-side alternative is set out in Enterprise Browser or Render-Layer Tokenization?.
What the record shows
Whether a model reads a Social Security number on a CRM record depends on what the page draws, and the page draws what the application stored. Skyflow's tokenization covers values an application sends to the vault: pseudorandom tokens, an isolated store for the original, SDKs for collection, and Connections for downstream use (Skyflow, Tokenization, 2026). A CRM that stores real numbers draws real numbers, so the model receives them and the vault's control never applies to the read. A buyer can test that on one record: open a customer record with the agent, capture what the model received field by field, then ask the application team where each field is stored; every field stored in clear text and drawn on the page is in the model's context, whatever the vault holds.
Methodology and limitations
Skyflow's four documentation pages, a Vault tutorial from HashiCorp, a university knowledge base entry, a FINRA notice, a governance whitepaper and a research preprint are the basis of this page. Vendor pages were read between October 21, 2026 and October 23, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control; where this page says a source does not describe something, it means the pages reviewed.
The products on this page are described from documentation; none was tested for this page, both products change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The customer record is an illustrative record type, not an organization. Compliance determinations belong to counsel, assessors and the organization's own security team, and nothing here replaces a pilot of one workflow on its own screens.
Frequently asked questions
Does Skyflow tokenize the data before the agent reads the screen?
No. Skyflow tokenizes values an application sends to its vault or API: its SDKs collect a value, the original goes to an isolated store, and a token stands in for it in the operational database (Skyflow, Tokenization, 2026). The agent's read is not that path. It opens the CRM page and receives what the application draws, so the screen shows a token only if the application stored one.
What does the model receive from a CRM record the vault never sees?
The text of the page as the browser draws it, including the customer's name, address and Social Security number when the application holds those values in clear text. No vault stands behind that page. A university's own description of its account summary page lists the total owed, any holds and a payment portal, all drawn by the application (North Carolina Central University, 2026).
Is a Skyflow token the same as a token on a rendered screen?
No. A Skyflow token replaces a stored value and keeps the original in an isolated store (Skyflow, Tokenization, 2026). A token on a rendered screen replaces the value as the page is drawn, before the model reads it, and the same token follows the value across screens. HashiCorp's Vault token is a third thing: a short-lived credential the agent's process carries, not a substitute for a value on a page (HashiCorp, 2026).
Who approves the release of the real value?
A person, in the design this record calls for. Skyflow's pages put policy in charge of vault access, with role and attribute rules on each request (Skyflow, Governance, 2026). A rule can refuse a retrieval; it does not name who agreed to a payment or a record change. For an irreversible action, the approval has to come from a person outside the model, with a name attached to the action and to the record the model read.
What record shows what the agent read?
Only a record made where the reading happened. Skyflow's governance page records policy decisions on data access requests, which shows what the vault allowed and not what the page displayed (Skyflow, Governance, 2026). A record that answers the question lists each screen the model read, the tokens on it, the action taken and the approver, exported to the customer's system. Without that, an auditor can see a retrieval and never see a read.
Does that leave a place for a data privacy vault?
Yes, for the flows an application owns: a vault collects a value, isolates the original and hands downstream systems a token, which is the right control for code the team writes (Skyflow, Tokenization, 2026). The agent reading a bought CRM is the case it does not cover, and that case needs a control on the rendered page. An organization running agents usually ends up with one of each, because the two placements answer different questions.
How RedactSure Answers the Screen Question in a CRM Record
Skyflow's tokenization covers the values an application sends to its vault, and the agent working a bought CRM never takes that path. Its page places collection in SDKs that "securely collect sensitive data client-side," a call the agent reading a bought record never makes.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the customer record under its own session, the page draws the Social Security number in full, and the model receives it. Inside the governed environment, the same record draws SSN_001, the token holds across the run, and the number resolves only when a named person approves the change.
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
One record replayed field by field shows whether the model received a Social Security number or a token, and what released the real one. Bring one CRM screen and see what the model reads and who signs the change. Book a demo