# Credential-store reads

Flags an AI agent reading a file that holds credentials into its context — a `.env`,
`~/.aws/credentials`, an MCP configuration with tokens in it, a private SSH key.
**Default: warn.**

## Why this is separate from secret scanning

Secret scanning catches a key when its *shape* shows up in the traffic. By then the value is
already in the model's context. This detector catches the *read itself*: the moment an agent
opens the store, whether or not a recognizable key ever appears in what it gets back. It is
also what infostealers and misbehaving agents went after first in 2026.

## What it looks at

Only two things, both in the agent's own tool calls: the file path a file tool (Read, Edit,
Write and their equivalents) was asked to open, and the shell command a terminal tool ran
(`cat .env`, `source ~/.aws/credentials`, input redirected from a store). A mention of `.env`
in a message is not a read and is ignored. Listing a directory or checking that a file
exists is not a read either.

It recognizes a fixed list of stores: `.env` files (but not `.env.example`, `.env.sample` or
`.env.template`), Claude Code configuration, MCP configuration files, git credentials, AWS
credentials, gcloud credentials, Kubernetes config, `.npmrc`, Docker config, private SSH
keys and `.netrc`. The list is in the product, not in your settings — nobody can turn this
into a tool for listing files.

## What is recorded

The **category** of store and a count — for example `aws_credentials × 1`. Never the path,
never the contents. Your developers' directory layout does not end up in the audit record.

## Setting it

**Warn** shows the read in Activity and to the developer. **Block** refuses the request that
would carry the file's contents to the model — the honest version of "keep `.env` out of the
model's context", which secret scanning alone cannot do. Expect a developer whose agent
legitimately needs a local `.env` to notice; the message names the category so they know why.

When a read is not blocked, it also counts as the *private data* part of the lethal-trifecta
check for that device, so untrusted content plus an outbound call afterwards is caught even
though the data came through a built-in tool rather than an MCP server.