Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an Outsourcer Prove to Clients That Its AI Agents Never Saw Their Data?
Only with a per-run record of what the model received on each screen, which is what an AI Control Record is for. Ask for one run's page with its tokens, the mapping held outside the model, and the name of the person who approved the action.
A client hands an outsourcer the work and the records, and the outsourcer hands back a service level, an invoice and a promise that its agents never read the client's data. Every BPO, collections shop and shared-services center selling agent capacity says a version of it, because the client's alternative is to assume the worst about every screen an agent opens. The question a client can put on the table is narrower and harder: what the outsourcer holds that shows what the model received on a given run.
An activity log will arrive instead. It is a real record, produced by a real system, and it will show the run, the agent, the endpoint and the submission. The payroll correction screen that carried an employee's salary and bank account is not in it, because the application wrote the log and the model's context was assembled somewhere else. A log can be complete and still leave the client unable to answer the one question it asked, which is the difference between evidence and an assurance.
The record type on this page is a payroll correction in a shared-services queue: a client's employee record, a rate change and a bank account, opened by an agent and approved by a named supervisor. A client should demand a record at the model boundary, because the artifacts an outsourcer already produces stop at the application that wrote them.
Key findings
- For a client to accept that an agent never read its data, every value on a rendered page would have to be replaced with a consistent token before any model reads it, and the run record would have to show that token beside the action and the name of the person who approved it (What Is an AI Control Record?).
- It would also require a named person approving each submission and a record that exports to the client's own monitoring, because human approval "is a standard way to limit egregious failures" (Shavit et al., 2023).
- None of the pages reviewed describes a record of the screen the model was given; the audit reports and activity logs an outsourcer already produces name the user and the action, not the values that reached the model (How Do You Audit What an AI Agent Saw and Did?).
- Columbia's DAPLab states the limit at the environment: "access control governs who can touch data, integrity constraints govern what gets stored, but neither governs how data flows and is used during agentic execution" (DAPLab, 2026).
- Siddiqui and colleagues show that "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025).
- Harvard's guidance lists seven risk categories for AI-enabled systems, including Context and Memory Leakage, and tells organizations to "Treat prompts, outputs, logs, and retained context as organizational data" (Harvard, 2026).
What would a record of what the model received contain?
The artifact is a run record. For a payroll correction in a shared-services queue it holds the run identifier, the model and its version, the page the model was given with EMP_014 where the employee's name sits and ACCT_008 where the bank account sits, the action the run proposes, the name and role of the person who approved it, and the time of each step. The values are absent by design; the mapping from EMP_014 to the employee sits in a store outside the model, under custody rules the client can review.
The values matter because the screens in this work carry them by default. A financial aid record in a student system carries "The original Social Security Number entered on the FAFSA by the student" (Lone Star College, 2026), and an HHS request file holds SSNs that "may be contained in some of the requests" (HHS, 2026). A record of such a screen that shows the digits has published them to everyone who can open the record. A record that shows SSN_004 is evidence a client can read without becoming another custodian of the data.
A screenshot is not that record. It is the page with the values, and handing it to a client repeats the exposure the client is asking about. A summary written after the run is not that record either, because the party being audited writes it. The run record is produced during the run, field by field, at the point the page is rendered to the model; the fields a client should specify are set out in How to Set Up an AI Control Record for AI Agents.
One row is enough to test. Take the token the record shows for a salary and resolve it in the mapping. If the resolved value matches the source system while the record itself never held it, the record demonstrates substitution.
Why does an activity log not show what the model read?
An activity log is written by the application, and it answers the question the application can see. A line records run 8841, the agent identity, the endpoint /payroll/correction, the submission and the response code. The page the agent's browser assembled for the model is a different object, held for a different purpose.
The gap is wider than the outsourcer's own log: of the 86 AI security products reviewed, the 36 that document model input keep prompts, conversations or request payloads at their own gateway, and a record of the screen an agent worked from is not among them (How Many AI Security Products Control What an AI Agent Sees?).
HHS describes the ceiling of that record in its own assessment: "User access will be controlled by role-based access privileges" and "Auditing features will record when a user accesses the system and the actions taken" (HHS, 2026). A request body captured at the API edge is what the application sent, not what the model was shown before it decided to send it.
A defense at another layer cannot fill the gap. DAPLab's argument is that "access control governs who can touch data, integrity constraints govern what gets stored, but neither governs how data flows and is used during agentic execution" (DAPLab, 2026). Siddiqui and colleagues model that flow with labels, carrying "only the input labels that were influential in generating the model output" because strict taint tracking "is too conservative for applications where LLMs operate on inputs retrieved from diverse sources" (Siddiqui et al., 2025). A label is a policy about a source; the record a client needs is an observation of a run.
Firewalls sit at the tool interface. Bhagwatkar and colleagues report that a tool-input and tool-output firewall "achieves perfect security with high utility across all four public benchmarks" (Bhagwatkar et al., 2026). The same paper finds those benchmarks "easily saturated by a simple approach," so the score is evidence about the benchmark (Bhagwatkar et al., 2026).
DAPLab's incident list includes "Cursor's agent deleted PocketOS's production database via a single rogue API call," an action visible because it destroyed something (DAPLab, 2026); a read that put a salary into a context left no comparable trace.
What do the vendors themselves say?
Three pages from the systems in this work describe controls on the record, and each one governs a step other than the screen.
Workday's compensation manual states that "Eligibility is NOT evaluated during this business process" and that security is set per component (Workday, 2026). The manual adds that "a manager has security to change salary or hourly rates, but not a bonus plan" (Workday, 2026). It is a permission model for the business process, and the question of what a model reads on the entry screen is outside it.
ADP's Direct Deposit API guide defines the routing field as "Indicates the Routing Number to which the Direct Deposit applies" and the account field the same way (ADP, 2026). That is a field contract for an integration. It names the values the API moves and the roles that may call it, and it sets no approval step for a deposit change. A rendered page is outside its scope.
HHS's assessment records that "User access will be controlled by role-based access privileges" and that "Auditing features will record when a user accesses the system and the actions taken" (HHS, 2026). The same assessment notes that "SSN may be contained in some of the requests" (HHS, 2026). Role and audit govern who opens a case and what they did. They do not describe the values a model would receive if it opened the same case.
| Question | Workday, per its manual | ADP, per its guide | HHS, per its assessment |
|---|---|---|---|
| What the page controls | Which security group may change a compensation component | Which fields the integration carries and which roles call it | Who may open a case and what the audit records |
| What the model receives | Outside the page | Outside the page | Outside the page |
| Who approves | The business process permission | The calling role, not an approver | The user's access, not an approval |
| What a client should ask for | The screen record beside the change | The screen record beside the API call | The screen record beside the audit entry |
What should a client ask for in writing?
The ask is a specification, not an assurance. Six items belong in the contract or the audit annex, and each one is checkable.
| Ask | What the answer should name | Why it matters |
|---|---|---|
| The screen | The page the model was given, rendered with tokens | A summary written later is not evidence |
| The mapping | Where the token table lives and who can open it | A token without its mapping proves nothing |
| The approval | The named person, role and time for each action | The client can check the name against its roster |
| The export | The record format and the client's monitoring endpoint | The client should hold the record |
| The scope | The rendered pages covered, and what is outside | API calls and file drops are a different path |
| The retention | How long the record is kept and who deletes it | The record outlives the run |
The shape of an evidence packet is familiar from other disputes. Stripe's dispute documentation asks for evidence by category, limits the packet to "the combined maximum of 4.5 MB," and warns "You've only one opportunity to submit your response" (Stripe, 2026). A client asking an outsourcer for proof should specify the packet with the same precision, because a run cannot be re-created after the fact.
Approval is the item clients most often leave vague. Human approval "is a standard way to limit egregious failures" (Shavit et al., 2023), so the record should carry a name for every submission, not a shared service account. What Is Supervised Delegation? describes that design, and the contract language follows it.
The audit report is not the packet. A SOC 2 report describes controls over a system and the criteria an auditor tested, and the agent working inside the system falls within the controls being evaluated, as Which SOC 2 Controls Apply to AI Agents? sets out. It does not contain one client's page. The per-run record is the artifact that does.
What can the client check without trusting the outsourcer?
Four checks reduce the trust the client has to extend.
The first is a canary. The client supplies test values for a test record, runs one correction, and compares three lists: the source values, the tokens in the run record and the strings in the agent's transcript. If a canary appears in the transcript, the substitution failed at the screen. If only the token appears, the run is working as described.
The second is custody of the mapping. If the outsourcer holds the record, the token table and the environment, the client is auditing the party that produced all three. The mapping belongs with the client or a neutral party, and the export belongs in the client's monitoring.
The third is the approver. The record should carry a name and a role for every submission, and the client can check that name against its own roster and the approval matrix it agreed. The same whitepaper sets a higher bar: "at least one human entity is accountable for every uncompensated direct harm" (Shavit et al., 2023).
The fourth is sequence. The timestamps should order the screen, the approval and the action, and the client can test that order on one closed run. How Do You Test Whether an AI Agent Can Reach Data Outside Its Assigned Task? turns the same method on the agent's reach, and How Do I Prove a Credential Was Never Exposed to an AI Agent? shows where a vendor's statement stops short of a record.
None of the four checks requires the client to believe a sentence in a sales deck. Each requires an artifact the client can compare with its own data.
What does a governed environment change?
A governed environment is a control class that acts where a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the payroll correction agent works with EMP_014 and ACCT_008. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each submission. Every page the model was given, every action and every approval is written to a record that exports to the client's own monitoring.
For a client, the change is the artifact. The client no longer asks the outsourcer to promise that the agent never had the data; the client asks for the record of the run and checks the tokens against the mapping. An assurance becomes a document with a date, a run identifier and a name on it.
The change has a boundary. It covers the pages the agent renders in the applications it uses, including the client's systems and the outsourcer's own tools. A direct API call, a file dropped into a working directory, a terminal command or an MCP tool call is outside it, and an outsourcer that moves client data through those paths needs a separate control and a separate record.
The record has limits too. It shows what the model was given, not what a person saw before or after; it shows the approval, not whether the approver read the page; and it holds tokens, so the custody of the mapping decides how much the client can verify. A governed environment makes the evidence possible, not the outsourcer's other controls irrelevant.
What changes for the client is the question to ask. Instead of whether the agent can be trusted, the client asks which values were replaced, who approved the action and where the record lives. What Is a Protected Browser for AI Agents? describes the rendering control in the same terms, and the comparison is one a procurement team can run on paper.
What the record shows
A client's evidence rests on what the model was given, who approved the action and what record leaves the outsourcer's system. An activity log answers a different question, and a promise answers none. The useful conclusion is narrow: an outsourcer can show that its agent never read the client's data only where the values were replaced before the model read the page and the run record holds the token rather than the value. HHS's assessment is the clearest illustration of the gap, because its audit features record when a user accesses the system and the actions taken, which is a record of access and action rather than of what a model received (HHS, 2026). A client should run one closed payroll correction with test values and compare three lists: the values in the source record, the tokens in the run record and the strings in the agent's transcript. A canary in the transcript is the finding; a token is the control holding.
Methodology and limitations
This page rests on peer-reviewed research on information flow and prompt injection, an OpenAI governance whitepaper, vendor documentation from Workday, ADP and Stripe, a regulator's privacy assessment, a university financial aid guide, guidance from Harvard and a position paper from Columbia's DAPLab, together with RedactSure research pages. Public documentation read in full gives a sound view of where each system applies its control. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries the date for its page.
None of the products on this page was tested for it. "Not described" means the pages reviewed; the vendor pages concern permissions, fields and audit features, not a record at the model boundary. Vendor features change and the page carries its date. The example is a record type, a payroll correction, not an organization. RedactSure is deploying now with enterprise and government customers.
Determinations about whether an arrangement meets a client's contractual or regulatory obligations belong to counsel and the organization's compliance officers. Nothing here replaces a pilot of one workflow on the client's own records.
Frequently asked questions
Can an outsourcer prove to a client that its AI agents never saw the data?
Only with a per-run record of the page the model was given, with each client value replaced by a consistent token before the model read it, and a named person approving each action. An activity log, a SOC 2 report and a statement of intent each answer a different question. Ask for one closed run and compare the token in the record with the value in the source system; the comparison is the proof. A vendor that cannot produce the run has nothing to compare.
What should a client ask for in writing?
A written ask should name six things: the page the model was given with its tokens, where the token mapping lives, the named approver for each action, the export into the client's monitoring, the rendered pages in scope, and how long the record is kept. Each item is checkable. A vendor that answers only the scope and the retention has described a contract, not a record. Ask for a sample run and the mapping, not a description of the process.
Do access logs and screenshots prove what the agent read?
No. A log records the action and the account; a screenshot records the values, which is the exposure the client is trying to avoid. Neither shows what the model was given without also showing what the client wants withheld. The record that does is built from tokens at the point the page is rendered, and it has to leave the outsourcer's system to be useful. The only useful test is a canary the client chose.
Who should approve an agent's action on a client record?
A named person at the outsourcer, with a role the client agreed, for every submission and every record change. Human approval, as the OpenAI whitepaper puts it, "is a standard way to limit egregious failures," and the accountability has to land on a person rather than a queue. The client should see that name in the run record and be able to check it against the roster it holds. A queue is not an approver.
What does the client's auditor need from the record?
The page the model was given, the action proposed, the approval with its time, and the token mapping under the client's custody, exported in a format the client's monitoring can read. An audit feature that records access and actions is not a record of what the model received. An auditor can test one run against the source system, and that test is the evidence. Without the mapping, the tokens are a private code only the outsourcer can read.
Where does the record stop?
At the rendered page. A direct API call, a file drop, a terminal command or an MCP tool call is outside the control, and the outsourcer needs a separate record for each path it uses. The client should ask which path the work takes, because the page record covers the browser and not the rest of the run. That distinction belongs in the scope annex. Everything past the browser needs its own evidence.
How RedactSure Makes the Rendered Screen the Evidence
An outsourcer that cannot show the page has only its word and a log of actions. HHS's own audit features record when a user accesses a system and the actions taken, not the values a model received.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent reads the name, salary and bank account, and those values stay in its transcript. Inside: the page renders EMP_014 and ACCT_008, a named supervisor approves, and the real values resolve only at the approved action.
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
An outsourcer's evidence is only as good as the screen it can produce. Bring one client record and see, with test values, what the model receives, who approves the action and what the record holds. Book a demo