Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can Claude Code Read My SSH Keys?

Yes unless ~/.ssh is denied in sandbox.credentials, and even then only for sandboxed commands, so deny the directory outright. An SSH key is easy to leave off the list of credentials to protect.

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

Developers who run Claude Code carry an SSH private key that acts as a permanent identity: it signs in to servers and repositories without a second factor in many setups, and it does not expire on its own. That makes it a higher-value target than most API tokens. Claude Code runs on the developer's own machine, so the question is which of its tools can reach the folder where the key lives and which setting limits them. A private key sits in a well-known folder in the home directory, it is a file like any other, and an agent that can read the home directory can read it. The answer to the title therefore depends on one setting and on the scope of that setting. This page works from Claude Code's sandboxing documentation, using one record type as its example, a ~/.ssh directory that is denied. The documented result is that a deny rule on the directory stops sandboxed commands from reading the key while the file tool runs outside the sandbox, so a team should check both routes before it relies on the rule. Does Claude Code Read My .env File? asks the sibling question for project files. The vendor pages cited here were read on October 20, 2026, and each section says which statements come from them.

Key findings

  • Claude Code's sandboxing documentation describes deny rules for files under sandbox.credentials, which block sandboxed commands from reading a listed path such as ~/.ssh (Anthropic, Sandboxing, 2026).
  • The same documentation 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, so a deny rule governs sandboxed commands and not the Read tool (Anthropic, Sandboxing, 2026).
  • GitGuardian's data, as reported, found Claude Code co-authored commits "leaked secrets at roughly double the baseline rate," which makes credential files a practical place to look (Help Net Security, 2025).
  • Adaptive attackers bypassed 12 published prompt injection defenses with attack success rates above 90% for most, so a key the agent can read should be assumed repeatable (Nasr et al., 2025).
  • A governed environment that replaces values with consistent tokens before any model reads the screen keeps a credential out of the context on rendered pages, a route a directory deny rule does not touch (What Is Least Exposure?).
  • Real values resolve only at the approved destination, so a person approves the use of a credential and the model never needs to hold it (What Is a Tethered Agent?).

Can Claude Code read a private key in ~/.ssh by default?

It can. A private key is a file in a known location, and an agent that is allowed to read the home directory can read it, whether to diagnose a failed git push or because a task asked for it. Nothing in the pages reviewed says the agent is kept away from the folder unless someone writes that down. The pages reviewed describe no default that hides the directory. The documented control is opt-in: a deny rule for the path under sandbox.credentials.

The stakes differ from an API token. A token can be rotated at the service that issued it. A private key authenticates its holder to every host that trusts the matching public key, and it often has no expiry. A key read into a context is a long-lived credential in a place designed to be copied from, and the pages reviewed describe no record of the read.

The record type for this page is one ~/.ssh directory that is denied. The deny rule blocks the sandboxed commands from reading it, so a command such as cat on the key file is refused. The same rule does not govern the routes the documentation places outside the sandbox. How Do You Let an AI Agent Manage API Keys Without Reading Them? covers the key-handling side of the problem, and this page keeps to the file.

What do the vendors themselves say?

Anthropic's Claude Code sandboxing documentation describes deny rules for files under sandbox.credentials, masking with a sentinel for values the agent must use, and an injectHosts list naming where substitution is allowed. It places file tools, MCP servers and WebFetch outside the sandbox (Anthropic, Sandboxing, 2026). An approver for the use of a key and a record of what the model read are not described in the pages reviewed.

Anthropic's engineering post says "effective sandboxing requires both filesystem and network isolation" and that sandboxing "safely reduces permission prompts by 84%" (Anthropic Engineering, 2025). The first is the design principle behind denying paths and limiting hosts together. The second is a usability result and does not measure how often a key file is read.

Coder's documentation warns that "LLMs and agents can be dangerous if not run with proper boundaries" and recommends separate identities with limited scope for autonomous work (Coder, 2026). It governs the identity an agent runs as and does not describe where a private key is stored.

Source What it documents What the pages reviewed do not describe
Claude Code sandboxing Deny rules for files; file tools outside the sandbox An approver; what the model read
Anthropic engineering post Filesystem and network isolation; 84% fewer prompts How often a key file is read
Coder best practices Separate identities with limited scope Where a private key is stored

What does a deny rule on ~/.ssh do, and what does it leave open?

It blocks the sandboxed commands from reading the directory. A cat, a copy or a script run through the sandboxed shell that touches a key in ~/.ssh is refused, so the command route is closed. The rule is one line in user or managed settings. The documentation says it is ignored in a repository's own settings file, so it belongs where the team controls it.

It leaves open what the sandbox does not govern. The file tool runs outside the sandbox. The documentation says a sandbox deny entry does not stop the Read tool, and a Read(...) deny permission rule does. A key copied somewhere else, a key loaded into an agent process, and a key referenced from a config file are different routes. The recommendation to deny the directory outright means listing it and not relying on the agent to avoid it.

Route Governed by the deny rule Note
Sandboxed command reading ~/.ssh Yes, as documented Closed when the path is denied
File tool reading ~/.ssh No, documented as outside the sandbox Test before relying on another setting
Key copied to another path Only if that path is denied Remove copies you do not need

The practical reading is that the deny rule is one control among several. Moving the key into a hardware token or a managed credential that signs on request, so that no file holds it, closes every file route at once. Is It Safe to Let an AI Agent Set Up Your Cloud Environment? covers the cloud side of the same choice.

Why is a private key different from other credentials?

Because it is a bearer of identity. Anyone who holds the file can authenticate as its owner, and a key without a passphrase needs nothing else. A single read is a complete loss, not a partial one.

Attack research shows why that matters. Nasr and colleagues report adaptive attacks that bypassed 12 published prompt injection defenses, with success rates above 90% for most (Nasr et al., 2025). If an instruction hidden in a README or an issue tells an agent to read a key and send it somewhere, the only question is whether a route to the file is open. The read need not be malicious at all: web agents "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025).

The information-flow research is explicit about 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). A private key is the confidential data in the sentence. 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).

Where do the keys end up in practice?

In repositories and configuration, often by accident. The GitGuardian figures, as reported, were "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 were SSH keys.

The modest conclusion they support is that credentials move from working files into commits and configuration, and that an agent reading and writing files sits on that path. The example record shows a version of it. The denied directory protects the key in place, and a copy placed in a project for a deployment script is a separate file with the same power.

The fix is architectural. A key that is not in a file cannot be read from one, so the strongest control is where the key lives, and the deny rule is the second line. A scoped, short-lived credential limits the loss further, which is the point made for sign-ups in Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?. Can a Coding Agent Read My AWS Credentials File? applies the same reasoning to cloud credentials.

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. If the agent works in a browser on a repository settings page where a public key is added or a key is displayed, the value is replaced with a placeholder before the model reads it. It does not read ~/.ssh, which the sandbox and the file tool govern. The two controls are complementary: one acts on files and commands on the machine, and the other acts on what a rendered page shows. A team that uses both has closed two different routes, and a team that uses one has closed one. The governed environment also keeps a record of what the model saw on each page, which the sandbox documentation does not describe.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a private key read from disk is not closed by it. That is closed by the deny rule where it applies and by keeping the key out of files.

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. The tables are a summary of the documentation as read and not a configuration guide. The research papers concern attacks and defenses 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 denied ~/.ssh directory, and not organizations. Each vendor page is cited for the statements it makes and for nothing it does not make.

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 Claude Code settings against a dummy key, repeated after each release, since a change to the sandbox or the file 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

For a security team, the documentation gives a direct answer with a limit. A key in ~/.ssh is readable by default, a deny rule under sandbox.credentials blocks the sandboxed commands from reading it, and the file tool runs outside the sandbox. The leak record says why credential files deserve protection; the attack record says why a single open route is enough. None of the pages reviewed describes who approved a use of a key or what the model read. Before relying on the rule, a team should place a dummy key file in a test home directory, deny the path, try to read it with a command and with the file tool, and record which attempt succeeded.

Frequently asked questions

Can Claude Code read my SSH keys?

Yes, unless ~/.ssh is denied in sandbox.credentials, and even then the rule covers only sandboxed commands, not every route. A private key is an ordinary file in a known folder, and the pages reviewed describe no default that hides it. Deny the directory outright, test with a dummy key using both a command and the Read tool, and keep real keys in a hardware token or a managed credential. The test that matters is whether a dummy key in ~/.ssh shows up in the agent's output after the next release.

How do I stop it from reading ~/.ssh?

List the directory under sandbox.credentials so sandboxed commands cannot read it, which is the documented control, and move the keys somewhere no file holds them, such as a hardware token or a signing service. The second step closes the file tool route as well, which the sandbox rule does not govern. Then test with a dummy key and record which route, if any, could read it, with the date and the version of the tool, so a later change shows up as a difference.

Does the deny rule also block the file tool?

No. The documentation says a sandbox deny entry does not stop the Read tool, and that Read follows permission rules, so add a permission rule denying the directory and test both routes. Record the result with the date and the tool version, and repeat the test after each release, since behavior could change with an update to the tool or its permission settings, and a passing result today is not a promise.

Why is a private key worse to expose than an API token?

Because it identifies its holder to every host that trusts the matching public key, and it often has no expiry. A token can usually be rotated at the service that issued it, while a key must be replaced everywhere its public half was installed, which can mean many servers and accounts. A key read into a context is a long-lived credential in a place built for copying, so rotate any key the agent could read, and check the hosts where its public half was installed.

Does a governed browser environment help with SSH keys?

Only on rendered pages. If the agent works in a browser on a page that displays a key or accepts one, such as a repository settings page, a governed environment replaces the value with a placeholder before the model reads it. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a key on disk needs the deny rule and a safer place to live, and the two controls complement each other. Test the page case separately from the key on disk.

What should a security team ask for in writing?

Ask which credential paths are denied and who reviews the list, whether a Read(...) permission rule also denies the path, where real keys are stored, and which MCP servers and hooks are enabled. Ask who approves a consequential use of a key, what record shows what the model read, and who owns each answer. What the vendor leaves undocumented is unanswered; ask for a dated answer that names 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 a Key Shown on a Settings Page Out of the Model

A deny rule on ~/.ssh closes the sandboxed command route, and no page reviewed covers what the model reads when the agent opens a repository's keys page.

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

Before: the model reads the key material shown on the deploy keys page, and it sits in the transcript for the rest of the run. Inside the governed environment: the model reads KEY_001, the real value resolves at the repository only when the named person approves the save, and the record holds the page as received.

RedactSure is deploying now with enterprise and government customers. Adaptive attacks broke most of 12 published injection defenses at rates above 90 percent.

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

See it on your own workflow

A key shown on a settings page is as exposed as one read from disk. Bring a deploy key task your team delegates and see, with test values, what the model reads and what the record keeps. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.