Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?

Yes, if the card number and identity fields reach the agent as tokens and the real values are inserted only at the checkout destination when a named person approves the purchase. Check how each agent handles the payment step: a pause for human takeover removes the agent from the form, while tokenization removes the values from the agent.

Payment and identity cards travel through a narrow boundary toward a developer-service signup page.

Yes, if the card number and identity fields reach the agent as tokens and the real values are inserted only at the checkout destination when a named person approves the purchase. Check how each agent handles the payment step: a pause for human takeover removes the agent from the form, while tokenization removes the values from the agent. Signing up for a cloud account, an API platform or a package registry is routine developer work, and it ends at a form that asks for a name, a work email, a phone number, a billing address and a card. That form is where a web agent is most likely to expose personal data: it is reading a page an attacker may have shaped while being asked to type the most sensitive values the organization holds. Peer-reviewed work on web agents measures the leakage, and the three agents whose documentation is reviewed here all answer the same way: they stop and hand the form back to the person. This page sets out what a browser control covers and does not cover for a developer, where the card and identity values appear on a sign-up form, how current agents handle that moment, why a pause is a partial answer, what a token-filled form looks like, and which claims a buyer should refuse. It builds on what an agent sees in a screenshot.

Key findings

  • Sign-up and checkout forms are a measured leakage point: an environmental injection attack on generalist web agents reached an attack success rate of up to 70 percent in stealing users' specific personal information (Liao et al., arXiv, 2025).
  • Even without an attacker, web agents are prone to inadvertent use of unnecessary sensitive information, so a form that asks for a card number is a place where the agent may type more than the task needs (Zharmagambetov et al., arXiv, 2025).
  • The three agents whose documentation is reviewed here handle the payment step by pausing: Meta's Muse checks with the person before making a purchase (Meta, 2026), and Claude in Chrome asks before high-risk actions like purchasing or sharing personal data (Anthropic, 2025).
  • OpenAI's documentation for the retired ChatGPT agent states that screenshots are not captured during takeover, which helps protect passwords, a design that protects the typed value by removing the agent's view rather than by changing the value (OpenAI, 2026).
  • A card value substituted at the render layer never reaches the model, so the question of whether the agent's view enters payment scope is answered by design rather than by contract (Does Payment Tokenization Protect an AI Agent's View?).

What does a governed browser environment cover for a developer, and what does it not?

The scope has to be stated before the question can be answered. A governed browser environment covers what an agent reads and does on a rendered page: the sign-up form for a developer service, the billing page it leads to, the console dashboard that appears after the account exists, the settings page where an API key is generated, and the confirmation email opened in a webmail tab. On every one of those pages the environment decides which values the agent sees and which actions it may take. That is where card numbers, identity documents, billing addresses and verification codes appear, so that is where a control on exposure belongs.

The same environment does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP servers. A developer who asks an agent to run a command-line installer, paste a key into a configuration file or call a provider's REST endpoint from a script is operating outside the browser, and a browser control makes no claim about those paths. Nothing on this page implies that a control on rendered pages governs a shell. A developer evaluating an agent for sign-up tasks should treat the browser path and the shell path as two separate reviews with two separate controls, and should ask each vendor which path its safeguards apply to. The OWASP guidance on excessive agency frames the general risk, an agent with more permissions or functionality than the task requires, in a way that applies to both paths but is enforced differently in each (OWASP, 2025).

Where do card and identity values appear on a developer sign-up form?

Take a single record type: the sign-up and billing form for a developer platform, as it renders in a browser. The first screen asks for full name, work email, a password and a phone number for verification. The second asks for a company name, a tax identifier for some countries and a billing address. The third asks for a card number, expiry, security code and the cardholder name. A verification code arrives by text or email and is typed on a fourth screen. After submission, the console lands on a dashboard that shows the account owner's name and email, the billing contact and the last four digits of the card on file.

Every one of those fields is a rendered value, and an agent working the form sees each one as text or as pixels in a screenshot, a point covered in detail in what an agent sees when it takes a screenshot. The card screen is the most sensitive, but the identity screens matter as well. NIST's digital identity guidelines treat the identity evidence and the authenticators used to establish and prove an account as protected elements of the identity lifecycle, not as incidental form data (NIST, 2025). A phone number used for verification, a password chosen on the first screen and the one-time code on the fourth are authenticators in that sense, and a model that reads them has read the means of entering the account.

The payment standard is explicit about the card number itself. PCI DSS v4.0.1 requires that the primary account number be rendered unreadable according to Requirement 3.5.1 wherever it is stored (PCI Security Standards Council, 2024). An agent that reads the number from a form and carries it in its context is not storing it in the standard's sense, but it has created a reading path that the organization's assessor will want to describe.

How do current agents handle the moment a form asks for a card?

The documentation reviewed shows one pattern across three vendors: the agent recognizes a sensitive action and stops. Meta's Muse, which runs on its own dedicated computer in the cloud, checks with the person before sensitive actions like sending an email or making a purchase; Meta also states that Muse cannot see stored passwords or payment methods but can use credentials stored for it (Meta, 2026). Anthropic's pilot announcement for Claude in Chrome states that Claude asks users before taking high-risk actions like publishing, purchasing or sharing personal data (Anthropic, 2025). OpenAI's help page for the retired ChatGPT agent, which notes the product was retired in favor of ChatGPT Work, describes a takeover mode in which screenshots are not captured, which helps protect passwords (OpenAI, 2026).

Agent, per its documentation What happens at the card field What the agent does not see
Meta Muse Checks with the person before a purchase; can use credentials stored for it Stored passwords and payment methods
Claude in Chrome Asks before purchasing or sharing personal data Not described in the pages reviewed
ChatGPT agent (retired for ChatGPT Work) Takeover mode; screenshots not captured The screen during takeover

Each design protects the value by changing who is at the keyboard. Muse lets a stored credential be used without displaying it. ChatGPT agent's takeover removes the agent's eyes while the person types. Claude in Chrome asks first. None of the pages reviewed describes a mode in which the agent completes the card field itself with a value it cannot read. That absence is the gap this page is about, and it is stated here as what the documentation covers, not as a claim about what any product cannot do.

Why is a pause for human takeover only part of the answer?

A pause beats no pause, and the measured risk explains why vendors reach for it. The environmental injection study found that a web agent reading an attacker-shaped page could be led to disclose a user's specific personal information with an attack success rate of up to 70 percent (Liao et al., arXiv, 2025). Anthropic reports that its mitigations cut prompt injection success for Claude in Chrome from 23.6 percent to 11.2 percent (Anthropic, 2025), a real reduction that still leaves a path open. Handing the form to a person at the card field closes that path for the card field.

It does not close it for the rest of the form. The name, work email, phone number, billing address and tax identifier were typed before the pause, and the agent read them. The dashboard after sign-up shows the owner's identity and the last four digits, and the agent reads that as well. The AgentDAM benchmark from Meta FAIR finds that web agents are prone to inadvertent use of unnecessary sensitive information, meaning they carry values forward into later steps where the task did not require them (Zharmagambetov et al., arXiv, 2025). A pause at one field does not stop that behavior on the other fields.

A pause also changes the economics of the task. If a developer must be present to type the card and the verification code, the sign-up cannot run unattended, and the point of delegating it is lost. OWASP's guidance on sensitive information disclosure describes the underlying exposure, personal and confidential data reaching a model's context through its inputs (OWASP, 2025). Removing the agent from one field for one minute does not change what entered its context before and after.

What does a token-filled sign-up form look like?

The alternative is to change the values rather than the operator. In a tokenized run, the agent sees the sign-up form with the identity and card fields already standing as tokens: the cardholder appears as PERSON_001, the card as CARD_001, the work email as EMAIL_001, the phone as PHONE_001. The agent fills the form by placing those tokens in the right fields, exactly as it would place real values. When the form is submitted to the provider's checkout page, and only then, the tokens resolve to the real values at that destination. The model never held the card number, so there is nothing for an injected page to extract and nothing for an inadvertent later step to reuse.

Two properties make this work. First, the tokens are consistent for the run, so the agent recognizes that the person on the billing screen is the same PERSON_001 who appeared on the account screen, and the task logic survives. Second, the resolution step is itself a governed action: a named person approves the purchase, as described in who approves an AI agent's claim payment, and the approval, the destination and the tokenized screen are recorded. The agent does not pause for takeover, because there is no field it needs to be kept away from.

This design also answers the scope question that card handling without wider PCI scope raises. The standard asks that the account number be unreadable in storage; a model that never receives it has nothing to render unreadable. The identity path is similar: a token in place of a phone number or one-time code keeps those authenticators out of the model's context. The agent's own identity and permissions remain a separate problem from what the agent reads, a distinction drawn in how an agent identity platform compares with render-layer control.

What does a governed environment change?

In a governed environment, the agent fills the sign-up form without ever reading the card number or identity values, because those values reach the model as tokens and resolve only at the checkout destination when a named person approves the purchase.

This class of control sits between the rendered page and the model. Sensitive values on the screen are replaced with consistent tokens before any model reads them, so the agent can recognize that a field holds a card number, an address or a date of birth and complete the form using the token. The real value is inserted at the approved destination at the moment of the approved action, and not before. A named person confirms what is tokenized and approves payments and submissions. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This differs from the pause for human takeover that current agents document. A pause removes the agent from the form for one step; it does not change what the agent read on the screens before and after, and environmental injection against web agents has reached success rates of up to 70 percent in stealing specific personal information (Liao et al., arXiv, 2025). Tokenization removes the values from the agent for the whole session. The evidence that settles the question is one real provider sign-up, rendered as the model saw it, with the fields shown as tokens, the approval named and the destination recorded, which is the measurement against the organization's own context that NIST's framework expects (NIST, 2023).

The control covers the rendered page the agent works in; it does not alter the provider's form, the verification steps, the model, or anything typed in a terminal, IDE or filesystem outside that page.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design places the agent in a governed environment in the customer's cloud and substitutes values at the render layer before any model reads the screen, so the sign-up form arrives with the cardholder as PERSON_001, the card as CARD_001 and the work email as EMAIL_001, with the same token for the same value across every screen of the run. Real values resolve only at approved destinations at the moment of an approved action, which for a sign-up is the provider's checkout page at the moment of purchase. A named person confirms the tokenization policy for the workflow and approves every payment, submission and record change under Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration with the developer service, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on one real developer sign-up would show the form as the model received it, the point at which the card resolved, and the named approval that released the purchase, which is the evidence this page says a buyer should ask for. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on peer-reviewed research on web agent privacy leakage (Liao et al., ICLR 2025, on environmental injection; Zharmagambetov et al., NeurIPS 2025, on inadvertent use of sensitive information), on vendor documentation from Meta, OpenAI and Anthropic describing how their agents handle sensitive actions, on the PCI DSS v4.0.1 standard and NIST's digital identity and AI risk management guidance, on the OWASP Top 10 for LLM Applications, and on RedactSure research pages on payment tokenization, PCI scope, approvals and screenshots. All sources were read as of October 16, 2026.

No hands-on testing of any named product was performed, and no sign-up was run against any provider for this page. Where this page says a behavior is not described, it means not described in the pages reviewed, not that a product lacks the behavior; vendor documentation is read as a statement of design intent rather than as test evidence. The attack success rates quoted come from the cited studies' own experimental settings and are not predictions for any particular deployment. Vendor features change, and OpenAI's own help page notes that ChatGPT agent has been retired in favor of ChatGPT Work; the page carries its date for that reason. Statements about RedactSure describe its current design, with deployments in pilot. The sign-up form, billing page and console dashboard described here are record types, not any organization's systems, and no customer or prospect is described.

Whether a given agent's handling of card and identity data meets an organization's obligations under PCI DSS, privacy law or its own policies is a determination for its counsel, its qualified security assessor and its own security and compliance officers, not for a research page.

What the record shows

Sign-up forms are where web agents are measured leaking personal data, with injection attacks reaching up to 70 percent success in the peer-reviewed study and inadvertent reuse of sensitive values documented in the benchmark that followed. The agents whose documentation was reviewed answer by pausing at the purchase and handing the form to a person, which protects the card field and leaves the identity fields, and everything on the screens before and after, in the model's context. The structural alternative is to fill the form with tokens that resolve only at the checkout destination under a named approval, a design RedactSure describes and that a pilot can show. The test is to name one agent and one real developer sign-up and ask to see the form exactly as the model received it, field by field, and then to ask where the card number was when the purchase went through.

Frequently asked questions

Does pausing for human takeover keep the card number away from the agent?

It keeps the card number away during the takeover. OpenAI's documentation for the retired ChatGPT agent states that screenshots are not captured during takeover, which protects what the person types in that window. It does not change what the agent read on the earlier screens, such as the name, work email, phone number and billing address, or what it reads on the dashboard afterward. The protection is real, and it is bounded to the fields the person types during the takeover window.

Can an agent use a stored card without seeing it?

Meta's documentation for Muse states that the agent cannot see stored passwords or payment methods but can use credentials stored for it, and that it checks with the person before making a purchase. That protects the vault from display. Whether the card value is visible on the merchant's page once it has been entered, or in a confirmation screen, is not described in the pages reviewed and is a question to put to the vendor with a real checkout flow.

Why do identity fields matter as much as the card?

Because they are the means of entering the account. NIST's digital identity guidelines treat identity evidence and authenticators as protected parts of the identity lifecycle. A phone number used for verification, a password chosen at sign-up and a one-time code typed on the next screen are authenticators. A model that has read them has read what is needed to reach the account, and an injected page can ask for them as easily as for a card number.

Does a browser control cover a developer's terminal or IDE?

No. A governed browser environment covers what the agent reads and does on rendered pages: sign-up forms, billing pages, console dashboards and settings pages. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP servers. A developer who delegates both a browser sign-up and a command-line setup is running two paths with two different controls, and should review them separately.

Does tokenizing the card field change PCI scope?

PCI DSS requires that the primary account number be rendered unreadable where it is stored. A model that never receives the number has created no storage of it, which simplifies the description an assessor needs. Whether that changes the organization's scope determination is a question for its qualified security assessor; the design removes a reading path, and the assessor decides what that means for the environment as a whole.

How does a token-filled form stay usable for the agent?

The tokens are consistent for the run, so the same person is PERSON_001 on every screen and the same card is CARD_001 wherever it appears. The agent fills fields with tokens exactly as it would with real values, and the task logic that depends on matching a billing contact to an account owner still works. Resolution to the real values happens at the checkout destination when a named person approves the purchase, and nothing about the form requires the agent to pause.

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.