Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does My AI Vendor See the API Keys My Coding Agent Reads?

Whatever is in the context goes to the vendor's model for the request, and retention and training depend on the plan. Zero-data-retention options govern storage, not whether the model received the value.

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

Security teams approving a coding agent should start from one fact: a credential that enters an agent's context has already left the developer's machine, because the model runs on the vendor's servers. Retention terms and training settings decide what happens next, but they do not decide whether the vendor received the value. Sorting those two questions apart is most of the work in answering this one. A coding agent works by sending its context, which includes the files it read and the output it saw, to a model that runs on the vendor's infrastructure. If a credential is in that context, the model received it for that request, whatever happens to the copy afterward. This page works from Anthropic's, Browser Use's and Skyvern's documentation, using one record type as its example, a credential in a prompt under zero data retention. The answer turns on what was in the context: retention and training settings change what the vendor keeps afterward, they leave the receipt itself unchanged, and a governed environment changes what reaches the context from rendered pages. Do Claude Code Transcripts Contain My Credentials? takes up the record that stays on the user's side.

Key findings

  • Anthropic's Claude Code documentation describes masking, deny rules and an injectHosts list, which govern what sandboxed commands read and not what the Read tool opens, and anything in the context is sent to the model for the request (Anthropic, Sandboxing, 2026).
  • Anthropic's privacy documentation for its consumer plans states that, if model training is allowed, "we may retain your data in a de-identified format for up to 5 years in our model training pipelines," and that commercial products are covered in a separate article (Anthropic Privacy Center, n.d.).
  • Zero-data-retention options are offered for Anthropic's API and for Browser Use's cloud, and they govern what is stored afterward, not whether the model received the value (Browser Use, 2026).
  • Web agents "are prone to inadvertent use of unnecessary sensitive information," so a credential in the context may be used or repeated when the task did not need it (Zharmagambetov et al., 2025).
  • A governed environment that replaces values with consistent tokens before any model reads the screen means the vendor's model receives the token and not the value, on rendered pages (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination, so a person approves the use of a key and the vendor never needs to receive it (What Is the PII Wall?).

Does my AI vendor see the API keys my coding agent reads?

Yes, for the request that carried them. A coding agent builds its context from the files it opened, the output it read and the instructions it was given, and it sends that context to a model hosted by the vendor. The model reads the whole of it to produce the next step. A credential that is in the context is read by the model, whether or not the vendor stores it afterward.

What happens next depends on the plan and the settings. Anthropic's privacy documentation for its consumer plans (Free, Pro and Max) states that, if model training is allowed, data may be retained in a de-identified format for up to 5 years in training pipelines, that the period applies to new or resumed chats after the setting is enabled, and that deleted chats are removed from back-end storage within 30 days (Anthropic Privacy Center, n.d.). Commercial products are covered in a separate article, and its terms are outside this page.

The record type for this page is a credential in a prompt under zero data retention. The retention option governs what is kept after the request. It does not change the fact that the model received the credential to answer it. Does Claude Code Read My .env File? covers one route by which a credential reaches the context.

What do the vendors themselves say?

Anthropic's Claude Code sandboxing documentation describes credentials that can be denied or masked under sandbox.credentials, with a sentinel for masked values and an injectHosts list naming where substitution is allowed (Anthropic, Sandboxing, 2026). It describes controls on what reaches the context, and the pages reviewed do not describe a control that removes a value the context already holds.

Browser Use's cloud secrets page says "Zero Data Retention (ZDR) projects never record, even when recording is requested" (Browser Use, 2026). Skyvern's credentials page says the model that drives the browser "gets placeholders, not your values," and that a typed value can still show up in later screenshots and page text (Skyvern, 2026).

Anthropic's privacy documentation, cited above, concerns consumer plans and states that commercial products are covered elsewhere. Which terms apply to a given Claude Code deployment is not described in the pages reviewed here, so a team should read the terms of its own plan and ask the vendor for a dated written answer.

Source What it documents What the pages reviewed do not describe
Claude Code sandboxing Masking, deny rules, injectHosts Removing a value already in the context
Anthropic privacy documentation Consumer retention and training terms Terms of a given commercial deployment
Browser Use Zero-data-retention projects; placeholders to the model Terms of the ZDR option
Skyvern Placeholders to the model; real value swapped in at typing Whether page text that echoes a value reaches the model

What do retention and training settings change?

They change what is kept. A zero-data-retention option means the vendor does not store the prompt and response after the request is served. A training opt-out means the data is not used to improve models. Both narrow the vendor's use of the data after the fact, and both are matters of contract and configuration, which a team can review in a procurement process and a security questionnaire.

They do not change what the model read. The request still carries the credential to the model, and the model still sees it to produce its answer, which is the point the contract language tends to bury. If the answer repeats the credential, writes it to a file or passes it to a tool, that happens on the user's side of the line, inside the session. The setting protects against retention. It does not protect against exposure to the model, and a team that treats the two as the same has bought less than it thinks.

The practical reading is to keep the credential out of the context in the first place. Masking, denial and removal of the value from the working tree all act before the request is sent. How Do I Keep API Keys Out of Claude Code's Context Window? lists the settings, and they are the only controls in this family that change what the vendor's model receives.

Why is the context the unit that matters?

Because the context is what crosses the boundary. Contracts and settings describe what the vendor does with data after it arrives. The context decides what arrives. A credential that is not in the context is not sent, not retained under any policy and not trained on under any plan, which is a stronger position than any promise about what happens afterward.

Attack research shows why the context deserves attention. Against adaptive attackers, 12 published prompt injection defenses gave way, with attack success rates above 90% for most (Nasr et al., 2025). An instruction hidden in a file can tell the agent to repeat a credential from its context, and the repetition happens regardless of the vendor's retention terms. Research on information flow in language models puts it this way: "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025).

OWASP names the failure class as secret leakage, the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" (OWASP, 2025). A vendor's model is a destination, and whether it is sanctioned is a decision for the organization.

Where do the credentials in a context come from?

From files, output and pages. The reported GitGuardian totals are "28,649,024 new secrets exposed in public GitHub commits across 2025" and "24,008 unique secrets exposed in MCP configuration files" (Help Net Security, 2025). The figures describe public commits and do not say how many reached a model's context.

They support a modest conclusion: credentials are scattered through the places an agent reads, and what it reads goes to the model. Harvard's security office lists Sensitive Data Exposure and Context and Memory Leakage among seven risk categories for AI-enabled systems (Harvard University Information Security and Data Privacy, 2026), and a credential in a prompt touches both.

The example record shows it in miniature. The credential was in a prompt, the plan applied zero data retention, and the model still received the value. What Can an AI Agent See in Your GitHub Settings? takes up the rendered-page case, and Is It Safe to Let an AI Agent Set Up Your Cloud Environment? covers the cloud side of the same question.

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. 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. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this question it covers the pages, and it changes what the vendor's model receives. If the agent works in a browser on a console or settings page where a key is shown, the value is replaced with a placeholder before the model reads it, so the request carries the token and not the key. Retention and training terms then apply to a token, which is a much smaller thing to protect. It does not change what a coding agent sends from a terminal or an editor, and the person approving consequential actions does not change that either.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a credential read from a local file is not closed by it. That is closed by the controls that keep the value out of the context, and the two sets of controls complement each other.

Methodology and limitations

This page rests on Anthropic's Claude Code sandboxing documentation and privacy documentation, Browser Use's and Skyvern's documentation, OWASP guidance, three research papers, a press report of GitGuardian data, Harvard University guidance and existing RedactSure research pages. Sources were read between October 16, 2026 and October 21, 2026. Quoted facts are cited to the page that states them, and the press figures are cited as reported, not as independently measured. The page is a reading of public documents and should be read with each vendor's current documentation open.

RedactSure did not test any of these tools hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader, and in particular the terms of zero-data-retention options and of commercial plans are outside this page, because the pages reviewed give only the consumer terms quoted. The table is a summary of the documentation as read and not a configuration guide. The research papers concern attacks and web agents in general and are cited for the principle only. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Examples describe record types, such as a credential in a prompt under zero data retention, and not organizations.

Determinations about whether a configuration meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a reading of the organization's own contract and plan terms, repeated when the plan or the product changes, since a change to either would change the answer.

What the record shows

The documentation gives a direct answer with a distinction. Whatever is in the context goes to the vendor's model for the request, retention and training depend on the plan, and zero-data-retention options govern storage and not receipt. The leak record shows how many credentials sit in the places an agent reads, and the attack record shows why a credential in a context can be repeated. None of the pages reviewed gives the terms of a given commercial deployment or describes who approved the use of a key. The organization's own plan is the place for that test: place a dummy credential in a prompt, then ask the vendor in writing where it went and how long it stays.

Frequently asked questions

Does my AI vendor see the API keys my coding agent reads?

Yes, for the request that carried them. Whatever is in the context goes to the vendor's model to produce the next step, and retention and training depend on the plan. A credential that is not in the context is not sent. Keep credentials out of the context with masking, denial and removal from the tree, read the terms of your own plan, ask the vendor to confirm them in writing, with a date, and rotate any credential that sat in a context you did not intend to share.

Does zero data retention keep my credential from the model?

No. Zero data retention governs what the vendor stores after the request, not whether the model received the value to answer it. The model still read the credential, and anything the agent does with it afterward, such as repeating it or writing it to a file, happens on your side. Retention options reduce what is kept, and only keeping the credential out of the context reduces what is sent, so use both kinds of control together.

What do retention and training settings change?

They change what the vendor keeps and how it uses data after the request, which matters for compliance and for the size of a later breach. Anthropic's consumer documentation says training-enabled data may be retained in de-identified form for up to 5 years and that deleted chats are removed from back-end storage within 30 days. Commercial products are covered separately, so read the terms for your plan and ask for a dated written answer that names the plan, the product and the version.

How do I keep a credential out of the context?

Deny the files and variables that hold it for sandboxed commands, mask the ones commands must use so they see a sentinel, add a permission rule against reading the files, and keep real values out of the working tree, test output and configuration the agent reads. These controls act before the request is sent, which is when they can change what the model receives. Then test with a dummy credential, check what the agent read, and repeat the test after each release.

Does a governed browser environment change what the vendor receives?

For rendered pages, yes. If the agent works in a browser on a console or settings page, a governed environment replaces the key with a placeholder before the model reads it, so the request carries the token. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a credential read from a local file still needs its own controls. For a key read from a file rather than a page, the question goes back to the vendor's own retention terms.

What should a security team ask the vendor in writing?

Ask what is sent to the model, what is retained and for how long, whether the data is used for training, who at the vendor can read it, and which terms apply to the plan in use. Ask whether zero-data-retention applies and what it covers. Treat anything the vendor does not document as unanswered, and ask for a dated answer that names the plan, the product and the version, so it can be checked again after the next release.

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 an API Key Out of the Request the Vendor Receives

Retention and training terms act after the request arrives, and masking and deny rules cover named credentials, so a key shown on a rendered page falls outside both.

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

Before: the agent opens a settings page showing a key, the request to the vendor carries it, and zero data retention decides only whether a copy is kept. Inside the governed environment: the request carries KEY_001, the named person approves the action that uses the key, and the real value resolves there alone.

RedactSure is deploying now with enterprise and government customers. Adaptive attackers bypassed 12 published prompt injection defenses at rates above 90 percent for most.

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

See it on your own workflow

Whatever the model reads on a page goes into the request your AI vendor receives. Bring a task that opens one of your settings pages and see, with test values, what that request would carry. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.