DEV Community: Dwayne McDaniel

Securing Agentic AI Workflows in n8n: From Leaked API Keys to Encryption Key Compromise

Dwayne McDaniel — Fri, 04 Sep 2026 18:36:13 +0000

Agentic AI expands the security boundary of workflow automation. An n8n agentic workflow does not just generate an answer. It uses stored credentials to act across source control, databases, cloud platforms, AI providers, and SaaS applications. A leaked n8n API key is therefore only the beginning of the attack path.

At the center of that access is a single root of trust: the N8N_ENCRYPTION_KEY.

Our research examined how an attacker could move from initial API access to that key and the credentials it protects. We found three weaknesses in the way n8n derives signing and session secrets, demonstrated how weak encryption keys can be recovered offline from public artifacts, and identified 129 internet-accessible instances using known weak keys.

We also reproduced an attack using CVE-2026-25053 that allowed an API key associated with a sufficiently privileged account to be escalated into access to the encryption key and encrypted credential records.

The result is a concrete picture of the risk behind agentic automation: the more systems an agent can reach, the more consequential a failure in its credential and execution layer becomes. This report traces the attack chain from exposed API credentials to encryption key compromise, then provides a hardened configuration designed to break it at multiple points.

The `N8N_ENCRYPTION_KEY` is n8n's root of trust

At the time of this research, n8n had received 48 CVEs since January 2026. Several allowed attackers to escape the workflow execution environment and gain code execution or filesystem access on the host.

Once an attacker reaches the filesystem, two assets become primary targets:

~/.n8n/database.sqlite, which contains stored credentials in encrypted form on default SQLite deployments
The N8N_ENCRYPTION_KEY, provided through the environment or stored in the n8n configuration, which decrypts them

Together, they provide offline access to the plaintext value of every credential stored in the database.

The encryption key also carries responsibilities beyond credential encryption. In the implementation we analyzed, it contributes to the secret used to sign JSON Web Tokens and to the value used to generate the public instance ID.

Concentrating those functions in one key makes it the central trust anchor for an n8n instance. Compromising it can affect stored credentials, token integrity, session authentication, and the confidentiality of every connected integration.

Our analysis identified three weaknesses in that trust model.

Three weaknesses in n8n's key derivation and session authentication

Flaw 1: JWT secret derivation discards half the key

The JWT signing secret is derived from the N8N_ENCRYPTION_KEY by taking every other character.

Under this derivation path, a 32-character encryption key produces a 16-character signing secret. Half of the input characters make no contribution to the derived value, reducing its effective entropy.

The practical severity depends heavily on how the original encryption key was generated. A long, randomly generated key remains difficult to recover. A short or human-memorable value is much more vulnerable to offline guessing.

Flaw 2: Sessions can be forged for OIDC-provisioned users

For users provisioned through OpenID Connect, n8n stores the literal string "no password set" in the password field.

The n8n-auth session token is derived using this password value and the N8N_ENCRYPTION_KEY. Because the password component is known, an attacker who obtains or recovers the encryption key can reproduce the derivation and forge a session for an OIDC-provisioned user without knowing that user's identity provider password.

Flaw 3: Sessions can be forged for pending users

Invited users who have not completed registration have a null password value.

During session derivation, JavaScript coerces that null value into an empty string. As with OIDC-provisioned users, the password component becomes predictable.

An attacker with the encryption key can therefore derive a valid session token for a pending user without knowing a password.

These weaknesses do not reveal the encryption key on their own. Their impact emerges when the key is exposed through a vulnerable host, recovered from weak key material, or obtained through another attack path.

Recovering weak encryption keys offline

The N8N_ENCRYPTION_KEY is often generated automatically, but self-hosted administrators can replace it with a custom value. When that value is human-memorable or follows a predictable pattern, public artifacts can make offline recovery possible.

A leaked n8n JWT acts as a verification oracle.

An attacker can generate a candidate encryption key, apply n8n's JWT secret derivation, and test whether the leaked token's signature verifies. A successful verification confirms that the candidate produces the correct signing secret.

Before n8n v2.25.6, unauthenticated requests to GET /rest/settings could also return the public instance ID, which was derived from the same encryption key. That provided a second independent way to confirm a candidate. Based on our validation, that public instance ID behavior was no longer present in the same form beginning with v2.25.6.

Once the JWT and instance ID had been collected, testing key candidates required no further requests to the target.

We evaluated the exposure at scale:

31,793 n8n instances identified through Shodan
4,398 instances exposing their public instance ID
13.8% of the observed instances affected
129 internet-accessible instances whose IDs matched known weak N8N_ENCRYPTION_KEY values previously exposed on GitHub

These were not merely instances that had once used weak keys. At the time of testing, the public artifacts still matched the known key patterns.

Leaked API keys provide a realistic starting point

Weak encryption keys provide one route to n8n's root of trust. Leaked API tokens provide another starting point, particularly when they belong to users who can create or modify workflows.

In a separate scan of public GitHub commits, we identified 4,576 unique n8n API tokens associated with 1,255 hostnames. Of the 896 instances reachable at the time of testing, 321 accepted at least one exposed token.

That represents approximately 36% of the reachable instances and 26% of all hostnames identified in the commits.

A valid token provides access according to the permissions of the user who created it. Many exposed tokens appeared to belong to owners or administrators, likely because those were the users configuring integrations and committing API credentials.

Depending on those permissions, an attacker may be able to enumerate users, read complete workflow definitions, inspect execution data, list stored credential objects, create workflows, or activate new automations.

Against a fully patched instance, that functionality can already be enough to abuse stored credentials or expose sensitive workflow data. Against a vulnerable instance, the same API access can become the first step toward host and encryption key compromise.

CVE-2026-25053 demonstrates that escalation path.

CVE-2026-25053: From workflow access to arbitrary file read

CVE-2026-25053 is a critical vulnerability in n8n's Git node. It affects versions earlier than 1.123.10 in the 1.x line and earlier than 2.5.0 in the 2.x line.

The vulnerability allows an authenticated user with permission to create or modify workflows to execute system commands or read arbitrary files accessible to the n8n process. n8n fixed it in versions 1.123.10 and 2.5.0.

For our proof of concept, we focused on the arbitrary file-read path.

The Git command-line option --pathspec-from-file=<file> instructs Git to read path specifications from another file. When Git attempts to stage a path that does not exist in the repository, it includes that path in an error message.

The behavior can be used to disclose a file one line at a time.

repo.git $ echo 'Hello\nGitGuardian' > /tmp/hello.txt
repo.git $ git add --pathspec-from-file=/tmp/hello.txt
fatal: pathspec 'Hello' did not match any files
repo.git $ touch Hello
repo.git $ git add --pathspec-from-file=/tmp/hello.txt
fatal: pathspec 'GitGuardian' did not match any files

The first command reveals Hello, the first unmatched line in the target file. After a file named Hello is created in the repository, Git moves to the next path and reveals GitGuardian.

The same behavior can be reproduced through an n8n workflow.

An attacker with a valid API key associated with an account that can create or modify workflows can:

Clone an empty attacker-controlled GitHub repository using the Git node.
Configure the Git node to attempt to add a path literally named --pathspec-from-file=/home/node/.n8n/config.
Read the first line of the configuration file from the resulting Git error.
Create a file in the repository whose name matches that line.
Pull the new file into the workflow's local repository.
Repeat the Git operation to reveal the next line.
Continue until the line containing the encryption key is disclosed.

The first error may reveal the opening { of the JSON configuration. Once a file named { exists in the repository, the next operation advances to the following line, which may contain the N8N_ENCRYPTION_KEY.

Example n8n workflow exploiting CVE-2026-25053 to disclose the encryption key

The official advisory describes the vulnerability as allowing arbitrary file reads, placing any file readable by the n8n process within scope. On a default SQLite deployment, that can include both /home/node/.n8n/config and the n8n database.

The configuration provides the encryption key. The database provides the encrypted credential records. Together, they allow an attacker to decrypt the stored credentials offline.

The attack chain is therefore:

Leaked API token → workflow creation → Git node exploitation → filesystem access → encryption key and credential database → offline credential decryption

The API token alone does not directly decrypt every credential. It provides the authenticated foothold needed to reach a vulnerable node. The encryption key and encrypted credential records complete the compromise.

Responsible disclosure

GitGuardian made several disclosures directly to n8n during the research.

n8n acknowledged the reports, said it was aware of the issues and planned to address them, and subsequently closed the reports. At the time of publication, GitGuardian had not independently confirmed that all changes related to the cryptographic findings had been released.

How to harden an n8n instance

n8n is not only an automation service. It is a credential store and execution environment connected to systems across the organization.

Hardening it requires controls at the instance, identity, node, runner, and credential layers.

Separate instances by trust boundary

Treat each n8n instance as a credential store for a defined team, business unit, or application boundary.

A single shared instance concentrates every connected credential and dataset behind one administrative plane. If one token, workflow, or encryption key is compromised, the blast radius includes every integration available to that instance.

Limit each deployment to the users, workflows, data, and credentials it genuinely needs.

Patch critical vulnerabilities immediately

Subscribe to the n8n security advisory feed and treat critical vulnerabilities as urgent patches.

CVE-2026-25053 is patched in versions 1.123.10 and 2.5.0. The official advisory recommends upgrading, restricting workflow editing to trusted users, disabling the Git node where it is unnecessary, and reducing operating system and network privileges.

In deployments that expose the n8n:config:sentry metadata tag, an unauthenticated visitor may also be able to determine the running n8n version. That allows attackers to identify potentially applicable CVEs before authenticating.

Do not rely on version obscurity as a control.

Keep the API and administrative interface private

Place the n8n instance and public API behind a VPN, or strict network allowlist.

If the public REST API is not required, disable it. n8n provides separate controls for disabling the API and its Swagger-based playground:

N8N_PUBLIC_API_DISABLED=true
N8N_PUBLIC_API_SWAGGERUI_DISABLED=true

n8n explicitly recommends disabling the public API when it is not in use.

Disabling the API removes the initial-access surface used in the API-token attack paths, although it does not protect against compromised interactive user sessions or other exposed endpoints.

Use independent, randomly generated secrets

Generate the N8N_ENCRYPTION_KEY using a cryptographically secure random source. Do not use a company name, project name, password, or other human-memorable string.

Configure a separate random N8N_USER_MANAGEMENT_JWT_SECRET rather than allowing authentication-related signing material to depend on the encryption key.

The two values must be generated independently. Reusing the same value preserves the single-root-of-trust problem.

n8n's official self-hosted AI starter kit includes separate N8N_ENCRYPTION_KEY and N8N_USER_MANAGEMENT_JWT_SECRET configuration values.

Isolate code execution

Use external task runners so code from the Code node executes in a separate container rather than inside the core n8n process.

n8n recommends external runner mode for stronger separation between workflow code and the main application. The runner should use a dedicated, randomly generated authentication token and operate with restricted filesystem and network permissions.

In n8n 1.x, task runners must also be explicitly enabled. From n8n 2.0 onward, the separate enablement variable is deprecated, but external mode still requires a separate runners deployment.

Disable unnecessary high-risk nodes

Nodes that can execute commands, run code, connect over SSH, manipulate repositories, or read local files deserve particular scrutiny.

Use NODES_EXCLUDE to remove unnecessary nodes from the instance:

NODES_EXCLUDE='[
  "n8n-nodes-base.executeCommand",
  "n8n-nodes-base.ssh",
  "n8n-nodes-base.git",
  "n8n-nodes-base.code"
]'

n8n documents NODES_EXCLUDE as the supported mechanism for preventing users from accessing specified nodes. The official guidance for CVE-2026-25053 specifically recommends disabling the Git node when it is not required.

Removing the Git node closes the CVE-2026-25053 path described in this report. It does not replace patching, and it does not address other nodes that may provide equivalent host or network access.

Only exclude the Code node if workflows do not require it. Where it remains enabled, run it through external task runners and preserve the default-deny approach to imported modules.

Restrict modules available to code

n8n blocks external module imports in the Code node unless they are explicitly allowed.

Leave NODE_FUNCTION_ALLOW_EXTERNAL unset unless a workflow has a documented requirement for a specific dependency. Allow only the minimum required built-in modules through NODE_FUNCTION_ALLOW_BUILTIN.

In external runner mode, JavaScript and Python module allowlists belong in the task-runner configuration file rather than the main n8n container's environment.

Do not use * in production unless all workflow authors are fully trusted and the runner is isolated accordingly.

Monitor and self-audit

Run the authenticated POST /api/v1/audit endpoint on a schedule and send the results to a SIEM or another monitored destination.

The audit response can identify:

High-risk nodes
Nodes with filesystem access
Unprotected webhooks
Unused credentials
Community-installed nodes
Potential SQL injection exposure
Security configuration
The running version for CVE matching

Also collect logs outside the n8n instance. A malicious workflow may be deleted after it executes, reducing the evidence available in n8n itself.

Preserve reverse proxy, network, cloud, identity provider, source control, SaaS, and downstream API logs wherever possible.

Scope credentials and remove inline secrets

Create a dedicated API key, OAuth token, or service identity for each workflow or narrow group of workflows.

Grant only the permissions the automation requires. Do not connect n8n using organization-wide administrator credentials when a scoped service account would work.

Review GET /api/v1/credentials for unused or overprivileged credential objects, and examine workflow definitions for tokens, passwords, and keys hard-coded directly in node parameters.

GitGuardian's ggshield can scan exported n8n workflow JSON for exposed secrets before the files are stored, shared, or committed.

Use n8n's credential store rather than hard-coding values in workflows. The credential store does not eliminate risk if the instance itself is compromised, but it prevents secrets from appearing directly in workflow definitions and Git history.

A hardened n8n configuration baseline

The following example is a starting point, not a drop-in configuration for every deployment. Validate each variable against the exact n8n version and deployment model in use.

Generate each placeholder independently with a cryptographically secure command such as:

openssl rand -hex 64

Store the generated values in a secret manager rather than embedding the command itself in a static .env file.

# == Root secrets
N8N_ENCRYPTION_KEY=<independently-generated-random-value>
N8N_USER_MANAGEMENT_JWT_SECRET=<different-random-value>
# Protect the local settings file where supported
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true

# == Disable unnecessary external surfaces
N8N_PUBLIC_API_DISABLED=true
N8N_PUBLIC_API_SWAGGERUI_DISABLED=true
N8N_DIAGNOSTICS_ENABLED=false
N8N_MCP_MANAGED_BY_ENV=true
N8N_MCP_ACCESS_ENABLED=false

# == Restrict workflow code
N8N_BLOCK_ENV_ACCESS_IN_NODE=true
NODE_FUNCTION_ALLOW_BUILTIN=
NODE_FUNCTION_ALLOW_EXTERNAL=

# == Remove unnecessary high-risk nodes
NODES_EXCLUDE='["n8n-nodes-base.executeCommand","n8n-nodes-base.ssh","n8n-nodes-base.git","n8n-nodes-base.code"]'

# == Isolate task execution
N8N_RUNNERS_ENABLED=true
N8N_RUNNERS_MODE=external
N8N_RUNNERS_AUTH_TOKEN=<separate-random-runner-secret>

This baseline interrupts the demonstrated attack paths at several points: it removes unnecessary API access, blocks the vulnerable Git-node path, separates encryption and authentication secrets, and isolates workflow execution from the core n8n process. Validate each setting against the deployed n8n version before applying it.

The root of trust defines the blast radius

n8n's security model concentrates substantial authority in the N8N_ENCRYPTION_KEY.

The key protects stored credentials, contributes to authentication-related secrets in the implementation we analyzed, and can become the difference between limited access to an automation instance and offline access to the credentials in its database.

The attack paths documented here begin in different places.

An attacker might obtain an API token from a public commit, recover a weak encryption key from exposed artifacts, or exploit a vulnerable node to read sensitive files from the host. Those paths converge on the same targets: the encryption key, the credential database, and the integrations connected to the instance.

That makes hardening a matter of breaking the chain at multiple points.

Keep the API and administrative interface off the public internet. Generate independent, high-entropy secrets. Patch critical vulnerabilities quickly. Isolate workflow execution. Disable nodes that provide unnecessary host access. Audit workflows and credentials continuously. Limit every credential to the permissions its workflow actually requires.

Automation platforms inherit the reach of every system connected to them. Their security boundary must be designed accordingly.

Secure the credentials behind your AI agents

Agentic systems can act only through the credentials and machine identities they are given. GitGuardian helps security teams find exposed secrets, understand which systems they can reach, and drive remediation before one compromised credential becomes an attack path.

Explore GitGuardian for agentic AI security

Credential Harvesting Explained: How Attackers Collect Secrets From Developer Machines

Dwayne McDaniel — Thu, 03 Sep 2026 13:45:11 +0000

TL;DR: Credential harvesting is the large-scale collection of valid credentials that lets attackers log in as legitimate users. Developer machines are an especially rich source: unlike phishing, the credentials already sit in plaintext on disk, so no one needs to be tricked.

Case in point: credential abuse remains the single most pervasive technique across full breach chains. According to Verizon's 2026 Data Breach Investigations Report, credential abuse appears in 39% of breaches when investigators trace the full attack chain, not only the first step in the process.

Most articles on the topic describe phishing attacks, where a fake login page tricks someone into entering a password. However, there is a second vector that matters more for engineering organizations: Credentials on developer machines.

Said credentials include cloud keys in config files, tokens in shell history, SSH keys, and secrets cached by AI tools. Most of them sit in plain text, and are easy to steal. An attacker who gains access to one of these machines doesn't need to trick anyone. The credentials are there, waiting for them to harvest.

This article is for anyone who wants to learn how credential harvesting works, why developer machines are at risk, how to find the credentials before attackers, and how to catch the harvest as it happens.

What is credential harvesting?

Credential harvesting is the large-scale collection of login credentials, like usernames, passwords, API keys, authentication tokens, and session cookies. Attackers gather them to use or sell on the dark web.

It's important to understand that attackers rarely target a single account. Instead, they aim to collect as many valid user credentials across an organization as possible. Doing so gives them the best chance to log in as a legitimate user and avoid the controls that keep other intruders out.

To clarify, credential harvesting isn't one technique. It's the outcome of many techniques working together to access systems as legitimate users and steal sensitive data.

How it differs from stuffing

Two quick distinctions: credential stuffing is the downstream step of replaying already-stolen credentials against login forms to see which still work, whereas harvesting is what fills that bucket in the first place.

How does credential harvesting work: The two main vectors

Attackers harvest credentials in a variety of ways.

Examples include adversary-in-the-middle phishing kits that defeat basic multi-factor authentication, keyloggers, malicious browser extensions, and breach dumps traded on the dark web.

All credential harvesting schemes sort into two broad vectors:

Vector 1: Tricking the user

The technique that matters most here is the adversary-in-the-middle (AitM) kit. It proxies a real login in real time and captures the session cookie after authentication, so it sidesteps multi-factor authentication (MFA) rather than trying to defeat it head-on. That turns MFA from a hard stop into a control attackers routinely work around, which is why this vector deserves more attention than the classic fake-login-page playbook. Device code phishing works along similar lines: instead of proxying a login, the attacker tricks the user into approving a legitimate device-authorization request, which hands over a fully authenticated session — again without ever capturing the password itself.

It helps to separate how a victim is lured from how their credentials are actually captured. The distribution techniques — phishing emails, lookalike domains, and watering-hole sites — still rely on social engineering to get someone to a malicious site, and they remain common even though most organizations already blunt them. What varies is the exploitation technique used once the victim arrives. In classic phishing, a fake login page simply collects whatever is typed into it. AitM is an evolution of the same playbook rather than a break from it: the victim is still lured, usually by email, but the malicious site now proxies the real login to capture the session cookie after authentication. Because the delivery is unchanged, the same defenses apply — email security and awareness training, such as spotting suspicious senders and checking the real domain, work against AitM much as they do against classic phishing. What has genuinely shifted the balance is the endpoint, where credentials can be harvested with no user to trick at all.

Vector 2: Harvesting from the machine

Malware, most often an infostealer, reads credentials on a device, like cloud credential caches, .env and config files, shell history, SSH keys, browser tokens, and AI tool caches. This malware doesn't make any phishing attempts or otherwise try to trick employees. It's arguably the purest form of credential harvesting because the malware simply reads what's on the device and reports back to the attacker.

It's important to note that infostealers don't stop at usernames and passwords. They also grab session cookies and previously authenticated tokens, which enables attackers to skip the multi-factor authentication (MFA) step rather than trying to defeat it. For most attackers, this is a preferable approach to credential theft, and why it's gaining popularity. Security teams need to be aware and act. This is especially true for developer machines, where the density of valid credentials is highest.

Why developer machines are the richest harvest

A developer laptop accumulates valid, long-lived credentials across many predictable locations. Unfortunately, none of them live in repositories that standard code scanning can see.

Because of this, when attackers gain access to developer machines, they can often view cloud keys in ~/.aws and similar directories, tokens in .npmrc and shell history, SSH keys, and secrets cached by AI coding tools. This last category is especially vulnerable. GitGuardian's own endpoint research found that 40% of high and critical secrets on developer laptops surface in AI tool directories and log files, i.e., locations no traditional scanner looks at.

As you're likely aware, a single harvested cloud key or registry token can grant legitimately authorized access directly to production, with no further attack required. That's what makes the developer machine such an attractive target. It not only contains the most secrets, but also the most sensitive information.

Worse, the credentials on developer machines are often long-lived and rarely rotated. GitGuardian's 2026 State of Secrets Sprawl report found that 64% of secrets confirmed valid in 2022 were still valid in January 2026. In other words, a harvest from a developer machine is useful for years, not months.

3 Credential harvesting examples

To make the two vectors concrete, here are three credential harvesting examples.

Vector 1 example: A phishing kit serves a pixel-perfect login page for a SaaS app and collects every credential entered by unsuspecting users. It then relays an occasional session in real time to defeat MFA through an adversary-in-the-middle technique to gain access.
Vector 2 example: An infostealer lands on a developer laptop, reads the cloud credential cache and shell history, and exfiltrates valid keys to production, without a single click from the developer.
Escalation example: An attacker uses a single harvested registry or CI token to publish a malicious package. This is the pattern behind the Shai-Hulud npm worm, which compromised over 500 npm packages by stealing GitHub personal access tokens and cloud API keys. It then reused them to automatically publish trojanized versions of the developer's own packages.

Credential harvesting malware on the endpoint

On the machine, the harvesting tool is typically an infostealer, as mentioned earlier.

An infostealer is usually lightweight malware designed to read the exact files where developers store credentials, then exfiltrate them. This is what most people mean when they search for credential-harvesting malware or tools built for the endpoint rather than the inbox.

Put simply, once installed, the infostealer scans known credential locations, packages what it finds, and exfiltrates it. The output often ends up bundled and sold as stealer logs on dark web marketplaces, where other threat actors buy access to compromised accounts rather than harvesting data themselves. This isn't always the case, though. Attackers can also use the credentials themselves.

What controls miss on the endpoint harvest

Most organizations defend against credential-based attacks by preparing for phishing and other malicious behavior. Few of them inventory the harvestable credentials sitting on their devices.

Email security and awareness training: This defense aims to detect phishing emails and fake websites before people click links. They do nothing about the credentials already on disk.
EDR: This defense watches for malicious processes and suspicious activity. Generally speaking, it doesn't monitor the plaintext keys the infostealers read from a company's config file.
Repo and CI secret scanning: This defense inspects the organization's repository and pipeline, not the local filesystem where harvestable credentials dwell, unprotected.
Secrets managers: This defense protects secrets, but only those that flow through them. The copy your developer leaves in a local config file will never route through the vault.

Because the read is hard to catch, you should reduce what's available to harvest, discover what's already there, and plant tripwires that fire when attackers take credentials, to defend against malicious software.

How to prevent credential harvesting

To defend against credential harvesting, you must account for both vectors.

For credential harvesting phishing, standard controls apply. For the endpoint harvest, the goal is to first leave less to harvest. Then, find what's already there, and get alerts as soon as attackers take credentials.

Harden against phishing. Phishing-resistant MFA, like U2F or passkeys combined with a second authentication factor, along with email filtering and awareness training, reduces Vector 1, including adversary-in-the-middle kits.
Shrink the harvestable pool. Prioritize short-lived, scoped credentials over long-lived static keys cached on disk. Additionally, treat static keys as a tracked exception, not the default.
Discover what's on the endpoint. Inventory and scan the locations where credentials accumulate on the machine, so it's a first-class scan target instead of a blind spot.
Set honeytoken tripwires. Plant decoy credentials where harvesting tools are likely to look. A honeytoken fires the moment it's used, turning a silent harvest into an immediate alert.
Rotate on discovery. Treat detection and revocation as one motion, prioritized by severity and validity. Mandate a short, measured time-to-revoke for all critical systems.
Map findings to identity. Finally, connect each discovered credential to the identity it belongs to. That way, every harvestable credential has a clear owner.

If you take the above precautions, you'll detect harvest events, not only reduce what's available to take.

Auditing the endpoint credential plane

If you're serious about how to prevent credential harvesting on your organization's developer machines, you need more than a single scanning tool. You need three separate layers to work together.

Governance layer: Define who owns endpoint credential risk, how often the team assesses the fleet, what severity triggers a response, and how findings route to incident and ticketing workflows.
Structure layer: Organize findings by surface, then severity, then validity, so audits produce a prioritized, revocable list of credentials that attackers can harvest on a machine, right now.
Discovery layer: This is where GitGuardian's Developer Endpoint Protection, one of the products in the GitGuardian platform alongside Internal Secrets Monitoring, Public Secrets Monitoring, and NHI Governance, fits. It extends ggshield to regularly scan locations where credentials accumulate on machines. It's deployed via existing MDM tooling, using a purpose-built scope rather than catch-all telemetry, and scores each finding by machine, severity, and validity, and disseminates honeytokens that fire the moment an infostealer harvests a credential. As such, it catches the harvest event itself, not only the exposure that preceded it.

Is this spyware running on developer laptops? No, and that distinction matters for adoption. This is credential discovery, not surveillance: ggshield runs locally and sends back only a hash and metadata, never the secret value or the source files, and it focuses on the high-risk locations where credentials accumulate. Browser token stores, for example, remain the job of your EDR and identity controls. The agent already runs on more than 600,000 developer machines.

It is also not a separate console to babysit. Findings land in the same platform as your repository and CI secret scanning, so endpoint results deduplicate and prioritize alongside the alerts you already triage rather than starting a second queue.

What good looks like here is measurable, not vague: growing coverage of the machines and locations that actually hold live credentials, and a shorter, tracked time-to-revoke once a finding is confirmed. Honeytokens make the harvest itself measurable too. Because a honeytoken has no legitimate use, a single deployment is a high-confidence signal with almost no false positives, and that alert routes straight to whoever owns incident response, so a silent harvest becomes a paged event.

At the end of the day, our tool complements email security, EDR, secrets managers, and identity controls rather than replacing them. The goal is to find harvestable credentials and catch a harvest before an attacker can use what they collect.

The future of credential harvesting

There are a few trends you need to know about to protect your organization's systems. These trends include commoditized harvesting, AI tools, and sessions.

Commoditized harvesting. Cheap, disposable infostealers — increasingly generated on demand and tailored to a specific victim — put a capable credential harvester within reach of less sophisticated threat actors, without the shared infrastructure that characterizes ransomware-as-a-service operations.
A bigger harvest, driven by AI tools. AI coding tools increase credentials in local places. Our research at GitGuardian found AI-assisted commits leak secrets at roughly 3.2%, more than double the 1.5% baseline. We also identified 24,008 unique secrets in public MCP configuration files, over 2,000 of which are still valid (per GitGuardian's State of Secrets Sprawl research). Supply chain campaigns already exploit this. By analyzing machines hit by the Shai-Hulud 2 attack, we found 294,842 secret occurrences across 6,943 systems.
The balance shifts toward sessions. As MFA makes credential phishing harder, infostealers adapt to harvest session cookies and tokens that are already authenticated, sidestepping MFA rather than attempting to defeat it head-on. Just as important, much of what gets harvested on developer machines is machine identity — API keys, service tokens, and CI credentials — that never sits behind MFA in the first place, because machine-to-machine authentication is rarely designed for it. As a result, the endpoint vector continues to rise.

Summary: Harvesting is collection, so reduce what there is to collect

Credential harvesting is the bulk collection of valid credentials, and it remains one of the most consistent threats to both sensitive systems and critical systems. While phishing is common, developer machines offer a richer harvest, because cloud keys, tokens, and SSH keys sit in plaintext for infostealers to read.

Defending against credential harvesting requires organizations to harden against phishing and, equally as important, leave less to harvest on the endpoint, discover what's already there before an attacker does, and plant honeytokens that fire the moment an attacker takes a credential. All of these strategies work best as a complement to the controls your security team already runs, not as a replacement for them.

FAQs about credential harvesting attacks

What is credential harvesting?

Credential harvesting is the large-scale collection of valid credentials, such as usernames, passwords, API keys, and tokens, for use or resale by an attacker. The aim is volume, as the attacker tries to steal as many working credentials as possible across an organization, rather than one specific account.

How does credential harvesting work?

Common credential harvesting strategies work through two main vectors. The first tricks a person into entering credentials on a fake login page. The second deploys malware, usually an infostealer, to read credentials that already sit in plaintext on a device. The second vector requires zero deception.

What is the difference between credential harvesting and credential stuffing?

Credential harvesting collects the credentials. Credential stuffing replays already-stolen credentials against login forms to find ones that still work. Harvesting fills the bucket, while stuffing pours it out.

Is credential harvesting the same as phishing?

No. Phishing is one vector used to harvest credentials by tricking a person. Harvesting is the goal, and phishing is just one way to reach it. On developer machines, the credentials already sit on disk, so an attacker who can run code there, whether the malware arrived via phishing, a drive-by download, or a compromised dependency, can harvest them without tricking anyone into typing a password.

What are examples of credential harvesting?

A phishing kit serving a fake SaaS login page or an infostealer reading cloud keys and shell history from a developer laptop. Both attempt to exfiltrate sensitive information from legitimate organizations.

What is credential harvesting malware?

Credential harvesting malware is malware built to collect credentials from a device. Most malware of this type are infostealers. The malware reads files where developers store credentials, like cloud caches, config files, and browser storage, then exfiltrates them, either to package for sale as stealer logs or for personal use.

How do you prevent credential harvesting?

Defend both vectors. First, use phishing-resistant MFA and email filtering to guard against phishing. Then, for endpoints, reduce long-lived credentials, discover secrets already on the machine, plant honeytokens that fire when an attacker takes a credential, and revoke what shouldn't be there.

How do you detect credential harvesting on an endpoint?

Detecting the file read itself is hard, which is why GitGuardian pairs endpoint discovery with honeytokens. Doing so places decoy credentials in the exact locations that harvesting tools look for them. As such, the system catches the harvest event the moment an attacker uses one of those decoy credentials, even if the original read went unnoticed.

What Was on This Machine? Answering the Blast Radius Question After a Laptop Compromise

Dwayne McDaniel — Wed, 02 Sep 2026 13:11:48 +0000

TL;DR: The containment clock starts immediately after a developer's laptop is compromised, an infostealer fires an alert, a device goes missing, or a dependency turns malicious.

While important, EDR and incident response only tell you what happened on the machine, like which processes ran, what the attacker touched, and what was exfiltrated. They can't tell you what was exposed, such as valid credentials that an attacker can now use.

This is the blast radius question, and most teams can't answer it fast enough. Nothing inventoried the credentials on the machine before the incident, so responders either rotate everything, which burns engineering time, or rotate too little, which exposes live credentials. The scale is real: GitGuardian's State of Secrets Sprawl 2026 counted 28.6 million new secrets leaked on public GitHub in 2025, up 34% year over year.

This article covers why this question is hard to answer, what a real answer requires, and how a per-machine credential inventory turns "we're not sure" into a prioritized, actionable list. It also covers the other half: how ongoing remediation and prevention shrink the blast radius before the next incident hits.

The moment the question gets asked

What happens when an infostealer alert fires or one of your company's laptops is reported stolen? How about when a developer believes their machine is compromised? In all likelihood, your incident response protocols isolate the host. Then, leadership asks the question that decides your next move: What was the attacker able to compromise, and what do we need to act on?

From that moment, every valid credential on the device is a live risk until someone rotates it. According to Verizon's DBIR, valid credentials factor into roughly 82% of intrusions. As such, the speed and precision at which you answer the two questions above (what was on the machine and what do we need to rotate) determine the severity of the incident.

This is when your endpoint incident response program runs like a well-oiled machine or turns into a mad scramble. The difference rarely depends on the skill of your security team. Rather, it comes down to whether you recorded the machine's credentials before the incident.

There's a second value that only shows up once you actually have the inventory: it surfaces credentials that shouldn't be on developer machines in the first place. Not compromised credentials, just misplaced ones. A production API key on a developer laptop that should live in the vault. An admin token in a .env file that should have been rotated out. These aren't incidents in the traditional sense, but every one of them shrinks the blast radius of the compromise that will eventually happen.

Why "what was on this machine?" is so hard to answer

To determine which credentials were on a compromised laptop, a security lead has to reconstruct the data by hand, under immense time pressure, based on the limited information forensics can surface and whatever the developer remembers. This process is slow for multiple reasons:

No pre-incident inventory: Few organizations maintain a credentials inventory. So, there's no baseline to check machines against, and every investigation starts at zero.
Credentials scatter across locations: Credentials accumulate in .env files, shell history, CLI caches, cloud profile folders, SSH keys, and AI tool caches. Worse, developers who use AI coding tools leak credentials roughly twice as fast as those who don't. The credential density is measurable: in one 2025 supply chain campaign (Shai-Hulud 2.0), attackers found a median of more than 10 valid credentials per compromised developer machine. Reconstructing that list by hand (and under pressure) is both slow and error-prone.
Behavioral tools don't list secrets: EDR and forensics show which processes ran and what behavior occurred, not a definitive list of the secrets that were on the machine.
Human memory is unreliable: Developers rarely remember what they stored locally on their devices. Furthermore, memory isn't an audit trail. Asking someone to reconstruct a credential inventory from recall is a surefire way to impede your investigation.

Because it's so hard to determine what was on a compromised machine at the time of attack, security leaders must make a difficult choice between over- and under-rotation.

Over-rotation costs days of engineering time and causes outages when teams rotate credentials that other systems depend on. Under-rotation leaves a valid credential in the attacker's hands.

Both problems trace back to the same root cause: Nobody knew what was actually there.

What EDR and security tooling tell you (and what they don't)

EDR, forensics, and DFIR tools are valuable. They reconstruct which processes the attacker ran, what they accessed, and what data the attack captured. For understanding the mechanics of an incident, this tooling is essential, and no credential inventory can replace it.

What these tools don't do, however, is produce a definitive list of valid credentials that were on the machine and are now exposed. Unfortunately, this is the information that drives rotation. After all, credential exposure after breach isn't a behavioral question. It's an inventory question, and inventory requires different instrumentation than behavioral detection.

The two views work together. EDR and forensics answer "what happened?" A credential inventory answers "what was exposed?" Combined, they provide a full scope of the incident, so you learn what the attacker did on the compromised device and the secrets they had access to.

How do you answer the blast radius question after an incident?

To answer the blast-radius question quickly, you need the right record in place before an attack occurs. In other words, you need these six elements for a speedy recovery:

A pre-incident inventory: This is the foundation of everything else. It also anchors the secondary scope: a harvested AWS key may have been used to query a Secrets Manager; a stolen GitHub token may have accessed private repositories. The blast radius can grow beyond the compromised machine, and tracing that expansion starts with knowing what credentials were on it.
Access scope & severity: A ranking of which credentials carry the highest access privileges, like admin keys, production tokens, broad OAuth grants. These are the candidates for immediate rotation, so they should be triaged first.
Validity status: The knowledge of which credentials on a specific machine are still valid. These details allow teams to prioritize specific, strategic rotations.
File locations: The knowledge of where each credential lives. These details make every finding verifiable and give developers a clear cleanup path to pursue.
History over time: A scan history that shows what's on the device now and what was there at the moment of compromise, so your security team can compare the two.
Ownership mapping: A document that maps every credential to its identity and owner. This element allows rotation to reach the right system and the right team when needed. The security team cannot rotate all secrets alone, so identify the tool owner or service admin for each finding and loop them in. Without ownership, rotation stalls.

Together, these six elements turn a days-long investigation into a quick lookup that tells you what to rotate immediately and what to promote to the incident workflow.

What good looks like: From "not sure" to a revocable list

A mature program treats the blast radius answer as something to retrieve rather than something to investigate. Here's what that level of maturity looks like in practice:

Inventory before the incident: Regularly scan for credentials at rest, well before an incident happens. Good looks like every machine assessed on a consistent schedule.
Keep it per machine: Log per-machine records, not only a fleet-wide total. Good looks like the ability to pull up a single machine and see exactly what's on it.
Track validity and location: Record validity status and file path for every finding. Good looks like a list that immediately separates high-privilege and confirmed-leaked credentials from lower-severity findings.
Remediate before the incident: A per-machine inventory is most powerful when it drives action, not just records. Good looks like a shrinking credential footprint over time: old cached keys redacted from disk, AI hooks stopping new agent-generated secrets from landing, and developer-initiated cleanup from the dashboard. Detection without remediation is just noise, and the inventory closes the loop only when it leads to a fix.
Keep history: Retain scan history, so you can answer for every moment of compromise. Good looks like a weeks-long timeline rather than a single current view.
Map to identity: Ensure every credential traces back to its owner and the system it authorizes. This full identity-and-owner mapping is the job of NHI Governance. When a credential found on an endpoint maps to an NHI, that identity gets an owner and routes to the right team automatically. Good looks like rotation that reaches the right place without guesswork.
Categorize what you find:
- Privileged secrets → remove from the machine
- Useless secrets → redact
- Useful secrets that should be safely stored → relocate to a vault
- Secrets that need to stay in plaintext → accept the risk, mitigate around it (this is where honeytokens come in)
Wire it into the runbook: Make blast radius scoping an explicit step in the security runbook. Good looks like responders who know exactly where to pull a machine's credential record in the event of an attack to better understand and minimize the damage.
Add honeytokens: For the category of credentials that must stay in plaintext on the machine, plant a honeytoken alongside them in the same directory or config file. An attacker harvesting the machine takes both. The honeytoken fires the moment it's used, confirming the compromise so you can revoke the real credentials you already knew were exposed.

How GitGuardian answers "What was on this machine?"

The machine's record is the blast radius answer.

GitGuardian Developer Endpoint Protection is one of the capabilities inside the GitGuardian platform, alongside Internal Secrets Monitoring, Public Secrets Monitoring, and NHI Governance. Developer Endpoint Protection regularly scans the locations where credentials accumulate on each developer machine, deployed through your existing MDM.

As important, the Endpoints view in the GitGuardian dashboard keeps a per-machine record that includes scan status and history, plus every discovered secret grouped by severity and validity, along with its file location. Findings are deduplicated across machines — you get a prioritized list of unique secrets, not a list of duplicated findings that inflates the noise. After a compromise, this record answers the question, "What was on this machine?" with a prioritized, revocable list scored by machine, severity, and validity.

This assumes Developer Endpoint Protection is already running across your fleet before the incident, and that's the point. The teams that have the answer ready built the inventory in advance.

Beyond discovery, Developer Endpoint Protection enables local redaction of discovered secrets from the developer's machine and deploys AI hooks inside Cursor, Claude Code, and Copilot to intercept secrets before they reach disk. The goal is not just a better answer to the blast radius question; it is a smaller blast radius next time.

Developer Endpoint Protection also helps plant honeytokens tied to specific machines. That way, the moment an attacker uses a harvested credential, they trip a high-fidelity alert.

Under the hood, ggshield runs locally on the endpoint and sends only a hash and metadata back to GitGuardian, never the secret value or your source files. This secure design keeps the tool complementary to EDR, DFIR, and whatever IR processes you already run.

Answer the question before it's asked

The blast radius question is hard if you only ask it after an incident. In this scenario, EDR and forensics will still tell you what the attacker did on your machine. However, these methods can't pinpoint the valid credentials that were exposed. Unfortunately, this is the exact information you need to protect your organization and minimize damage.

A per-machine credential inventory, built before the compromise and kept current with validity, location, and history details, turns the question, "What was on this machine?" from a days-long investigation into a precise, revocable list. To be clear, it doesn't replace the incident response process your team already runs. Rather, it fills in the one input the process always misses. The teams that also remediate, clearing the backlog and preventing new credentials from landing, start the next incident with fewer secrets to scope.

These are two faces of the same capability: one tells you what the attacker was able to reach; the other limits how much they can reach next time.

FAQs

What is the blast radius question after a compromise?

It's the question of what an attacker can now access. In other words, which valid credentials sit on the compromised machine and need rotation? Scoping the blast radius turns "the laptop was compromised" into a precise list of exposed credentials and the systems each one can reach.

How do you find what credentials were on a compromised laptop?

The only reliable way is to consult records from before the attack. A per-machine credential inventory that scans the locations where credentials accumulate, while tracking validity and file location, gives you that record. Reconstructing it by hand is a slow and error-prone process.

What should you rotate after a developer laptop is compromised?

Every valid credential on the machine, prioritized by severity and by what it can access. Without a per-machine inventory, teams either rotate everything, which is slow and disruptive, or miss credentials, which is dangerous because it gives the attacker a live path to company secrets.

How do you scope blast radius after a laptop compromise?

Pull the machine's credential record to learn what credentials were at rest on it, their validity, and their locations. Combine these details with EDR and forensic data to learn what the attacker did. Then, rotate the exposed, still-valid credentials in priority order to minimize damage.

Should you rotate everything after a laptop compromise?

Only if you have limited information to work with. Blanket rotation is safe but costly and disruptive to the teams that depend on those credentials. With a per-machine inventory, you only need to rotate what was exposed and still valid. This process is faster and less disruptive.

How do you determine credential exposure after an endpoint compromise?

If possible, start with the machine's pre-incident credential record. This record, paired with the EDR and forensic timeline, tells you which credentials were live on the device and need rotation.

How does GitGuardian help answer what was on a machine?

GitGuardian Developer Endpoint Protection maintains a per-machine record of the credentials discovered on each device, including severity, validity, file locations, and scan history. After a compromise, that record is the blast radius answer: A prioritized, revocable list that complements your existing EDR and IR processes rather than replacing them.

An AI Agent Breached Hugging Face. The Attack Playbook Was Older Than the Attacker

Dwayne McDaniel — Tue, 01 Sep 2026 15:45:05 +0000

On July 16, 2026, Hugging Face disclosed unauthorized access to a limited set of internal datasets. Five days later, OpenAI confirmed the attacker had come from inside its own walls. A combination of OpenAI models, including GPT-5.6 Sol and a more capable prerelease model, escaped a sandboxed cyber-capabilities evaluation and went hunting for benchmark answer keys. Along the way, it escalated privilege and harvested multiple credentials for internal Hugging Face services. It appears to be the first publicly documented case of an autonomous AI agent breaching a production company.

Strip the attacker's identity out of the incident report, though, and the remaining pages could have come from any breach retrospective of the past decade. Credentials were taken from a compromised system and reused to move laterally into production. The headlines belong to the agent. The exposure that made the attack work belongs to almost everyone.

The incident splits cleanly into two phases, and keeping them separate helps us draw the right lessons.

The first phase took place inside OpenAI's infrastructure. During an internal evaluation of cyber capabilities, with production guardrails intentionally relaxed, the models exploited a zero-day in a package registry cache proxy that isolated their sandbox. That gave them a path to the open internet. Their motive was ordinary to the point of comedy. They were being scored against a security benchmark called ExploitGym, and they reasoned that the test solutions might live on Hugging Face.

Hugging Face's turn came in the second phase. The sandbox escape got the agent to the internet. Entry into Hugging Face occurred through two injection vectors in the company's production dataset-processing pipeline. The first abused HDF5 external raw storage to read local files from a processing worker, exposing its environment, including secrets and credentials, as well as its source code. The second used a template-injection flaw in a dataset configuration to execute arbitrary Python inside the worker. From there, the agent escalated privileges and moved laterally into several internal clusters over a weekend. In one sequence that OpenAI later documented, the model paired credentials it had already stolen with zero-day exploits to gain remote code execution on Hugging Face servers, then read test data from a production database. The campaign left an action log of more than 17,000 recorded events.

The confirmed impact was narrower than the initial disclosure indicated. The only customer content accessed was a set of ExploitGym/CyberGym challenge solutions stored in five datasets. No other customer-facing models, datasets, Spaces, or packages were affected, and the only customer records read were operational metadata tied to searches against the dataset server. The intrusion did expose internal service credentials and reach Hugging Face's internal infrastructure. The company has since addressed both injection vectors, rebuilt the compromised nodes, revoked and rotated the affected credentials, and begun a broader precautionary rotation of secrets.

The first real test for agentic AI security

An attacker with no keyboard changes the risk. The campaign ran at machine speed across a swarm of short-lived sandboxes, and its activity included decoys that investigators later had to separate from genuine impact. The forensic burden was so heavy that Hugging Face turned to their own agent, leveraging the open-weight GLM 5.2 model, to analyze the attacker's full action log just to reconstruct the timeline. Agentic AI security has been a discipline built on forecasts. Since July 16, it has a production incident to study, and defenders have spent the days since disclosure doing exactly that.

The incident deserves to be sized honestly, though. Publicly confirmed cases of this class can currently be counted on one hand. Novelty is not the same thing as probability, and a risk register that treats them as interchangeable will misallocate budget.

Standing credentials and lateral movement did the real damage

Look at what the agent actually did once it reached the internet. It exploited a code execution flaw to land on a worker. Then it stole the credentials that worker legitimately held.

The credentials it harvested were reusable and granted enough privilege to access internal production systems. The disclosures don't say how long those credentials had lived or what scope Hugging Face intended for them. They don't need to. The lesson sits in the category itself: any credential that persists and travels is a credential someone else can present, and nothing about it knows or cares who is doing the presenting.

OpenAI's July 28 update makes the credential lesson even clearer. The agent found publicly exposed credentials for four accounts across four public services. It used one as an outbound relay and staging path and another for data storage; the remaining two were accessed read-only. For the two accounts used in the campaign, the exposed login was enough to turn a legitimate account into infrastructure the agent could use to keep the attack moving.

Persistence is the norm. GitGuardian's State of Secrets Sprawl 2026 found that 60.4% of identities held long-lived secrets. The report also found that a full 64% of valid secrets first found in 2022 were still active when retested in January 2026. A credential created four years ago and never rotated still opens the same doors today. An attacker who finds it inherits every one of those doors, whether that attacker is a ransomware crew or a benchmark-obsessed language model.

Standing credentials also buy attackers time. Per IBM's 2025 Cost of a Data Breach report, breaches that begin with stolen or compromised credentials take up to 186 days just to identify, because a valid credential in use looks like business as usual. Hugging Face's own anomaly detection surfaced this campaign within days. Most environments should not count on that.

How to explain AI agent security to your board

This new class of autonomous attacker relied on one of security's oldest weaknesses: reusable credentials. That is the sentence to build the board conversation around. The incident introduced a new threat model, but the conditions that gave the agent access to production were already familiar. It helps to separate the risk into two categories.

The emerging risk

Autonomous agents can now operate as attackers, exploit vulnerabilities, move across systems, and generate activity at machine speed. Security teams should monitor how this threat evolves and test whether their detection and response processes can keep pace with campaigns that unfold faster and produce far more activity than a human-led intrusion.

The current risk

The agent still needed credentials it could steal and reuse. Standing access on service accounts and pipelines, secrets exposed in code and configuration, production systems reachable from untrusted processing environments, and weak internal segmentation all increased the impact of the initial compromise.

These are established security problems, even if many organizations have not addressed them consistently. They can be reduced through better credential discovery, shorter-lived access, tighter scope, stronger segmentation, and faster revocation.

That framing gives security leaders a practical answer after a headline incident. The attacker was new. The weaknesses it exploited were not, and organizations can start closing them now.

Five controls, starting with zero standing privileges

Stop issuing long-lived credentials with standing privileges to automation that can reach production. Short-lived credentials, scoped to a single task and dead at its end, apply to AI agents as much as to the service accounts and pipelines that predate them. The end state has a name: zero standing privileges. No credential outlives the work it was issued for, so anything stolen mid-attack has a much smaller reuse window and cannot hand an attacker durable access. This control also asks nothing of the unsolved questions around agent autonomy. It works the same whether the thief is a person or a model.
Get visibility into the credentials your machines and agents already hold. The previous control is impossible for secrets you can't see. Non-human identities now outnumber human employees 109 to 1, and every machine identity authenticates with credentials that live somewhere, whether in code, in configuration, on a worker, or in a pipeline. Finding them is the first step towards replacing them.
Treat data and model pipelines as a first-class attack surface. Hugging Face's own postmortem makes this point. Dataset loaders, template configurations, processing workers, and anything else that executes code derived from untrusted input belong in the same threat model as production APIs.
Segment so that one worker's credentials cannot reach production clusters. What determined the depth of this breach was how far the stolen credentials could travel once harvested.
Detect credential abuse as a trajectory. Installing a package looks benign, and so does querying a credential store or reaching out to an external server. When chained in sequence, those same actions constitute a breach. Monitoring that only evaluates each action in isolation would have watched this attack happen and never raised an alarm.

Every AI agent you deploy runs on secrets

The same lesson runs in the defensive direction. Every AI agent wired into the enterprise is another identity carrying credentials your security team has to find, and an agent holding a standing, broadly scoped token is this incident's setup waiting for a different trigger.

Attackers holding your credentials do not need to break in; they can log in. GitGuardian finds secrets across the entire surface where they live: the developer machine where they are created, the repositories, pipelines, and collaboration tools inside your perimeter, the public code where they escape, and the vaults meant to hold them. It confirms which ones are real and still live, then attaches the identity context behind each one, from owner to blast radius. A four-year-old credential that still works stops being invisible, and the standing-access problem your secrets management program has been circling becomes a queue your team can actually manage.

Find exposed credentials everywhere they spread

How to Reduce Time to Revoke for Exposed Credentials

Dwayne McDaniel — Mon, 31 Aug 2026 12:41:22 +0000

This is the second article in a series on time to revoke, following our piece on The Hacker News. The first explains how to measure the amount of time an exposed credential remains usable. This article focuses on the operational changes security teams can make to shrink that exposure window.

TL;DR: Reducing time to revoke means addressing the operational blockers that keep exposed credentials valid after detection. Security teams need to validate which credentials still work, route them to the right owners, make revocation safer, and remove avoidable manual delays. Provider-specific runbooks, risk-based remediation paths, short-lived credentials, automation, and closure verification can all reduce the amount of time exposed access remains usable.

Why time to revoke matters for AI-era non-human identity risk

Every security team can find an exposed secret, but most can't tell you how long it kept working after they found it.

Over 28.6 million new hardcoded secrets hit public GitHub in 2025, up 34% year over year, with AI-service secrets up 81% (State of Secrets Sprawl 2026). AI-assisted development and agentic tooling cut both ways. Defenders find and triage more, but creation is outpacing governance. So while detection keeps up, revocation is where teams fall behind. And that disconnect is what this article is about.

If an exposed credential remains valid, an attacker doesn't need to breach the same system twice. They can use it directly against any service that trusts the identity behind it, like a cloud console or a production database. And these credentials stay valid far longer than teams expect: 64% of secrets confirmed valid in 2022 were still valid when we retested them four years later.

That is especially dangerous for non-human identities (NHIs). Service accounts and OAuth apps often run on long-lived tokens and deploy keys that no one rotates for months, sometimes years. Their access is broad, their ownership unclear. And because these identities keep critical systems running, teams hesitate to revoke them without knowing what will break. This is where NHI security and time to revoke intersect most directly.

The result is a recurring pattern: detection happens, but revocation stalls. Time to revoke turns that stall into a measurable risk window.

Why exposed secrets stay valid after detection

Secrets remediation often breaks down for operational reasons. The most common blockers are unclear ownership, fear of breaking something, provider-by-provider friction, and treating removal as the finish line.

No clear owner for the exposed credential

Many exposed secrets belong to non-human identities. They may have been created years ago by a team that no longer owns the system, or wired into an automation workflow that no one will touch without proof. If no one knows who owns a credential, no one can confidently revoke it.

Fear of breaking production systems

A valid credential may be tied to a deployment pipeline, data sync, monitoring tool, internal service, or customer-facing application. Revoking it blindly could break something important. Security teams therefore need more than a detection alert. They need to know what the credential can reach, and what breaks if it stops working.

Manual provider-specific revocation workflows

Credential remediation is often provider-specific. The steps to rotate an AWS access key look nothing like the steps to revoke a Slack webhook. Some providers make it straightforward. Others require manual investigation or sign-off from another team. Every manual step adds delay.

Removal-only secrets remediation

Many workflows still treat removal as the end state. The secret was deleted from a repository, the pull request was merged, the Jira ticket was closed. But removal only reduces future exposure from that location. It does not invalidate the credential. If the secret was copied, scraped, logged, cached, indexed, or exposed elsewhere, it may still be usable.

This breaks down completely for public leaks. When a credential is exposed on public GitHub, often in a developer's personal repository outside any perimeter you control, you usually cannot delete it, and it has likely already been cloned and indexed by others. There is no file to clean. Revocation is the only action that ends the exposure.

No verification that the secret was invalidated

Without validity checks, teams may not know whether a secret is still live or already dead. That uncertainty creates two problems: teams may waste time on dead secrets, and they may close incidents before live credentials are actually invalidated. Time to revoke depends on verification. Without it, the metric becomes another proxy instead of a measure of actual risk reduction.

How to reduce time to revoke

Reducing time to revoke means taking on those blockers directly. What follows tracks the path a leaked credential takes: prove it still works, get it to someone who can act, make the act of revoking safer, and cut the manual delays in between.

Validate exposed secrets quickly

Validity should drive priority. A valid production credential deserves a different response than an expired test key. Where safe and supported, automated validity checks help teams focus on secrets that still grant access. They also help confirm when a credential has been successfully revoked, which is essential for measuring time to revoke accurately.

Map exposed credentials to owners

Ownership is the bridge between detection and action. Security teams should connect exposed secrets to the systems and identities behind them wherever possible. The faster the right owner is identified, the faster the organization can revoke safely.

For NHIs, this is especially important. Machine identities often outlive the teams and pipelines that created them. Without machine identity ownership mapping, they become difficult to govern and even harder to revoke.

Discovering NHIs wherever they run and attributing each to an owner gets exposed credentials to the people who can act on them. Scoring them by risk decides who acts first.

Build provider-specific revocation runbooks

Revocation steps vary by provider. A mature program should not require responders to rediscover the process every time a secret leaks. Provider-specific runbooks should document how to identify the credential and what it touches, then rotate or revoke it and confirm the old one is dead. They should also name the approvers and which team(s) to notify.

Runbooks reduce hesitation, especially when a credential may affect production.

Separate emergency revocation from planned rotation

Not every exposed secret should follow the same path. Some credentials need immediate revocation. Others require coordinated credential rotation to avoid downtime.

Security teams should define risk-based pathways before an incident occurs:

Immediate revocation for exposed credentials with known abuse, public leakage, or critical privilege
Coordinated rotation for production-connected credentials with dependencies
Standard cleanup for invalid, expired, or non-sensitive test credentials
Governance review for recurring exposures from the same system or team

This keeps urgent incidents from getting stuck in general remediation queues.

Reduce reliance on long-lived credentials

The shorter a credential's lifetime, the smaller the window in which exposure can become abuse. Organizations should move away from static, long-lived secrets where possible. Short-lived credentials, just-in-time access, managed secret stores, and automatic rotation all cut the time a leaked credential stays useful.

This does not eliminate the need for detection. But it changes the blast radius. If a credential expires quickly, the exposure window shrinks even before a human responder acts.

Automate secret revocation where it is safe

Automation should be applied carefully, but it has a clear role in reducing time to revoke. For high-confidence findings on known providers, revocation can be automated or semi-automated through the provider's own controls, closing the attack window far faster than manual workflows. In other cases, automation can prepare the response by surfacing the owner and the remediation steps a responder will need.

Used this way, automation removes the delay from decisions that have already been made, and the judgment stays with the team.

Verify secrets remediation closure

Every secrets remediation workflow should end by confirming that the exposed credential no longer works. A cleaned file or a closed ticket is not proof on its own. Verification proves the old credential has actually been invalidated, and turns remediation from a reported activity into a measurable security outcome.

A maturity model for time to revoke

Organizations do not need to reach full automation immediately. Time to revoke can mature in stages.

The model applies across every surface where credentials leak: internal repositories, CI/CD, collaboration tools like Slack and Jira, cloud configurations, and public GitHub. Source code is only one of them. Maturity is as much about widening coverage as it is about speeding up revocation.

Level 1: Secrets detection only

The organization can find exposed secrets, usually in source code or public repositories, but coverage is uneven everywhere else. Remediation is manual and inconsistent. Ticket closure may be treated as success.

Level 2: Secrets detection and validation

The organization can distinguish valid secrets from invalid or expired ones. Prioritization improves because teams know which findings still represent active access.

Level 3: Secrets validation and ownership mapping

At this stage, ownership reaches past the repository to the identity behind the credential. The organization can tell which machine identity a secret belongs to and who owns that identity. It also knows what the identity can access. Remediation moves faster because alerts reach the people who can act, and because teams understand the blast radius before they revoke.

Level 4: Runbook-driven secret revocation

The organization has provider-specific workflows for rotating or revoking common credential types. Teams know when to revoke on the spot and when to rotate carefully, and how to verify closure.

Level 5: Automated secret revocation and verification

For supported providers and high-confidence incidents, the organization can move from detection into guided or automated remediation without leaving the incident workflow. That remediation validates the credential and identifies its owner, then initiates revocation through the provider's own controls. Closure is verified, and time to revoke becomes a reliable executive metric.

Exposed secrets incidents are not over until credentials stop working

Exposed secrets need the same measurement discipline security teams already apply to detection, investigation, containment, and remediation. But credential exposure needs a metric built for the way secrets create risk. What makes a secret dangerous is that it still works, and time to revoke is the one metric that tracks that directly, giving CISOs a way to measure the exposure window and pull it shorter.

No matter how clean the repo or how fast the ticket closed, the incident stays open until the credential is dead.

Reduce the time exposed credentials remain valid

The leak is just the start. GitGuardian is built for what comes after. It detects exposed credentials across code, CI/CD, collaboration tools, and public GitHub, checks which ones still work, and attributes each valid secret to the machine identity behind it and the owner who can kill it. Risk scoring puts the most dangerous exposures in front of the right person first, so revocation starts sooner. That path, from a leaked credential to a dead one, is what shrinks time to revoke.

See how GitGuardian helps security teams find exposed credentials, prioritize what matters, and revoke faster.

Why SAST and DAST Aren't Enough for Secrets Security

Dwayne McDaniel — Fri, 28 Aug 2026 13:02:27 +0000

If you run an application security program in 2026, secrets detection can look like a solved line item. Your static analysis suite ships rules for hardcoded credentials. Your code platform's built-in scanner flags API keys on push. So when someone asks if SAST and DAST are enough for secrets security, the reasonable response is: yes.

That answer holds only if a leaked credential behaves like any other finding. Spoiler alert: it doesn't.

Static application security testing (SAST) and dynamic application security testing (DAST) find vulnerabilities an attacker could exploit: an injection path, say, or a broken access control. A vulnerability finding identifies a condition an attacker may be able to exploit. A valid leaked secret requires no exploit. It is an authentication mechanism that already works, and it can spread far beyond the code those tools scan.

Nobody has to find a flaw or write an exploit; they copy the key and log in. Last year, credential abuse showed up in 39% of breaches, not just as the way in, but as the means to move laterally and reach the target once inside. Potential risk and active access are different problems, and tools built for the first were never meant to carry the second.

What static application security testing (SAST) and DAST do well

SAST analyzes application internals without executing the application, often through IDE, pull-request, and CI scanning, catching injection flaws and unsafe patterns while they are still cheap to fix. DAST tools probe the running application from the outside, surfacing runtime and configuration problems no static scan can see. Together, they take on much of the OWASP Top 10, and nothing in this article argues for removing either.

They also complement each other by design; most of the SAST vs. DAST question comes down to vantage and timing. SAST is white box testing. It reads the program's internals and can sit directly in the IDE, which keeps the feedback loop short. DAST is black box testing. It attacks from the outside the way a pentester would, agnostic to the stack underneath. One catches what the other can't.

A hardcoded secret does not behave like a conventional code vulnerability and can leave the application's behavior completely unchanged. Even when a SAST tool detects the string, the code can compile, the tests can pass, and the build can go green while a live production key moves through places it was never meant to reach.

A vulnerability is a prediction. A valid secret is access

Vulnerability prioritization commonly combines technical severity, exploitability, exposure, and threat intelligence. A valid credential changes that calculation because authentication may already be possible without developing an exploit.

Take a SQL injection finding. Serious, worth fixing fast, and still conditional: an attacker has to find the endpoint and turn the flaw into a working attack. A live cloud key in a config file skips every step of that.

Not every leaked secret is still valid, though. Static detection alone cannot establish whether a credential remains valid. That requires provider-aware validation or other contextual evidence. More on that below.

Secrets are a credential problem that lives in code

Application security tools manage code risk. A leaked secret is an exposed credential, which makes it an access problem from the moment it leaves the developer's editor. The two disciplines sit side by side the way a web application firewall and an identity program sit side by side. Neither substitutes for the other.

So when a security team says their SAST suite already scans for secrets, the right response is agreement. It probably does. Pattern-matching a connection string is within reach of many static analyzers, and scanning git history has become table stakes for the secrets scanners built for the job.

Detection was never where this argument got decided, and without remediation, it's just more noise.

The code-risk playbook assumes the finding and the fix both live in the codebase, and that the developer who introduced the issue owns the resolution. Both assumptions fail for credentials.

Secrets don't stay in repositories

Secrets sprawl across every surface developers touch, and most of those surfaces sit outside anything a SAST or DAST scan will ever read. The tooling's scope ends at the application. The sprawl doesn't.

The public numbers are only the visible edge. In 2025, we detected 28.6 million new secrets on public GitHub, up 34% year over year, and internal repositories are six times more likely than public ones to contain hardcoded secrets.

Inside a repository, platform scanning holds up. A pushed API key, connection string, or private token should be detected as early as possible. But the repository is only one stop in a secret's journey, and rarely the last.

A pipeline echoes credentials into its own logs. Someone attaches a config file to a Jira ticket. A database goes down at 2 a.m., and the key gets pasted into the incident channel. Every intact copy preserves the same access for as long as the original credential remains valid, and, based on our 2025 incident data, 28% of secrets incidents originated entirely outside code repositories, in collaboration and productivity tools.

And the sprawl extends beyond application source and collaboration tools:

Container registries and image layers
Infrastructure-as-code templates, including Terraform, Helm, and Kubernetes manifests
AI tooling configuration, where Model Context Protocol (MCP) files alone exposed 24,008 unique secrets in 2025
Public GitHub, through employees' personal repos, gists, and forks

The Shai-Hulud 2 supply chain attack gave researchers a rare look at what compromised developer machines actually hold: each live secret appeared in eight locations on average across the same machine, and 59% of the compromised systems were continuous integration and continuous delivery (CI/CD) runners rather than laptops. Traditional application testing does not provide comprehensive coverage across these surfaces, even when a broader suite adds selected integrations.

The same boundary problem shows up in adjacent security categories. Software composition analysis (SCA) adds dependency and component risk, while interactive application security testing (IAST) adds runtime instrumentation. Both remain centered on the application and its components rather than the complete credential lifecycle. Cloud posture tools can reveal risky permissions, configurations, and sometimes exposed keys within the cloud estate. They generally do not inventory every copy of a credential across code, collaboration systems, developer machines, and external repositories.

Git history still hides what code review cleans up

Pull-request review usually emphasizes the aggregate diff, so a secret introduced and removed in separate commits may disappear from the final change set unless individual commits or branch history are scanned. The branch history can retain every intermediate commit, including one where a secret was hardcoded and then removed before the pull request. The cleaned-up diff passes review while the credential stays in the history, clone after clone.

Secrets detection has to inspect not just what the code looks like now, but what it carried before and where that history has traveled. Once a secret enters git history, it can move with every clone, fork, mirror, and personal repository, including places the organization does not fully control.

The pattern is familiar. A developer opens a feature branch and hardcodes an API key to move fast, as in commit C in the tree below. The feature works, the branch gets tidied, the key becomes an environment variable, and the pull request shows nothing amiss. Commit C still holds the key. Squash-merging keeps the secret-bearing commit out of the target branch's ancestry, but it does not guarantee that the object disappears. The original branch, pull-request refs, existing clones, forks, mirrors, caches, or reflogs may continue to retain it. Once a credential has been committed and pushed, rotation is still required even if repository history is later rewritten.

a typical reflex when committing a secret

Purpose-built secrets scanners have treated history as a first-class surface for years. A conventional SAST run analyzes the revision it is given; it does not inherently enumerate every historical commit.

The gap in addressing security vulnerabilities shows up after detection

When a static analyzer flags an injection bug, the developer edits the code, and the finding closes. When a scanner flags a leaked credential, removing it from the code prevents further propagation, but it does not invalidate the credential or eliminate copies that already exist. Remediation means replacing the credential, updating its legitimate consumers, and confirming that the exposed credential has been revoked without unnecessarily breaking the systems that depend on it. That work crosses team boundaries a code fix does not touch.

At detection time, four questions decide everything, and static detection alone can answer none of them reliably:

Is the credential still valid?
What does it grant access to?
Where else does it exist?
Who owns it?

Without those answers, the alert stalls. The actual fix is operational. Replace the credential, update and verify every legitimate consumer, and then revoke the exposed credential. If active abuse is suspected, teams may need to revoke first and accept the resulting disruption. The replacement belongs in a vault rather than in another file. None of that resembles editing a line and merging a pull request, and none of it lands on a single developer.

The industry's track record on this follow-through is the most damning number in GitGuardian's research. Of the secrets confirmed valid in 2022, 64% were still valid in January 2026, four years after they first leaked. That persistence suggests many teams still lack a repeatable path from alert to confirmed revocation. The exposure may have been detectable, but the credential stayed usable. That is the difference between finding one instance of a secret and neutralizing the credential everywhere it has spread.

Context is the layer a code scanner can't produce

Prioritizing a leaked secret requires knowing whether it is valid, what it authenticates to, where else it appears, how long it has been exposed, and who owns it. A static analyzer models a secret as a string in a file, because that is what it sees. Answering those questions requires modeling it as a credential with state, checked against the provider that issued it.

Validity alone doesn't settle priority either. Roughly 46% of critical secrets have no vendor-provided validation mechanism, so exploitability has to be assessed from contextual signals: where the secret sits, what consumes it downstream, whether a copy already lives in a secrets manager, and whether the exposure is internal or public.

This is the layer the GitGuardian platform operates in. Where supported, validity is checked against the issuing provider, occurrences are mapped across connected repositories and the non-code surfaces above, ownership is attributed, and priority reflects real exposure.

Secrets are how non-human identities (NHIs) authenticate, and a program that treats them with that weight looks very different from a scanning feature bolted onto a code-quality tool.

Keep SAST and DAST, and close the gap they leave

Nothing here retires a scanner. Static and dynamic testing remain the right tools for the problem they were designed for, and the teams running them should keep investing in them.

The same is true for repository-native secret scanning and cloud posture management. They add important coverage, but each operates inside a boundary: the repository, the application, or the cloud environment. Credential exposure does not respect those boundaries.

A valid leaked secret is access that already works. It may be copied across code, history, logs, tickets, messages, images, runners, and developer machines long before anyone opens a remediation ticket.

The next time someone says the SAST suite already covers secrets, agree with them. Then ask whether it found every copy, identified the owner, and got the credential revoked before anyone else could use it.

Public GitHub is the one surface you can check in minutes, and the one an attacker checks first. See what's already exposed.

FAQs

What is the difference between SAST and DAST?

SAST (static application security testing) analyzes source code before the application runs, catching issues like SQL injection and access control mistakes early. DAST (dynamic application security testing) tests the running application from the outside, surfacing runtime and configuration flaws SAST cannot see. SAST is white box testing and DAST is black box testing. They are complementary, and most application security programs run both.

Do SAST and DAST detect hardcoded secrets?

Many SAST suites and code platforms now pattern-match hardcoded credentials, so they detect some secrets. But detection is only the first step. SAST and DAST cannot tell you whether a secret is still valid, what it grants access to, where else it has spread, or who owns it, and they do not scan the collaboration tools, pipelines, and registries where secrets also accumulate. Detection without that context and remediation leaves the access open.

Why aren't SAST and DAST enough for secrets security?

SAST and DAST manage code risk: weaknesses an attacker might exploit in the future. A leaked credential is active access risk that works right now, with no exploit required, and it spreads far beyond the repository and stays valid until someone revokes it. Those are different problems, and code scanners were never built to validate, locate, prioritize, and rotate live credentials across every surface where they leak.

Where do secrets leak outside of source code?

Secrets sprawl into every surface developers touch: CI/CD logs and pipeline variables, Jira tickets and Slack messages, container registries and image layers, infrastructure-as-code templates, AI tooling and MCP configuration files, and employees' personal GitHub repos. In 2025, 28% of secret incidents originated entirely outside code repositories, so scanning only the repo misses a large share of exposure.

How do you remediate a leaked secret?

Editing the code does not fix it, because the credential stays valid wherever it was copied. Real remediation is to revoke the leaked credential at the provider, reissue a replacement, update every consumer that depends on it, and store the new secret in a vault rather than in code. Because this crosses security, development, and operations, it needs validity, usage, and ownership context to move quickly.

How to Measure Time to Revoke for Exposed Credentials

Dwayne McDaniel — Wed, 26 Aug 2026 12:36:12 +0000

This is a follow-up to an article we published in The Hacker News introducing time to revoke as a critical CISO metric. This version provides a practical guide for measuring it across exposed secrets and non-human identities.

👉 TL;DR: Time to revoke is a security metric that measures how long an exposed credential remains usable after it has been confirmed valid. Measuring it requires teams to record when a credential is validated and when its invalidation is confirmed. From that baseline, CISOs can track median and P90 time to revoke, the percentage of exposed secrets revoked within SLA, owner coverage, the percentage that remain valid after detection, and the incidents that require manual escalation.

Detection is not the same as credential revocation

Detection tells you when a credential was found. A remediation ticket tells you when work was assigned or closed. Neither tells you whether the exposed access was fully neutralized.

For leaked credentials, "Did we find it?" is the first question. "How long did it remain valid?" is just as important, if not more so.

If a leaked API key, cloud credential, service account token, OAuth secret, private key, or database connection string is still valid, it is a point of ingress. Until it is revoked, rotated, or otherwise invalidated, it remains a path an attacker can use. Credential rotation only counts when the exposed credential is disabled, expired, or otherwise rendered unusable. That makes time to revoke a critical CISO metric. It connects detection to business risk by measuring the exposure window security teams need to close.

What is time to revoke in secrets remediation?

Time to revoke measures how long an exposed credential remains usable after it has been confirmed valid.

Time to revoke = confirmed invalidation timestamp − validation timestamp

The clock starts when the organization verifies that the credential works and stops when it confirms that the credential can no longer be used. Closing a ticket, deleting a file, or removing the secret from a repository does not stop the clock. Only revocation, rotation, expiration, or another form of confirmed invalidation does.

Why secrets remediation needs more than MTTD and MTTR

Security programs have become much better at finding exposed secrets. Source code scanning, pre-commit hooks, CI/CD controls, secret detection in collaboration tools, and monitoring for public leaks have all improved visibility. But visibility is only the first step.

A secret can be found quickly and still remain valid for days, weeks, or months. It can be removed from a repository, cleaned from a pull request, or deleted from a local file without invalidating the credential itself. For attackers, cleanup doesn't matter if the credential still authenticates.

Many security teams already track mean time to detect and mean time to remediate. Those metrics still matter, but they can blur the specific risk that exposed secrets create. Mean Time to Detect (MTTD) tells you how quickly a secret was found. Mean Time to Remediate (MTTR) often depends on how the organization defines "resolution": a closed ticket, a cleaned file, a merged pull request, or a completed rotation.

For secrets, that ambiguity is dangerous. Time to revoke is stricter, and measures one outcome: whether the exposed credential was invalidated. That makes it a better metric for credential exposure risk and a necessary companion to MTTD and MTTR.

How to measure time to revoke: secrets remediation metrics

The best version of time to revoke is simple enough to report and specific enough to drive action.

At a minimum, each exposed secret incident should capture four timestamps:

Detection timestamp: when the secret was first found.
Validation timestamp: when the secret was confirmed valid or invalid.
Owner assignment timestamp: when the responsible owner or team was identified.
Invalidation timestamp: when the exposed credential was revoked, rotated, or confirmed unusable.

From those timestamps, security teams can report several useful measures.

Median time to revoke

Median time to revoke shows the typical speed of credential neutralization. It is useful for trend reporting because it is less distorted by a small number of extreme outliers.

90th percentile time to revoke

P90 time to revoke shows the long tail. This is often where the real risk lives: secrets with unclear owners, sensitive access, or operational dependencies that keep them valid too long.

Percentage of exposed secrets revoked within SLA

This turns time to revoke into an accountability metric. For example, security teams might set different targets for different risk levels:

Critical valid production secrets: revoke within hours
High-risk valid secrets: revoke within one business day
Lower-risk valid secrets: revoke within a defined remediation window
Invalid or expired secrets: document and clean up according to policy

The specific SLA should reflect the organization's risk model. The important point is that the SLA is tied to credential invalidation, not ticket movement.

Percentage of exposed secrets with confirmed owners

Owner mapping is one of the strongest predictors of remediation speed. If a credential has no known owner, time to revoke will almost always suffer. Tracking owner coverage helps CISOs see whether they have a detection problem, an identity governance problem, or an operational handoff problem.

Percentage of exposed secrets still valid after detection

This is one of the clearest risk indicators. It shows how many exposed credentials remain usable after being found. For executive reporting, this is often more meaningful than raw alert volume. A thousand detected secrets may sound alarming, but the board-level concern is how many of them still grant access.

Percentage of secrets incidents requiring manual escalation

Manual escalation is a sign of process friction. If many incidents require security to chase owners, interpret provider-specific documentation, or negotiate revocation manually, the organization has a scalability problem. This metric helps justify investment in automation, ownership mapping, provider integrations, and better remediation workflows.

CISO security metrics for leaked credentials

Time to revoke belongs in executive reporting because it translates a technical exposure into a business risk window. For board and executive audiences, the point is not to report every leaked key or every remediation ticket. The point is to show whether the organization is reducing the amount of time exposed access remains usable.

A useful CISO dashboard might include:

Number of valid exposed secrets detected
Percentage tied to production, sensitive data, or privileged systems
Median and P90 time to revoke
Percentage still valid beyond SLA
Top systems or teams contributing to delayed revocation
Recurrence rate by credential type or business unit

This gives leadership a clearer view of exposure than alert counts alone. It also reframes remediation as a measurable security outcome: are we shrinking the window of usable exposed access?

Want to reduce time to revoke for exposed credentials?

Measuring time to revoke shows how long exposed access remains usable and where the remediation process is slowing down. The next step is reducing that window by addressing the ownership, dependency, and workflow problems that delay revocation.

See how it works.

The Perimeter Moved to the Laptop: From Network, to Identity, to the Developer Endpoint

Dwayne McDaniel — Mon, 24 Aug 2026 13:29:06 +0000

👉 TL;DR: The perimeter has moved before. It went from the network to identity, the shift everyone summarized as "identity is the new perimeter." It is moving again, onto the device.

Open a developer's laptop, and you will find a stash of working credentials: cloud access keys, API tokens, SSH keys, package-registry tokens, and the secrets AI coding agents cache as they run. Network controls never see them. The identity provider decides who can log in, but not which valid keys are already on the disk. EDR watches process behavior, not the plaintext credential sitting in a config file. The credentials are present, valid, and reusable, but no layer in the stack is responsible for inventorying them.

The next phase of perimeter security starts with visibility into the credentials already sitting on the developer endpoint, before they become someone else's access.

The perimeter keeps moving

For thirty years, "securing the perimeter" has meant defending the boundary around access. First, that boundary was the corporate network. Then it became identity. Now it is wherever valid credentials live.

Era 1: The network was the perimeter

In the first era, the perimeter was a place. Firewalls, VPN concentrators, and network segmentation separated the trusted inside from the hostile outside. This was the castle-and-moat model that defined enterprise security for decades: get onto the corporate network and you were largely trusted; stay outside it, and you had to get through the wall first.

Cloud, SaaS, and remote work dissolved the trusted inside. Workloads moved to infrastructure the company did not own. Data moved into third-party applications. Employees signed in from kitchens and airport lounges. The assets worth protecting no longer sat behind a single boundary, so there was no single boundary left to defend. This erosion of the fixed network edge has a name: deperimeterization.

Era 2: Identity became the perimeter

With no fixed network edge, security shifted from where access came from to who was requesting it. Single sign-on, multi-factor authentication, conditional access, and the identity provider became the new control plane. This was the era of "identity is the new perimeter," and identity-first security is now the default for most mature programs.

It was the right move, but it left a deeper gap. An identity provider governs authentication. It can challenge a user signing in from an unusual location because the context looks wrong. But it does not inventory the valid credentials already resting on a device, and it cannot always tell whether a local access key is still being used by the identity it belongs to. If the key is valid and the access is in scope, there may be nothing anomalous to flag.

Era 3: The device is where the keys now live

Now the developer laptop is where those long-lived credentials pile up: cloud credentials in ~/.aws, Kubernetes configs in ~/.kube, API tokens in dotfiles, SSH private keys in ~/.ssh, package-registry tokens in .npmrc, and secrets AI coding agents write into config and temp files as they operate.

An attacker who reaches that endpoint does not need to break the identity system. The credentials already grant authorized access to cloud accounts, source control, package registries, and the SaaS tools the developer uses. There is no IdP exploit or password to phish. The attacker simply uses valid credentials as the trusted identity they belong to.

Agents make that surface even denser. A human may have location, device posture, or behavior patterns an identity system can challenge. Agents authenticate to systems constantly, often without a human in the loop, and with fewer contextual signals to evaluate. A valid credential can keep working long after anyone has context for why it exists.

That is what makes discovery the missing control here. You have to know which credentials are already on the device before someone else finds and uses them.

The credential plane on the developer endpoint is the new edge of the perimeter. It is also the one with the least dedicated coverage.

Why credentials pile up on the developer endpoint

Credentials pile up on developer machines because modern development rewards speed. Developers are expected to move quickly across cloud services, package registries, containers, source control, and AI tooling, and every repeated login slows that work down. So the tools optimize for convenience: every cloud login, container-registry login, and package-manager auth leaves a token behind in a config file so the developer does not have to authenticate again next time.

Vaults manage secrets at the source, but they do not control every local copy created after retrieval. A developer may pull a credential for local use, finish the task, and leave it behind in a file, cache, or shell history. That local copy becomes the exposure.

AI tooling adds another layer. Coding agents cache tokens, rewrite configuration, and drop secrets into temp files as they work. Each new agent or integration creates another identity and another place for a credential to land. Model Context Protocol (MCP) servers, agent skills, and local model tooling all expect credentials to be available on disk.

Many of these credentials are static by default. They are not tied to a session, and they do not disappear when the task ends. Unless someone rotates or revokes them, a key created for one local workflow can remain usable for months, sometimes years (for the mechanics of how this happens day to day, see protecting developers' secrets).

The attack path does not have to be sophisticated. A poisoned dependency or compromised editor extension lands on a developer machine and scans the places credentials usually live: ~/.aws/credentials, cached cloud sessions, SSH keys, old .env files, and shell history. Once those secrets are exfiltrated, the attacker can reach whatever they grant access to, from cloud accounts to private repositories to SaaS tools.

This is not hypothetical. In August 2025, the s1ngularity attack pushed malicious versions of the popular Nx build tool to npm, and its post-install script swept developer machines for SSH keys, npm and GitHub tokens, cloud credentials, and .env files. It was the first known attack to turn locally installed AI command-line assistants into accomplices, using them to help hunt down secrets before exfiltrating everything to public repositories. The self-replicating Shai-Hulud worm ran the same playbook across hundreds of npm packages. Neither attack had to break the perimeter. They went looking for what was already on the machine.

The gap: what network and identity controls don't see

Every layer in a mature stack watches a different part of the credential lifecycle. Each control below is valuable and necessary. But none is responsible for inventorying the plaintext credential on a device. That ownership gap sits between their mandates.

Network security: watches traffic, connections, and egress. It does not see the access key in ~/.aws/credentials or the token in shell history, because a credential can exist on the device before it is ever used.
Identity and access management (IAM): governs who can access what, usually through the identity provider (IdP) and its authentication and authorization policies. It does not enumerate the standing credentials already present on a machine.
Privileged access management (PAM): stores and controls access to privileged credentials and sessions. The local copy a developer pulled to their laptop falls outside its scope.
Endpoint detection and response (EDR): monitors the device for suspicious activity, malicious processes, and signs of compromise. It is built for detection and response, not for maintaining an inventory of credentials sitting in config files.
Repo and CI secret scanning: inspect code and pipelines. They do not reach credentials on the local filesystem, whether those credentials are waiting to be committed or never enter a repository at all.

The future of the perimeter

Identity security and endpoint credential discovery are becoming harder to separate. One tells you which identities exist and what they can access. The other shows where the credentials for those identities are actually sitting. Together, they answer the question security teams increasingly need to ask: who, or what, holds access, and where does that access live?

AI agents will make the endpoint harder to control. Every new agent, integration, or local tool creates another identity and another place for a credential to land. As agentic development grows, credentials on the device multiply instead of disappearing.

Compliance will likely follow the same direction as the risk. Even when frameworks do not name endpoint credential discovery outright, they increasingly expect teams to account for exposed credentials, local secrets, and the paths those credentials create into critical systems.

All of this is changing the working definition of the perimeter. Network first, then identity, now the device. Each shift followed where access concentrated, and today that access increasingly sits on the developer endpoint.

Summary: the perimeter is wherever a valid credential sits

Network and identity controls are not going anywhere, and nor should they. But they also do not inventory the exposed credentials resting on the machine itself. Closing that gap means finding and revoking those credentials before an attacker uses them, and recognizing the developer endpoint for what it has become: part of the perimeter.

See how it works

FAQs

Is the network perimeter dead?

The network perimeter is not dead, though it is no longer the boundary that matters most. Cloud, SaaS, and remote work dissolved the trusted inside. Protection moved first to identity and then to the device, where valid credentials now concentrate.

What does "identity is the new perimeter" mean?

With no fixed network boundary, identity (who is authenticating, and whether they are authorized) became the primary control plane. The framing is accurate but incomplete. Identity governs login events, not the standing credentials already sitting on devices.

Has the security perimeter moved to the endpoint?

The security perimeter has increasingly moved to the endpoint. The developer endpoint is where cloud keys, tokens, SSH keys, and AI-agent secrets accumulate. An attacker who reaches the device picks up valid, reusable credentials, which makes the endpoint credential plane the current frontier of the perimeter.

What is deperimeterization?

Deperimeterization is the long-running erosion of the fixed network boundary as cloud, mobile, and SaaS push assets and access outside it. The practical result is that protection has to follow identity and credentials wherever they live, including the device.

Does zero trust protect credentials sitting on a laptop?

Zero trust verifies access requests instead of trusting the network, which is essential. But it does not inventory credentials sitting at rest on a device, like a forgotten access key in ~/.aws.

Why isn't EDR enough to protect credentials on a developer machine?

EDR detects malicious processes and behavior. It does not inventory the plaintext credentials sitting in config files, caches, and shell history. Credential discovery is a complementary control that finds the secrets EDR was never designed to look for.

How is endpoint credential discovery different from identity security or ITDR?

Identity security and identity threat detection and response (ITDR) govern and monitor identities and authentication. Endpoint credential discovery inventories the actual secrets at rest on a device. One manages the identity. The other finds the standing credential that could compromise it.

How do attackers get valid credentials without breaching the network?

Attackers get valid credentials through infostealer malware on the endpoint, which reads cloud caches, shell history, SSH keys, and browser tokens. Because those credentials are valid, the attacker gains legitimately authorized access without ever touching the network perimeter.

What CISA Got Right After Its GitHub Leak: Lessons Every Organization Should Copy

Dwayne McDaniel — Fri, 21 Aug 2026 13:30:45 +0000

On May 14, 2026, we found 844 MB of sensitive CISA-related data in a public GitHub repository and got it taken down in 26 hours. I told the story in How We Got a CISA GitHub Leak Taken Down in Under a Day.

Two months later, CISA published Lessons from CISA's Cyber Incident. Most organizations bury this kind of incident. CISA wrote it up, explained what worked, what did not, and invited the industry to learn from it. As a practitioner, I think the document is really good. As the researcher who reported the leak, I want to translate its lessons into practical steps for security teams.

To my knowledge, it is also the first time a national cybersecurity agency has publicly advocated for secrets scanning and for simplifying relations with security researchers. These are topics my team has been pushing for years, and I am proud to see them recognized at this level.

CISA's response offers six lessons for security teams: take external reports seriously, continuously scan repositories for secrets, build dedicated leak-response playbooks, simplify reporting channels, strengthen development guardrails, and test credential rotation before an incident.

1. Take external vulnerability reports seriously

CISA ultimately acted on a report that reached it through an unnecessarily complicated path, including CERT/CC, personal contacts, and a journalist. They engaged, kept the channel open, and thanked us for the collaboration.

What to copy: Treat every external report as signal until proven otherwise. The person reporting a leak to you is not the threat. Letting nine notification emails go unanswered is how a one-day incident becomes a six-month exposure.

2. Monitor repositories continuously for exposed secrets

CISA's action plan includes stricter control over public repositories and enhanced monitoring for exposed developer secrets. The lesson is broader than public repositories: no plaintext secret should be committed to source control, including private repositories.

What to copy: Scan continuously, not quarterly. The Private-CISA repository sat public for six months. Continuous monitoring of public GitHub surfaced it. Comprehensive internal scanning could have caught the plaintext passwords and committed backups long before they left the building.

3. Build a dedicated secrets-leak response playbook

CISA acknowledged it lost time early on because it had no GitHub and cloud incident-response playbook and had to build one during the incident.

What to copy: Write a secrets-leak playbook before you need it. Who revokes the keys? Who talks to GitHub? Who checks the Git history, not just the working tree? A leaked credential is not a generic incident; it needs its own runbook.

4. Simplify security incident reporting channels

Before reaching CISA, I emailed the contractor, filed through the vulnerability disclosure platform, and finally involved a reporter. CISA recognized the ambiguity and is refining its channels.

What to copy: Make it trivial to report a leak about you, not just about your products. Maintain a public vulnerability disclosure policy alongside any bug bounty program, and publish a security.txt that makes the reporting channel easy to find. Put reporting instructions in several prominent places, and make sure a report about your own infrastructure does not land in a product-bug queue.

5. Strengthen development environment guardrails

CISA was already consolidating its developer environments when the incident hit, and the leak confirmed the direction: consistent controls, fewer unmanaged tools.

What to copy: Unmanaged tooling creates exactly the kind of blind spot where secrets can leak. Personal GitHub accounts, contractor laptops, and ad hoc backup scripts all sit outside your controls. Consolidate them, and the guardrails follow.

6. Test cryptographic key rotation readiness

CISA admitted key rotation took longer than expected because of the complexity of its systems and interconnections.

What to copy: Test your rotation before an incident forces you to. If you cannot rotate a credential quickly, you do not have operational control over it. Key agility is the most overlooked item on this list, and the one that determines how long an attacker's window stays open.

Transparency is what makes these lessons valuable

CISA also credits Zero Trust principles and strong logging for containing the incident, and both points are worth reading in full. But the biggest takeaway is the postmortem itself. "It is not a matter of if, but when." CISA lived it, wrote it down, and shared it. That is exactly the incident communication we should expect from every organization.

Want to know what your public GitHub exposure looks like before someone else finds out? Run a GitHub Security Audit or check a specific credential with HasMySecretLeaked.

Identity Infrastructure: Why Credentials Are the Layer Directories Don't Secure

Dwayne McDaniel — Thu, 20 Aug 2026 17:23:17 +0000

👉 TL;DR: Identity infrastructure is the foundation of enterprise security: the directories, identity providers, access management systems, credential stores, and governance workflows that control who and what can reach organizational resources.

Most enterprises treat identity infrastructure as a directory problem, investing in Active Directory, Entra ID, Okta, or SailPoint to manage identity lifecycle and access policy. Those investments are necessary, but on their own, they are incomplete.

Directories manage identity lifecycle; they do not detect whether the credentials identities use — API keys, service account tokens, OAuth secrets, certificates, and kubeconfig files — have leaked into source code, CI/CD pipelines, or collaboration tools.

The identity infrastructure risks that matter most in 2026:

Non-human identities outside directory reach: service accounts, API keys, and machine tokens that were never created in, or governed by, the directory.
Credential sprawl across environments: the same secret copied across repositories, CI/CD variables, logs, tickets, collaboration tools, and developer machines.
Credential exposure: leaked tokens and keys that grant attackers legitimately authorized access, so directory-level controls evaluate them as valid.
Multi-cloud fragmentation: identity infrastructure spread across multiple directories, identity providers, and cloud IAM systems, each with its own credential handling.
Credentials that outlive their owners: keys that keep working after the identity that used them is deprovisioned.
Compliance evidence directories cannot produce: credential inventory, exposure history, and remediation proof that access reviews alone do not cover.

A mature identity infrastructure secures both the governance plane (directories, identity providers, lifecycle management) and the credential plane (exposure detection, ownership, vault coverage, secrets hygiene).

The part of identity infrastructure your directory was never built to see

In 2025, GitGuardian detected millions of new hardcoded secrets across customer environments. These are working credentials to real systems: API keys, service account tokens, database connection strings, OAuth secrets, and cloud keys. Each one can authenticate an identity, service account, workload, or integration somewhere in the environment. Once exposed, those credentials can be copied, reused, and rediscovered far from the system that issued them.

This is where modern identity infrastructure extends beyond the directory: into the credentials moving through code, pipelines, collaboration tools, and developer environments. Securing that layer requires visibility into where credentials are exposed or mismanaged, without disrupting the systems that already manage identity lifecycle and access policy.

What is identity infrastructure? A complete picture

Modern digital identity infrastructure spans three layers: governance, credentials, and enforcement.

The governance plane: directories, identity providers, and lifecycle management.

This is the identity services infrastructure where most IAM investment concentrates:

Identity directories: Active Directory, Entra ID, LDAP, etc. The authoritative record for users, groups, and sometimes service accounts.
Identity providers: Okta, Entra ID, Ping Identity, Auth0, etc., handling authentication and authorization flows and token issuance.
Identity Governance and Administration (IGA): SailPoint, Saviynt, ConductorOne, etc. Access certification, provisioning, and compliance reporting.
Privileged Access Management (PAM): CyberArk, BeyondTrust, Delinea, etc. Governs and vaults privileged credentials.
Identity orchestration: Strata Identity, Ping DaVinci, Simeio, etc. Unifies fragmented identity systems into coordinated workflows.

The credential plane: tokens, keys, secrets, and certificates.

This is where identity management infrastructure meets the artifacts that actually grant access:

API keys and tokens: bearer tokens, OAuth access and refresh tokens, JSON Web Tokens, and personal access tokens.
Service account credentials: Kubernetes ServiceAccount tokens, cloud IAM service account keys, and machine-to-machine client secrets.
Certificates: TLS and mutual TLS certificates for service-to-service authentication, and client certificates for API access.
Secrets and connection strings: database credentials, SaaS integration secrets, SMTP passwords, and cloud storage access keys.
SSH keys: developer and automation keys for repositories, servers, and pipelines.
Secrets managers and vaults: HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Akeyless, Delinea, and similar systems.

Some credentials are issued by governance-plane systems. Others come from cloud services, SaaS platforms, developer tools, package registries, or one-off integrations. Once issued, they move through code, configuration files, CI/CD pipelines, collaboration tools, and developer workstations — far from the systems that created or governed the identity in the first place.

The enforcement layer: where identity meets cloud, network, and workloads.

Cloud IAM: AWS IAM, GCP IAM, and Azure RBAC enforcing permissions across cloud resources.
Kubernetes identity: Kubernetes RBAC, ServiceAccounts, and workload identity federation governing access between workloads and clusters.
Service mesh and workload identity: Istio, Linkerd, Cilium, and mutual TLS carrying trust between services.
API gateways: token validation, authorization checks, and policy enforcement at the perimeter.

Identity infrastructure blind spots

Directories were built for people, not non-human identities at this scale

Most directories were designed around human users. Non-human identities — service accounts, API keys, OAuth apps, and CI/CD credentials — often sit partly or wholly outside directory governance. Service accounts created directly in cloud IAM or Kubernetes may never appear in the corporate directory. API keys issued by SaaS platforms are managed per service, not centrally. Developer-created tokens proliferate in git repositories, .env files, and CI/CD configs, where directories do not reach.

With machine identities outnumbering humans 109 to 1, the practical problem becomes ownership. The first question about any service account is "whose is it?" — and the directory has no answer for an account it never held.

Credentials outlive their directory entries

When an employee leaves or a service is decommissioned, the directory entry is deactivated. The credentials that identity used can persist. API keys embedded in application code keep working until they are revoked at the issuing service. Service account tokens committed to a repository remain in git history indefinitely, even after the account is deleted. OAuth refresh tokens cached in SaaS integrations can keep granting access after the authorizing identity is gone.

Deprovisioning removes the identity. It does not guarantee removal of every credential that identity ever held.

Credentials spread faster than identity systems can track them

A credential rarely lives in only one place. The same API key may appear in a repository, a CI/CD variable, a build log, a Jira ticket, a Slack thread, and a developer's local environment. Revoking the copy found in one location does not answer the larger question: "where else did this credential travel before anyone found it?"

For a machine, the credential is the identity

For a human identity, the credential and the person stay separable. A machine offers no equivalent seam. There is no second factor, and no colleague notices that a login does not look right. Whoever holds a service account's key is, for every practical purpose, that service account.

When a service account key leaks in a public repository, a CI/CD log, or a chat message, the attacker authenticates with a valid credential. RBAC grants the request because the token carries valid privileges, cloud IAM allows the call because the key belongs to an authorized service account, and audit logs record the activity as normal, authorized access. A leaked machine credential with elevated privileges can be difficult to distinguish from legitimate use until the exposure itself is found.

Multi-cloud and hybrid infrastructure multiplies credential fragmentation

In hybrid identity infrastructures spanning on-premises Active Directory, Entra ID, AWS IAM, GCP IAM, Kubernetes, and multiple SaaS platforms, credential handling fragments across every layer. Each cloud provider has its own service account and key system, with different rotation and auditing capabilities. The result: an enterprise can have strong directory governance in Entra ID, mature RBAC in Kubernetes, and comprehensive IAM policy in AWS, and still have exposed credentials in repositories that grant access to all three.

Compliance requires credential evidence directories do not hold

SOC 2, ISO 27001, PCI DSS, NIST 800-53, DORA and HIPAA all create expectations around identity and access controls, credential management, logging, monitoring, and incident response. Directory systems provide identity lifecycle evidence like provisioning, deprovisioning, and access reviews. They do not provide credential exposure evidence like whether secrets leaked, how long they were exposed, whether they were still valid, and whether they were remediated.

Securing identity infrastructure: best practices across the planes

Governance plane: directory and lifecycle hygiene.

Consolidate directories where possible to reduce identity provider sprawl.
Automate provisioning and deprovisioning through SCIM, IGA workflows, and HR-driven triggers.
Enforce MFA and conditional access across human access paths.
Integrate cloud IAM and Kubernetes RBAC with corporate directories through OpenID Connect or SAML federation, and run regular access certification campaigns.

Credential plane: secrets hygiene and exposure evidence.

Vault long-lived secrets in dedicated systems (HashiCorp Vault, CyberArk, AWS Secrets Manager, or Azure Key Vault).
Prefer short-lived, automatically rotated credentials over static keys, and enforce rotation policy.
Replace hard-coded credentials with vault-backed references, workload identity, or ephemeral credentials wherever possible.
Set mean time to remediation targets for exposed credentials and wire confirmed findings into incident response.
Measure vault coverage — a vault mandate without measurement is a suggestion.

Enforcement layer: cloud, Kubernetes, and workload identity.

Use cloud-native workload identity (AWS IRSA, GCP Workload Identity, Azure Managed Identity) to remove static cloud credentials from applications.
Implement Kubernetes RBAC with a dedicated ServiceAccount per workload, and disable token automounting for pods that do not need API access.
Scope CI/CD pipeline credentials to short-lived tokens and keep long-lived secrets out of pipeline config.

Auditing identity infrastructure: proving access control and credential control

Most identity audits start on the governance plane: access reviews, certification campaigns, directory group membership, federation trust, cloud IAM policy, privileged access, identity provider logs, and deprovisioning checks. That work is essential.

But governance-plane auditing does not answer the credential questions behind that access: whether a token has leaked, whether a service account key still works, who owns it, where else it appears, or whether remediation can be proven.

Credential-plane auditing fills that gap. It should cover:

Source code, including full git history, for leaked API keys, tokens, service account credentials, and connection strings.
CI/CD pipelines for credentials in build output, environment variables, and configuration.
Collaboration tools (Slack, Jira, Confluence, Teams) where credentials are often copied during development, debugging, and incident response.
Developer endpoints for credentials stored in local files, shell history, CLI configs, IDE caches, browser stores, and AI coding tool artifacts.
Public repositories for organizational exposure outside the company's controlled environments.
Non-human identity credentials, attributed to an owning team wherever possible.
Exposure metrics including time to detection, time to remediation, exposure window, recurrence, duplication, validity, and vault coverage.

Because GitGuardian sits in the SDLC layer, with more than 500 secrets detectors running across repositories, pipelines, collaboration tools, and developer endpoints, it can add context to credential findings. It also reconciles detected credentials against vaults including HashiCorp, CyberArk, AWS, Azure, Akeyless, and Delinea, reporting vault coverage as a measurable control.

Modernizing legacy identity and directory infrastructure

Many enterprises still anchor identity infrastructure on on-premises Active Directory, with layers of LDAP integration, Kerberos authentication, and static service account credentials accumulated over decades.

Governance-plane modernization:

Extend on-premises Active Directory to the cloud through Entra ID, or adopt cloud-native identity providers for new workloads.
Consolidate fragmented directories into a federated architecture.
Implement IGA for automated lifecycle management across hybrid environments.

Credential-plane modernization:

Inventory the static, long-lived credentials created under legacy infrastructure.
Move hard-coded secrets into vault-backed storage with automated rotation, and replace long-lived service account keys with workload identity federation.
Continuously detect legacy credentials that leaked into code and config over years of development.
Set credential hygiene baselines and track remediation as part of the program.

The future of identity infrastructure in 2026 and beyond

Credential context feeding governance, not merging into it: exposure, ownership, and vault-coverage evidence flowing into the directory, PAM, and IGA systems that already run.
Non-human identity as a first-class infrastructure concern, with dedicated tooling for discovery, ownership, and risk scoring.
Workload identity federation replacing static credentials as the default for cloud-native environments.
Credential exposure evidence becoming a standard compliance expectation, not just a security best practice.
AI-driven identity analytics: anomaly detection on credential usage and continuous access review. AI agent identities have become one of the fastest-growing parts of the machine identity estate.
Decentralized identity and verifiable credentials beginning to shape enterprise design.

What is identity infrastructure?
Identity infrastructure is the complete set of systems, services, and processes that manage digital identities and their access to organizational resources. It includes identity directories, identity providers, governance platforms, secrets management systems, cloud IAM, Kubernetes RBAC, and the credentials (tokens, API keys, certificates) that authenticate identities across all of them.

Why do credential-based attacks succeed even with strong directory infrastructure?
Because directories govern identity lifecycle, not credential exposure. When an API key leaks in a repository or a service account token appears in CI/CD output, the attacker can authenticate with a valid credential, and downstream controls may treat the activity as legitimate.

What role does identity infrastructure play in zero trust architecture?
Identity is the primary enforcement plane in zero trust: every access decision requires verification regardless of network location. Zero trust is undermined if the credentials used for verification have been compromised, so credential exposure detection is a prerequisite for zero trust integrity.

How should enterprises approach identity infrastructure for non-human identities?
Non-human identities need the same rigor as human identities: inventory, ownership, least privilege, rotation, and lifecycle management. Because these identities often sit outside directory governance, enterprises need credential-plane visibility that pairs exposure detection with ownership attribution, risk scoring, and rotation-policy flagging.

GitGuardian Power for Amazon Kiro: Secrets Detection Built Into the Agent

Dwayne McDaniel — Wed, 19 Aug 2026 13:16:27 +0000

GitGuardian is now live on the Kiro Powers marketplace.

Install the Power once, and Kiro's agent can help you use GitGuardian tools directly in your workflow. Ask it to scan your repo for secrets with the GitGuardian CLI, or remediate incidents tied to your current project through the GitGuardian MCP server.

GitGuardian's CLI, MCP server, and built-in steering files are ready when you need them, so teams can start finding exposed secrets, resolving incidents, and reducing future exposure faster, without adding another process to manage.

GitGuardian is one of the first security independent software vendors (ISVs) with a live Power on the Kiro marketplace.

How the GitGuardian Power keeps credentials out of commits

AI-assisted development is accelerating credential exposure from two directions at once. Developers ship code faster, and the models doing the writing were never trained to avoid hardcoding credentials. Developers using AI coding assistants leak secrets at roughly twice the baseline rate, according to GitGuardian's State of Secrets Sprawl 2026 report, which also found 28.6 million new secrets exposed on public GitHub in 2025. That is a 34% jump year over year, the largest single-year increase on record.

The failure mode is specific. The model writes the credential, the agent commits it, and a post-commit or CI/CD scanner finds it after it has already landed in git history. At that point, the secret is exposed, and cleanup means rotation, history rewriting, or both.

Detection has to move to the point of creation. That is what this Power does.

What Kiro Powers are

Amazon Kiro is an AI-powered IDE that combines agentic coding with spec-driven development. Powers are packages of expertise and tooling that activate on demand based on keywords in your conversation. Mention "secrets" or "API keys" in a Kiro session, and the GitGuardian Power loads automatically. When the task changes, it unloads, keeping the agent's context focused on the task at hand rather than loading every installed tool simultaneously.

What the Power does

The Power gives Kiro's agent the ability to scan proactively across multiple surfaces:

Files and directories: anything on disk in the current workspace.
Git history: the full history of a repository, including secrets that were committed and later deleted.
Staged changes: specific commits, commit ranges, or pre-commit staged changes.
Docker images and PyPI packages: built artifacts as well as source.

Coverage also extends past the agent. The Power can install git pre-commit and pre-push hooks, so the same check holds when a human is the one committing.

When something is found, the agent guides remediation in code. Remove the hardcoded value and replace it with an environment variable or a secrets manager reference. Then rotate the exposed credential, with AWS Secrets Manager as the recommended destination for the new one. Rotation itself stays in your hands; the Power's job is making sure the leaked version never ships.

Honeytokens: a tripwire for anything that slips through

Defence in depth adds a second layer beyond prevention. The Power's honeytoken capability provides a tripwire for credentials that bypass the primary gate.

Kiro's agent can generate decoy AWS credentials — decoy credential pairs that mimic real AWS access keys, monitored by GitGuardian. Plant them where an attacker would look: .env.example files, internal wikis, runbooks, open repositories. If anyone touches one, an alert fires on your GitGuardian dashboard, and you know someone is inside before they reach anything real.

You can generate them as bare credentials or wrapped in realistic code (Python, JavaScript, Bash, or Terraform), convincing enough to hold up under inspection.

How it runs

Scanning works through ggshield, GitGuardian's open-source command-line interface, already on 600,000+ developer machines. Setup includes one manual step: a browser-based authentication to your GitGuardian workspace. The Kiro agent handles the rest, ggshield installation and configuration included.

Four steering files structure the Power, and Kiro loads them contextually:

gitguardian-platform: authentication and workspace configuration, including instance URLs.
scan-workflows: every scan command variant and when to use each.
scan-remediation: how to interpret findings and handle false positives, including when to rotate versus delete.
honeytoken-planting: generation and placement tactics, plus alert response.

One Power, every agent your team runs

The Kiro Power is one entry point into GitGuardian's agent-skills repository, which officially supports five agents: Claude Code (Anthropic), Codex (OpenAI), Cursor, VS Code with GitHub Copilot, and Kiro (AWS). Through the skills.sh installer, the same skills reach more than 50 additional agents, including Windsurf, Gemini CLI, OpenCode, and Cline.

For agents with hook support — Claude Code and Cursor among them — the skills screen prompts and outgoing code before anything executes. Kiro relies on the steering files described above, with the git hooks as the deterministic backstop.

Get started

The GitGuardian Power is available now in the Kiro Powers marketplace and on GitHub. You need a GitGuardian workspace; a free account works.

Secrets detection at the point of creation is one piece of the GitGuardian platform, which secures every secret from the developer's machine to public GitHub. If your team is adopting agentic coding tools and asking what the guardrails are, this is a good place to start.

Install in one click from Kiro:

Open the Powers panel in Kiro (or browse powers at kiro.dev).
Search for "GitGuardian" and click Install.
Authenticate with your GitGuardian workspace when prompted (a free account works).

Every Laptop Is a Credential Store: Complete Map of Hidden Secrets

Dwayne McDaniel — Tue, 18 Aug 2026 12:50:18 +0000

👉 TL;DR: A developer's laptop quietly becomes one of the densest credential stores in the organization. Cloud keys sit in ~/.aws, tokens pile up in shell history and .npmrc, SSH keys live in ~/.ssh, session cookies persist in the browser, and AI coding agents cache secrets in their own config files. None of it in a Git repository, none of it visible to the scanners most teams rely on.

The laptop is the origin point: where credentials first land, where they dwell unrotated for months, and where infostealer malware goes looking. This article maps every location, explains why traditional scanning misses them, and lays out how to bring that hidden credential plane under the same discipline you apply to code.

The perimeter moved to the laptop

Security has spent a decade hardening repositories, pipelines, and vaults. The machine where developers actually work — installing CLIs, authenticating to clouds, running AI assistants — is still treated as trusted ground. But it isn't.

A single laptop accumulates dozens of long-lived credentials across a dozen or more locations over months of normal work. No standard secrets scanner inspects any of them. Modern infostealers are written specifically to harvest the credential files that accumulate through ordinary development workflows. The laptop is not a new attack surface. It's one the industry has under-measured for years.

Why your repo and CI scanners never see this

Pre-commit and CI secret scanning inspect what reaches the repository or the pipeline. That is exactly why they miss the laptop.

A credential sitting in ~/.aws/credentials or shell history never gets committed, so a repo scanner never sees it. Most of those credentials are long-lived and rarely rotated, dwelling on the machine for months. AI tooling accelerates the problem: more agents, more integrations, and more local config files mean more credentials in more places than manual hygiene can track.

Structurally, the laptop is where every credential originates before it reaches a repository, a pipeline, or an attacker. Local secret scanning guardrails address the code-file part of this, not the broader landscape mapped below.

Where credentials hide on a developer's machine

What follows is a scan surface map for a developer endpoint. For each location: what lives there, why it ends up there, and why a Git-only scanner misses it.

1. Shell history

Files: .bash_history, .zsh_history, fish history files.

API keys, database connection strings, and tokens get pasted into one-off curl and CLI commands, then persist in shell history indefinitely. There is no expiration, no automatic redaction, and no warning that they were stored. Shell history is plaintext, persistent, and one of the very first files infostealer malware reads. It is also one of the most overlooked by security teams, because it feels ephemeral.

2. Environment files and dotfiles

Files: .env, .env.local, .gitconfig, .netrc, and exported variables in .zshrc or .bashrc.

Secrets get copied between projects, duplicated across machines, and rarely rotated. ".env sprawl" has become shorthand for the category, but the problem extends well beyond .env files. Exported variables in shell profiles are equally persistent and sit outside any version-controlled context. These files often hold production credentials at completely predictable paths, outside any repository. For more on how developers end up carrying secrets in these files, see protecting developers' secrets.

3. Cloud credential files

Files: ~/.aws/credentials, ~/.config/gcloud, ~/.azure, Terraform state files, and cached session tokens.

Cloud CLIs write credentials to disk at login: sometimes short-lived session tokens, but just as often static access keys with no expiry. The AWS CLI writes keys to ~/.aws/credentials by default. The Google Cloud CLI stores tokens under ~/.config/gcloud. Azure CLI credentials live in ~/.azure. This is typically the single highest-value target on the machine: direct, legitimately authorized access to production. One stolen key from this layer can translate into cloud account access, S3 bucket enumeration, compute spin-up, and lateral movement across services.

4. SSH and signing keys

Files: ~/.ssh/ private keys, known_hosts, and GPG signing keys.

SSH keys are generated once and reused for years, often without a passphrase. They grant direct access to infrastructure and the ability to sign commits as the developer. A compromised SSH private key is also harder to detect than a stolen API token: there is no API call log showing an unusual access pattern. It just looks like the developer logging in.

5. Package and registry tokens

Files: .npmrc, .pypirc, ~/.docker/config.json, ~/.gem/credentials, Hugging Face tokens, and Cargo tokens.

Package managers write authentication tokens to disk for publish and pull operations. A publish token is supply chain leverage: it can be used to push a malicious version of a package that other teams or downstream users depend on. Docker registry credentials in config.json are a particular blind spot: written automatically at docker login and rarely cleaned up afterward.

6. AI coding agent and MCP caches

Files: Config and cache files for Cursor, Claude Code, and Copilot, plus MCP server configurations that store tokens.

Each agent needs a credential to call its LLM service. Some tools write tokens directly to home-directory config files. The larger exposure is what agents produce while doing their jobs. An agent wiring up an integration may create an API key, store an OAuth token, or provision a service account, then write all of it into conversation history, context persisted to disk, or a temp file. The developer never made that decision.

Our research says agentic credentials account for more than 40% of secrets found on developer endpoints. Some land in well-known, agent-specific directories (.claude/, .cursor/, ~/.continue/), where origin is attributable. Others land in /tmp during task execution, where attribution is often impossible.

MCP servers compound this: they pull vault secrets into local configuration files at runtime, and those copies outlive the task. In 2025, security researchers found over 24,000 unique secrets in public MCP configurations.

7. Browser and session storage

What lives here: saved credentials, session cookies, and OAuth and refresh tokens held in browser profile storage.

Everyday authentication to cloud consoles and SaaS applications leaves persistent tokens in the browser profile. Stolen session tokens allow an attacker to resume an already authenticated session without requiring the password or MFA. This is exactly why infostealer operators sell "stealer logs" rather than raw credentials: a valid session cookie from a browser profile is often worth more than a username and password, because it is already past the authentication gate.

8. Structured files and archives

Files: CSV, SQL, XLSX, PDF, and SQLite exports; .zip and .tar archives; and the contents of /tmp and Downloads.

Data exports and vault-pulled secrets get written to disk "just for a minute" and forgotten. These are invisible to anything that only parses code or known config formats. A secrets scanner that reads .env files will not read a spreadsheet export of database connection strings or a PDF containing API credentials. But an infostealer will, because it reads the filesystem indiscriminately.

How credentials end up on the laptop and stay there

Every aws configure, gcloud auth login, docker login, or npm login writes a credential to disk by design. A key pasted into .env for a local test gets scaffolded into the next project. A vault secret pulled for debugging leaves a local copy nobody explicitly deletes.

And then they stay. The vault policy says rotate every 90 days. The local copy does not know that.

What an attacker actually gets from a developer machine

When an endpoint is compromised — most commonly by infostealer malware delivered through malicious packages, phishing, or trojanized tools — the attacker does not get a login prompt. They get a working set of legitimately authorized credentials across cloud accounts, source control, registries, and SaaS platforms. Infostealers are written to read exactly these files: cloud caches, shell history, SSH keys, browser tokens. Kits now target developer machines specifically because the credential density is that high.

One cached cloud key or registry token can reach far beyond the machine it sat on: production infrastructure, source control, or a package registry used by thousands of downstream consumers.

The hardest question comes after the incident: "What credentials were on this machine, and what do we revoke first?" Most security teams cannot answer quickly because they have never inventoried the laptop. That gap is what turns a containable incident into a prolonged breach investigation.

Bringing the endpoint credential plane under control

Inventory first. You cannot govern what you cannot see. Start by inventorying credentials across the surfaces mapped above. A repeatable, fleet-wide assessment is the baseline.

Prefer short-lived credentials. Favor SSO, Security Token Service (STS), OpenID Connect (OIDC), and workload identity federation over long-lived static access keys cached on disk. Static keys should be the rare exception, not the default.

Reduce the footprint. Clear secrets from shell history, scope .npmrc and .pypirc tokens narrowly, passphrase-protect SSH keys, and clean up temp exports when the task that required them is done.

Vault, but verify. Secrets managers help only if secrets actually flow through them consistently. Reconciling what is in the vault against what is discovered on endpoints closes the gap between "we have a vault" and "secrets are actually contained."

Rotate on discovery. Treat detection and rotation as a single motion. Prioritize by severity and access scope. Time-to-revoke is the metric: an exposed credential rotated in minutes causes far less damage than one sitting valid for days while an investigation runs.

Close the origin gap. Extend secret scanning to the developer endpoint so the laptop is covered by the same discipline as the repository and the pipeline. Traditional scanning misses the origin: the credential surfaces above are exactly what it cannot see.

Auditing the endpoint credential plane

Visibility alone is not a program. You need a governance layer: who owns endpoint credential risk, how often the fleet is assessed, what severity warrants what response, and how findings route into existing incident and ticketing workflows.

GitGuardian Developer Endpoint Protection extends ggshield to scan the developer's filesystem on a schedule, covering shell history, config files, cloud credential caches, AI agent configs, and archives across exactly the surfaces mapped in this article. Each finding is scored by severity and access scope. ggshield runs locally and sends only a hash and metadata — not the secret value or your source files — so the audit does not create a new exposure of its own. It deploys through your existing MDM with no continuous agent.

Developer Endpoint Protection is one capability within the GitGuardian platform, complementing (not replacing) your repository scanning, secrets manager, identity governance and administration, privileged access management, and identity provider. Where EDR watches for malicious processes and behavior, endpoint credential discovery inventories the exposed secrets sitting on the machine. They address different parts of the same problem.

The future of endpoint credential security

Two trends are converging on this surface.

Agentic expansion will make the inventory denser. As AI agents and MCP servers proliferate, the number of credentials landing in local configuration files grows with them. Each new integration is another location traditional scanners do not cover.

Commoditized theft keeps lowering the barrier. Infostealer-as-a-service kits are increasingly developer-aware, targeting the specific paths where cloud credentials, registry tokens, and browser session data accumulate.

The endpoint is becoming a first-class credential surface that deserves the same programmatic treatment as code and cloud.

Treat the laptop like the credential store it is

The developer endpoint is not trusted ground. It is one of the densest, longest-lived, and least-inspected credential stores in the organization: cloud keys, tokens, SSH keys, session cookies, and AI agent caches accumulating across a dozen locations that no Git scanner ever sees.

The teams that map this surface, inventory what is on it, and bring it under the same discovery and rotation discipline they apply to code will dramatically shrink their blast radius when an endpoint is compromised. Those who continue treating the laptop as trusted will keep handing attackers a working set of legitimately authorized keys and a scoping problem that takes days to resolve.

Where are secrets stored on a developer's machine?
Across many locations: cloud credentials, shell history, .env and dotfiles, SSH keys, package-manager tokens (.npmrc, .pypirc), AI agent and MCP caches, browser session storage, and temp exports or archives — almost none of which live in a Git repository.

Can secret scanning find credentials that aren't in Git?
Only if it scans beyond the repository. Pre-commit and CI scanning inspect code and pipelines; credentials stored in local files like ~/.aws/credentials or in shell history require endpoint-level scanning.

What's the most exposed place credentials hide on a laptop?
Cloud credential caches such as ~/.aws/credentials are usually the highest-value target. They often hold long-lived access keys to production and are a primary objective for infostealer malware.

Do infostealers target developer machines specifically?
Yes. Modern infostealers are written to read exactly the files developers accumulate — cloud caches, shell history, SSH keys, browser tokens — because those credentials grant legitimately authorized access to cloud and source systems.

How long do credentials stay on a developer's machine?
Often months. Most exposed credentials are long-lived and rarely rotated, so they dwell on the endpoint long after the task that created them.

Is scanning a developer's laptop for secrets a privacy risk?
It doesn't have to be. Endpoint credential discovery can run locally and transmit only a hash and metadata — not the secret value or your source files — so security sees what to revoke without reading the contents of your machine.

How is endpoint credential discovery different from EDR?
EDR watches for malicious processes and behavior. Credential discovery inventories the exposed secrets sitting on the machine. They're complementary: one addresses the malware, the other removes the credentials the malware is after.

DEV Community: Dwayne McDaniel

Securing Agentic AI Workflows in n8n: From Leaked API Keys to Encryption Key Compromise

The N8N_ENCRYPTION_KEY is n8n's root of trust

Three weaknesses in n8n's key derivation and session authentication

Flaw 1: JWT secret derivation discards half the key

Flaw 2: Sessions can be forged for OIDC-provisioned users

Flaw 3: Sessions can be forged for pending users

Recovering weak encryption keys offline

Leaked API keys provide a realistic starting point

CVE-2026-25053: From workflow access to arbitrary file read

Responsible disclosure

How to harden an n8n instance

Separate instances by trust boundary

Patch critical vulnerabilities immediately

Keep the API and administrative interface private

Use independent, randomly generated secrets

Isolate code execution

Disable unnecessary high-risk nodes

Restrict modules available to code

Monitor and self-audit

Scope credentials and remove inline secrets

A hardened n8n configuration baseline

The root of trust defines the blast radius

Secure the credentials behind your AI agents

Credential Harvesting Explained: How Attackers Collect Secrets From Developer Machines

What is credential harvesting?

How it differs from stuffing

How does credential harvesting work: The two main vectors

Vector 1: Tricking the user

Vector 2: Harvesting from the machine

Why developer machines are the richest harvest

3 Credential harvesting examples

Credential harvesting malware on the endpoint

What controls miss on the endpoint harvest

How to prevent credential harvesting

Auditing the endpoint credential plane

The future of credential harvesting

Summary: Harvesting is collection, so reduce what there is to collect

FAQs about credential harvesting attacks

What Was on This Machine? Answering the Blast Radius Question After a Laptop Compromise

The moment the question gets asked

Why "what was on this machine?" is so hard to answer

What EDR and security tooling tell you (and what they don't)

How do you answer the blast radius question after an incident?

What good looks like: From "not sure" to a revocable list

How GitGuardian answers "What was on this machine?"

Answer the question before it's asked

FAQs

An AI Agent Breached Hugging Face. The Attack Playbook Was Older Than the Attacker

The first real test for agentic AI security

Standing credentials and lateral movement did the real damage

How to explain AI agent security to your board

The emerging risk

The current risk

Five controls, starting with zero standing privileges

Every AI agent you deploy runs on secrets

How to Reduce Time to Revoke for Exposed Credentials

Why time to revoke matters for AI-era non-human identity risk

Why exposed secrets stay valid after detection

No clear owner for the exposed credential

Fear of breaking production systems

Manual provider-specific revocation workflows

Removal-only secrets remediation

No verification that the secret was invalidated

How to reduce time to revoke

Validate exposed secrets quickly

Map exposed credentials to owners

Build provider-specific revocation runbooks

Separate emergency revocation from planned rotation

Reduce reliance on long-lived credentials

Automate secret revocation where it is safe

Verify secrets remediation closure

A maturity model for time to revoke

Level 1: Secrets detection only

Level 2: Secrets detection and validation

Level 3: Secrets validation and ownership mapping

Level 4: Runbook-driven secret revocation

Level 5: Automated secret revocation and verification

Exposed secrets incidents are not over until credentials stop working

Reduce the time exposed credentials remain valid

The `N8N_ENCRYPTION_KEY` is n8n's root of trust