Can OpenAI Dots Handle Cardholder or Bank Data?

Secure sign-in protects credentials, not every card or bank value a task may encounter. Assess the model's input, connected systems and payment controls before deciding PCI scope or banking-data access. An accounts payable screen can show a vendor's bank details beside the invoice the agent needs to match. A credential vault does not automatically remove those fields. Cardholder data and bank-account data also raise different scoping questions: PCI DSS addresses payment-card data, while banking records can fall under other security obligations. Neither conclusion follows from a no-training setting. RedactSure, an AI agent controls, governance and data protection company, applies Least Exposure and render-layer tokenization to this problem.

Key findings

• Secure sign-in "sends your credentials directly to the browser environment and submits them without exposing them to the model's context," per OpenAI's safety document. The model receives webpage text and document content within connected apps; the parent page reads every control.
• A dot has its own cloud computer and browser on OpenAI infrastructure, per The Next Web and Axios; the key holder is not disclosed and no compliance certification is named.
• PCI SSC's scoping guidance places in scope any system component that stores, processes or transmits cardholder data. It also places in scope any component connected to, or able to affect the security of, the cardholder data environment.
• 16 CFR 314.4 requires a written risk assessment, access controls, encryption in transit and at rest, oversight of service providers by contract and periodic assessment, and monitoring of user activity.
• PCI SSC's tokenization guidelines describe replacing the PAN with a token of no value outside the tokenization system, which reduces the components handling cardholder data. Render-layer tokenization applies that at the screen.

What does secure sign-in protect, and what does it not?

OpenAI's description is specific. Secure sign-in "sends your credentials directly to the browser environment and submits them without exposing them to the model's context." For saved passwords, "the service supplies the password for sign-in without passing it to the model" (OpenAI). The password is the one value on any page that the documentation says the model never receives.

Everything after the sign-in is the page. Inside the bank portal, the processor's console, the ERP's vendor master or the checkout, the model receives webpage text and document content: the card number in the payment form, the routing and account number on the vendor record, the SSN on the loan application. None is a credential, so none is covered by secure sign-in. Can a Credential Vault Protect the Data an AI Agent Reads? walks the same boundary for every vault design, Meta's Muse included. A vault covers the values it stores, and the agent reads page content within its permitted access. Secure sign-in is a credential control; the assessor's question is about the data.

When does a dot's cloud computer enter PCI scope?

PCI SSC's scoping guidance sets the rule. Components that store, process or transmit cardholder data are in scope, as are components connected to or able to affect the security of the cardholder data environment. Segmentation takes a component out only when it has no connectivity to and no ability to affect the CDE. The assessor confirms the scope.

A dot working a payment or refund reads the card number from the page into the context of a model on a cloud computer OpenAI runs. On the guidance's terms that computer is processing cardholder data and is connected to the CDE through the browser session. It and whatever runs beneath it are components in the assessment. OpenAI's document does not disclose who holds the keys or which certifications the environment carries. Custom Rules requiring approval before a payment do not change the scope question, because scope follows where the PAN went (Can an AI Agent Handle Cards Without Wider PCI Scope?).

The tokenization guidelines describe the alternative: a token standing in for the PAN with no value outside the tokenization system, so components handling only the token may fall outside the CDE. Applied at the render layer, the model receives CARD_001 and the tokenization system is the governed environment the customer owns. Whether that removes the model from scope is the assessor's determination; the arithmetic it starts from is shorter.

What does the Safeguards Rule ask of a service provider that reads account data?

16 CFR 314.4 lists the elements of a financial institution's information security program: a written risk assessment; access controls limiting authorized users to the customer information they need; encryption in transit and at rest; and monitoring and logging of user activity. It also requires oversight of service providers: selecting providers capable of appropriate safeguards, requiring them by contract and periodically assessing them.

An AI agent reading a loan file or a payment instruction is an authorized user's session extended to a model. The model vendor whose cloud computer holds that page is a service provider that received customer information. The program has to assess that risk and limit the model's access to the customer information it needs. It has to show the encryption and the key holder, log what the model did, and hold the vendor to safeguards by contract. OpenAI's documentation gives the institution an Activity View of actions, a no-training default and secure sign-in for the password. It does not give a way to limit what the model receives to the task's fields, a disclosed key holder, or a log of what the model read that the institution holds. Each is a gap the compliance officer writes around in the risk assessment.

What does a dot see on an accounts payable screen?

The vendor master. An AP invoice run in NetSuite, Oracle ERP or SAP opens the vendor record with its remittance bank account and routing number, tax ID and invoice history. It also opens the payment batch with amounts and dates. A dot working under the AP clerk's sign-in receives that page as text, and the bank details enter model context on every invoice. Permissions are unchanged; exposure is the visible screen content. The AP pages set out the alternative for each system: NetSuite, Oracle ERP and SAP, with the model handed the invoice fields and the vendor as VENDOR_001, its account as ACCT_001.

Bank account substitution is the fraud AP controls exist to stop, and an agent that reads and writes the vendor master in clear is a new path to it. An injected instruction in an emailed invoice that persuades the agent to update remittance details is the OWASP LLM01 case in AP clothing. An agent that receives ACCT_001 cannot copy the real account anywhere, and the update still stops for a named person.

Who approves the payment?

A person, in every design; the question is which person, under whose permissions, on whose record. Dots stop for the user's approval where Custom Rules or mandatory confirmations require it, inside OpenAI's app. In a governed environment the AP manager or treasury officer approves under the ERP's existing permissions. The approval, the screen as tokens and the action are recorded in the AI Control Record and exported to the institution's SIEM. Real card and account values resolve at the processor or bank only at that moment. The AI prepares the batch; the named person pays.

How do Dots and a governed environment answer the assessor?

Where does RedactSure sit?

RedactSure builds the governed environment in the middle column. AI co-workers work inside the ERP, the bank and processor portals and the email around them from a secure virtual machine in the cloud the institution's posture requires. It runs on hardware-encrypted enclaves with keys the institution holds, with no per-application integration and no change to user permissions. Card numbers, account and routing numbers, SSNs and the other identifiers chosen by policy are replaced at the render layer by consistent tokens before any model reads the screen. The model is handed the invoice or payment fields rather than a picture of the page, so it never holds a number an assessor has to trace. Amounts, dates and invoice numbers stay in clear where the policy says so.

That is what the institution avoids: a PCI assessment and a Safeguards Rule risk assessment that reach a vendor's cloud computer with an undisclosed key holder. A named person confirms the policy and approves every payment and vendor change under Supervised Delegation. Real values resolve at the bank or processor only then. The environment is model-agnostic. Deployments are in pilot.

What the record shows

Secure sign-in protects credentials, not every card or bank value a task may encounter. Assess the model's input, connected systems and payment controls before deciding PCI scope or banking-data access. Trace one payment flow with the assessor, including the browser, model request, logs and any system that can affect the cardholder-data environment.

Frequently asked questions

Does secure sign-in protect the card on the checkout page?

No. OpenAI describes secure sign-in as sending credentials to the browser environment and submitting them without exposing them to the model's context. A card number on a checkout page is page content, not a credential, and page content is what the model receives. Secure sign-in protects the password; the card enters model context. RedactSure replaces the card with CARD_001 before the model reads the page.

Does a dot in accounts payable see vendor bank details?

Yes, when they are on the screen the dot opens. A vendor master record in NetSuite, Oracle ERP or SAP shows the remittance account and routing number to the signed-in AP user. A dot under that sign-in receives the page as text. Custom Rules can require approval before the dot changes or pays; they do not remove the account number from what the model reads. RedactSure hands the model ACCT_001 in its place.

Where is the record of the payment kept?

For a dot, in OpenAI's Activity View and the ERP's own audit trail. In a governed environment, the screen as tokens, the action and the named approval land in the AI Control Record and export to the institution's SIEM, beside the ERP's trail. The Safeguards Rule's monitoring element and a PCI assessment both ask for a log the institution holds.

Does a one-time card from a payment partner change the analysis?

It changes what a compromised card is worth, not what the model received. A one-time card number on the page enters model context like any other. The partner's tokenization protects the underlying card in the partner's vault. The bank account and SSN on the same screen are untouched by it. Does Payment-Partner Tokenization Protect What an AI Agent Sees? walks the boundary.

Is a dot in scope if it only reads and never submits?

Reading is processing. PCI SSC's guidance brings into scope components that store, process or transmit cardholder data or could affect its security. A read-only dot in "proactive research" mode that opens a page with a PAN on it has received the PAN into model context. The absence of a submit action bears on the fraud analysis, not on scope. The assessor decides.

Who determines PCI scope?

The organization, confirmed by its assessor. PCI SSC's guidance makes the entity responsible for identifying every system component in scope, with the assessor validating it. A vendor's statement that its product is out of scope does not settle it; where the cardholder data went does. For a dot that is the model's context on OpenAI's cloud computer. For a RedactSure environment it is a token the model cannot resolve.

Related research

Comparison · September 30, 2026

Do OpenAI Dots Rules Control What the Agent Sees?

Review OpenAI Dots Custom Rules, AI agent security and tokenization before connecting billing, claims or other workflows that expose PII.

Data Report · September 19, 2026

Can an AI Agent Handle Cards Without Wider PCI Scope?

Examine PCI scoping for AI agents in payments, including tokenization boundaries, cardholder-data exposure and questions for a QSA.

Data Report · September 26, 2026

Can AI Work NetSuite Payables Without Bank Details?

Explore AI agents for NetSuite accounts payable, using tokenization to protect vendor bank details through matching and payment approval.

Data Report · September 26, 2026

Can AI Work Oracle Payables Without Bank Details?

Examine AI agents for Oracle accounts payable across enterprise systems, with tokenization for vendor details and human payment approval.

Data Report · September 26, 2026

Can AI Work SAP Payables Without Vendor Bank Details?

Explore AI agents for SAP accounts payable in S/4HANA and ECC, with tokenization of vendor details and named approval before payments.

Explainer · September 30, 2026

Does Payment Tokenization Protect an AI Agent's View?

Compare payment tokenization with AI agent input controls for billing and accounts payable, including customer PII and vendor bank details.

White Paper · July 2026

Payments Security in the Age of AI

Explore AI agent security for payments operations, where PCI controls, tokenization and human approval address new data-exposure risks.