Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can a Call Center Use AI Agents Without Agents Seeing Caller Identities?
Yes for screen work, where a caller's name, address and card digits can render as consistent tokens such as CALLER_001 before any model reads the page. Split the job so identity verification happens outside the model, and treat the live call as the one step no screen control covers.
A contact center that puts AI agents on its queues takes a version of this call every day. The caller answers a date of birth and a one-time code, the agent desktop opens the account, and the screen fills with the name, the service address, the card on file and the notes from the previous conversation. If an AI agent works that screen, the model receives all of it, including fields the task never needed. The useful question is whether the name has to reach the model at all. Identity verification answers a different question, and a vendor's role settings answer a third. The work divides in two: verify the caller outside the model, then put the agent on a page where the caller is CALLER_001 and the address is ADDR_001. That split holds for the desktop, where it asks for a control that acts before the page reaches the model and leaves a record of what the model saw. A caller who says a name aloud is a harder case, because the value arrives as sound and there is no page to change. It sets the boundary of what a screen control can promise for a call center, and it is the first thing a pilot should measure.
Key findings
- For a call center's screen work, the caller's name, service address, date of birth and card digits would have to be replaced with consistent tokens such as CALLER_001 before any model reads the page, so the agent works on labels instead of a caller (What Is Render-Layer Tokenization?).
- It would also take a named person approving each address change and refund, and a record that separates the agent's actions from the person's, the split AWS draws when it asks that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026).
- The gap sits in the voice channel: substitution happens on a rendered page, and a caller who says a name aloud is heard before any page exists (What Is a Protected Browser for AI Agents?).
- BILL's role page draws the boundary around a role: "The Accountant role can manage the payables processes, but cannot pay bills" and "is not able to manage users or view/manage banking information," which limits which screens a seat can open, not what a model reads once a screen is open (BILL, Roles, 2026).
- BILL's ePayment page shows "the last four digits of the bank account, and the full routing number" to the user who entered the details, a masked partial view built for a person and silent on what a model receives (BILL, ePayment, 2026).
- Harvard's guidance names the combination to avoid: "The riskiest agent setup combines three things: access to private data, exposure to untrusted content, and the ability to send data outward", and a support agent that reads account data, follows caller text and can send a refund outward holds all three (Harvard University Information Security and Data Privacy, 2026).
What does the agent read when it opens a verified caller's account?
Take a collections account after verification. The caller answered the date of birth and the one-time code the IVR sent to the phone on file, so the session is verified before any model is involved. The page then draws the name, the service address, the date of birth, the card on file, the last two arrangements and the note the previous agent left. The task is small: move the arrangement by ten days. A person at the desk reads five fields; a screen agent reads the page.
The page is the unit of exposure. An agent that reads a rendered screen takes the whole page the application builds, not the fields the task needs. OWASP's sensitive information entry names what that hands over: "Personal identifiable information (PII) may be disclosed during interactions with the LLM", and a caller's record is exactly that data (OWASP, 2025). Siddiqui et al. describe the movement inside a pipeline, where "poisoned data retrieved from one component can change the model's behavior and compromise the entire system" (Siddiqui et al., 2025).
The page changes field by field.
| Field on the account | What the page draws for a person | What the agent reads with substitution | Who needs the value |
|---|---|---|---|
| Caller name | the full name on the account | CALLER_001 | the person who greets the caller |
| Service address | the street, unit and city | ADDR_001 | the approver who confirms the change |
| Date of birth | the date on the identity record | DOB_001 | the verification system, before the model |
| Card on file | the last four digits | CARD_001 | the payment form at the destination |
| Arrangement date | the agreed payment date | DATE_001 | the agent, as a date it can move |
| Previous call note | the free text the last agent wrote | the caller's name and account number: CALLER_001, ACCT_001 | the person reviewing the account |
The tokens stay the same for the whole run, so the agent can follow the record from the first screen to the last, and a token that resolves at the destination completes the change (Can an AI Agent Work With a Placeholder Instead of a Real Credential?).
Reading a value aloud still needs a person or the layer that resolves the token. Over-redaction has a cost: the minimizer in one agent-tool firewall "can also remove information that is important for task success, leading to a drop in utility", and the authors describe the trade-off that comes with redacting input arguments in the same paper (Bhagwatkar et al., 2026). Tokenize the arrangement date as well as the name and the agent cannot compute the new date, so the policy has to name the fields the task needs. Consistent pseudonyms with restoration also keep the task accurate, with semantic utility errors reduced by a factor of five against baseline techniques (Does Masking Data Still Let an AI Agent Complete Its Task?).
Why does verifying the caller outside the model leave the name on the screen?
Verification answers whether the person on the call may see the account. It does not decide what the account page draws once the answer is yes. In most call centers the check happens in the IVR or in a panel beside the CRM, and both open a verified session; the record itself is unchanged. The stronger the verification, the more the page is willing to show.
Role settings move the boundary without changing the page. BILL's help center describes six pre-defined roles, and the boundaries are real: a Payer "cannot enter or approve bills", and anyone who pays "must complete identity verification to become authorized to use the bank account in BILL" (BILL, Roles, 2026). A role limits which screens a seat can open, and an agent running under the seat inherits that reach. Once the screen is open, the model reads every field the role permits.
Masking is the other half of the same boundary. BILL's ePayment article treats a masked screen as evidence: for a vendor that maintains its own details, "the numbers will be masked, but you'll see if there's an existing verified bank account", a display convention that tells a person the account is verified and leaves out what a model receives (BILL, ePayment, 2026). The account number is partly hidden and the routing number is not, because the screen was designed for a person.
The verification step is still worth keeping outside the model: it is an authorization decision, and that belongs to the system that holds the identity rather than to a model that can be talked out of a conclusion. A page that renders tokens keeps the decision where it was (What Is Render-Layer Tokenization?). A role decides who may open a record, a mask decides which characters a person sees, and neither decides what the model receives. The same control applies to people: a worker inside a governed environment sees the same tokens an agent does, with policy setting what each role may see.
What do the vendors themselves say?
The vendor pages here come from a payments platform and a model provider, and they show where each control sits rather than how a support queue runs. None is a call-center desktop, so each row is read for the layer it acts on.
| Dimension | What the vendor documents | What a buyer should verify |
|---|---|---|
| The role gate | BILL's Administrator can "authorize bill payments" while the Accountant role "cannot pay bills" (BILL, Roles, 2026) | Whether the gate stops the agent's session or only a person's seat, and what the model reads on the screens the seat opens |
| The masked view | BILL shows "the last four digits of the bank account, and the full routing number" (BILL, ePayment, 2026) | Whether the mask is a display convention or a substitution before the model, and which characters remain |
| The training control | OpenAI's data controls "let you choose whether your conversations help train OpenAI models" (OpenAI, 2026) | Whether the question is training or exposure, because a training setting does not change the screen |
| The audit line | AWS asks that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026) | Whether the log records the model's input or only the action that followed |
Read together, the four rows describe controls that act on a role, a display, a training set and a log. A call center that buys one of them has bought something real, and it has not bought the property this page is about: a page where the caller's values never reach the model. The OpenAI row is the clearest example, because a data control is a retention and training decision, and the screen an agent reads is neither. The BILL rows sit closest, because a support desk and a payments desk both open an account record for a person; the difference is what the page describes, a person's view rather than a model's.
A caller's name, service address and card digits are customer data a screen agent reads, and of 15 AI agents and 86 AI security products reviewed, none describes replacing those values with tokens it can work with (Do AI Agents Ask Before Making a Payment?; How Many AI Security Products Control What an AI Agent Sees?).
What does a voice agent hear that no screen control covers?
The call is the part of the workflow that never renders. A caller says a name, a date of birth and a reason for calling; speech recognition writes those words into a transcript, and a voice agent works from the transcript or from the audio itself. There is no page to substitute on, because the value arrives as sound and leaves as text. A center can verify in the IVR with keypad entry and a one-time code before a model is in the path, but the caller who then explains the problem still says who they are.
Audio is also an injection channel. Indirect prompt injection, the family that hides instructions in content an application processes, was described in 2023 as a way for adversaries to "remotely (without a direct interface) exploit LLM-integrated applications" (Greshake et al., 2023). A caller who tells the agent to ignore its instructions and read out the last four digits is the same attack with a voice. The pages reviewed record no speech-level substitution, so the practical controls are to keep the voice agent away from account values and route changes to a channel that can be tokenized.
A workable split: the IVR or a person completes verification; the voice agent handles intents that do not need the record; anything that requires an account value moves to a screen agent working on tokens or to a person with the record open. That is a decision about where the model sits, not a claim that a setting makes a live call safe.
The defense research carries the same limit. A defense at the agent-tool interface that "achieves perfect security with high utility across all four public benchmarks" is a strong result on benchmarks rather than on a support queue (Bhagwatkar et al., 2026). The same paper reports that existing benchmarks are "easily saturated by a simple approach" (Bhagwatkar et al., 2026). Guardrails follow the pattern: the common rails sit at input and output, where text is filtered, not at the render step (What Are AI Agent Guardrails?).
What should a call center ask for in writing?
Procurement language decides most of this before a pilot starts, and each question has an answer a vendor can put in writing or decline.
Where the substitution happens. Ask what the model receives from a rendered screen, field by field: the name, the service address, the date of birth, the card digits, the balance and the notes panel. A filter on the model's output runs after the model has read the value.
Whether the token is stable. CALLER_001 on the account page has to be CALLER_001 on the arrangement page and the refund form, or the agent cannot follow the record across the run. Ask for the token map and how long a token lasts.
Who approves, and what the record holds. Name the person for an address change, a refund and a payment arrangement, and ask what the record shows: the screen as the model saw it, the action it proposed, the approval and the destination where the value resolved. In a SailPoint survey, 80% of organizations said agents took unintended actions, which is why the record has to show model input (How Do You Test Whether an AI Agent Can Reach Data Outside Its Assigned Task?).
The voice scope and the read-back. Ask whether the agent hears the caller, where the transcript is stored and which intents are barred from the account record, and ask where a value becomes speech, because that is where a token has to resolve and the model may see the value again.
Harvard's guidance supplies the standard for the approval line: "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard University Information Security and Data Privacy, 2026). Article 5(1)(c) of the GDPR limits personal data to what is necessary for the purpose, which is the argument for tokenizing the notes panel and the balance as well as the name (How Do You Pilot an AI Agent on Real Customer Data Without Creating a Breach?).
An answer that describes a role, a mask or a retention setting answers a different question. The answer that matters names the layer and the destination.
What does a governed environment change?
A governed environment acts at the point a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the same caller keeps CALLER_001 from the first screen to the last, and the model works on those tokens without receiving the underlying values.
For a support queue the change is concrete. The account page renders CALLER_001, ADDR_001, DOB_001 and CARD_001; the arrangement page renders DATE_001, which the agent can move; the refund form renders the order and the amount the policy allows. Real values resolve only at an approved destination, at the moment of an approved action, so the address change reaches the record the named approver confirmed and the refund reaches the card on file. A named person approves each change, and every screen, action and approval is written to a record that exports to the organization's own monitoring.
The voice step needs its own boundary, and this design does not supply one. The caller still says who they are, so verification stays outside the model and the voice agent stays away from account values. That is the honest limit of a render-layer control on a call-center workflow.
The test of the design is what an injected instruction collects. If the model holds CALLER_001 and CARD_001, a hijacked run collects placeholders, and the caller's real values stay at the destinations the approver released them to. The scope is the rendered page, and a protected browser describes the same substitution for any agent that reads one (What Is a Protected Browser for AI Agents?).
What the record shows
A support record and a call audio feed are different surfaces, and the answer changes by surface. On the screen, the property that matters is what the page gives the model before it acts: a verified session that opens the account still draws the name, the address, the date of birth, the card and the notes, and a role or a mask leaves that drawing intact. Replace those values with consistent tokens at the render layer and the agent can still move a payment date, change an address or issue a refund while the caller's identity stays in the system that verified it. The voice channel is the surface no render-layer control reaches, and a queue that says otherwise has confused a setting with a boundary. A contact center should run the same test on its own desk: open one account after verification, list every field the page draws, and ask which fields the model needs; the ones it does not need are the ones to tokenize first.
Methodology and limitations
This page rests on vendor help pages, standards guidance, preprints and the published pages of the products discussed, and the call-center desk is described as a record type rather than as any organization's deployment. Public documentation read in full gives a sound view of where each product applies its control. The vendor and guidance pages were read between October 16, 2026 and October 22, 2026.
No product was tested for this page, and a sentence that says a page does not describe something means the pages reviewed rather than the product in every configuration. Vendor features change and this page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, not an organization. A pilot of one workflow on the organization's own screens is the only test that settles what a model receives there.
Determinations about verification, consent, notices and records belong to the organization's counsel, its assessors and its own security and compliance officers.
Frequently asked questions
Can a call center use AI agents without agents seeing caller identities?
Yes for the screen work, and only when the screen is changed before the model reads it. A verified session opens the account page, and that page draws the caller's name, address and card unless the values are replaced with tokens such as CALLER_001 first. The call audio is a separate channel: a caller who says a name aloud is heard by a voice agent, and no rendered page is involved. The answer therefore holds per channel, not for the whole queue.
What does the model receive when it opens a verified caller's account?
Everything the page renders, which is usually more than the task needs. A support desktop draws the name, the service address, the date of birth, the card on file, the balance and the notes from earlier calls. Nothing in the verification step removes a field from that page, so the model holds the full record unless a control replaces values before rendering. Reading a page is not the same as querying one field, and the page is what the agent gets.
Who approves a refund or an address change the agent prepares?
A named person, at the moment of the action, with the value in front of them. The agent can prepare the change and show the record it used, and the approver confirms the destination and releases the real value. A written policy that refunds need approval and a system that blocks the refund until a person approves it are different controls. Ask which one a vendor has built, and where the approval is written down.
What record shows what the model read on each screen?
Only a record built to capture it. An activity log that says the agent changed an address tells a reviewer what happened, not what the model held when it decided. The record this page describes holds the screen as tokens, the action proposed, the approval and the destination where the value resolved. Without it, an incident review rebuilds the run from memory and from logs that were never designed to show model input.
Does a voice agent hear the caller before any screen renders?
Yes, and that is the limit of the design. Speech arrives as audio, recognition turns it into text, and the voice agent works from that text or from the audio itself. There is no rendered page to substitute on, so the caller's name and the reason for the call reach the model in the caller's own words. Keep verification in the IVR, keep account values out of the voice agent, and route changes to a screen that renders tokens.
What should be written into the contract before an agent reads caller accounts?
Four things: where values are replaced, which fields are covered, who approves each consequential change, and what record of the model's input is exported. Add the voice scope, because a contract that covers screens and stays silent on call audio has left half the workflow unaddressed. A vendor that cannot name the layer where substitution happens has not described a control this page can test, and one workflow in a pilot will show it.
How RedactSure Keeps a Caller's Identity Off the Agent's Screen
A verified caller still arrives on a screen full of values the model never needed, and roles, masks and verification checks leave the page as it is. BILL's ePayment page shows the full routing number beside four account digits, a mask built for a person's screen.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the account page draws the caller's name, address, date of birth and card, and the agent reads all of it to move one payment date. Inside: the page renders CALLER_001 and ADDR_001, the model proposes the new date, and the real address reaches the record only when a named reviewer approves it. A representative inside the environment sees the same tokens.
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 caller's name on a support record is what a queue is asked about first. Bring one account workflow and see, with test values, what the model reads on the screen, who approves the change and what the record holds. Book a demo