Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does WitnessAI Tokenize Data in the Browser or Only in API Traffic?
Only in API traffic: WitnessAI tokenizes prompts, tool calls and model responses on the path its platform inspects, and a page an agent reads on screen does not cross that path. Ask for one screen replayed field by field, then decide whether a traffic control covers the work.
A payment run starts with an invoice the finance agent has already read. The agent pulls the invoice through the accounting system's API, matches it to a supplier record, and opens the supplier page in the procurement portal to confirm the bank account before it queues the payment. The same field crosses both hops. On the API hop the number travels in a JSON body along a path a security platform can inspect; on the portal hop the portal's own service draws the number onto a page, and the model reading that page receives it.
An account number in a model's context can be repeated in a summary, written into a case note or carried to the next page. The team has decided the agent will read the invoice; what it has not settled is what the model may hold while it does.
WitnessAI's pages describe a control layer over AI traffic: prompts, model responses, tool calls and the network flows its platform inspects. The procurement portal's screen is drawn by the portal (What Is Render-Layer Tokenization?).
Key findings
- For a browser agent to work a supplier record without exposing the bank account, the values on the page would have to be replaced with consistent tokens before any model reads it, and a traffic control never sees that page (What Is Render-Layer Tokenization?).
- It would also require a named person approving each payment and a record of what the model received, properties of the screen and the approval rather than of the network hop (What Is Supervised Delegation?).
- WitnessAI's published documentation does not state that values on a rendered page are replaced before the model reads them; it describes tokenization of prompts, responses and tool calls (WitnessAI, Protect, 2026).
- Its Protect page says the platform will "Keep sensitive PII, credentials, and secrets safe by identifying and tokenizing them before they ever reach an AI model or agent," a substitution made on the path to a model (WitnessAI, Protect, 2026).
- 1Password's browser design states that "the AI agent and underlying LLM never need to see nor handle the credentials," filled "if, and only if, the human approves the access," which covers a credential fill, not the record a page shows (1Password, 2025).
- A study of information flow in LLM applications found that "poisoned data retrieved from one component can change the model's behavior and compromise the entire system," which makes the page a model reads the unit that matters (Siddiqui et al., 2025).
What does WitnessAI tokenize, and what reaches the model from a screen?
Protect is the first surface the vendor documents: it tokenizes values "before they ever reach an AI model or agent" (WitnessAI, Protect, 2026). Agentic Control "governs agents at the tool boundary, the moment an agent acts on a system," and its pre-execution scan "tokenizes PII and secrets before the agent acts" (WitnessAI, Agentic Control, 2026). The January post adds that pre-execution protection "scans prompts before agents process them" (WitnessAI, Agentic Security, 2026).
Each of those is a crossing. A prompt crosses into a model, a response crosses back, a tool call crosses to a system, a network flow crosses the platform. Tokenization happens where the crossing is, and the claim that follows, that "the agent never sees sensitive values," is a claim about the inspected path (WitnessAI, Agentic Security, 2026). A page an application draws is not a crossing. The portal authenticates the agent's session and composes the supplier page; the platform sees the request for the page, not the fields it will show.
The vendor's own discovery page describes the shape of that coverage: "See AI activity across your entire network without relying on browser extensions or endpoint clients" (WitnessAI, Observe, 2026). Network coverage is what the sentence says, and no page among those reviewed describes a component that redraws a page with a token where a value sits. That leaves the model holding the account number as the portal renders it, with the traffic control working correctly on the hop it was built for.
Of the 86 AI security products reviewed, 28 control model input or mask a browsing layer, 27 of them on pipelines or traffic, and none of the 28 describes giving an agent tokens it can work with on a screen (How Many AI Security Products Control What an AI Agent Sees?).
Is a rendered page the same thing as API traffic?
The two hops are different objects to a control that inspects traffic. An API call is a request the platform can sit in front of: the account number is in the body, and a token can be written over it before the model builds the call. A rendered page is composed after the request: the portal receives an identifier, looks up the supplier's record and draws the fields, so the account number reaches the browser as text the application assembled.
The invoice workflow makes the split visible on one record. On the API hop, the request for the supplier's payment details carries the account number, and a control on that path can tokenize it. On the portal hop, the agent's request asks for the page by identifier, and the response the browser renders includes the account number; nothing crossed the platform, because the field was never in a request.
Browser-level designs show what it takes to cover that hop. 1Password describes a fill where "the AI agent and underlying LLM never need to see nor handle the credentials," injected "if, and only if, the human approves the access" (1Password, 2025). A credential manager gets there by sitting in the browser. A placeholder does the same for a value the agent types (Can an AI Agent Work With a Placeholder Instead of a Real Credential?), and an enterprise browser governs where data can go and leaves the read to the page (Enterprise Browser or Render-Layer Tokenization?). None of the three is a traffic control.
What do the vendors themselves say?
WitnessAI's pages are consistent about where the work happens, and the table sets the wording beside the check a buyer can run. Every row names a crossing the platform inspects, none names a page the application draws, and a buyer can ask which one covers the portal an agent opens under its own login.
| Dimension | WitnessAI, per its pages | What a buyer should verify |
|---|---|---|
| Where the control sits | "Keep sensitive PII, credentials, and secrets safe by identifying and tokenizing them before they ever reach an AI model or agent." (WitnessAI, Protect, 2026) | Which hop the value crosses |
| What it redacts | "redact sensitive data in real time" (WitnessAI, Witness Control, 2026) | Whether redaction reaches a page |
| Agents that act through tools | "governs agents at the tool boundary, the moment an agent acts on a system" (WitnessAI, Agentic Control, 2026) | What the model held before the tool call |
| What the model receives | "This ensures the agent never sees sensitive values, and neither do downstream tools or databases it accesses." (WitnessAI, Agentic Security, 2026) | Whether that holds outside the inspected path |
| The record | "Every blocked call writes an audit record naming the user, the agent, the tool, and the rule that denied it." (WitnessAI, Agentic Control, 2026) | Whether allowed calls are recorded |
Who approves an action, and what record does the traffic layer leave?
A traffic control decides by policy. It routes, allows, blocks or redacts, and its pages describe that decision as automatic. A person enters the picture only if the workflow puts one there. OpenAI's paper on governing agentic systems treats human approval as "a standard way to limit egregious failures" and asks that "at least one human entity is accountable for every uncompensated direct harm" (Shavit et al., 2023). Those are requirements on a design, and no network hop supplies them by itself.
The record has the same shape. Agentic Control writes a record for a blocked call naming "the user, the agent, the tool, and the rule that denied it" (WitnessAI, Agentic Control, 2026). That record names a call that was denied, not the fields a model held when it read a page, and nothing in the traffic path produces the second record, because the page produced no call.
Detection is a race, which makes the gap in the record larger. An adaptive-attack study bypassed 12 published defenses against jailbreaks and prompt injection with "attack success rate above 90% for most," many of which had reported near-zero rates (Nasr et al., 2025). A scan that catches an injection today is worth having. The question that survives a bypass is what the model was holding, and on a rendered page the answer is whatever the portal drew.
What should a security team ask for in writing?
Ask which hop tokenizes the account number, and ask to see one rendered screen replayed field by field from the model's own input. A vendor that can produce the replay for the portal page as well as for the API call has covered the read; one that can show only the call has covered the request. The answers sort into five questions.
First, where does the control sit: in the request path, in the browser, or at the point a page is composed? Second, what did the model receive on a rendered screen, field by field, on a record the agent is permitted to open? Third, which component holds the real value, and what releases it: a rule, a schedule, or a named person at the moment of the action? Fourth, what record exists of the read itself, and does it export to the organization's own monitoring? Fifth, what does the control do on a hop it does not inspect, since the supplier portal is one?
OWASP's agentic list frames the last two, because tool misuse and identity abuse are named risks, and both sit on hops a gateway can see (What Is the OWASP Top 10 for Agentic AI?). The screen an agent reads is where those risks meet a record the platform never handled, and the written answers are what a renewal review will ask for. Get each one beside the test that confirmed it.
What does a governed environment change?
A governed environment is a control class rather than a product feature. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the supplier appears as VENDOR_001 and the bank account as 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. Real values resolve only at approved destinations, at the moment of an approved action, a named person approves every payment and record change, and every screen as tokens, every action and every approval is written to a record that exports to the organization's monitoring, the page What Is an AI Control Record? describes.
For this page's question it changes the second hop. The page is composed with tokens where the values sit, so the model that reads the portal holds VENDOR_001 and ACCT_001, and an instruction hidden in the page's notes collects tokens rather than a bank account. The API hop keeps its own control. A render-layer environment does not govern the request path, and a traffic control does not govern the screen. The comparison for the vendor named in the title sets the two side by side (RedactSure vs WitnessAI: 2026 Comparison & Alternative).
Its scope is the rendered page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so the API half of this workflow still needs the control that watches the call.
What the record shows
The values a model receives depend on the hop that carried them, and the pages reviewed put WitnessAI's tokenization on the traffic hop: prompts, responses, tool calls and network flows. Its Observe page describes network coverage "without relying on browser extensions or endpoint clients" (WitnessAI, Observe, 2026), and its Protect page places tokenization before values reach a model. On that record, the answer to the title is API traffic and not the browser: the supplier portal renders the account number to the model unless something replaces it as the page is composed. A two-hop test on one invoice settles it: run the agent's task once through the API and once through the portal, capture the model's input at each hop, and compare the fields.
Methodology and limitations
This page rests on WitnessAI's three product pages and two 2026 agent posts, three research papers, one vendor write-up of a browser credential design, and existing RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read as of October 23, 2026, and each Sources line carries the date for its page.
The products on this page are described from documentation, and none was tested for this page; where a sentence says a vendor's pages do not describe something, it means the pages reviewed. WitnessAI's features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers, and the supplier record is a record type rather than an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers.
Frequently asked questions
Does WitnessAI tokenize data in the browser?
Only in API traffic, not in the browser. Its pages put tokenization before values reach a model, at the tool boundary and across the network flows the platform inspects, and the discovery page describes coverage "without relying on browser extensions or endpoint clients" (WitnessAI, Observe, 2026). A supplier page the portal draws for the agent crosses none of those paths, so the model receives the fields as rendered. Covering the browser takes a component that substitutes values as the page is composed.
What does the model receive when an agent opens a supplier page?
The fields the portal draws, including the bank account, the tax identifier and any notes on the record, whether or not the task needs them. A traffic control sees the request for the page and the response, not the values the page's own script assembles, so nothing in that path replaces them. The model receives the supplier as the application rendered it. Narrowing that takes a control at the page, or a task that never opens one.
Does redacting the model's response protect the page?
Not the read. Redaction on the response path changes what a model says, and tokenization on the request path changes what it is sent. Neither changes what the portal drew before the model produced its first token. A page that carries the account number in a field the model must read still puts it in the context, whatever happens to the reply. The control has to sit before the read, not after it.
Who approves an agent's action on a screen the platform does not inspect?
No named person, on the pages reviewed. WitnessAI's controls route, allow, block or redact by policy, and Agentic Control governs the call an agent makes to a tool. None of the pages names a person who approves one payment before it runs, and a screen that produces no call produces no policy decision either. Approval on that hop has to be designed into the environment the agent works in.
What record exists of what the model read on the supplier page?
A record of traffic, not of the page. Agentic Control writes "an audit record naming the user, the agent, the tool, and the rule that denied it" for a blocked call (WitnessAI, Agentic Control, 2026). It shows the call and the rule, and it does not show the fields a model held when it read the portal. The record answers who did what, not what the model saw.
Can a traffic control and a browser control work together?
Yes, at different hops. A traffic control tokenizes the call the agent makes and a render-layer control tokenizes the page it reads, so a supplier workflow can carry both without overlap. RedactSure's environment is the second kind, and its scope is the rendered page rather than the request path. The pairing is a design decision: one control answers what left the agent, the other answers what reached it.
How RedactSure Tokens a Supplier Page the Traffic Layer Never Sees
A traffic control tokenizes the call and leaves the page an agent reads, so the account number arrives at the model in the clear.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the portal under the clerk's session, the supplier page draws the bank account, and the model holds it for the rest of the run. Inside: the same page draws VENDOR_001 and ACCT_001, and the real number reaches the payment form only when the clerk approves.
RedactSure is deploying now with enterprise and government customers. WitnessAI's Protect page tokenizes values "before they ever reach an AI model or agent," on the path and not on the page.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A supplier page is where a payment can be redirected, and the read is the moment to check. Bring one invoice workflow and see, with test values, the page as the model receives it, the approval waiting, and the record it writes. Book a demo