Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
How Do You Run Claude Code on a Repository With Real Customer Data?
Replace the records before Claude Code arrives: seed the test database from fixtures, add a permission rule for each export path, and declare the service credentials as masked. Check what the model receives when a task needs the real record, since the sandbox covers shell commands and masking swaps a credential on an outbound request.
A customer record reaches a coding agent by more than one route. It sits in the fixture file the test suite loads, in the rows a seed script writes into the test database, in the export a developer saved last week, and on the admin page the agent opens to check the seeded record. Claude Code is asked to fix a failing test there, and the model reads whatever those routes hand it. The preparation a team controls is concrete: a seed built from fixtures rather than a production dump, a permission rule on each path that exports customer data, and service credentials declared as masked rather than pasted into a file the agent reads (Anthropic, 2026). The order matters: a rule written after the first run arrives after the first read. The preparation stops where a task needs the real record, and that is the part worth planning for: an environment that shows the model placeholders is what the task requires, and Claude Code's documentation describes masking for a credential on an outbound request, not for a value on a rendered page.
Key findings
- For Claude Code to work a repository of real customer records, the values on every page it reads would have to be replaced with consistent tokens before the model reads them, released only at an approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each record change and a record of what the model received, and human approval is the documented way to limit egregious failures (Shavit et al., 2023).
- Claude Code's published documentation does not state that values in a query result, a fixture file or a rendered page are replaced before the model reads them; it describes a sandbox that covers shell commands, with masking that substitutes a credential on an outbound request (Anthropic, 2026).
- Anthropic's engineers report that sandboxing "safely reduces permission prompts by 84%" and that "effective sandboxing requires both filesystem and network isolation" (Anthropic Engineering, 2025).
- Serenari and Lee found that swapping identifiers for consistent pseudonyms and restoring them afterward "reduces semantic utility errors by a factor of 5 compared to baseline techniques" (Serenari and Lee, 2025).
- A registry measurement drew on "98,380 skills collected from two major registries" and found skills that "execute with full user privileges," so installed tooling shares the developer's reach (USENIX Association, 2026).
What does the agent read when a test database is seeded from production?
The seed is the first place the record appears. A seed script that copies a production dump writes real names, addresses and card numbers into the test database, and the dump stays in the repository until it is deleted. An agent asked to reproduce a failing test reads the script, runs it and queries the result, so the rows arrive as text. A sandbox limits what the agent can touch, not what a permitted query returns (Does Sandboxing an Enterprise AI Agent Protect Your Data?).
Thomas Livers, Associate Athletic Director for IT Services, University of North Carolina at Chapel Hill, described a network limit of that kind on a HAL podcast: "They talk to a set up DNS server that only has the entries that they need to talk to" (HAL Transcript: Thomas Livers). That limit narrows where a permitted query can send data, and it does not change what the query returns to the model.
The second place is the page. Once the seed runs, the agent often opens the admin console to see whether the record renders, and there the customer appears as a page: a balance, a status, an address.
The scope needs stating. A governed browser environment covers what an agent reads and does on a rendered page: a dashboard, a console, a settings page, a form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, and nothing here should be read as a browser control governing a shell. The seed script, the dump and the query sit on the far side of that line, which is why the data has to change; the admin page sits on this side, and it is where the question ends (What Is Render-Layer Tokenization?).
What replaces the records before the agent reads them?
Three moves cover most of the ground. The first is a fixture seed: rows written or generated for every table the tests touch, with the shape of the production data and none of its values, so a merge test still finds two addresses and neither belongs to a customer.
The second is a permission rule on the paths that export records. A sandbox deny entry is the wrong one: "A denyRead entry doesn't stop the Read tool," and Read, Edit and Write "follow permission rules instead," so a Read deny rule naming the path is what keeps a dump out of the model's context (Anthropic, 2026). Deny entries under sandbox.credentials affect sandboxed Bash commands only (Does Claude Code Read My .env File?).
The third is a masked credential for the services the tests call. With mask, the sandboxed command sees a sentinel and the local proxy substitutes the real value only on hosts in injectHosts, so a test run reaches a payment sandbox without the model holding the key (Anthropic, 2026). Placement matters: sandbox.credentials is honored from user and managed settings and ignored in .claude/settings.json, so a rule committed with the code never applies (How Do I Keep API Keys Out of Claude Code's Context Window?).
What do the vendors themselves say?
Anthropic's sandboxing page describes a sandbox for shell commands, with Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks outside it, and a mask setting under which a sandboxed command sees a sentinel while a local proxy substitutes the real value on hosts in injectHosts (Anthropic, 2026). The engineering post states the design goal: "effective sandboxing requires both filesystem and network isolation," and reports that sandboxing "safely reduces permission prompts by 84%" (Anthropic Engineering, 2025).
What the pages do not describe is a control on what a permitted read returns. An allowed Read places the file in the model's context, an approved command prints its result, and a page renders in full (Anthropic, 2026).
| Dimension | Claude Code, per its documentation | What a buyer should verify |
|---|---|---|
| Where the control sits | A sandbox for shell commands, with credentials under sandbox.credentials, and Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks outside it | Which commands it governs, and which paths it never reaches |
| What the model receives | Whatever an allowed Read, an approved command or a page returns | What a seed query and an admin page contain |
| Where the setting is honored | User and managed settings and the --settings flag; ignored in the repository's own settings file | Where the rule lives, and who changes it |
What does the agent still read when the task needs the real records?
Some tasks do not survive a fixture. A duplicate record comes from a particular sequence of imports, and the team lets the agent read the real record. A student account summary shows what the page carries: "The Account Summary page provides a high-level view of your student account, including:" the total owed, any holds and a payment portal (North Carolina Central University, 2026).
An application can mask a field on its page. The student system's knowledge base says that "All SSNs initially display as XXX-XX-XXXX" until a user is granted the right to view them (Infinite Campus, 2026). It changes the page and not the row: the value arrives unmasked through the query the same agent may run, so a placeholder has to survive the round trip, the property Serenari and Lee measure (Serenari and Lee, 2025).
Trustworthy automation "cannot be solved at a single layer of the stack" (Columbia University, 2026), and registry skills "execute with full user privileges" (USENIX Association, 2026). A token projected into a session a host substitutes for stays usable while unreadable (Is It Safe to Give Claude Code My GitHub Token?), and masking reaches the same idea from the other side (Can a Coding Agent Use a Credential It Cannot Read?).
What should a security team ask for in writing?
These are questions a repository review can answer from documentation before anyone runs a task. Each names a control a vendor describes, and each has an answer a team can put before an assessor.
| Ask | What the answer settles | What to write down |
|---|---|---|
| Which rule keeps the export path out of the file tools | Whether it is a permission rule or a sandbox deny entry | The path and the file it lives in |
| Whether a query result is masked | Whether any control inspects what comes back | Its output for one query run as the agent's role |
| What the model receives from a rendered screen | Whether the admin console is covered at all | The fields on the page, before and after any mask |
| Where a masked credential may be substituted | Whether the host list matches the service the tests call | The host list and scope |
| Who approves a record change | Whether approval sits outside the model | The approver's name and the change |
| What record exists of the reading | Whether a reviewer can reconstruct the run | The export and where it lands |
The screen question is the one a repository team skips, because the seed and the rule are visible while the page is not. Ask what the model receives from a rendered screen the agent opens after the seed, since that page sits outside every control in the table.
The review of 15 AI agents found none that describes replacing the customer data a working page shows with tokens the agent can work with, from vendor documentation read between October 22 and October 27, 2026 rather than tested behavior (Do AI Agents Ask Before Making a Payment?).
What does a governed environment change?
A governed environment changes where the decision is made. Values chosen by policy are replaced with consistent tokens at the point a screen is rendered, before any model reads it, so the run works with CUST_014 and ACCT_014 and the join between two records survives. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each record change, and every screen as tokens, every action and every approval is written to a record the organization exports to its own monitoring. None of that depends on the agent behaving well.
For a repository task it adds the half the seed and the rule cannot reach. Those act on files and commands, and the record still arrives in full the moment an agent opens the admin console to check a seeded row. A control at the render keeps the join and loses the value: the agent sees one customer across three screens, and none of those screens carries the card number.
Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, which is why the seed and the rule stay in place underneath it. The comparison with Claude Code sets out where each control acts (RedactSure vs Claude Code: 2026 Comparison & Alternative).
What the record shows
A fixture seed, a permission rule on the export paths and a masked credential keep a production dump out of a coding agent's reach, and each acts somewhere other than the page that renders the record. The preparation is worth doing, and it stops where a task needs a real customer's row on a screen. Claude Code's documentation describes a sandbox for shell commands, file tools that follow permission rules, and masking that substitutes a credential on an outbound request; it does not state that a value on a rendered page is replaced before the model reads it. A team can settle the question in an afternoon. Seed one test database from fixtures, add a Read deny rule for the export path, then run one task that opens the admin console for a seeded record and write down what the page showed the model and what the query returned.
Methodology and limitations
This page rests on Anthropic's Claude Code sandboxing documentation and the engineering post beside it, two knowledge base pages from student information systems, one preprint on pseudonym replacement, a registry measurement of agent skills, a Columbia lab page, and existing RedactSure research. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where a product applies its control.
None of the products on this page was tested for this page, and "not described in the pages reviewed" means the recorded facts for that page do not contain it. Vendor features change and the page carries its date, so treat a later release as unreviewed until the task above is repeated. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a test database seeded from production, and not an organization. Determinations belong to counsel, assessors and the organization's security and compliance officers.
Frequently asked questions
How do you run Claude Code on a repository with real customer data?
Replace the data before the agent starts, then check what a task that needs the real record can still read. A fixture seed, a Read deny rule on each export path and a masked credential for the services the tests call cover the repository. They do not cover the page: an admin console opened after the seed renders the record in full, and masking substitutes a credential at a listed host rather than a value on a page.
Can Claude Code read a test database seeded from production?
Yes, wherever a permitted command or the Read tool can reach it. The sandbox covers shell commands, so a command run inside it can query the database and the rows land in the model's context. The Read tool follows permission rules rather than sandbox settings, so a connection string or a dump file is readable unless a rule names its path. Neither inspects what comes back.
Does the sandbox keep customer records out of the model's context?
No. The documentation scopes the sandbox to shell commands and places Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks outside it, and the mask setting substitutes a credential on outbound requests to hosts in injectHosts. Those controls govern what a command may touch and where a credential may travel. A permitted read still returns its file, and a page still renders, so the record reaches the model either way.
What should the model receive instead of the real records?
A consistent token per value, for the whole run. CUST_014 stays CUST_014 across the query, the fixture and the admin page, so the agent can still join two records and follow a task that depends on the link. Real values resolve only at the destination a named person approved, which means the substitution has to sit where the page is rendered, because a file rule leaves the rendered value untouched.
Who approves a change the agent makes to customer data?
A named person, in any design that answers the question, and the approval has to sit outside the model. Anthropic's documentation describes permission rules and an approval prompt for commands, which decide what the agent may run; none records a person's decision about a record change. The research record treats human approval as a standard limit on egregious failures, a floor rather than a control on what the model read.
What record shows what the agent read?
In Claude Code, the transcript and the command output are the record, and they show what the session did rather than what each page showed the model. A governed environment exports a record of the screens as tokens, the actions taken and the name on each approval, which an assessor can compare against the repository's own rules. Ask for that export before the first task and keep it with the seed version the run used.
How RedactSure Keeps a Seeded Test Database Out of the Model's View
A fixture seed and a permission rule stop the dump, and a task that needs the real record still hands the agent every value the admin page renders.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent signs in to the admin console, opens the seeded customer record, and the page prints the card number and address into the model's context for the run. Inside the governed environment: the same page renders CUST_014 and CARD_014, and the real values reach the payment form only when a named reviewer approves the change.
RedactSure is deploying now with enterprise and government customers. Anthropic's engineers report that sandboxing safely reduces permission prompts by 84 percent, a count of prompts avoided rather than values protected.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
The page after the seed is where a repository task stops being safe to delegate. Bring one repository task and see, with test values, the page the model receives and the approval it waits for. Book a demo