Skip to content
redactsure
Book a demo

Explore.

Guide · By Chris Sowa · Published
Last updated

How to Secure AI Agents That Access Customer Data

Give the model the task's fields with identifiers as tokens, inside an environment you own, so all 4 regulations that ask who received the record get the same answer.

Customer records pass through an isolated computing chamber to an ordered activity ledger.

62% experimenting · 23% scaling · 1 named person

Most organizations are experimenting with AI agents, and 23% are scaling them anywhere (CX Today, 2026). The gap between those numbers is customer data. The dispute, the claim and the ticket all run on a record that carries a name, an address and a card number, and the security team will not let a model read that record.

You are the person asked to say yes or no. The agent you are evaluating reaches the record through a connector that returns it whole, a browser extension that reads it off the screen, or a cloud computer the vendor owns. Each hands the customer to the model and to the vendor, and leaves you answering a regulator's question with a vendor's privacy page.

The Roman census taker wrote the citizen's name on the roll and the tax on the ledger, and only the ledger left the city. Your agent needs that split. It can work disputes, claims and tickets while the model receives the amount and the date in clear and the customer as CUSTOMER_001, inside an environment you own, with a named person approving every refund and record change, and every screen in your SIEM. Permissions do not change; what the AI can see does.

A connector returns the customer whole across 4,000 apps

The control you are most likely using today is a connector scope, and a scope is not exposure control. Each dot has its own cloud computer and browser and can connect to more than 4,000 apps through plugins (The Next Web, 2026). The scope decides which endpoints the agent may call, not which fields of the response the model reads, so it reads all of them.

A browser extension does the same from the other side. Claude in Chrome takes screenshots of the active tab, and all visible information, including personal data, becomes part of the context (Claude Help Center, 2026).

Property Connector or API Browser extension on the employee's machine Vendor cloud computer Customer-owned governed environment
What the model receives The record, whole The screen, in clear The page, in full The task's fields, identifiers as tokens
Where the record is held during the task The vendor's model context The employee's browser, then the vendor The vendor's cloud Your secure virtual machine
Who holds the keys The vendor The employee, then the vendor Not disclosed in the documentation You
Who approves the refund Rules in the vendor's product Automatic by default The vendor's review system, then the user A named person, on the record

Encryption at rest and a no-training clause still leave the record in the model

Two protections you already have do not reach the agent. Encryption at rest protects the stored record from whoever lacks the key; the application decrypts for the user, and the agent reads what the user sees. HHS makes the point in reverse: a cloud provider that only stores encrypted ePHI and lacks the key is still a business associate (HHS, 2026). If ciphertext creates the relationship, the decrypted screen creates it twice.

A no-training commitment is necessary and is not the exposure. Training data can be extracted from language models (Carlini et al., 2021), so the commitment matters. Dots' Business, Enterprise and Education workspaces do not use content to train models by default, and the documentation names the key holder and data location only by reference to a system card (OpenAI, 2026). The record still passed through the vendor's cloud the moment the agent read it. Both clauses govern what happens after the vendor holds the record, not whether it holds it.

4 regulations ask the same question: who received the record

4 regulations · 1 question · 0 clauses that answer it

The HIPAA minimum necessary standard limits a disclosure to what the purpose requires (eCFR, 2026). PCI DSS scoping brings every system that stores, processes or transmits cardholder data into scope (PCI SSC, 2026). The GLBA Safeguards Rule requires oversight of service providers (eCFR, 2026). FERPA's school official exception requires direct control over the use and maintenance of education records (eCFR, 2026).

Four regimes, one question: who received the customer record, and under whose control. A model that received the record whole is a recipient. A vendor whose cloud held it is a service provider to oversee, a business associate to contract with, or a system for the assessor to scope. The answer you want to give is that the model received the task's fields and CUSTOMER_001, in an environment that was yours. That answer depends on a mechanism, not a clause.

The model receives CUSTOMER_001 and the amount in clear

The design that passes is Least Exposure: the principle that for each piece of work, the AI receives exactly the data the task requires and nothing more, enforced before any model reads the screen. A dispute runs on the amount, the date and the order. A claim runs on the loss date and the coverage code. The name, address and card number sit on the same screen, and the task does not run on them.

The mechanism is render-layer tokenization: replacing sensitive values with consistent stand-in tokens at the point where a screen is rendered, before any AI model reads it, so the model works with SSN_001 and ACCT_001 and real values resolve only at approved destinations at the moment of action. CUSTOMER_001 on the CRM screen is CUSTOMER_001 on the billing screen, so the agent lines the customer up across systems without holding the customer.

Where you tokenize decides what the model sees.

Property Redaction at the AI gateway Tokenization in the database vault Tokenization at the render layer
Where it acts On the prompt, after the agent read the screen On the stored column On the screen, before any model reads it
What the model receives Identifiers already in context, then a filter Whatever the application detokenized for the user The task's fields, identifiers as tokens
What the assessor finds the model holding The PAN The PAN Tokens

The PCI Council's tokenization guidance treats a system that holds only tokens differently from one that holds the PAN (PCI SSC, 2026); your assessor decides where the model lands. This is where the PII Wall comes down: the point in an AI program where the valuable workflow turns out to run on data the security team will not let a model see, and the project shrinks or stops.

A successful injection collects tokens, and the refund still waits

Indirect prompt injection through observed content is the attack that matters here (Greshake et al., 2023). Anthropic reports attack success under 0.08% for Claude in Chrome (Claude Help Center, 2026). OpenAI combines model safeguards, tool restrictions, checks before actions and monitoring (OpenAI, 2026). Those are detection rates. The question is what the attack collects when detection misses.

In the governed environment, a successful injection collects CUSTOMER_001 and CARD_001: strings with no customer behind them.

The other half is Supervised Delegation: a named person grants the access, chooses the applications, confirms what is tokenized, can watch and pause the run, and approves every consequential action, on the record. An injection that tries to send a refund to a new card arrives at the person as a request, and is declined.

The person also chooses where the agent may go, which makes it a tethered agent: an agent that works only inside the governed environment a named person connected it to, on the applications that person chose. Compare the automatic-approval default a browser extension ships with (Claude Help Center, 2026): an agent that approves itself is an agent whose injection approves itself.

An AI Control Record holds tokens, not a second copy of the customer

The audit trail is where careful programs store the customer again: a screenshot in a vendor's activity view is the customer record, in clear, in a second cloud. Dots' Activity View lets the user follow, redirect or stop work (OpenAI, 2026); it is the vendor's record.

The record to keep is an AI Control Record: the record of every screen the agent saw as tokens, every action, every approval with a name, exported to the customer's own monitoring. An auditor reads what the agent did on CUSTOMER_001's account and who approved the refund, with no second copy of the identifiers. GLBA asks you to oversee the service provider (eCFR, 2026); the record is the oversight.

This is where separation of model and control earns its place: the principle that the environment deciding what an AI agent sees and who approves what it does is owned by the customer and independent of whichever model performs the work. The vendor that is the model should not also be the judge of the model. With the record, keys and approval in your environment, you can change models without changing controls.

6 Rules for securing an agent on customer data

Write the two lists before the first run

List the fields the first workflow runs on, then everything else on the screen. The first list stays in clear; the second becomes tokens.

Before: The agent reads the dispute screen as the analyst sees it: name, address, card number, amount, date, order.

After: The agent reads CUSTOMER_001, ADDRESS_001, CARD_001, the amount, the date and the order.

Tokenize at the render layer, not the gateway or the database

A gateway filter runs after the agent read the screen. A database vault is silent on the screen the application already detokenized. Only a change at the read works.

Test: Open one customer screen through the agent and read the model's stream. If the customer's name appears, the tokenization sits in the wrong place.

Keep the environment and the keys yours

The HHS test and the GLBA test both turn on who held the record. A customer-owned secure virtual machine with customer-held keys keeps the chain at one link.

Question counsel asks Answer that passes
Whose environment held the screen? Ours
Who holds the keys? We do
Did any vendor receive the customer record? No, the model received tokens

Name the person before the first run

The approver is named in the policy before the agent opens a screen. A role is not a person.

Before: "The claims team approves payments."

After: "The named person confirmed the policy on October 9, 2026 and approves each claim payment on the record."

Make every refund, payment and record change wait

Each waits for the named person, who sees the same tokenized stream and can pause or take over.

Action Who decides
Read the dispute The agent, on tokens
Draft the resolution The agent, on tokens
Issue the refund to CARD_001 The named person
Update the customer's record The named person

Export the record to your SIEM, as tokens

Every screen as tokens, every action, every approval with a name, in your SIEM on your retention terms. No screenshots in a vendor's activity view.

Test: Pull one run from the SIEM. It shows CUSTOMER_001, the action, the approval and the name.

How to choose where the agent runs on customer data

  • If the workflow touches PHI, cardholder data, nonpublic financial information or education records, run the agent in a customer-owned governed environment and give the model the task's fields with identifiers as tokens.
  • If the vendor cannot name the key holder for its cloud computer, treat its agent as a recipient of the record and keep customer systems away from it.
  • If your only control is a connector scope, assume the model receives the record whole and move the control to the read.
  • If the agent would run in the employee's own browser, assume the screen reaches the model in clear and keep customer screens out of it.
  • If the workflow ends in a refund, payment or record change, name the approver before the first run and reject any design where the agent approves itself.
  • If you expect to change models within the year, keep the tokenization, the approval and the record in an environment you own.

The checklist

Check Pass Fail
Read the model's stream for one customer screen CUSTOMER_001 for the name, the amount in clear The customer's name appears
Locate the keys Held by you Held by the vendor or not disclosed
Locate the environment that held the screen Your secure virtual machine A vendor's cloud computer or the employee's browser
Open the confirmed policy Carries the named person's name and the two lists Carries a role or no name
Count service accounts created for the agent Zero One or more, with API keys
Issue a refund through the agent Waits for the named person Completes on the agent's own approval
Pull one run from the SIEM Tokens, actions, approvals with names Screenshots with real values, or no export
Plant an instruction on a test page Collects tokens, action stops at the person Collects identifiers or completes the action

Questions

Does encrypting the database protect customer data from the agent?

No. Encryption at rest protects the stored record from whoever lacks the key. The application decrypts for the user, and the agent reads what the user sees. HHS makes the same point in reverse: a cloud provider holding only encrypted ePHI without the key is still a business associate (HHS, 2026). The control has to act on the screen at the read.

Can the agent still do the work if it never sees the customer's name?

Yes. The task runs on the fields: the amount, the date, the order, the loss date and the coverage code. The customer is CUSTOMER_001 on every screen, so the agent lines up the CRM record and the billing record without holding the customer. Real values resolve at the approved destination at the moment of an approved action, so the refund reaches the right card.

Is a vendor's no-training commitment enough?

It is necessary and it is not the exposure. Training data can be extracted from language models (Carlini et al., 2021), so the commitment matters. But the record was disclosed to the vendor when the agent read it, before any training decision. Dots' business workspaces do not train on content by default (OpenAI, 2026); the record still passed through the vendor's cloud.

Does a connector scope limit what the model sees?

No. A scope limits which endpoints the agent may call. A customer endpoint returns the customer whole, and the model reads every field of the response. With more than 4,000 apps reachable through plugins (The Next Web, 2026), the scope is a list of doors, not a rule about what comes through them. Exposure control acts on the fields before the model reads them.

Does the agent need a new service account for each customer system?

Not when it works the screen. A tethered agent works under the permissions the person already holds, on the applications a named person chose, so no new credential is created and nothing changes in the identity provider. A connector path needs a service account or API key per system, each with scopes to review and rotate. What changes is what the AI sees.

What does a successful prompt injection get?

Tokens. Indirect injection through observed content is the documented attack on agents that read pages (Greshake et al., 2023). When the model holds CUSTOMER_001 and CARD_001, an injection that tells it to send the record elsewhere sends tokens that resolve nowhere. An injection that tells it to issue a refund produces a request that waits for the named person, who declines it. The prize is a string.

What should we ask a vendor before giving its agent customer data?

Five questions. What does the model receive from a screen or a connector? Where is the record held during the task, and who holds the keys? Who approves a refund or record change, and can that person watch the run? Does the record of the run export to our SIEM, as tokens? Can the model change without the controls changing? A vendor that answers all five from its documentation has a reviewable design.

Methodology

What this page rests on. Vendor documentation from OpenAI and Anthropic, read as of October 9, 2026, quoted and dated; 45 CFR 164.502, 16 CFR Part 314 and 34 CFR 99.31; HHS cloud guidance; the PCI Council's scoping and tokenization guidance; McKinsey's State of AI figures as reported by CX Today; and Carlini et al. (peer-reviewed) and Greshake et al. (preprint), cited for the findings each is known for.

What was not tested. No hands-on testing of any named product was performed for this page. Vendor features and defaults change with releases, and this page carries its date. The dispute, claim and ticket workflows are illustrations. The 0.08% figure is Anthropic's own reported result.

Whose determination it is. Whether a design meets the minimum necessary standard, PCI scoping, the Safeguards Rule or FERPA's direct-control test is a determination for the organization's counsel, its assessor and its security and compliance officers, on its own deployment and record.

How RedactSure does this

RedactSure runs the agent inside a governed environment the customer owns: a secure virtual machine in the cloud the customer's posture requires, on hardware-encrypted enclaves, with keys the customer holds; RedactSure holds ciphertext it cannot read. The agent works the CRM, billing system, claims platform or EHR through their screens, with no integration work and no change to permissions.

1 named person · 0 new service accounts · 4,000 apps a connector opens

Every identifier chosen by policy (names, SSNs, MRNs, account and card numbers, dates of birth, addresses) is replaced by a consistent token at the render layer before any model reads the screen. The Planner writes the per-task policy; a named person confirms it and approves every refund, payment and record change while it runs. Real values resolve only at approved destinations at the moment of action. 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: Claude, GPT, Gemini or open-weights models, swappable without moving the controls. Deployments are in pilot. The work gets done. The data stays hidden.

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.