Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is Skyflow Enough to Let an AI Agent Work Patient Records?
No: an agent working a patient record reads the Epic screen the EHR renders, and Skyflow's pages place tokenization in applications built against its vault, not in the screen of software the practice bought. Check what the model receives from one patient screen and who approves the change it proposes.
A patient billing screen draws the guarantor's name, the balance, the statements and the payment options, and an agent sent to set up a payment plan or post a refund reads every one of those fields as the page paints. The data-security platform the practice bought sits somewhere else: it tokenizes values an application sends it, keeps the originals in an isolated store, and returns tokens to systems wired to call it. Between those two facts sits the coverage question, because the agent does not call the vault. It opens the EHR the way a billing clerk does, with the clerk's account, and reads the screen the EHR draws; the clerk's account is the one the practice provisioned, so the same permissions apply and the same page appears. A practice that has bought a vault may believe the record is covered, and that belief holds only for the path the vault sees. The record that decides the answer is a patient account screen in an EHR: what the model receives from it, what the application's own permissions change, and what an approval and a record have to add before the agent touches the account.
Key findings
- For an agent to work a patient record without reading the patient, the values on the screen would have to be replaced with consistent tokens before any model reads it, and the real name would resolve only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each record change the agent proposes, and a record of what the model received on each screen (Can Staff Use AI on Patient Records Without PHI?).
- Skyflow's published pages do not state that values on a patient screen are replaced before a model reads them; they describe tokenization inside applications built against its vault (Skyflow, Tokenization, 2026).
- Skyflow's tokenization page states that "Tokens are pseudorandom and don't have exploitable value", and that tokens sit in "the company's operational database while the original data is stored in a secure, isolated data store" (Skyflow, Tokenization, 2026).
- De-identification redacts "PII, PHI, and PCI from text, PDFs, images, and audio files" with tokens, which covers files sent to its API and not a bought EHR's screen (Skyflow, De-identify, 2026).
- Swapping identifiers for consistent pseudonyms and restoring them afterward "reduces semantic utility errors by a factor of 5 compared to baseline techniques", so the work on tokens holds up (Serenari and Lee, 2025).
What does an agent read when it opens a patient screen?
The record for this page is an Epic screen, and the fields are the ones an EHR draws for a patient account: the name, the date of birth, the member ID, the balance, the statement and the payment options. A patient billing page at one health system shows the guarantor, the balances, the statements and the payment options, and it offers proxy access so someone other than the account holder can view and manage a patient's account (Cleveland Clinic, 2026).
An agent reads that page the way the browser paints it: the text of the page, the values in the fields, and the pixels of a screenshot when the agent works from images. Nothing between the EHR and the model edits a field. The application draws the record, the browser renders it, and the model receives it, including parts the task does not need: a balance from an earlier visit, the note from the last call, the guarantor's address.
That is the difference between a screen and a database. A query returns the columns it names. A rendered page returns what the application decided to draw, and the model holds it for the rest of the run, in the transcript and the summary. Access to private data, exposure to untrusted content and the ability to communicate externally all sit in a session that opens a billing page (Is It Safe to Let AI Agents Read External Web Pages?).
What do the vendors themselves say?
Skyflow is a data privacy vault that applications are built against. Its tokenization page states that "Skyflow provides SDKs that can help you securely collect sensitive data client-side" and that Connections help a team "use tokenized data in downstream APIs" (Skyflow, Tokenization, 2026). De-identification "locates sensitive information like PII, PHI, and PCI from text, PDFs, images, and audio files and then redacts that information with tokens", with role-based controls over who sees masked, redacted or plaintext values (Skyflow, De-identify, 2026). For AI, the LLM Privacy Vault "reduces LLM risks by offering a secure framework for handling sensitive inputs and outputs" (Skyflow, Protect LLMs, 2026).
Each control begins at a call the application makes: an SDK, a file sent to an API, a prompt routed through the pattern. That is the pipeline a team builds, and it is covered where the team integrates it. An Epic screen is not one of those flows, and that case is not described in the pages reviewed.
The gap is not one vendor's: a review of 86 AI security and data protection products found no product describing, in its public documentation, reversible tokenization of what an agent reads on a screen; the vaults it counted are documented inside integrations a team builds, and an EHR screen is not one of them (How Many AI Security Products Control What an AI Agent Sees?).
| Dimension | Skyflow, per its documentation | What a buyer should verify |
|---|---|---|
| What it covers | Text, PDFs, images and audio files sent to its API, and prompts routed through its LLM pattern (Skyflow, De-identify, 2026) | Whether the EHR in scope is one of them |
| What the model receives | Not stated for a screen an agent opens | One patient screen, replayed field by field |
Does the EHR's own access control keep the record off the model?
An EHR does not open every record to every user. A student information system's knowledge base, read as a close analogue, tells administrators to "Review User Groups and Suggested Tool Rights as a starting point for assigning tools and rights to user groups", and it cautions that "These are suggestions" (Infinite Campus, 2026). The same catalog shows that SSNs display as "XXX-XX-XXXX" until a user is granted the right to view them, and that calendar rights are needed in addition to SSN rights (Infinite Campus, 2026).
Two limits decide what that work means for an agent. The rights decide which records the agent can open and, for a field the application masks, what the page draws; the agent signs in with the account the practice gives it, so it inherits that person's rights exactly. The record that opens is then drawn in full for that role: the name, the date of birth, the member ID and the balance are the page's ordinary content. A permission is a gate on the record, not a filter on the model's context.
There is an identity problem too. An agent working inside a person's session leaves the application's log recording the person, not the agent, and the OWASP list for agentic applications names identity and privilege abuse as a category (What Is the OWASP Top 10 for Agentic AI?).
What does a vault in the agent's own pipeline protect?
Before an agent can read a patient screen, it has to log in, and the credential it uses is the first thing a pipeline protects. HashiCorp's tutorial for agent permissions states that "Token lifetime is reduced from days or weeks to minutes" and that the agent "receives a token that is read-only, repo-only, scoped to a single secret, and short-lived" (HashiCorp, 2026). A wrapper script "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent", which places the token in the agent's environment (HashiCorp, 2026). AWS's AgentCore Identity token vault is built to "Securely store OAuth 2.0 Access and Refresh tokens, API keys, and OAuth 2.0 client secrets", and the agent retrieves them with its own workload token (AWS, 2025).
Both designs narrow how long a credential lives and where it is stored, and both leave the credential in the agent's process when it is used. That is the right place to solve the credential problem, and it is a different problem from the record: the token gets the agent through the login, and the page it reads afterward is the exposure.
A practice usually gives its agent a separate EHR account, and that credential belongs in a store of this kind, short-lived and scoped to the one application. A protected store keeps the record where it sits, and the screen still draws it for whoever opens the account.
Who approves an agent's change to a patient record, and what record does it leave?
A record change is a payment plan, a refund, a corrected address or a billing note, and each one needs a person who saw the screen and approved that change. The reason is not distrust of the model but the human tendency the research records: automation bias, "the tendency to over-rely on automation, has been studied in various academic fields" (Goddard et al., 2012). A reviewer who is told the agent prepared the work tends to accept it.
So the approval has to be built so that the approver sees what the model saw, not a summary the model wrote. The approver needs the page as it was rendered, the change the agent proposes and the fields the change touches, and the approval has to name the person. The EHR approves a person's edit, not an agent's proposal. Web-delivered attacks made GPT-4o multi-agent systems execute malicious code in 58 to 90 percent of trials, which is why the approval has to sit outside the model (How Do You Protect Sensitive Data Across Multiple AI Agents?).
The record is the other half. A practice that cannot show what the model received, what it proposed and who approved it has no way to answer a question about a payment six months later. A team that reconstructs the review from the agent's transcript is reading the system under review.
What does a governed environment change?
A governed environment moves the control to the page. Values chosen by policy are replaced with consistent tokens as the screen is drawn, so the model reads PATIENT_001 and ACCT_001 where the name and the account number sit, and the same tokens hold for the run. Real values resolve only at an approved destination, at the moment of an approved action, so the name reaches the letter the practice prints and not the transcript. A named person approves each payment, submission and record change, and every screen as tokens, every action and every approval is written to a record that exports to the practice's own monitoring.
What that changes is the object under control. A vault governs a value an application sends it; a governed environment governs what the screen shows the model, the path an agent takes into an EHR it did not build. The categories are placements rather than quality tiers, and both can run together (What Tools Tokenize Data Before an LLM Sees It?). The difference between the two is set out beside the products in RedactSure vs Skyflow: 2026 Comparison & Alternative.
The agent still has to open the account, read the balance and prepare the change, and the resolution at the destination turns the prepared change into a real one. The scope is the rendered page, not a script, a file or a direct API call.
What the record shows
The control that keeps a patient record out of the model sits on the rendered page: values replaced with consistent tokens before any model reads the screen, real values released only at the destination a named person approved, and a record of what the model received. A vault does a different job, and the pages reviewed place its work at the call an application makes, which is why a bought EHR sits outside it. For a patient account screen the exposure is the page's ordinary content, and an agent working it holds the name, the date of birth and the balance for the rest of the run unless the screen itself is tokenized. A practice can check this in an afternoon: pick one agent and one patient billing task, run it against a test record, compare the screen the agent opened with the transcript, then ask who approved each change.
Methodology and limitations
This page rests on Skyflow's documentation for tokenization, de-identification and the LLM Privacy Vault, vendor documentation from HashiCorp, AWS and Infinite Campus, one health system's patient billing page, and two research sources. Pages were read between October 21, 2026 and October 23, 2026, and each Sources line carries the date for its page. Documentation read in full gives a sound view of where each product applies its control.
None of the products on this page was tested for this page, and "not described in the pages reviewed" means only that the recorded pages do not carry the statement. Vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a patient account screen in an EHR, not an organization. Whether a workflow meets a contractual, privacy or regulatory requirement is a determination for counsel, assessors and the organization's own compliance officers.
Frequently asked questions
Is Skyflow enough to let an AI agent work patient records?
No. Skyflow's tokenization, de-identification and LLM Privacy Vault pages place the control in an application built against its vault, and the pages reviewed do not describe replacing values on the screen of an EHR the practice bought. An agent working a patient account reads the screen the EHR draws, so the model receives the record unless something replaces the values on the page first. The vault still protects what an application sends it.
What does the model receive when an agent opens a patient billing screen?
The fields the page draws: the name, the date of birth, the member ID, the balance, the statement and the payment options, plus any note the account carries. An agent reads the page the browser paints, and a computer-use agent reads its pixels as well. Those values stay in the run's context, the transcript and any summary the agent writes. Nothing in the EHR's rendering path removes them.
Does the EHR's own permission model keep the record off the model?
Only for records the account cannot open. Permissions decide which records a user may view and, for a field the application masks, what the page draws. An agent signs in with the account it is given, so it inherits those rights exactly, and every record that account can open the agent reads in full. The permission gates the record; it does not filter what the model receives from a record that opened.
Does a token vault in the agent's pipeline protect the patient record?
No. A vault protects the credential the agent uses to log in, and it can keep a token short-lived, scoped and out of the code. That is the login problem, and it is worth solving. The record is what the page draws after the login, and a vault does not see that page. Storing the record in a protected cloud has the same limit: the store is protected while the screen still draws the values.
Who should approve an agent's change to a patient record?
A named person who saw the page as the model saw it and approved that specific change. Automation bias is the reason: a reviewer told the agent prepared the work tends to accept it, especially when the screen looks tidy. The approval should carry the rendered page, the proposed change and the fields it touches, and it should sit outside the model. An approval that only says yes to a summary the agent wrote is not a review.
What record of an agent's work should a practice keep?
One record per run that shows what the model received on each screen, what it proposed, who approved it and when. That record answers a question about a payment or a note months later, and it is what an auditor will ask for. Keep it in the practice's own monitoring rather than only in the agent's transcript, because the transcript is written by the system under review.
How RedactSure Keeps Patient Identifiers Off the Screen the Model Reads
The controls above protect the store, the file or the credential, and the agent still reads whatever the EHR paints on the screen. Skyflow's tokenization page places tokens in "the company's operational database," not on a screen a model reads (Skyflow, Tokenization, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent reads the name, date of birth, member ID and balance into the transcript. Inside the governed environment: the page draws PATIENT_001 and ACCT_001, the plan is prepared on tokens, and the real name resolves only for the approved letter.
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
A patient billing screen is the first place a practice asks what the model read. Bring one billing task and see, with test values, what the model reads on the screen, who approves the change and what the record holds. Book a demo