Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Do Claude Code Transcripts Contain My Credentials?

A masked credential appears as a sentinel in the output of sandboxed commands, but anything read through the Read tool or found in command output appears as read. Masking covers configured credentials and not discovered ones.

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

Teams that govern coding agents tend to think about what an agent can read and forget what it leaves behind. A session writes a record of commands and output, and a record is a second copy of anything that passed through it. Credentials in that copy outlive the session, can be synced or shared, and are not covered by a setting that only stopped the first read. A transcript is the record of a session: the commands the agent ran, the output it saw, the files it opened and what it said about them. If a credential passed through any of those, it can be in the record. The answer to the title therefore depends on how the credential reached the agent. This page works from Claude Code's sandboxing documentation, using one record type as its example, a token printed by a failing test and found in the transcript. Masking covers a configured key, while a credential the agent discovers in output reaches the record as read, so the discovered credential is the harder case and the one a security team should plan for. How Do I Keep API Keys Out of Claude Code's Context Window? covers the settings that keep configured keys out of the context.

Key findings

  • Claude Code's sandboxing documentation describes a sentinel shown to sandboxed commands in place of a masked credential, so those commands carry the sentinel and not the real value (Anthropic, Sandboxing, 2026).
  • Output the agent discovers, such as a token printed by a failing test or a value in a file it opens, is not described as masked, and it appears in the session as read (Anthropic, Sandboxing, 2026).
  • GitGuardian's data, as reported, found Claude Code co-authored commits "leaked secrets at roughly double the baseline rate," which is a reason to look at what a session holds (Help Net Security, 2025).
  • Web agents "are prone to inadvertent use of unnecessary sensitive information," so a credential that enters a session 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 keeps a key out of the record on rendered pages, because the model and the record only ever hold the token (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination, so a person approves the use of a key and the record shows the token and not the key (What Is the PII Wall?).

Do Claude Code transcripts contain my credentials?

They can. A transcript holds what the session held. If the agent read a .env file, the contents are in the record. If a test printed a token, the token is in the record. If the agent ran a command that echoed an environment variable, the value is in the record. The transcript is a faithful copy of the inputs, and it is only as clean as they were.

For credentials the configuration masks, the record is cleaner. The documentation describes a sentinel that the agent sees instead of the real value, so the commands in the transcript carry the sentinel and the real value is supplied outside the model's view (Anthropic, Sandboxing, 2026). That protects the configured credentials: the ones the team named in advance.

The record type for this page is a token printed by a failing test and found in the transcript. Nobody configured that token as a credential in the session, because nobody knew the test would print it. It was discovered, not declared, and the masking did not apply. Does Claude Code Read My .env File? covers the file route into a session, and Is It Safe to Give Claude Code My GitHub Token? covers a credential given deliberately.

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. It states that Read, Edit, Write, WebFetch and WebSearch follow permission rules instead of the sandbox and that local MCP servers and hooks run with full access (Anthropic, Sandboxing, 2026). The pages reviewed do not describe masking of values the agent discovers in output, and they do not describe where a transcript is stored or for how long.

In Anthropic's engineering post, "effective sandboxing requires both filesystem and network isolation," and sandboxing "safely reduces permission prompts by 84%" (Anthropic Engineering, 2025). The first is a design principle for what the agent can reach. The second is a usability result and does not measure what a transcript contains.

Coder puts the boundary first in its documentation, "LLMs and agents can be dangerous if not run with proper boundaries," and pairs it with separate identities with limited scope for autonomous work (Coder, 2026). It governs the identity an agent runs as and does not describe transcripts.

Source What it documents What the pages reviewed do not describe
Claude Code sandboxing Sentinel for masked credentials; deny rules Masking of discovered output; transcript storage
Anthropic engineering post Filesystem and network isolation What a transcript contains
Coder best practices Separate identities with limited scope Transcripts

What does masking replace, and what can it not see?

It replaces the values the configuration names. If a team lists a key as masked, sandboxed commands see a sentinel, the agent writes those commands with the sentinel, and a proxy supplies the real value for the hosts on the injectHosts list. The Read tool is outside the sandbox and still returns the real value from any file that holds it. The sentinel is what appears in the transcript.

It cannot see what nobody listed. A token in a file the agent opens, a value in a stack trace, a header in a debug print and a key in a response body are all discovered at run time. The pages reviewed describe masking for configured credentials and do not describe a scan of the output for credentials, so the transcript holds those values as read.

Item in the session Appears in the transcript as Note
Configured, masked credential A sentinel Real value supplied outside the model's view
Value read from an opened file The value A sandbox deny does not stop Read; add a permission rule, or keep it out of the tree
Token printed by a failing test The value Fix the test output

The practical reading is to treat the transcript as sensitive, because it may hold the most complete copy of whatever the session saw. It should be stored and shared like the credentials it may contain, and it should be reviewed before it is pasted into an issue or sent for support. How Do You Let an AI Agent Manage API Keys Without Reading Them? covers the key-handling side.

Why is a discovered credential the harder case?

Because nobody planned for it. A configured credential has a rule: deny it, mask it, name its hosts. A discovered credential has none. It arrives in output the team did not expect, and the control the team set up does not know it is there. A scan of the transcript afterward can find it, but only after it has been recorded.

Attack research shows why the difference matters. In one evaluation, adaptive attackers defeated 12 published prompt injection defenses, most of them at success rates above 90% (Nasr et al., 2025). If a credential is in the session, an injected instruction can ask the agent to repeat it, and the transcript is the first place it appears. Information-flow research states the mechanism: "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).

Among the seven risk categories Harvard's security office names for AI-enabled systems are Sensitive Data Exposure and Context and Memory Leakage (Harvard University Information Security and Data Privacy, 2026). A transcript holding a discovered credential touches both, since it is a store of context.

Where do the credentials in a record come from in practice?

From files, tests and tools. As reported, GitGuardian counted "28,649,024 new secrets exposed in public GitHub commits across 2025" and, separately, "24,008 unique secrets exposed in MCP configuration files" (Help Net Security, 2025). The figures describe public commits and do not say how many were in transcripts, which are not public by default.

They support a modest conclusion: credentials are scattered through the places an agent reads, and an agent that reads them records them. The example record shows it in miniature. The token was printed by a failing test, the agent read it as output, and the transcript kept it. Nothing in the setup was misconfigured. The configuration simply covered the credentials it knew about, and the test was written before anyone thought of the agent as a reader of its output.

The fix is architectural. A credential that never reaches the session cannot be in the record, so the strongest control is what the agent can read and what the tests print. 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.

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 record holds. 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 record of that session holds the token and not the key. It does not rewrite a Claude Code transcript from a terminal session, which the harness controls. The two controls are complementary: one acts on what a rendered page shows and so on what the record holds for that session, and the other acts on credentials the configuration names. A team that uses both has closed two different routes, and a team that uses one has closed one, which is the practical case for using both.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a token printed by a local test is not closed by it. That is closed by fixing what the tests print and by keeping real credentials out of the environment.

Methodology and limitations

This page rests on Anthropic's Claude Code sandboxing documentation and engineering post, Coder's documentation, 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 20, 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 Anthropic's current documentation open, since Claude Code changes frequently.

RedactSure did not test Claude Code hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader, and in particular transcript storage, retention and any scan of output for credentials are not described. 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 token printed by a failing test, 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 test of the organization's own sessions, with a dummy token printed on purpose, repeated after each release, since a change to the tool would change the answer. The date on this page marks when the documents were read, and a later release should be treated as unreviewed until the test is repeated.

What the record shows

The documentation gives a direct answer with a limit. Masked credentials appear as sentinels in sandboxed command output, and values the agent reads through the Read tool or discovers in output appear as read. The leak record shows how widely credentials are scattered through the places an agent reads, and the attack record shows why a credential in a session can travel. None of the pages reviewed describes where a transcript is stored, who can read it, or who approved the use of a key. To check a given setup, make a dummy token print in a failing test, run the agent on it, and search the transcript for the dummy value, recording the date and the version of the tool.

Frequently asked questions

Do Claude Code transcripts contain my credentials?

They can. Masked credentials appear as sentinels in sandboxed command output, but anything the agent read through the Read tool or found in command output appears as read, so a token printed by a failing test is in the record. The transcript is as clean as the inputs. Test with a dummy token printed on purpose, search the transcript for it, keep real credentials out of the environment and the tests, and repeat the test after each release because behavior can change and the record may differ by version.

Does masking remove credentials from the transcript?

For configured credentials, sandboxed commands see a sentinel and the proxy supplies the real value for listed hosts. A credential file opened with the Read tool still appears in full, so keep the file out of reach as well. Values the agent discovers in files or output are not masked unless the team declared them, so they appear as read in the session record. Keep real credentials out of test output and files too.

Where is the transcript stored, and who can read it?

Transcript storage, retention and access are not described in the pages reviewed, so do not assume. Treat a transcript as sensitive, since it may hold whatever the session held, including values nobody meant to record, so limit who can read it. Store and share it like the credentials it may contain, with access limited, review it before pasting it into an issue or sending it for support, and ask the vendor in writing for a dated answer that names the version.

What should I do if a credential ended up in a transcript?

Treat the credential as exposed and rotate it, since a value that reached a session cannot be recalled. Find how it got there, whether a file, a test or a tool, and close that route so it cannot recur. Remove or restrict the transcript where policy allows, and note who had access, and check the provider's logs for use of the credential since the session ran. Then add the route to your review list, and ask whether other copies of the transcript exist.

Does a governed browser environment change what a transcript holds?

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 record holds the token and not the key, and a person approves any consequential action. It does not rewrite a terminal transcript or cover the IDE, the local filesystem or MCP, so those routes need their own controls, and the controls complement each other.

What should a security team ask for in writing?

Ask which credentials are masked, what happens to values the agent discovers, where transcripts are stored and for how long, and who can read them. Ask who approves a consequential use of a key and what record shows what the model read. Anything the vendor does not document counts as unanswered; ask for a dated answer naming the version and the configuration, so the check can be repeated after the next release. A transcript nobody can locate is a transcript nobody can audit.

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 a Discovered Credential Out of the Session Record

Masking covers credentials a team named in advance, so a value discovered on a page the agent opens is read as is and kept in the record.

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

Before: the agent opens a console page showing a key nobody configured, and the model and the record hold it. Inside the governed environment: the model reads KEY_001, the named person approves the one action that uses it, and the record shows KEY_001 and the approval.

RedactSure is deploying now with enterprise and government customers. GitGuardian's data, as reported, found Claude Code co-authored commits leaked credentials at roughly double the baseline rate.

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

See it on your own workflow

A credential that reaches a session transcript stays wherever that transcript is later copied or shared. Bring a task your agent already runs and see, with test values, what the record holds once it finishes. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.