Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Can AI Agents Work With Customer Records Without Seeing the Actual Data?

By reading tokens instead of values: each identifier on a rendered record is replaced with a consistent surrogate before the model sees it, and the real value is restored only at an approved destination when an approved action needs it. Check where substitution happens, where the mapping lives, and whether the model ever touches it.

Customer record fields pass through a mapping card and a bounded transformation before reaching a matching output record.

By reading tokens instead of values: each identifier on a rendered record is replaced with a consistent surrogate before the model sees it, and the real value is restored only at an approved destination when an approved action needs it. Check where substitution happens, where the mapping lives, and whether the model ever touches it. The idea has a long precedent. Payment systems have handled card numbers this way for fifteen years, keeping the real number in a vault and letting every other system work with a token that stands in for it. The same shape applies to an agent that must update a customer account, reconcile an invoice or answer a service ticket: the model needs to know that this record belongs to one customer and that the same customer appears on the next screen, but it does not need the name, the account number or the date of birth to do that work. This page sets out the mechanics in order: what tokenize-to-read means on a single record, how resolution at the destination completes the action, why the model never needs the vault, what the payments precedent establishes, how consistent tokens keep the task intact, and which claims a buyer should refuse. It builds on the question of what the AI should see for a piece of work and on the operating controls described in how to secure AI agents that access customer data.

Key findings

  • Tokenization replaces a sensitive value with a surrogate that has no exploitable meaning on its own, while the real value is held in a separate store; the payments industry formalized this pattern to shrink the scope of systems that handle card numbers (PCI Security Standards Council, 2011).
  • Several data platforms already separate token issuance from value storage: Snowflake documents external tokenization in which tokenized data is stored in the table and detokenized at query time by an external function (Snowflake, 2026), and Skyflow documents tokenization with isolated storage of the original values (Skyflow, 2026).
  • Swapping identifiers for consistent pseudonyms and restoring them afterward is a measured technique: one preprint reports that it reduces semantic utility errors by a factor of five compared with baseline approaches (Serenari and Lee, 2025).
  • The same separation is used for credentials: 1Password describes browser agents whose model never needs to see or handle the credentials, which are injected only if the human approves the access (1Password, 2025).
  • De-identification is a governance decision as much as a technique: NIST's guidance treats which identifiers to remove, and how, as choices that must be documented against a re-identification risk (NIST, 2023).
  • Working on a record without exposing it depends on knowing which agents are reading it at all, which is why an inventory of agents comes before any tokenization policy (What Is a Shadow AI Agent?).

What does working with a record without seeing the data mean in practice?

Take a customer account record of the kind a service agent opens many times a day: a name, an account number, an email address, a billing address, a payment method ending in four digits, a list of open orders and a notes field. A task such as "apply the loyalty credit to this account and confirm by email" requires the agent to find the account, check the eligibility rule, apply the credit and send the confirmation. Read the task closely and the agent needs the structure of the record and the state of its fields. It does not need to know who the customer is.

Working without seeing the data means that the record the model reads has the structure intact and the identifiers replaced. The name field reads CUSTOMER_001, the account number reads ACCT_001, the email reads EMAIL_001. The order list, the eligibility flag and the credit amount remain readable because the task depends on them. The model reasons over this version of the record, decides to apply the credit, and composes a confirmation addressed to EMAIL_001. When the confirmation is actually sent, the email system, not the model, receives the real address.

Two tests distinguish this from a cosmetic masking display. First, the substitution has to happen before the model reads anything, not after the fact in a log. Second, the model's output must work when tokens are resolved at the destination, which means the tokens must be consistent for the whole run. A design that passes both tests lets an agent complete the task on a per-task view of the record while the data that would identify the customer never enters a prompt.

How does tokenize-to-read work on a single rendered screen?

The reading path has four steps. The application renders the account record. A policy decides which fields on that screen are protected. Each protected value is swapped for a token, and the token is written to a mapping held inside the governed environment for the duration of the run. The screen, now carrying tokens, is what the model reads.

This is substitution at the render layer: the application is unchanged, its database is unchanged, and other users of the same application see the record exactly as before. The operation is scoped to one screen at a time, which keeps it small. A customer account screen presents dozens of values, and the protected subset is smaller still. Vendor documentation for API-based masking describes the same two primitives at a different layer: Protecto's identify-and-mask call detects sensitive values in text and returns tokens in their place (Protecto, 2026), and its unmask call reverses the exchange for a holder of the token (Protecto, 2026). The render-layer version applies the same primitives to a screen rather than to a text payload, and ties the unmask step to a destination rather than to a caller.

Step What the model reads Where the real value is
Render Nothing yet; the application draws the record In the application, as always
Detect Nothing yet; policy identifies protected fields Unchanged
Substitute CUSTOMER_001, ACCT_001, EMAIL_001 In the run's mapping, inside the governed environment
Reason and act Tokens throughout; the plan references tokens Still in the mapping
Resolve Nothing; the model's work is done Written to the approved destination at the moment of action

Why does the model never need the vault?

Because every operation the model performs is an operation on the structure and state of a record, not on the identity behind it. Finding the right account is a matter of matching a token the model was given at the start of the task. Checking eligibility reads a flag. Applying a credit changes a number. Composing a confirmation needs a recipient placeholder, not an address. None of these steps is improved by the model knowing the customer's name. The vault, meaning the mapping between tokens and real values, is consulted only at resolution, and resolution is performed by the environment at the destination, after the action has been approved.

This mirrors a principle the payments industry wrote down when it defined tokenization: a system that holds only tokens, and has no means to exchange them for the original value, is out of scope for the controls that protect the original (PCI Security Standards Council, 2011). Applied to agents, the model is the system that holds only tokens. The design works only if the model has no path to the mapping: no tool that returns real values on request, no debug screen that shows both columns, no fallback that sends the unredacted screen when detection is uncertain.

The 1Password credential pattern shows the same logic in a neighboring domain. In its description, the agent and the underlying model never need to see or handle the credentials, which are injected into the sign-in form only if the human approves the access (1Password, 2025). Replace credentials with identifiers and sign-in with an approved record change, and the pattern is the one described on this page. What the model needs is the ability to cause an outcome. What it never needs is the secret that makes the outcome real.

What does the payments precedent establish, and where does it stop?

The PCI tokenization guidelines established three things that carry over. A token must not be reversible without access to the tokenization system. The system that performs the exchange must be segmented from the systems that hold tokens. And the value of tokenization lies in reducing the number of systems that ever touch the real value (PCI Security Standards Council, 2011). Data platforms have since built the same separation into their products. Snowflake documents external tokenization, in which tokenized data is stored in the table and detokenized at query time by a function the customer controls, so the platform itself never holds the mapping (Snowflake, 2026). Skyflow documents tokenization with the original values held in isolated storage, separated from the systems that use the tokens (Skyflow, 2026).

Where the precedent stops matters just as much. Payments tokenization protects one field type, the primary account number, with a known format. A customer record carries many field types, some of them free text, and an agent reads whole screens rather than single columns. The policy question is therefore wider: which fields on this screen, for this task, must be tokens, and which must stay readable for the task to succeed. NIST's de-identification guidance frames that as a documented choice made against a re-identification risk, not a default applied to everything (NIST, 2023). The precedent supplies the mechanism. The agent setting supplies a harder policy problem, and a per-task policy confirmed by a named person is how that problem gets settled.

How do consistent tokens keep the task intact?

An agent working across screens must recognize that the account on the search results page is the account on the detail page and the account on the confirmation page. If each screen issued fresh tokens, the model would lose the thread and the task would fail. Consistency within the run, the same value yielding the same token on every screen, is what makes tokenized work possible rather than merely safe.

There is evidence that this consistency preserves the usefulness of the work. In a study of conversational AI services, swapping identifiers for consistent pseudonyms and restoring them afterward reduced semantic utility errors by a factor of five compared with baseline techniques (Serenari and Lee, 2025). The finding points at the failure mode of cruder approaches: deleting or scrambling values without consistency damages meaning, while consistent substitution keeps the relationships a task depends on.

Consistency also serves the audit. If every screen the model read is kept as tokens, and every action and approval is recorded against those tokens, a reviewer can reconstruct what the agent did without the record of the review itself becoming a store of customer data. That is the purpose of an AI Control Record: a run-level account of screens, actions and approvals in which the identifiers are already surrogates. The same property makes it possible to use open-weights or lower-cost models on regulated records, since where the model came from matters less when what it reads contains no identities.

What does a governed environment change?

When an agent works a customer record in a governed environment, the model reads the record as tokens rather than values, and the real identifiers return only at the destination where an approved action needs them.

The mechanism is a class of control, not a product. Sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, so the task runs on tokens: the same customer carries the same surrogate across every screen, which is what keeps a lookup, a comparison or a form fill coherent. Real values resolve only at an approved destination at the moment of an approved action, such as a payment or a record update. A named person confirms what is tokenized and approves consequential actions. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This is the payments pattern applied to a screen. The payments industry formalized tokenization to shrink the number of systems that handle card numbers, with the real value held in a separate store (PCI Security Standards Council, 2011). The credential case shows the same separation in an agent context: a model that never handles the credential, which is injected only if a person approves the access (1Password, 2025). In this class of control the mapping lives outside the model's reach, nothing the model can call resolves a token, and the run record shows every screen as tokens and every resolution with an approval attached.

The environment does not change the application, the user's permissions or the model; it changes what the model receives from the screen.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design is the one this page describes, placed in a governed environment that runs in the customer's cloud. Substitution happens at the render layer before any model reads the screen, with consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, so the model recognizes the same account across search, detail and confirmation screens without learning whose account it is. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy for the workflow and approves every payment, submission and record change, a pattern the company calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The environment is model agnostic, requires no per-application integration and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own customer workflow would show, for one agent and one task, which fields the policy tokenized on each screen, whether the agent completed the task on tokens alone, and where the single resolution step occurred and who approved it. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

The mechanics on this page rest on the PCI Security Standards Council's Tokenization Guidelines Information Supplement (2011; industry standards guidance), NIST Special Publication 800-188 on de-identifying government datasets (2023; official guidance), vendor documentation from Snowflake, Skyflow, Protecto and 1Password describing tokenization, detokenization and credential-injection behavior, a 2025 preprint by Serenari and Lee on consistent pseudonymization in conversational AI services, and RedactSure research pages on per-task visibility, the AI Control Record and shadow agents. All sources were read as of October 16, 2026.

No hands-on testing of any named product was performed for this page. Where a vendor's behavior is described, the description comes from the pages reviewed, and "not described in the pages reviewed" means exactly that, not that the product lacks the capability. Vendor features change, and the page carries its date. The preprint cited was not independently replicated; its factor-of-five result is reported as its authors state it, in its own setting of conversational services rather than enterprise agents. Statements about RedactSure describe its current design, with deployments in pilot. The customer account record used as a worked example describes a record type, not any organization, and no customer or prospect is described.

Whether a tokenization policy, a resolution path or a run record meets an organization's regulatory obligations is a determination for its counsel, its assessors and its own security and compliance officers. This page supports that review; it does not replace it.

What the record shows

Agents can work on customer records without seeing the data when three conditions hold at once: substitution happens before the model reads the screen, tokens stay consistent for the whole run, and the only path from token to value runs through an approved destination at the moment of an approved action. Payments tokenization established the mechanism and the segmentation principle fifteen years ago, data platforms have built the same separation into their products, and early research suggests that consistent pseudonyms preserve the usefulness of the work. The harder problem in the agent setting is policy: which fields, on which screens, for which task. One design, RedactSure's, settles that per workflow with a named person. The test is to name one agent and one task and ask what the model would read, as tokens or as values, on each screen it opens.

Frequently asked questions

Does the agent still complete the task if it never sees the real values?

Yes, provided the tokens are consistent across every screen in the run and the fields the task actually depends on remain readable. An agent applying a credit needs the eligibility flag and the amount, not the customer's name. The one published measurement of consistent pseudonymization reports that it preserves semantic utility far better than cruder masking. A pilot on a real workflow is the way to confirm the same holds for a specific task.

Where is the real value stored while the agent works?

In a mapping held inside the governed environment for the duration of the run, separate from anything the model can read or call. The application and its database are unchanged; the substitution is applied to the rendered screen only. At the moment of an approved action, the environment exchanges the token for the value at the destination, in the same way payments systems detokenize at the processor rather than in every system that handles a transaction.

Is this the same as data masking?

It shares the detection step but differs in two ways. Masking usually destroys the value or replaces it with a fixed placeholder, which breaks any task that must recognize the same record across screens. Tokenization issues a consistent surrogate that can be resolved later at an approved destination. Masking is often applied to copies of data for testing; tokenize-to-read is applied to live screens during the work itself, before the model reads them.

How is this different from the tokenization payments systems use?

The mechanism is the same: a surrogate with no exploitable value, a segmented system that holds the mapping, and resolution only where the real value is needed. The scope is wider. Payments tokenization protects one field type with a known format. An agent reads whole screens with many field types, including free text, so the policy must choose fields per screen and per task, and someone accountable must confirm that choice rather than a pattern library guessing it.

Can the model ask for the real value if it gets stuck?

In a sound design, no. Any tool or fallback that returns a real value on request undoes the separation, because the model then holds both the token and the value. If a task cannot be completed on tokens, the correct outcome is that the task halts and a person decides, not that the model is given the data. Buyers should ask for the list of calls available to the model and confirm that none of them resolves a token.

What does the audit trail contain if everything is tokenized?

Every screen the model read, as tokens; every action it took, referencing tokens; and every approval, with the name of the person who gave it and the destination where resolution occurred. Because the identifiers in the trail are surrogates, the trail itself is not a second copy of customer data, which makes it safe to export to a SIEM and to share with reviewers who have no business reason to see the underlying records. Reviewers who do need a real value obtain it through the destination system, under that system's own access controls.

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.