Skip to content
redactsure
Book a demo

Explore.

Explainer · By Chris Sowa · Published
Last updated

What Is Screen-Level Tokenization?

Screen-level tokenization replaces sensitive values in the rendered view an agent reads, before a representation of that view is created for the model. The screen is the last point where everything the model will see sits in one place and can still be changed; a control inside any one system leaves the rest of the picture intact.

Application and financial fields become tokens before entering a linked model network.

Screen-level tokenization replaces sensitive values in the rendered view an agent reads, before a representation of that view is created for the model. The screen is the last point where everything the model will see sits in one place and can still be changed; a control inside any one system leaves the rest of the picture intact. Screen-level tokenization is the replacement of sensitive values with consistent tokens at the level of the screen an agent is looking at, in the rendered presentation of an application, before that presentation is passed to a model. For an agent that operates software through its interface, the screen is where data from many underlying sources becomes visible at once: fields from a record, a banner from another system, a note, a total, a warning. The substitution happens after the application has assembled its view and before the model receives it, which is what render-layer tokenization means in practice. That placement differs from tokenizing in a database, in an API response, or in a document, and it makes the screen a distinct control point. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • The screen is an aggregation point. A single rendered view can combine data from several systems, so a control placed only inside one system leaves the rest of the view untouched; a computer-using model works from that assembled view, not from any one source (Anthropic, 2024).
  • Screen-level tokenization acts on the rendered presentation, not on stored data. The source record, and the view shown to authorized staff, remain unchanged, which separates it from the tokenization of stored card data that PCI guidance describes (PCI Security Standards Council, 2011).
  • Because the agent receives a representation of the screen, the substitution must happen before that representation is created for the model, whether the representation is an image, a set of extracted fields, or a structural description of the page (Google, 2025).
  • Computer using agents from major model providers work from screenshots and interface actions, which is why the rendered view, rather than a database row, is the relevant unit for exposure (Anthropic, 2024; OpenAI, 2025).
  • The approach covers applications with no integration surface, but it inherits the messiness of real interfaces: values in images, scanned documents, and free text are harder to detect than values in labeled fields, which is why coverage has to be measured with testing rather than asserted (NIST, 2023).

Why is the screen a separate control point?

Most data controls sit where data is stored or where it moves between systems. Those locations made sense when software consumed data through interfaces designed for software. An agent that works through a user interface consumes data where a person would: on the screen. Anthropic's computer use capability, released in public beta in 2024, has a model work from screenshots and issue mouse and keyboard actions, with developers running the actions in an environment they provide (Anthropic, 2024). OpenAI's computer using agent similarly combines visual perception of a browser with reasoning and action (OpenAI, 2025). In both patterns, what the model knows about a record is what the screen showed it.

That fact creates a gap in layered defenses. A database can be tokenized, an API can filter its responses, and a network control can inspect traffic, while the screen still assembles the real values from a legacy window, a scanned attachment preview, or a notification. Conversely, a control at the screen can protect the model's view even when none of the underlying systems can be modified. The screen is therefore not a cosmetic layer. For interface driven agents, it is the last point at which everything the model will see is present in one place and can still be changed.

There is a second reason: the screen is where context that is not data in any schema appears. Totals calculated by the application, status banners, handwritten style annotations in a notes panel, and the name in a window title all reach the model. A reviewer who only inventories database fields will not list them, yet the agent reads them.

What exactly gets tokenized on a screen?

Three kinds of content appear on a working screen, and they need different handling. Structured values sit in labeled fields: a policy number, a date of birth, an account balance, a claim status. These are the easiest to identify because the interface itself labels them. Semi structured content sits in lists, tables, and search results, where one row may summarize a person and where a single screen can expose dozens of records the task does not concern. Unstructured content sits in notes, message threads, and document previews, where identifiers are mixed into prose written by staff who were not thinking about an automated reader.

Screen-level tokenization, done seriously, addresses all three. Field rules handle the first. Row and scope rules handle the second, and they matter more than they first appear: an agent asked to work one claim should not receive a results list naming forty other claimants, even if each name were individually tokenized, because the volume itself reveals the shape of a book of business. Pattern detection handles the third, searching free text for value shapes such as identifiers and account numbers.

Also present are values the task needs in readable form. A screen-level policy is a selection, not a blanket. Amounts, dates, statuses, and product types usually stay readable, because the agent's reasoning depends on them. The policy question is always which elements of this screen are identity bearing and which are work bearing, and the answer changes with the task.

How does screen-level tokenization compare with other layers?

Layer What is changed Coverage Main weakness for agent work
Database Stored values, permanently Systems the organization controls and can rewrite Misses portals and vendor applications, and the change is not task specific
API response Fields returned by an interface Applications with a suitable interface Many working screens have no equivalent interface, and rendered extras are missed
Document A file or attachment before use Files passed to a model Does not cover the live application view around the document
Screen The rendered view, during the run Any application the environment can render Detection must cope with layout, images, and free text

The comparison is not an argument that one layer replaces the others. Database tokenization remains the right control for stored card data, and PCI guidance describes how replacing a stored card number with a token reduces the amount of real card data an organization holds (PCI Security Standards Council, 2011). API filtering is precise where an interface exists. Screen-level tokenization is the layer that addresses the specific condition of an agent reading an assembled view. An organization can reasonably operate several layers and still need this one.

Timing also separates the layers. Database and document approaches generally act before any task is known. Screen-level substitution acts during the run, so it can reflect the task, the workflow step, and the policy confirmed for that run. That is the same distinction drawn in the runtime tokenization page, but the emphasis here is spatial rather than temporal: not when the substitution happens, but where in the stack it happens, at the presentation surface the model actually consumes.

What can go wrong at the screen level?

Layout is the first difficulty. Interfaces change, fields move, columns are renamed, and a rule tied too tightly to a position on a page will fail silently when a vendor updates its application. Silent failure is the dangerous mode, because the run continues with real values in view and nobody is alerted. Well designed implementations therefore monitor for unrecognized screens and for values that match protected patterns in unexpected places, and they stop or flag rather than proceed.

Images are the second difficulty. A scanned letter, an identity document, or a photographed form presents its values as pixels. Detecting them requires reading the image content, which introduces its own accuracy limits and its own processing step. A vendor claim about screen-level coverage should be pressed on this point: does the control cover image content rendered on the screen, or only text the interface exposes as text?

The third difficulty is consistency across screens. If a value is tokenized in a record view but appears untokenized in a print preview, an export dialog, or a hover tooltip, the protection has a hole in the place a reviewer is least likely to look. Agents wander into exactly those secondary views because they follow the same paths a person would. Coverage has to be defined over the whole working surface of an application, including dialogs, previews, and error messages, not only its main record page.

Finally, there is a usability failure mode. Tokenizing too aggressively at the screen level can remove labels or values the agent needs to distinguish options, producing wrong selections. The control must preserve enough structure for the work to be done correctly, which is a design constraint, not an afterthought.

How should coverage at the screen level be tested?

Testing should start from the model side. The single most informative artifact is the exact representation of a screen as the model received it, for a real workflow, with real shaped data in a test environment. A reviewer can read that artifact and look for values that should not be there. This is more reliable than reading a policy document, because the artifact shows the outcome of detection, layout handling, and policy combined.

A practical test set includes the awkward cases rather than only the main record page: a search results list, a notes field containing an identifier typed by staff, a scanned attachment, a print preview, an error message that echoes input, a report export screen, and a screen where two people with similar details appear together. It also includes a check that the same entity receives the same token across screens, and that a token cannot be reversed from anything else visible in the run.

The NIST AI Risk Management Framework's Measure function supports this kind of evidence based approach, expecting risks to be analyzed and tracked with testing rather than asserted (NIST, 2023). Buyers can ask how often screen coverage is retested when an application changes, and who is told when a test fails. A control without a retest trigger is a control with an expiry date nobody recorded.

Where does RedactSure sit?

The coverage test points directly to RedactSure, whose tokenization is placed at the screen itself. The whole rendered view, assembled from however many underlying systems contributed fields, banners, and totals, is tokenized as one picture before a model representation is made, and the model receives the task's fields with identifiers as tokens such as ACCT_001 and PATIENT_001. Applications with no integration surface are still covered because RedactSure works the interface as rendered, inside a governed environment, under the user's existing permissions and with no per-application integration. The Planner sets which values on each screen are tokenized and what the agent may do there; a named person confirms that policy before the run and approves every payment, submission and record change while it runs, under Supervised Delegation. Real values resolve only at approved destinations at the moment of an approved action.

The screen that the model receives is the same screen a reviewer can later inspect in the AI Control Record, which holds every screen as tokens, every action and every approval by name, and exports to the customer's own SIEM. Keys stay with the customer, and the model is swappable. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

The page defines a term and compares control layers. It rests on provider publications describing how computer using agents perceive and act on interfaces: Anthropic's computer use documentation (2024, vendor documentation), Google's Gemini computer use documentation (2025, vendor documentation) and OpenAI's description of its Computer-Using Agent (2025, vendor documentation); the PCI Security Standards Council's Tokenization Guidelines information supplement (2011, official guidance) for tokenization of stored data; and the NIST AI Risk Management Framework 1.0 (2023, official guidance) for testing and measurement expectations. All sources were read as of October 13, 2026. Vendor documentation is quoted or paraphrased as the vendor states it, with its date.

No hands-on testing of any named product was performed, and no original screen coverage testing or detection accuracy figures are reported, because no primary source consulted published comparable accuracy measurements for screen level detection across applications. Statements about failure modes, including layout drift, image content and secondary views, are architectural observations, not incident findings. Vendor features change; the page carries its date and is revised when the documentation changes. The claims, policy and record examples describe record types, not any organization; no customer or prospect is described. RedactSure statements are limited to design facts the company publishes about itself.

Whether screen-level tokenization, or any combination of layers, meets an organization's obligations under PCI DSS or any other requirement belongs to its counsel, its assessor and its security and compliance officers, not to this page. The test described above produces evidence those people can read; it does not replace their determination.

What the record shows

Screen-level tokenization matters because the screen is where an agent's exposure actually happens. A rendered view pulls fields, banners, notes, and totals from several underlying systems into one picture, so a control placed inside any single system leaves the rest of that picture exactly as it was. Substituting values in the rendered presentation, before a representation of it is created for the model, is the placement that covers the whole view at once. The approach reaches applications that offer no integration surface at all, which is a large part of its value, but it inherits the difficulty of real interfaces: labeled fields are easy to handle, while values buried in images, scanned documents, and free text are not. The one test to apply is to ask for the exact representation of one screen as the model received it, for a real workflow, and read it for values that should not be there.

Frequently asked questions

Does screen-level tokenization change what our staff see on screen?

No. The substitution acts on the rendered presentation as it is prepared for the model, not on the source record and not on the view shown to authorized staff. A person opening the same record sees the real values, because their work requires them and their access permits them. Only the representation handed to the agent, whether that is an image of the screen, a set of extracted fields, or a structural description of the page, carries tokens in place of the sensitive values it contains.

Which values on a screen are hardest to tokenize?

Values that arrive without a label. A field named for a tax identifier or an account number announces what it holds, so a substitution rule can find it. Values inside images, scanned documents, photographs of letters, and free text carry no such signal; a number can be a price, a date, or an identifier depending on the sentence around it. Misses concentrate in those places, which is why coverage claims for screen-level tokenization should be read as claims about the messy parts of real screens, not the tidy ones.

Does it matter whether the model gets a screenshot or extracted text?

For placement, no; for testing, yes. Whether the agent receives an image of the screen, extracted fields, or a structural description, the substitution has to happen before that representation is created, or the real values are already inside it. What changes with the format is how coverage can go wrong: image-based views can carry values in pictures and banners, while extracted fields can drop context or miss values rendered outside form fields. A reviewer should therefore test the specific representation the model receives, not a tidier stand-in for it.

How is screen-level tokenization different from database tokenization?

Database tokenization changes stored values, permanently, in systems the organization controls and can rewrite, and it acts before any task is known. Screen-level tokenization changes the rendered view during the run, in any application the environment can render, and can reflect the task and the policy confirmed for that run. The two are complementary: stored card data still belongs in a database control, while the agent's view of a portal or vendor application needs the screen control.

Does screen-level tokenization work for applications that have no API?

Yes, and that is a large part of its value. Because the substitution acts on the rendered view, it covers legacy windows, vendor portals and applications with no integration surface, as long as the environment can render them. The trade-off is that detection has to cope with layout, images and free text rather than labeled API fields, so coverage of those awkward cases has to be tested rather than assumed.

Does the agent still receive the values it needs to do the work?

It should. A screen-level policy is a selection, not a blanket: amounts, dates, statuses and product types usually stay readable because the agent's reasoning depends on them, while identity bearing values become consistent tokens. Tokenizing too aggressively removes labels the agent needs to distinguish options and produces wrong selections, so preserving enough structure for correct work is a design constraint of the control, and the policy changes with the task.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

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.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.