Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can a Coding Agent Read My AWS Credentials File?

Any agent with filesystem access can read ~/.aws/credentials unless the harness blocks the path, and Claude Code and Cursor document a way to block named paths. Treat the file as readable and move the credentials out of it.

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

Cloud access on a developer machine often comes down to one small file that has sat in the same place for years. Anyone or anything that can read that file holds the keys to the account, and an agent working in the home directory is a new reader of it. The credentials file is plain text in a known location in the home directory, which makes it the first place an agent, or an instruction hidden in a repository, would look for cloud access. Whether the harness stops that read is a question for each vendor's documentation, and the documentation differs, so the answer to the title depends on the harness and on whether it documents a control for that path. This page works from the vendors' own documentation, using one record type as its example, a ~/.aws/credentials file on a developer laptop. Claude Code, Cursor and Devin document a way to block named paths, and none documents a default block for this file, so the protection exists only where the team that owns the account has configured it and confirmed that it holds against every route the agent has. How Do I Let a Coding Agent Use AWS Without Giving It My Access Keys? covers the alternative.

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 ~/.aws (Anthropic, 2026).
  • Cursor documents .cursorignore as its file-access block, and also says it ignores files in .gitignore and a default list by default, with protection not guaranteed and terminal and MCP tools unable to block access (Cursor, 2026).
  • Devin's CLI sandbox hides paths named in Read(...) deny rules from sandboxed commands, and its pages name no credentials file and no default block for one (Cognition, CLI, 2026).
  • GitGuardian's data, as reported, found Claude Code co-authored commits "leaked secrets at roughly double the baseline rate," so credential files are a practical place to look (Help Net Security, 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 path-level block 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 a coding agent read ~/.aws/credentials by default?

It can. The file is plain text in a known location, and an agent allowed to read the home directory can read it, whether to diagnose a failed deployment or because an instruction told it to. The access keys inside it are long-lived by design. They stay valid until someone rotates them, and they carry whatever permissions the user holds.

The stakes follow from that. A key in the credentials file is a bearer credential: anyone holding the pair can call AWS as the user until it is revoked. A pair read into an agent's context is a long-lived credential in a place built for copying from, and it can be repeated in output, written to a log or sent to a tool. Web agents "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025), so the read need not even be malicious.

The record type for this page is one ~/.aws/credentials file on a developer laptop with a default profile and one pair of long-lived access keys. Whether an agent can read it depends on the harness, and the next sections take them in turn. The comparison is meant to show where each vendor draws its documented line, not to rank the tools. Is It Safe to Let an AI Agent Set Up Your Cloud Environment? covers the cloud side of the question.

What do the vendors themselves say?

Anthropic's Claude Code sandboxing documentation describes deny rules for files and environment variables under sandbox.credentials, and 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, so a deny rule governs sandboxed commands and not the Read tool (Anthropic, 2026). Cursor's ignore-files documentation describes .cursorignore as the mechanism that blocks file access, and says it also ignores .gitignore entries and a default list, without saying whether the default list covers ~/.aws (Cursor, 2026).

Cognition's Devin CLI sandbox page says paths covered by Read(...) rules in the deny list are "hidden from sandboxed commands entirely," and it does not mention credentials files or a default block for ~/.aws/credentials (Cognition, CLI, 2026). Devin's secrets guide covers stored credentials by scope, not files on disk (Cognition, Secrets, 2026).

The Claude Code row of the table below is the only one that describes a deny rule and its boundary together. Each row is documentation as read on one date, and it does not reflect what the products do in every configuration, version or plan.

Harness What the pages reviewed document What they do not describe
Claude Code Sandbox deny rules for files; a denyRead entry does not stop Read, and Read follows permission rules An approver; what the model read
Cursor .cursorignore blocks listed paths; a default ignore list Whether the default list covers ~/.aws; an approver
Devin Credential handling; CLI sandbox with Read(...) deny rules A default block on a credentials file

What does a path-level block cover, and what does it leave open?

It covers the listed path for the route it governs. In Claude Code a deny rule on ~/.aws blocks sandboxed commands from reading the directory. In Cursor an entry in .cursorignore blocks the agent's file access to the listed path, though Cursor says its terminal and MCP tools cannot block it and protection is not guaranteed. The Cursor rule lives in the project and can be reviewed in a code review. The Claude Code rule must sit in user or managed settings, because the documentation says it is ignored in a repository's own settings file.

It leaves open the routes it does not govern. Claude Code's Read tool follows permission rules and not the sandbox. A Cursor entry covers the paths it lists, using .gitignore syntax, so a pattern such as .aws/** covers the directory and a negation can reopen it. A copy of the credentials file in a project, a backup, a profile in an environment variable, a key in a config file and a session token in a shell are different routes, and none is covered by a block on the original path alone.

The practical reading is to treat the file as readable and to remove the long-lived key from it. Short-lived credentials issued per session, through a federation or an assumed role, leave nothing durable in a file for any harness to read. How Do You Let an AI Agent Manage API Keys Without Reading Them? covers the key-handling side, and Does Claude Code Read My .env File? asks the file question of project files.

Why is a long-lived key in a file the weakest form?

Because the file is the credential. A short-lived token that expires in an hour limits what a read can cost. A pair of access keys that has been valid for two years limits nothing. The difference is a design choice made before the agent ever runs.

Attack research shows why that matters. Adaptive attackers bypassed 12 published prompt injection defenses with attack 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 the credentials file and send it somewhere, the open route decides the outcome. Information-flow research states the mechanism plainly: "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's work on agentic applications frames the broader risk set for autonomous systems (OWASP Gen AI Security Project, 2026), and 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). A cloud key in the context touches both.

Where do the keys end up in practice?

In repositories and configuration, often by accident. GitGuardian's data, as reported, counted "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 they do not say how many were AWS keys.

They support a modest conclusion: credentials travel from working files into commits and configuration, and an agent that reads and writes files is part of that path. Columbia's DAPLab collected incidents in which agents deleted a production database and rebuilt a production environment (Columbia DAPLab, 2026). That list covers agent incidents in general, and it is cited here for one pattern: damage follows from reach. The example record shows a version of it: the key in the file carries the user's full permissions, so a read is a loss of everything the user could do in the account.

The fix is architectural. A key that is not in a file cannot be read from one, so the strongest control is where the credential lives and how long it lasts. Does Cursor Read My .env File? asks the same question of a hosted agent.

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 the AWS console, an IAM page where access keys are created or a settings page that shows a key, the value is replaced with a placeholder before the model reads it. It does not read ~/.aws/credentials, which the harness and the operating system govern. The two controls are complementary: one acts on files 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 vendor pages reviewed do 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 credentials file on disk is not closed by it. That is closed by the harness controls where they exist and by removing the long-lived key from the file.

Methodology and limitations

This page rests on Anthropic's Claude Code sandboxing documentation, Cursor's ignore-files documentation, Cognition's Devin documentation, three research papers, OWASP guidance, a press report of GitGuardian data, Harvard University guidance, a Columbia DAPLab post 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, since these products change frequently.

RedactSure did not test any of these tools hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader. The table is 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 credentials file on a developer laptop, 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 harness against a dummy credentials file, repeated after each release, since a change to any of these products would change the answer. The date on this page marks when the documents were read.

What the record shows

The documentation gives a direct answer across harnesses. A credentials file is readable by default, Claude Code, Cursor and Devin document a way to block named paths, and none documents a default block for this file. The leak record shows why credential files are worth protecting, and the attack record shows why one open route is enough. None of the pages reviewed describes who approved a use of a credential or what the model read. Before trusting any block, a team should place a dummy credentials file in a test home directory, apply each harness's block, ask the agent to read it by every route it has, and record which routes succeeded.

Frequently asked questions

Can a coding agent read my AWS credentials file?

Any agent with filesystem access can read ~/.aws/credentials unless the harness blocks the path. Claude Code, Cursor and Devin each document a way to block named paths, with limits, and none documents a default block for this file. Treat the file as readable regardless of the harness: test with a dummy file, move long-lived keys out of the file in favor of short-lived credentials, and repeat the test after each release because behavior can change and the products differ.

Which harnesses document a path-level block?

Claude Code documents deny rules under sandbox.credentials that govern sandboxed commands only. The Read tool is governed separately, since a denyRead entry does not stop it and a Read(...) deny permission rule does. Cursor documents .cursorignore as its block for listed paths, and Devin's CLI sandbox hides paths named in Read(...) deny rules from sandboxed commands, with no credentials file named. Repeat the check after each release, and name the tool version in the record.

Is blocking the path enough?

It closes one route. A sandbox deny rule in Claude Code governs sandboxed commands while the Read tool follows permission rules, and a Cursor entry covers the paths it lists. A copy of the file, a profile in an environment variable or a session token in a shell are different routes, and a block on the original path does not cover them. Remove the long-lived key from the file, use short-lived credentials so a read yields little, and test each route with a dummy file.

What is better than a key in a file?

A short-lived credential issued per session or per task, with a stated expiry, through federation or an assumed role, with permissions scoped to the task. Nothing durable sits in a file, so a read by any harness yields a token that expires. A person should approve consequential actions, and the record should show which credential was used. This limits the loss from a read and does not prevent the read, so it belongs beside the harness block and not in place of it. Rotation becomes routine.

Does a governed browser environment help with AWS keys?

Only on rendered pages. If the agent works in a browser on the AWS console or an IAM page that shows a key, 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 credentials file on disk needs the harness block and a safer way to hold the key, and the two controls complement each other.

What should a security team ask for in writing?

Ask which credential paths each harness blocks, who reviews the list and how often, whether the block covers every read route, where real keys are stored and how long they last. Ask who approves a consequential use of a credential and what record shows what the model read. Treat anything the vendor does not document as unanswered, and ask for a dated answer that names the version, so the answer 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 AWS Access Key Off the Screen an Agent Reads

A credentials file is plain text in a known place, and the blocks reviewed above each govern one route without governing the page where a key is created.

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

Before: an agent creating a key on the IAM page reads the key ID and access key in the clear, and the pair can land in a commit or a log. Inside the governed environment: the page renders with KEY_001 and the real pair is written only to the credential store a named person approved.

RedactSure is deploying now with enterprise and government customers. Cursor states that terminal and MCP tools cannot block access to ignored files.

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

See it on your own workflow

The IAM page shows a new key pair once, and once is enough for it to reach a commit or a log. Bring an AWS task your team delegates and see, with test values, where the pair is written. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.