Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can an AI Agent Sign Up for a Developer Service Without My Credit Card Number?

Yes, when the card number is entered where the agent cannot read it: a step a person completes outside the agent's view, a payment credential the environment holds and submits for it, or a field filled from a store while the model sees CARD_001. Ask which of the three your tool uses and what the model received.

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

A sign-up for a developer service ends at a billing step, and the billing step asks for a card. An agent that fills the form the way a person does reads the number it types, and from that moment the number is in the model's context alongside everything else the run produced. The question in the title therefore has one answer with three shapes. The agent can finish the sign-up without the number only if the number is entered by a route the agent does not read: a person completes the billing step while the agent waits, the environment holds a payment credential and submits it on the agent's behalf, or the field is filled from a store while the model sees a placeholder. Each route has a different failure mode, and a buyer who cannot say which one a tool uses cannot say where the card went. This page sets the scope, then lays out the three routes with one record type as the example, a card field on the billing step of a sign-up form, filled three ways. It reads the custody designs vendors document for API credentials, the nearest documented relatives of the second route, and the research record on what happens when a credential reaches a model. Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? covers the sign-up question as a whole; this page covers only the card field and the three ways to fill it.

Key findings

  • A study of neural code completion tools found that they "can not only return the precise piece of their training data" and that "two valid credentials were identified during our experiments," the memorization risk a card number faces once it enters model-facing text (Huang et al., 2024).
  • GitGuardian's test of GitHub Copilot reported that "Copilot generates 2702/900 = 3.0 valid secrets for one prompt on average," a measure of how readily a model repeats values it has seen (GitGuardian, 2025).
  • OpenAI's cloud environment documentation states that credentials "are only available to setup scripts" and that "secrets are removed before the agent phase starts," a custody design for API API keys in a cloud task and not for a card typed on a page (OpenAI, Codex Cloud, 2026).
  • Microsoft's managed identity documentation states that "this token acquisition doesn't require any secrets," a credential a workload uses without holding, though it covers Azure resources and not a browser form (Microsoft, 2026).
  • A governed environment replaces a card number with a consistent token before any model reads the screen, so an agent that fills a billing form works with CARD_001 and never holds the digits (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, so the number reaches the payment form the person approved and not the transcript or the next page (What Is Least Exposure?).

What does a governed browser environment cover on a sign-up form?

The scope comes first because the title says "agent" and the answer depends on which kind. A governed browser environment covers what an agent reads and does on a rendered page: dashboards, consoles, settings pages and sign-up forms, including the billing step where a card field appears. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent that signs up for a service by calling its API from a shell with a card number in an environment variable is outside this page. An agent that opens the sign-up page in a browser and fills the form is inside it.

That split matters for the card because the two routes leak differently. On a page, the number is a value the agent reads as it types or as the form echoes it back, and anything the model reads can be repeated. Web agents in a measured study "are prone to inadvertent use of unnecessary sensitive information," and a card number is unnecessary to every step of a sign-up except the one that submits it (How Do You Let an AI Agent Manage API Keys Without Reading Them?). In a shell, the number is a string in a file or a variable, which is the territory of sandboxes and credential stores rather than of a browser control.

The example record for this page is one card field on the billing step of a developer service sign-up form. The same field is filled three ways in the sections that follow, and the test at each step is the same: which component held the sixteen digits, and what the model received when the page rendered them.

Which three routes keep the card out of the agent's view?

The first route is a handover. The agent reaches the billing step and stops, a person takes the session, types the card and returns control. The agent never reads the number because it was not watching when it was typed. The limit is the moment after: the billing page the agent reads next may echo the last four digits, and a person has to be present for every sign-up, which is the step most teams wanted to delegate.

The second route is custody. The environment holds a payment credential the way a credential store holds an API key, and submits it on the agent's behalf. The documented relatives, read in the next section, are credential designs rather than card designs: credentials removed before an agent phase begins, a managed identity that needs no stored credential, a vault token scoped to one credential for minutes. The limit is the page: custody keeps the number out of the agent's process, and says nothing about what the browser renders once the form is submitted and the account page shows the card on file.

The third route is substitution at the render layer. The page is drawn, the card field is filled from a store, and the model is shown CARD_001 where the digits sit. The real value resolves only at the approved destination, the payment form, at the moment a named person approves the submission. The limit is scope: it governs the rendered page, not a shell.

Route Who holds the number What the model receives Where it fails
Handover The person, for the typing step Nothing during the step; whatever the next page shows Echoed digits on later pages; a person needed per sign-up
Custody The environment, as a stored credential Nothing from the store; whatever the page renders Pages that display the card on file
Render-layer substitution A store; the page is filled from it CARD_001 for the whole run Terminal, IDE, API calls and MCP are outside it

What do the vendors themselves say?

The vendor pages reviewed describe credential custody for API API keys and tokens, and none describes a payment card. They are cited for the custody pattern, the second route, and for its limits.

OpenAI's Codex documentation states that "by default, the agent runs with network access turned off" and that "Codex asks for approval to edit files outside the workspace or to run commands that require network access," controls on what a local session may do that do not describe how credentials are stored or handled in it (OpenAI, Agent, 2026). The cloud environment page, which OpenAI marks as legacy, states that "environment variables are set for the full duration of the chat (including setup scripts and the agent phase)" while secrets are removed before the agent phase, so a value placed in a variable rather than a secret is in the agent's reach throughout (OpenAI, Codex Cloud, 2026).

HashiCorp's tutorial states that "token lifetime is reduced from days or weeks to minutes" and that a wrapper script "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent," which places the raw token in the agent's environment; the page does not say whether the agent can read it (HashiCorp, 2026). Microsoft's page states that "managed identities eliminate the need for developers to manage these credentials," a design for workloads on Azure resources rather than for a form in a browser (Microsoft, 2026).

Why does one reading of the number matter?

Because models repeat what they read, and the record on credentials says so in numbers. The memorization study found two valid credentials among what the tools returned, and GitGuardian's test of Copilot across public repositories found that "over 1,200 leaked at least one secret" (GitGuardian, 2025). The post does not confirm whether the extracted credentials were still active, and the memorization study's abstract does not give the number of tools tested, so both are cited for the pattern and not for a rate.

The pattern transfers to a card. A number that enters the context during a sign-up can be written to a transcript, repeated in a summary or pasted into the configuration file that records the new service. The volume of credentials already sitting in source is the reason that matters: SecretBench is "a labeled dataset of source codes containing 97,479 secrets (of which 15,084 are true secrets)," built from public repositories (Basak et al., 2023). A card number in a config file is one more true credential in that population.

The sign-up itself has a second exposure. A developer sign-up usually ends with an install step, and code generating models hallucinate package names at a rate of "at least 5.2% for commercial models and 21.7% for open-source models" (Spracklen et al., 2025). An agent that holds a card number and installs a package whose name it invented has put the number within reach of whatever that package does. The study does not say whether hallucinated names were registered and exploited, so the point is about reach and not about a measured attack. Either way, the cheapest defense keeps the number out of the context, which is what each of the three routes does in its own territory.

How should a team test which route its tool uses?

Name one agent, one sign-up and one test card, run the billing step and record what the model received. The result sorts the tool into a route. If the agent paused and a person typed, it is a handover, and the test continues to the next page to see whether the card on file is rendered. If the agent submitted without a pause and the number appears nowhere in its transcript, it is custody or substitution, and the question is whether the model saw a placeholder or nothing.

Testing beats reading the vendor's page because sign-up 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 (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?). An agent holding the number when the attack lands gives it up; one holding CARD_001 gives up a token.

The credential record adds two checks. The MCP guidance warns that "poor scope design increases token compromise impact, elevates user friction, and obscures audit trails" (Model Context Protocol, 2026); a stored card should likewise work for one sign-up and not for every purchase the agent might make. AWS's advice against creating root access keys applies to any durable top-level credential handed to an agent (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?), and its AgentCore Identity documentation says centralized credential management removes the need to embed credentials in agent code (Does AWS Bedrock Keep Company Credentials Away From Agents?). A card belongs in that store, not in a prompt.

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as CARD_001. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and a payment is one. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this page's question it is the third route, and it changes two things the other routes leave open. The first is the page after the sign-up. A handover keeps the number out of the typing step and custody keeps it out of the agent's process, but the account page that shows the card on file is rendered to the model in both cases. Under render-layer substitution it is rendered as CARD_001, on that page and on every page for the rest of the run. The second is the record. Neither of the other routes produces a statement of what the model saw; the governed environment does, screen by screen, with the name of the person who approved the submission. Meta describes its own agent design as one where credentials are used through surrogate tokens the agent does not see, with a separate component approving each network egress, the same idea applied to one vendor's agent rather than to any agent on any page (What Would an Enterprise Version of Meta Muse Need?).

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a card placed in an environment variable for an API sign-up stays with the sandbox and the credential store a team configures for its coding agent.

Methodology and limitations

This page rests on three research preprints on credential memorization, package hallucination and credentials in source code, vendor documentation from OpenAI, HashiCorp and Microsoft, the Model Context Protocol security guidance, one vendor research post from GitGuardian, and existing RedactSure research pages. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from research posts are cited as reported, not as independently measured.

RedactSure did not test any of the named products hands-on. The vendor pages concern API API keys and tokens; a payment card is not described in the pages reviewed, and the custody route is described here by analogy to those designs, with that limit stated. Vendor features change, and the page carries its date; a reader should treat a release after that date as unreviewed until the test above is repeated. The research preprints are cited for the findings their abstract pages state and not for rates those pages do not give. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a card field on the billing step of a developer service sign-up form, and not an organization. The handover and custody routes are described as mechanism classes, without naming products, because those products' pages were not among the pages reviewed.

Determinations about whether a payment flow meets a contractual, card-scheme or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against a test card on a test sign-up, repeated after each release.

What the record shows

The three routes answer the title in the same way with different reach. A handover keeps the number out of the agent's view for the typing step and nothing after it. Custody keeps the number out of the agent's process, which the vendor designs for API keys show in detail and which none of them extends to a page. Substitution at the render layer keeps the number out of the model on every page of the run and produces a record of what the model saw, which is the one property neither of the other routes documents; RedactSure's environment is built on that route. The research record says why one reading is one too many: models return credentials they have seen, and credentials in source are counted in the tens of thousands. Name one agent and one sign-up, run the billing step with a test card, and write down which component held the digits and what the model received on the page that followed.

Frequently asked questions

Can an AI agent sign up for a developer service without my credit card number?

Yes, if the number is entered by a route the agent does not read. A person can type it during a handover, the environment can hold a payment credential and submit it on the agent's behalf, or the field can be filled from a store while the model is shown a placeholder. Each route has a limit: the handover needs a person per sign-up, custody does not govern the page, and substitution covers only the rendered page. Choose the route by where the number must never appear.

Is a handover to a person enough?

For the typing step, yes. The agent does not read a number it was not watching being typed. The limit is every page after the billing step: an account or billing page that shows the card on file renders to the model like any other page, and the last four digits plus the expiry date identify a card to anyone holding a list. The handover protects one step and not the run. Check every page the agent reads after the handover as well as the one it stepped away from.

Does storing the card in a credential store solve the problem?

It solves the process half. The vendor designs reviewed here keep an API API key out of the agent's phase, scope a token to one credential for minutes, or acquire a token without any stored credential at all, and a card held the same way never sits in a prompt or a variable the agent prints. What a store cannot do is change what the browser renders once the account exists. For that half the control has to sit at the page.

What does the agent see with render-layer substitution?

A placeholder, CARD_001, in the card field and on every later page where the card would be displayed, for the whole run. The real number is resolved from the store when a named person approves the submission and travels only to the payment form. The transcript, the summaries and any file the model writes contain the placeholder, which is worthless outside the environment that issued it, so the run ends without the digits ever having been rendered to the model.

Could the agent still leak the card some other way?

Only by a route that bypasses the page. A card placed in an environment variable for an API sign-up from a shell is outside a browser control and inside the sandbox and credential-store rules a team sets for its coding agent. A card the agent reads from a file is the same. The research on memorization and credentials in source applies to those routes in full, so keep the number out of files and variables as well as out of the page.

What should a security team ask a vendor in writing?

Which of the three routes the tool uses at the billing step; whether the card on file is rendered to the model on later pages; where the stored credential lives and whether it can be used for more than one sign-up; who approves the submission; and what record shows the page as the model saw it. Treat any answer the documentation does not support as unanswered until a run with a test card confirms it, and keep the answers beside that run's transcript.

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 Fills the Billing Step Without Showing the Card

An agent that types the card number has read it, and the custody designs reviewed above keep a credential out of its process but ignore the page.

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

Before: the agent reads the sixteen digits as it fills the form, and the account page echoes the card on file afterward. Inside the governed environment: the field is filled from a store the agent does not read, the model sees CARD_001 on both pages, and the real number reaches the payment form only on a named person's approval.

RedactSure is deploying now with enterprise and government customers. OpenAI's cloud environment removes credentials before the agent phase but leaves environment variables in place.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

A card number on a billing step is the value finance will ask about first. Bring a signup your team pays for and see, with test values, the billing step completed while the model reads only CARD_001. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.