Skip to content
redactsure
Book a demo

Explore.

Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated

Can a Startup Use AI Agents on Production Customer Data?

No, not on a production login that renders real customer records, because the agent receives every value the screen draws and the founder's own access is what opened it. Replace those values with consistent tokens before the model reads the screen, have a named person approve each consequential action, and keep the record the questionnaire asks for.

A credential reference travels from a browser record through a bounded route to a separate API destination.

A startup reaches production customer data through a short list of logins, and the founder usually holds the widest one. That arrangement works while the company is small: the person who built the product can open any account, correct a bad record and answer a customer without waiting for a support rota. It becomes a security question the moment an agent is attached to that login, because the agent does not read the way a person reads. A person opens a customer page for one field and ignores the rest. An agent asked to change a billing address receives the whole rendered page, including the card on file, the tax identifier and the notes from the last call, and it carries them into the context that plans its next step.

The exposure is not hypothetical for a company that sells to other companies. The first enterprise contract arrives with a security questionnaire, and the questionnaire asks which systems the agent can reach, what data it sees, who approves its actions and what record the vendor can produce. A startup that answers from memory is describing a design nobody checked. The answer that survives review is written down, and it is about the screen: which values the model receives when the page renders, which person approves a change, and where the record of the run lives.

One record carries the question: a founder's production session on a customer account, opened to correct an address. The page draws far more than the address, and the rest of it is what the buyer's questionnaire will ask about.

Key findings

  • For a founder's production session to be safe on customer records, the values on the rendered page would have to be replaced with consistent tokens before the model reads it, so the agent works CUST_014 and ACCT_002 where the record holds a name and an account number (What Is Render-Layer Tokenization?).
  • It would also require a named person approving each address change, refund and payment, and a record of what the model received on every screen of the run (Does an AI Agent Need Approval Before Submitting a Transaction?).
  • None of the vendor pages reviewed describes a control that replaces the values on a rendered production screen before the model reads them, and the access settings they do document govern what a person may do after signing in (Chase, 2025).
  • The Cloud Security Alliance's shadow-AI note reports that "Eight in ten employees use AI tools not approved by their organizations", the pattern a startup recognizes from its first year (Cloud Security Alliance, 2026).
  • Chase's business portal documents "varying levels of access" and "daily transaction limits and approval thresholds", controls on what an employee may do once signed in (Chase, 2025).
  • Meta's research post states that, until injection is reliably stopped, "agents must satisfy no more than two of the following three properties within a session" (Meta AI, 2025).

What does production access mean at a startup with no security team?

At most startups, production access is a set of logins the first engineers created, held by the founder and two or three others, with the administrator rights that came with building the product. The live database, the billing portal and the support inbox sit behind those logins, and the agent is usually connected the shortest way: the founder's own browser profile, or a service account with the same rights.

That is why the agent inherits the exposure rather than creating it. MIT Sloan's review defines the class as "autonomous software systems that perceive, reason, and act in digital environments to achieve goals on behalf of human principals", which is what a session with production access becomes once an agent holds it (MIT Sloan, 2026). Agents acting on live systems have already produced a hard example: a coding agent deleted a live production database during a code and action freeze, after which the vendor separated development and production databases (Is It Safe to Let AI Agents Act in Production Systems?).

The stakes are set by whose data is on the screen. A startup's production data is usually its customers' data, and the founder who granted the access has no second person to check the grant. The agent's session is the founder's session with a faster reader.

Harry Ghuman, CEO, Alpha Decisions, said: "Every company knows what their most consequential processes are, where the money comes in from and where the costs are" (What Is the AI Delegation Frontier? Harry Ghuman on Who Gave the AI Its Authority).

Of 15 AI agent products reviewed, one documents asking a person by default before every consequential action and five document a per-action record (Do AI Agents Ask Before Making a Payment?).

What does the model receive from a customer account screen?

The record for this page is a customer account page in a startup's own admin console, opened from the founder's production session to correct a billing address. The page is drawn for a person with the rights to fix the account, so it shows the name, email, phone, address history, plan, the last four digits of the card on file and the tax identifier stored for invoicing.

The task needs two of those fields: the address block and the customer identifier. Every other value arrives with them, because the page renders the record and the model reads the page.

The values a record carries are set by the rules the business operates under, and those rules put identifiers on the same screen as the field a task needs. HHS's de-identification guidance lists what it removes, including "All geographic subdivisions smaller than a state" and "All elements of dates (except year)", names and Social Security numbers (HHS Office for Civil Rights, 2026). FINRA's rulebook requires a member to record the "customer's name and residence", whether the customer is of legal age and a trusted contact person age 18 or older (FINRA, 2026). A supplier registration guide states that "Bank account information must be included" and that Individual is selected for suppliers using a government identification number such as a US Social Security number (Suntory Global Spirits, 2025).

Screen a production session reaches What it draws What the task needs
Customer account page Name, email, phone, address history, plan, card last four, tax identifier The address block and the customer identifier
Invoice list Amounts, dates, billing address, payment terms The invoice the customer is disputing
Supplier registration form Legal name, street and house number, VAT number, EIN or Social Security number, bank account The supplier's name and a remit-to contact
Payment portal Payees, balances, approval thresholds, approvers The single payment the agent was asked to prepare

Four record types, one pattern: the page is drawn for the person allowed to fix the record, and the agent inherits that person's view. Whether the console is well designed matters less than what the model received when the page rendered.

What do the vendors themselves say?

The vendors whose pages this question touches document access and approval in detail, and those controls govern people rather than the page a model reads.

Chase's Access and Security Manager lets a business assign "varying levels of access", set "daily transaction limits and approval thresholds" and "Require a second approver on transactions with Dual Control", and it lets a business "Control which accounts employees can see", none of which changes what the page renders to a session that has opened an account (Chase, 2025). The same page offers "Search for activity by user, accounts and transaction types", which records who moved money and not what the model read (Chase, 2025).

Suntory's supplier registration guide shows where the values come from. The form takes a legal name, a street and house number, a VAT registration number, an entity type of Organization for an EIN or Individual for a US Social Security number, and a bank account, because "Bank account information must be included", and it describes the fields a person completes rather than what an agent reads on the screen (Suntory Global Spirits, 2025). The same guide says electronic payment "must be selected if bank account is included", so the bank details are captured before any invoice exists (Suntory Global Spirits, 2025).

Dimension Chase, per its documentation What a buyer should verify
Access "varying levels of access"; which accounts an employee can see Whether the screen differs by role, or only the set of accounts
Approval Daily limits, approval thresholds, a second approver under Dual Control Whether the approval covers the reading or only the action
Record Search by user, accounts and transaction types Whether any record shows what the model received
What the model receives Not described in the pages reviewed Ask for a run with test values on the screen

The pattern is consistent: the pages describe what a person may reach and approve, and leave the reading of the screen to the page itself.

What should a startup ask a vendor about what the model receives from a screen?

Two questionnaires matter here, and they run in opposite directions. The startup's customer asks how the startup's agent handles the customer's data. The startup asks the vendor whose agent or browser it is about to deploy. Both want the same four things: which systems the agent can reach, what it receives when a page renders, who approves an action, and what record exists afterward.

The customer's version has a standard shape. An organization that reports on its controls uses the AICPA's Trust Services Criteria "to evaluate and report on controls over the security, availability, processing integrity, confidentiality, or privacy" of a system, and an agent inside the system falls within the controls being evaluated (Which SOC 2 Controls Apply to AI Agents?). The confidentiality and privacy criteria are the ones a buyer will point at.

The vendor's version is where a startup has leverage before signing. Five questions are worth putting in writing. What does the model receive from a rendered screen, field by field? Are sensitive values replaced before the model reads the page, consistently across screens? Who approves a consequential action, and is that a step the agent cannot take? What record shows what the model received, and can it export? What sits outside the control, given that a browser control does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP?

An answer that says the agent only sees what it needs answers none of the five. A startup that has run one workflow with test values can reply with the screen as the model read it, an approval carrying a name and a record carrying a timestamp.

Who approves a production change, and what record does the session leave?

Approval is the half of the problem the vendor pages handle. Chase's portal puts a second approver on transactions under Dual Control and lets a business set daily limits and approval thresholds, controls on the action and not on what the approver read (Chase, 2025). Those are real controls on money leaving an account, and they do not change what the approver, or the agent, read before the request was raised.

At a startup the approval button usually exists; the weak point is the approver, who has too little time and too much trust. A systematic review of automation bias describes it as "the tendency to over-rely on automation", the habit that makes a confident agent's summary easier to accept than the record behind it (Goddard et al., 2012). A founder who approves an address change from a one-line summary is approving the summary.

Automation also has a cost when review is skipped. Solventum's sheet says its ProMonitor rules can send codes "directly to billing without coder review", with only user-defined rules and pre-qualification conditions standing between the suggestion and the claim (Solventum, 2025). A startup's version is a workflow that refunds a customer because a rule matched.

The record is the second half, where the portal's own log stops short. Chase's activity search answers who moved money and which accounts were touched (Chase, 2025), and the buyer asks what the model received before it proposed the move. Identity carries the same limit: for an identity provider to secure a record as completely as the sign-in, the values a page renders would have to be tokens before any model reads the screen (Is Okta Enough to Secure AI Agents on Customer Data?).

What does a governed environment change?

A governed environment is a control class that acts where the screen is rendered, before a model reads it. Values chosen by policy become consistent tokens for the whole run, so a customer appears as CUST_014 and an account as ACCT_002 on every page. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each consequential change, and every screen as the model read it, every action and every approval lands in a record that exports to the organization.

For this page the change is specific. A production session holds sensitive customer data and can change state. Meta's rule says a session should satisfy no more than two of three properties: untrusted input, access to sensitive systems or data, and external state change or communication (Meta AI, 2025). A session that also reads a support email has all three, and the governed environment removes the second from what the model holds.

Substitution is not deletion. HHS's guidance warns that both de-identification methods "yield de-identified data that retains some risk of identification", which is why deleting a value differs from replacing it with a token (HHS Office for Civil Rights, 2026).

Scope matters as much as mechanism. A governed environment covers the rendered page and not the terminal, the IDE, the local filesystem, direct API calls or MCP, so a query run from a shell is outside it and the approval that gates the command says nothing about the rows it returns (How Do I Let a Coding Agent Use a Test Database That Contains Real Customer Data?). A prompt injection that reaches the agent can persuade it to send what it holds, and what it holds is a token (Does Prompt Injection Expose Customer Records?).

What the record shows

A session that renders real customer values to the model cannot be made safe by an approval setting, because the approval arrives after the model has read the page. The control has to sit at the render: values chosen by policy become tokens before any model reads the screen, a named person approves each consequential change, and the run leaves a record of what the model received. The vendor pages reviewed here answer the access and approval half of that standard and leave the reading half open. The conclusion for the title is narrower than the question sounds: an agent can work production customer data, but not while the page it reads is the page a person would read. Name one customer screen and one change the agent is meant to make, run it with test values, then compare what the model received with what the task needed and who approved the result.

Methodology and limitations

The page rests on public documentation: a business banking portal, a supplier registration guide and a medical coding fact sheet from the vendors that publish them, regulator guidance from HHS and FINRA, a research note from the Cloud Security Alliance, a systematic review of automation bias and an industry analysis from MIT Sloan. Those pages were read in full, which gives a sound view of where each control applies and where it stops. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page.

No product named on this page was tested for it, and "not described in the pages reviewed" means the pages listed in Sources. Vendor features change, and the page carries its date, so a release after it should be treated as unreviewed until the check above is repeated. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a founder's production session on a customer account, not an organization. Compliance determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.

Frequently asked questions

Can a startup use AI agents on production customer data?

No, not while the agent reads the same rendered pages a person reads. A customer account page carries the name, address, card on file and tax identifier beside the field the task needs, and the model receives the page as drawn. The work becomes possible when values are replaced with tokens before the model reads the screen, a named person approves each change and the run leaves a record. Until then, the honest answer to a buyer is that the agent saw the record.

What does the model receive when it opens a customer account?

Every value the page draws, not the field it was asked to change alone. On a typical account that means the customer's name, email, phone, address history, plan, the last four digits of the card, the tax identifier and the support notes. The page is built for a person with the rights to fix the record, so it hides nothing from that person. An agent signed in with those rights is shown the same screen, which is why the reading has to be controlled at the render.

Does read-only access to production solve the problem?

No. Read-only access limits what the agent can change and leaves what it can read untouched. A read-only session still opens the customer page, still renders the card, the tax identifier and the notes, and still sends them to the model. The limit worth adding sits on the values rather than on the writes: replace them with consistent tokens before the model reads the screen, and the read-only session becomes a reading of placeholders.

Who should approve a change the agent proposes?

A named person outside the agent's session, not the agent itself and not a rule. The approval should come when that person can see the change and the record it affects, and it should be a step the agent cannot take. A portal that requires a second approver under Dual Control shows the shape for money. The same shape applies to an address change, a refund or a payee update, and the approver's name belongs in the record beside the action.

What record should a startup be able to produce?

One that answers what the model received, not only what the agent did. Most portals can show who moved money, which account was touched and when. A customer's questionnaire will ask the harder question: what did the model read before it proposed the change? The record that answers it lists the screens the run opened, the values as the model received them, each action and the name of the person who approved it, and it exports to the startup's own monitoring.

What does a buyer's security questionnaire ask about the agent's screen?

It asks which systems the agent can reach, what data it sees, who approves its actions and what record the vendor can produce. The screen is where those answers meet, because the systems, the data and the approval all appear on it. A startup that has run one workflow with test values can answer with the page as the model read it, the approval and the record. A startup that has only a policy document is describing a design, and the buyer's auditor will notice.

About the author

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.

How RedactSure Keeps Customer Values Off the Production Screen

A founder who connects an agent to the production login hands it every value the customer page draws, and the approval comes after the reading. Meta's rule allows two of its three properties in a session, and production data is one.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent opens the customer account from the founder's session and the page renders the customer's name, the card on file and the tax identifier, which travel into its plan and its reply. Inside: the page renders CUST_014 and CARD_002, the order status and the address stay readable, and the real values resolve only at the destination a named person approves.

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 production screen that renders tokens gives the model the task without the customer's identity. Bring one customer account and see, with test values, what the model receives, who approves the change and what the record holds. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.