Credentials

The Credentials page shows which credential sources are in use across your developer machines, how many devices each one affects, and how much of that material is sitting in plaintext.

Credential files are what supply chain malware goes looking for. A malicious npm postinstall script or a compromised IDE extension does not need to break anything: it sweeps a known list of locations, reads ~/.aws/credentials, ~/.npmrc, and ~/.docker/config.json, and sends what it finds to a remote server. That list is public, short, and the same on every machine.

This page gives you the same list for your own fleet, ahead of time. When the next compromised package is disclosed, you already know which sources are in play, how far each one spreads, and which machines hold the material.

Credential-bearing files are read locally, using bounded reads, only far enough to determine whether concrete credential material is present and whether it is protected. No credential value, fragment, hash, fingerprint, or parser output is ever stored, logged, displayed, or sent off the device.

How the page is organised

Three terms run through the page, and they count different things:

• A source is a tool that keeps credentials, such as AWS credentials or kubeconfig. There are thirteen, listed under Covered sources.
• A location is one credential file on one device. A developer with three SSH keys has three locations for that source.
• An entry is one credential inside a location. An AWS credentials file with two named profiles holds two entries.

So a source with 7 affected devices, 16 locations, and 16 entries is one tool, holding sixteen credential entries, spread across seven machines. Entries are counted as found. They are not validated against the provider, checked for expiry, or deduplicated across devices.

Findings show where credential material was found during each device's latest scan. They do not tell you whether a credential is still active or valid, and the same credential present on two machines is counted on each of them rather than recognised as one credential. Read the counts as a map of where material sits, not as a count of distinct secrets.

Where to start

• The Plaintext devices column. It is called out in red for a reason: on those devices the credential material for that source is stored without encryption or passphrase protection, so any process that can read the file can read it directly.
• Sources that spread widest. The list is a picture of blast radius. A source on most of your fleet is one where a single credential-stealing package reaches nearly everyone.
• Filter by category. Cloud and Package registries are where production keys and publishing tokens live. Not every developer needs either, and this is the view that shows who has them.

Filters

Category chips scope the list to one of the five families, each showing how many sources in that family were observed:

• Cloud
• Source control
• Package registries
• Containers
• Infrastructure

The page also supports Search sources for free-text search across source names, and Export CSV to export the current view.

The sources list

Column	What it shows
Source	The tool that keeps the credentials, with its category beneath.
Affected Devices	How many devices hold this source at all.
Plaintext devices	How many of those devices hold at least one entry stored without encryption or passphrase protection. Shown in red
Locations	How many credential files were found across the fleet for this source.
Credential entries	How many reported credential entries those files hold
Last observed (GMT)	When a device last reported this source.

Where Locations exceeds Affected devices, some machines hold more than one file for that source, which is normal for SSH keys and for developers juggling several kubeconfigs. Where Credential entries exceeds Locations, some files hold several credentials, which is normal for an AWS credentials file with multiple profiles or a .netrc covering several hosts.

Source details

Select any source to open its detail panel.

Six figures summarise the source across the fleet:

Figure	What it counts
Affected	Devices holding this source.
Plaintext	Devices holding at least one entry stored without encryption or passphrase protection
Protected	Devices holding at least one encrypted entry.
Locations	Credential files found across those devices.
Credential entries	Individual credentials in those files.
In plaintext	How many of those entries are stored without encryption or passphrase protection.

The Plaintext and Protected device counts can overlap, and often do. A developer with one passphrase-protected SSH key and one without counts on both sides, which is exactly the machine worth looking at.

Affected devices lists every device holding the source, searchable by name. Each row shows the device, whether its entries are Plaintext, Protected, or both, the user account, platform, and device identifier, and a summary in the form 3 locations · 3 entries (2 plaintext) with when it was last seen. View device opens that machine.

Protection

State	What it means
Plaintext	The material is stored without encryption or passphrase protection, so a process that can read the file can read the credential directly
Protected	The material is present but not readable as stored, because it is encrypted, passphrase-protected, or hardware-backed

Protection describes how the material is guarded, not how sensitive it is. A plaintext registry token and a plaintext cloud key are both readable by anything running as that user, which on a developer machine includes every package postinstall script, every IDE extension, and every AI agent with shell access.

Protected currently applies to encrypted, passphrase-protected, or hardware-backed private-key material. That is most often an SSH private key, and it also covers supported private keys embedded in a kubeconfig client-key-data field. Sources that store credentials in a form their tool reads directly are reported as Plaintext.

What counts as an entry

An entry means credential material is in the file: a concrete value in a field the tool consumes as authentication, or a structurally valid private key. A Docker configuration holding a registry auth token counts. So does an AWS credentials file with a key in it, and an .npmrc carrying a publish token.

A file that only names a credential kept somewhere else does not. That includes a field whose whole value is an environment variable reference the tool expands at read time, a configuration that defers to a credential helper or the system keychain, and a file a tool wrote as an empty placeholder. These are not omissions. The credential genuinely is not in that file.

A file that could not be read, or that this version of the agent could not interpret, is recorded as incomplete rather than as clean. An unreadable credential file never resolves to "this machine holds nothing".

Covered sources

Thirteen sources across five categories.

Source	Category	macOS and Linux	Windows
AWS credentials	Cloud	$HOME/.aws/credentials	%USERPROFILE%\.aws\credentials
AWS config	Cloud	$HOME/.aws/config	%USERPROFILE%\.aws\config
Google Cloud application default credentials	Cloud	$HOME/.config/gcloud/application_default_credentials.json	%APPDATA%\gcloud\application_default_credentials.json
SSH private keys	Source control	$HOME/.ssh	%USERPROFILE%\.ssh
Git credential store	Source control	$HOME/.git-credentials and $XDG_CONFIG_HOME/git/credentials	(same, with $XDG_CONFIG_HOME defaulting to %USERPROFILE%\.config)
netrc	Source control	$HOME/.netrc	%USERPROFILE%\_netrc
GitHub CLI hosts	Source control	$HOME/.config/gh/hosts.yml	%APPDATA%\GitHub CLI\hosts.yml
npm configuration	Package registries	$HOME/.npmrc	%USERPROFILE%\.npmrc
PyPI configuration	Package registries	$HOME/.pypirc	%USERPROFILE%\.pypirc
Docker configuration	Containers	$HOME/.docker/config.json	%USERPROFILE%\.docker\config.json
kubeconfig	Containers	$HOME/.kube/config	%USERPROFILE%\.kube\config
Terraform credentials	Infrastructure	$HOME/.terraform.d/credentials.tfrc.json	%APPDATA%\terraform.d\credentials.tfrc.json
Vault token	Infrastructure	$HOME/.vault-token	%USERPROFILE%\.vault-token

The Terraform credentials file is the one HCP Terraform and the Terraform CLI write their tokens to. $XDG_CONFIG_HOME defaults to .config under the developer's home on every platform, including Windows, and follows the variable where a developer has set one.

SSH private keys are counted one location per key file rather than one for the directory, because protection differs between keys and a key committed to a repository has to be identifiable on its own.

Where a tool reads several files at once, every location containing concrete credential material is counted. That applies to the git credential store, which reads both of its paths, and to kubeconfig, where each entry in a KUBECONFIG path list is its own location. For every other source, the highest-precedence location the tool would actually read is counted, because counting a superseded file would claim a credential is in use when the tool never looks at it.

Relocated credential files

Developers move these files, and probing only the default path would report such a machine as holding no credentials at all. Where a tool supports an environment variable that relocates its credential file, that variable is resolved from the developer's own session and searched ahead of the default path:

Variable	Relocates
AWS_SHARED_CREDENTIALS_FILE	AWS credentials
AWS_CONFIG_FILE	AWS config
GH_CONFIG_DIR	GitHub CLI hosts
NPM_CONFIG_USERCONFIG	npm configuration
DOCKER_CONFIG	Docker configuration
KUBECONFIG	kubeconfig, as a path list where every entry is read
XDG_CONFIG_HOME	The git credential store and GitHub CLI hosts, for tools that honour it

Paths are resolved from the signed-in developer's environment, read from their login shell on macOS and Linux and from their user environment on Windows, not from the agent's own environment, which belongs to the root or SYSTEM account the agent runs as.

Requirements

Credential inventory requires Dev Machine Guard agent v1.16.0 or later. Devices on earlier agents keep reporting everything else and contribute nothing to this page.

macOS: several of these locations are TCC protected, so the agent needs Full Disk Access to read them. Without it, those sources cannot be read and will be missing from this page. See MDM Deployment.

A scan that resolves no signed-in developer account reports no credential inventory rather than reporting the sources as absent.

What is collected

Every location is an exact path rather than a directory to walk, and each one is a single size-capped read. No directory tree is traversed. The one exception is .ssh, which is listed a single level deep so that candidate private-key files can be inspected individually. Known public-key files, config, known_hosts, and other non-key files in that directory are skipped.

Never collected, from any source:

• The credential value
• Any fragment of a credential value
• A hash, digest, or fingerprint of a credential
• Any classification derived from the characters of a secret