DEV Community: Dwayne McDaniel

AI Created a Leaked Credentials Flood: Here's How We're Draining It

Dwayne McDaniel — Sat, 26 Sep 2026 14:48:36 +0000

TL;DR

The exposure problem: AI-driven development pushed exposed credentials to 1.27 million last year, up 81%, and 64% of secrets confirmed valid in 2022 are still unrevoked as of January 2026.
The fix: GitGuardian Public Secrets Monitoring now runs two AI agents and deep analysis over every public GitHub and Docker Hub incident, returning a company-related verdict, a risk score, and visible reasoning.
The rollout: New workspaces get Agents Analysis by default, existing ones roll out gradually, one enterprise team saw a 10x productivity gain, and human review still closes every incident.

Credentials for AI services reached 1.27 million exposed across public code last year, up 81%, and 24,008 unique secrets turned up in public MCP configuration files alone. What makes those numbers worse is how long they stay live: of the secrets GitGuardian confirmed valid in 2022, 64% were still unrevoked when we retested them in January 2026, which means the same leaked credentials are still reaching the same systems they did on day one.

AI-driven development has multiplied the places compromised credentials can land in public: not just source code and CI/CD pipelines, but MCP configuration files, AI tool caches, terminal session logs, and the output of agents that write code for the humans running them. The public exposure surface grew faster than any team's capacity to review it.

Scale moved the bottleneck rather than creating a new one. Detection at this volume is tractable, and what has become hard is everything downstream of the alert: deciding whether the leaked key belongs to your organization at all, and whether it is serious enough to act on today.

The two main questions that gate every public incident

Two questions determine whether a public monitoring program delivers value or drowns in noise.

1. Is this actually ours?

A credential appearing in a public repository could belong to your organization, a vendor, a contractor, or a developer who used your domain in a test environment.

The hard cases run in both directions. A cloud key in the personal repository of one of your developers looks damning until you consider that it might belong to their own account. A key committed by someone you have never heard of, in a repository you did not know existed, looks irrelevant until you notice that the surrounding code references one of your internal services. Both are live credentials, and the difference between "critical: escalate now" and "not ours: ignore" is the first thing a reviewer needs to know, and it's the thing most risk scores couldn't reliably answer.

2. How serious is it?

Risk is contextual: an unrevoked production database password sitting in a six-month-old public commit is a different situation entirely from a test API key in a sandbox. A number on a scale of one to 10 collapses that difference into an ordinal, without the reasoning behind it, the triage path that follows from it, or anything an AppSec lead can hand to their team.

Without reliable answers to both, security teams end up choosing between over-triage, which means reviewing everything and burning analyst hours on incidents that were never theirs, and under-triage, which means moving fast enough to miss the ones that were. Neither holds up as the volume grows.

A multi-agent pipeline built for both questions

GitGuardian Public Secrets Monitoring now runs two AI agents over every public incident across GitHub and Docker Hub. A triage agent makes a first-pass assessment of each incident. The most promising cases are promoted to a deep analysis agent for a more thorough investigation. Their conclusions surface in three places:

A company-related verdict

Each incident is marked Related, Uncertain, or Unrelated, with the reasoning available to inspect rather than a probability to interpret. Only the deep analysis agent can confirm a Related verdict, so seeing one means the incident cleared both passes.

An agent-computed risk score

The score reflects what the secret is, where it appeared, and what it can reach. It is set once and does not drift, and anything ruled Unrelated scores zero, so sorting by risk buries the noise automatically.

An Analysis tab

This is the part that changes how a reviewer actually works. The investigation details view lays out how the agents moved from detection to verdict, showing the triage reasoning, the deep analysis where it ran, and the timeline of both. Most tooling in this category hands back a classification and expects it to be taken on trust, which is a difficult thing to ask of a team that will have to justify a credential rotation to an engineering group that did not ask for one. Here the working is shown, so a reviewer who disagrees with a verdict can see which signals produced it and judge whether their own knowledge of the environment outweighs them.

Three saved views arrive pre-configured, covering company-related, unclear if company-related, and not company-related incidents, so teams open a queue that has already been triaged rather than a flat list to work through. Where a verdict misses the mark, a feedback loop lets reviewers flag it, and GitGuardian uses that signal to improve later versions of the analysis.

Agents Analysis is on by default for new Public Secrets Monitoring workspaces, which get the company-related verdict, the risk score, the Analysis tab, and the new saved views immediately. Existing workspaces are being rolled over more gradually, because many teams have workflows built around the previous tags and scoring and should understand what changes before it changes underneath them. The capability is in beta, analysis lands within a day of detection rather than instantly, and customers who want it enabled early can ask their Customer Success Manager.

From detection to action

One enterprise security team managing their GitGuardian incidents through an MCP server integration reported a 10x improvement in productivity. Agent-generated context, meaning the verdict, the reasoning, and the risk score, replaces the manual investigation that used to precede every remediation conversation. The analyst who needs to know whether an incident is theirs and how bad it is now gets that answer delivered alongside the incident instead of going to look for it.

Here, you can read about how we got a CISA GitHub leak down in under a day.

Where the signal matters most

Public Secrets Monitoring has always sat at a specific point in how organizations respond to exposure. Most of the time, a secret that appears in public was exposed internally first, which makes the public alert less a starting point than the earliest external signal that something upstream has already gone wrong.

That makes the triage decision more consequential than it looks, since a false positive costs analyst hours while a missed true positive can mean an attacker reaches the credential first.

Agent analysis makes the signal sharper: less noise to filter, clearer reasoning for the findings that do need human attention, and a faster path from "a secret was disclosed in public" to the internal question that actually matters: where did this come from, and what else is exposed?

AI-driven development built this exposure problem, and the same class of tooling is now what makes it manageable, because exposure arriving at machine speed cannot be triaged at human speed alone. What the GitGuardian platform does is separate the noise from the incidents worth reading. It does not close anything automatically, and that judgment stays with your team.

Find the leaked credentials that are actually yours

GitGuardian Public Secrets Monitoring gives every public incident a verdict, a risk score, and the reasoning behind both.

Join the live webinar.

FAQ

Why are leaked credentials an ongoing problem?

Exposure outlives the commit. Of the credentials GitGuardian confirmed valid in 2022, 64% were still active in January 2026, and credentials for AI services grew 81% year over year to 1.27 million exposed across public code. Revocation rarely keeps pace with the rate of new exposure.

How can businesses detect leaked credentials?

Public secrets monitoring scans public sources such as GitHub and Docker Hub for credentials tied to your organization. At current volume, detection alone is not enough, so a useful system also determines whether the credential is actually yours and how severe the exposure is before anyone reviews it.

Which secrets managers detect leaked credentials?

None, and that is by design. A secrets manager protects credentials you have deliberately placed under management, controlling issuance, rotation, and access. It has no visibility into credentials that were never stored in it, which is precisely the category that ends up in public repositories. Detection is a separate control.

What to do after credentials are leaked?

Confirm the credential belongs to your organization, then revoke or rotate it. Scope comes next: find where else the secret exists internally, since a public appearance can be a downstream symptom rather than the origin. Close the incident once the internal source has been identified and fixed.

OWASP Top 10 CI/CD Security Risks Explained: Why Credential Hygiene Decides the Outcome

Dwayne McDaniel — Thu, 24 Sep 2026 14:59:50 +0000

TL;DR

Credentials are the multiplier: OWASP's Top 10 CI/CD Security Risks cover ten distinct trust failures, but exposed or overprivileged credentials (CICD-SEC-6) make nearly every other risk more dangerous once attackers gain a foothold.
Attacks are accelerating: Since 2025, worms like Shai-Hulud, Miasma, and ChainDrop have compromised hundreds of packages, and GitGuardian's 2026 report found 59% of machines hit in one early wave were CI/CD runners.
Fix starts at the source: GitGuardian's credential layer security spans developer endpoints, source control, and pipelines using ggshield, container scanning, and Developer Endpoint Protection to cut off attacker access before it spreads.

CI/CD pipelines have become a high-value target

Continuous integration and continuous delivery/deployment (CI/CD) systems have a lot of privileged access inside the enterprise. They connect the code developers write to the infrastructure where that code eventually runs. Along the way towards production, they touch source repositories, build systems, package registries, cloud platforms, deployment tools, and secrets. They also carry a lot of risk.

Attackers have noticed and have ramped up attacks since 2025. Many of these malicious campaigns take the form of infostealer attacks via self-propagating worms, such as Shai-Hulud, Miasma, and, more recently, ChainDrop, which compromised hundreds of packages across multiple ecosystems, including some packages with millions of weekly downloads. The 2026 GitGuardian State of Secrets Sprawl Report showed that 59% of the machines compromised in one early wave of these attacks were CI/CD runners.

OWASP built its Top 10 CI/CD Security Risks around defending this critical part of the modern software supply chain.

The project examines how attackers can exploit the systems and trust relationships that move software from a developer workstation to production. It covers 10 different risk areas, but one keeps showing up underneath many of the others: credentials.

A malicious package is much more useful if it can steal a token. A poisoned pipeline is much more dangerous if the job can reach production credentials. Weak access controls become a bigger problem when the identity behind them carries broad standing privilege.

Let's first take a look at the whole list before we examine how lax credential security magnifies the risk.

The OWASP Top 10 CI/CD Security Risks

1. CICD-SEC-1: Insufficient flow control mechanisms

CI/CD pipelines need controls that prevent a single person or compromised account from pushing code or artifacts all the way to production. Without required reviews, approvals, and protected branches, an attacker who gains access to one part of the pipeline may be able to ship malicious changes without anyone finding out until too late.

2. CICD-SEC-2: Inadequate identity and access management

CI/CD environments contain a huge number of human and machine identities spread across source control, build systems, registries, and deployment tools. Overprivileged, stale, shared, or poorly managed identities give attackers more ways into the software delivery process and more authority once an identity is compromised.

3. CICD-SEC-3: Dependency chain abuse

Attackers can manipulate how build systems and developer machines retrieve dependencies, causing malicious packages to be downloaded and executed instead of trusted ones. Techniques such as dependency confusion, package hijacking, typosquatting, and brandjacking can turn a normal dependency installation into an entry point for credential theft, lateral movement, or malicious code.

4. CICD-SEC-4: Poisoned pipeline execution (PPE)

An attacker with access to source control may be able to change pipeline configuration files, scripts, tests, or other files that the build process executes. When the pipeline runs those changes, the attacker effectively gains the build job's role and permissions, potentially exposing credentials, infrastructure, and production deployment capabilities.

5. CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)

Build pipelines often need powerful access to source code, credentials, registries, infrastructure, and deployment environments to do their jobs. If that access is not tightly scoped to individual pipelines and stages, malicious code running inside a build can use those permissions to steal data, move laterally, or deploy malicious artifacts.

6. CICD-SEC-6: Insufficient credential hygiene

CI/CD systems depend heavily on secrets and tokens, which can end up exposed in source code, build logs, container layers, environment variables, or poorly protected pipeline configurations. Long-lived, overly permissive, and poorly managed credentials give attackers usable access that can extend from development systems all the way into production.

7. CICD-SEC-7: Insecure system configuration

Every SCM, CI server, artifact repository, runner, and deployment platform brings its own security settings, network controls, permissions, and patching requirements. Weak defaults, outdated software, excessive privileges, or exposed services can give attackers an easy foothold and a path toward credentials, build processes, and production systems.

8. CICD-SEC-8: Ungoverned usage of 3rd party services

CI/CD environments frequently connect third-party apps, plugins, actions, and external services directly to engineering systems. Without visibility and governance over what these services can access, every integration can expand the organization's attack surface and inherit powerful permissions into code, pipelines, and credentials.

9. CICD-SEC-9: Improper artifact integrity validation

Organizations need a reliable way to prove that code and artifacts moving through the pipeline have not been modified or replaced along the way. Without signing, verification, hashes, or other integrity controls, a malicious artifact can potentially move through trusted delivery processes and arrive in production looking legitimate.

10. CICD-SEC-10: Insufficient logging and visibility

Security teams need visibility into both human and programmatic activity across source control, CI systems, registries, and deployment infrastructure. Missing or disconnected logs can allow attackers to operate undetected and leave defenders without enough evidence to understand what happened, what was accessed, or how far the compromise spread.

The common thread: attackers abusing trusted access

Step back from the individual risks and a larger pattern starts to emerge. This list is anchored on preventing attackers from abusing trust.

CI/CD systems exist to take trusted instructions and turn them into real actions, often with very little human involvement. They merge code, run builds, pull dependencies, create artifacts, access infrastructure, and deploy into production. That makes the pipeline incredibly powerful, and it means an attacker does not necessarily need to break into production directly. They just need a way into something the pipeline already trusts.

That access can take many forms. A compromised developer account can push malicious code. A poisoned dependency can execute on a build runner. An overprivileged pipeline, misconfigured service, ungoverned third-party integration, or unverified artifact can then give that initial foothold somewhere to move laterally. Insufficient logging compounds the problem by allowing that abuse to continue without defenders clearly seeing what the attacker is doing.

CI/CD security is fundamentally about controlling who and what can exercise authority inside the software delivery process.

The risks describe different paths in, different trust failures, and different ways an attacker can move through the system, but the danger is attackers stealing legitimate access to code, systems, infrastructure, or deployment paths.

If defenders want to reduce the impact of many of these risks at once, they need to look closely at what grants that authority, how far it reaches, and how easily an attacker can turn it against them.

Why credential hygiene is the lynchpin of CI/CD Security

Right in the middle of the list is CICD-SEC-6, Insufficient Credential Hygiene. This makes sense as credentials are what turn access into authority.

CI/CD environments are full of secrets, tokens, deploy keys, service account credentials, cloud keys, registry credentials, and API tokens that allow one system to talk to another and keep the delivery process moving. OWASP calls out how widely these credentials are spread across repositories, pipelines, build processes, artifacts, logs, and production deployment workflows. Once an attacker gets hold of one, they are no longer just standing inside the pipeline. They may have a legitimate way to act as something the organization already trusts.

That makes poor credential hygiene a force multiplier for many of the other risks on the list, and OWASP explicitly connects several of these risks to overly permissive identities, pipeline permissions, and credentials that can be accessed from the wrong context. Weak IAM becomes far more dangerous when an overprivileged identity has a long-lived token attached to it. Insecure system configuration can expose default credentials or permissive tokens, while third-party services can become pathways to the secrets they have been granted. Even weak flow controls become more damaging when the attacker already possesses the credentials needed to move code or artifacts farther down the delivery chain.

Credentials deserve special attention here, as they are often what let an attacker turn an initial foothold into persistence, lateral movement, data access, or deployment authority, making finding, controlling, and eliminating exposed standing credentials one of the highest-leverage places to start.

GitGuardian's credential layer security reduces risk across the CI/CD attack surface

Getting credential hygiene right has an outsized impact because it takes away one of the main things attackers need to turn a CI/CD foothold into a larger compromise: usable authority. If the path an attacker takes does not lead to an exposed, long-lived, or overly powerful credential, it becomes much harder for malware, a human attacker, or a rogue AI agent to move from that initial compromise into another system. Addressing CICD-SEC-6 therefore helps reduce the blast radius of several other risks on the OWASP list at the same time.

That is the idea behind credential layer security.

GitGuardian is a credential-layer security platform built to protect credentials across developers, repositories, pipelines, build systems, cloud services, and production infrastructure. Those credentials rarely stay neatly within one tool, and protecting them requires visibility into both where credentials should exist and where they have leaked, been copied, or are being used.

Detecting secrets is the first step, then add context

The GitGuardian platform's native source integrations can continuously monitor GitHub, GitLab, Bitbucket, and Azure DevOps, including historical code, while container scanning extends detection into images where credentials can survive the build process.

Inside the pipeline itself, ggshield, the GitGuardian CLI, gives teams a way to make credential detection part of CI/CD execution. ggshield can scan commits and changes as builds run in GitHub Actions, GitLab pipelines, Jenkins, CircleCI, Azure Pipelines, Bitbucket Pipelines, and other common CI systems. Teams can make that scan an actual control point in the delivery process. In GitHub Actions, for example, the GitGuardian scan can be configured as a required status check so a pull request containing a detected secret cannot move forward until the problem is addressed.

GitGuardian can also connect to the systems where non-human identities and their credentials are created, stored, and consumed. Through NHI Governance, integrations with secrets managers, including HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, and others, help show every team where credentials are stored and whether they are where they are supposed to be. This connection to vaults works both ways, empowering GitGuardian's Push-to-Vault functionality.

CI and infrastructure integrations with GitHub Actions, GitLab CI, and Kubernetes help show where those identities are actually being used. Cloud IAM integrations with AWS IAM and Microsoft Entra ID can then add context about the permissions associated with discovered credentials and the potential blast radius if one is exposed.

Knowing that a string in a repository looks like an AWS key is useful. Knowing that the credential is valid, is being consumed by a production pipeline, maps back to a particular non-human identity, carries powerful permissions, and is or is not properly represented in a secrets manager gives defenders a much clearer picture of what needs attention first. GitGuardian's NHI integrations are designed to inventory these identities and add context around their usage, scope, lifecycle, and security posture rather than leaving every secret finding as an isolated alert.

An ounce of credential prevention is worth a pound of leakage cure

The same detection and protections can start before CI/CD ever gets involved. Developers can use ggshield through pre-commit, pre-push, and pre-receive hooks, as well as integrations with development environments such as VS Code, Cursor, and Windsurf. GitGuardian has also extended these guardrails into AI-assisted development, where ggshield hooks can inspect activity from tools such as Cursor, Claude Code, and GitHub Copilot before credentials get passed into an AI workflow or pushed farther down the software delivery chain.

Developer Endpoint Protection extends that coverage even farther left, onto the machines feeding code into or running the CI/CD tooling in the first place. Developer laptops and on-prem machines can accumulate credentials in .env files, shell histories, cloud profiles, CLI caches, IDE configurations, MCP configurations, and AI agent histories that may never appear in a repository. GitGuardian can deploy endpoint scanning through existing MDM tools such as Intune, Jamf, and Kandji, identify those credentials locally, and feed the resulting findings into the same security workflows. Honeytokens can also be planted on developer machines to provide a tripwire when an infostealer or other attacker starts harvesting credentials from an endpoint.

Put these pieces together and the larger GitGuardian platform strategy starts to come into focus. Detect exposed credentials across the places developers, pipelines, and machines actually work. Add context from CI/CD, infrastructure, secrets managers, and IAM to understand the identities and authority behind them. Remediate the credentials that create real risk, then prevent new exposures closer to where they originate.

GitGuardian's platform brings those motions together around the credential layer instead of asking security teams to manage every repository, pipeline, developer endpoint, vault, and identity system as a completely separate problem.

Turn credential hygiene into CI/CD resilience

The OWASP Top 10 shows how many different ways attackers can get into trusted software delivery paths and abuse the access already there. Credential hygiene helps limit what happens next. A poisoned dependency, compromised developer, or malicious build step is far less dangerous when it cannot reach a valid credential that opens another door.

That gives teams a very practical place to make progress. By finding exposed credentials across developer endpoints, repositories, pipelines, images, and connected cloud and identity systems, then removing, constraining, or preventing that access, organizations can reduce the blast radius of many CI/CD attacks at once.

The goal is not to slow CI/CD down. It is to keep all that automation and connectivity working while making the credential layer stronger, safer, and much harder for attackers to abuse.

FAQ

How does the OWASP CI/CD Top 10 differ from the classic OWASP Top 10?

The classic OWASP Top 10 focuses on risks in web applications. The CI/CD Top 10 looks at the engineering systems and trust relationships that build and deliver those applications, including source control, build systems, dependencies, artifacts, identities, and deployment pipelines.

Why is insufficient credential hygiene so important in CI/CD?

CI/CD systems need credentials to interact with repositories, registries, cloud environments, and production systems. If those credentials are exposed, overprivileged, or long-lived, an attacker who compromises another part of the pipeline can use legitimate authority to keep moving.

What is Poisoned Pipeline Execution?

Poisoned Pipeline Execution happens when an attacker changes a pipeline configuration or another file the pipeline trusts so malicious commands execute inside the build environment. The impact depends heavily on what credentials and resources that pipeline can access.

How can teams improve credential hygiene in CI/CD?

Start by continuously finding credentials across code, Git history, pipelines, artifacts, logs, and developer environments. Limit each pipeline to the credentials it actually needs, prefer temporary access where possible, validate and prioritize exposed credentials, and rotate or revoke static credentials with enough context to avoid breaking production.

Credential Security: What Endpoint Protection Really Means for Secrets

Dwayne McDaniel — Wed, 23 Sep 2026 17:30:21 +0000

TL;DR

"Endpoint protection" is often heard as EDR: When buyers hear "endpoint," they think antivirus or EDR. Antivirus started as signature-based malware detection; EDR added continuous behavioral monitoring and response. Both are designed to detect and stop malicious activity on the machine.
Credential security asks a different question: Neither antivirus nor EDR can tell you which valid credentials are exposed on a machine right now. That's credential security.
A mature program needs both: EDR asks whether something malicious is happening. Credential security asks which secrets are exposed - and, just as importantly, helps you fix them by rotating, redacting, and preventing that exposure, not just inventorying it.

This article draws the line between the two and explains why a mature endpoint program runs both.

Why "endpoint" is a loaded word

For two decades, endpoint protection meant detecting malicious activity. Antivirus came first, then EDR, and finally, XDR. The whole lineage is about malware and behavior. When a new tool says "endpoint," buyers reasonably hear "EDR agent."

But the endpoint holds something this lineage was never built to protect: the credentials themselves. Cloud keys, API tokens, and SSH keys sit in plaintext across developer machines, in .env files, shell history, CLI caches, and increasingly, AI tool directories.

Protecting your machines from malicious activity and knowing which secrets are exposed on them are two different jobs. And the second one needs its own control.

That's why GitGuardian launched Developer Endpoint Protection. The Developer word is deliberate: this is the credential layer of the developer machine, not another behavioral agent for the fleet.

What EDR does, and does well

EDR is continuous behavioral monitoring and response on the endpoint. It watches processes, memory, file operations, and network activity, then detects and contains malicious behavior.

What EDR catches: EDR catches ransomware, fileless and living-off-the-land attacks, lateral movement, and credential-theft behavior, like a process reading LSASS memory.
Where EDR sits: EDR is positioned as the behavioral detection and response layer of the endpoint. Every mature security program should run it.

Some EDR and identity platforms have expanded into credential-adjacent features. CrowdStrike's Falcon Identity Threat Detection and Falcon Identity Threat Protection surface weak or exposed identity credentials, detect authentication anomalies, and flag dark-web credential exposure. Microsoft Defender for Identity covers similar ground. CrowdStrike's Falcon Cloud Security also scans container images and IaC files for secrets, though without a published detector methodology, liveness validation, or remediation workflow, it functions as a checklist item rather than a mature credential security capability.

These features share a structural limitation: they key off domain email addresses and managed identity systems like Active Directory, Entra ID, and cloud IAM. A hardcoded AWS key, GitHub token, or SSH key carries no domain email address. When domain email attribution is missing, these tools have no way to track the credential. Hardcoded developer secrets fall structurally outside what they're built to see.

CrowdStrike sees the malware and, increasingly, who owns the identity. GitGuardian sees the credential that shouldn't exist in the first place.

What credential security does

Credential security is the control that covers the credential plane on the endpoint. It has three functions: discovery, remediation, and deception.

Discovery runs on a schedule. Periodic scans build a timestamped record of which valid secrets are present on a machine over time.

These secrets include cloud keys, tokens, and SSH keys in .env and config files, shell history, and CLI or AI tool caches. At GitGuardian, we also include credentials in environment variables and memory at scan time to ensure we capture every potential secret on a device.

Findings are scored by machine, severity, and validity, then routed for remediation: local redaction from the developer's machine for lower-risk findings, escalation to the incident workflow for confirmed-leaked or high-privilege credentials.

Deception is the third function, and the only one that fires in real time. Honeytokens are decoy credentials planted where harvesting tools look. Any attempt to use one alerts immediately, so you learn the instant someone acts on an exposed secret rather than only that it exists.

Together the three functions cover the credential plane the way detection and response cover behavior: discovery establishes what is exposed, remediation reduces it, and deception catches anyone reaching for what remains.

"Credential security" on the endpoint isn't a named analyst category the way EDR and XDR are, at least, not yet. In our opinion, it's a distinct endpoint function that the market still needs to carve out and label.

The core difference: Behavior vs. the credential plane

A valid exposed credential is neither malicious nor anomalous on its own. An attacker who uses it looks like a legitimate user. EDR can sometimes catch the harvesting act, a process exhibiting infostealer behavior on the endpoint. What it can't catch is the use of the stolen credential afterward, which looks like a normal login from a different machine. Credential security closes the front end: finds the credential before it's taken.

	EDR	Credential security
Question asked	Is something malicious happening on this machine?	What exposed secrets are on this machine right now?
What it watches	Processes, memory, files, and network activity (continuously)	Secrets at rest across files, caches, history, and configs (scheduled)
What it catches	Ransomware, fileless and living-off-the-land attacks, lateral movement, credential-theft behavior like memory dumping	Valid exposed credentials before they're used, scored by machine, severity, and validity
What it doesn't see	A plaintext key in a config file, EDR sees the file, but cannot parse its contents for credential values	Malicious runtime behavior
Best for	Detecting and containing malicious activity on the host	Finding and revoking exposed credentials before an attacker can access them

Why the credential plane needs its own control now

The scale of the problem is what makes it urgent. GitGuardian's Developer Endpoint Protection launch data found roughly 15 times more valid secrets on developer endpoints than in the repositories those same teams already scan, an average of about 150 per machine. The surface most security teams have never inventoried holds far more live credentials than the one they have.

It is also growing fastest where coverage is thinnest. In the last three months, 59% of endpoints scanned held at least one secret written by an AI coding agent, and around 40% of high and critical secrets surfaced in AI tool directories and log files, away from repo scanners. Some AI coding tools don't support .env credential isolation, so secrets have to live in plaintext config files. The developer can't prevent that. They can only inventory and monitor it.

These credentials are also long-lived. Of the credentials that were valid in 2022, over 64% were still valid when retested in January 2026, so an exposed secret is rarely a stale one.

That matters because stolen valid credentials grant legitimately authorized access. The attacker using one looks like a normal user, not an intruder. Behavior-based tools can't always catch this: infostealers harvest credentials from the endpoint and take session tokens that are already authenticated, sidestepping MFA, and none of that has to look malicious. Sophisticated infostealers go further and operate through legitimate system tools, so a stolen session token in use is indistinguishable from an authorized login. The controls built to catch this kind of anomaly, like role-based access control and conditional access policies, are often missing or only partially configured, which widens the gap further.

During an incident: The credential-plane view

When a machine is compromised, the security team needs to answer three questions quickly: which credentials were exposed, what does the attacker now have access to or control over, and what needs to rotate first. That scoping has to be complete before any rotation starts: if three credentials get rotated while three more stay live, the attacker can dig in for persistent access before the team finishes evicting them. Complete visibility first means remediation happens in one pass instead of tipping them off.

If the solution is deployed before the incident, the credential record is waiting the moment the team needs it, and that's the right posture. Deployed in the first 48 hours of a confirmed compromise, before shell history rolls and temp files clear, it still captures most of what matters. The further from the incident, the more ephemeral the evidence becomes.

When used together, EDR will tell you what happened on the host while the credential-plane inventory will tell you what was there to take. This combination shortens the path from detection to containment.

What good looks like: Covering both questions

A mature endpoint program answers both the behavioral and credential-plane questions to maximize security potential. Here's what that looks like in practice.

Run EDR for behavior: Keep EDR as the behavioral detection-and-response layer. To succeed at this step, ensure full EDR coverage across your entire fleet.
Run scheduled credential discovery: Scan every endpoint on a regular cadence. The output is a ranked list: what to rotate immediately, what to remediate over time, and what to accept and monitor with a honeytoken alongside it.
Add honeytokens as the deception layer: Plant decoy credentials in the locations where infostealers look. Any attempt to use one fires a high-fidelity alert with near-zero false positives.
Connect findings to the identity map. A credential found on 12 machines that also appears in a secrets manager is a different risk signal than one on a single laptop. Routing endpoint findings through the GitGuardian dashboard surfaces that pattern automatically and routes it to the right team.
Unify the response: Route behavioral alerts and credential findings into one incident workflow. To succeed at this step, confirm that both signals land in the same queue with shared context. That way, every team member works from the same information.

How GitGuardian fits

GitGuardian Developer Endpoint Protection is the credential security layer on endpoints. It's one capability in the broader GitGuardian platform, alongside Internal Secrets Monitoring, Public Secrets Monitoring, and NHI Governance. Each helps protect secrets.

Developer Endpoint Protection scans the locations where credentials accumulate on the machine, on a schedule deployed through your existing MDM (Intune, Jamf, or Kandji). It then scores each finding by machine, severity, and validity and surfaces results as a prioritized, deduplicated list. You can also disseminate honeytokens that fire the moment an attacker attempts to use a harvested credential. Developers can redact secrets from their machines directly from the dashboard.

In addition, GitGuardian's CLI, ggshield, runs the endpoint secret scanning process locally, and only hashed metadata leaves the machine, never the secret value or the source files.

Developer Endpoint Protection isn't an EDR or an antivirus. It answers the credential-plane question and complements EDR and XDR. It doesn't replace them.

Two questions, one endpoint

The credential surface keeps growing. Every new AI workflow is a new credential surface, and none of it shows up in behavioral telemetry. The teams that answer the blast radius question fast: which credentials were on the compromised machine, what an attacker can reach, and what rotates first, built the inventory before they needed it. They didn't start from zero.

Find the credentials sitting on your endpoints

FAQ

Is credential discovery the same as EDR?

No. They're different controls that share the same endpoint. EDR is behavioral detection and response. As such, it watches activity and detects malicious behavior. Credential discovery is a point-in-time inventory of the valid secrets exposed on the machine, scored and ready to revoke. The first acts on behavior, while the second acts on the exposed state.

Does endpoint security mean antivirus?

Not only. Antivirus and its successor, EDR, protect the machine from malicious code and behavior. Endpoint security for secrets also means knowing which credentials are exposed on the device. It's a different job that antivirus and EDR were never designed to do.

Can EDR find secrets on a developer machine?

Not as its core purpose. EDR watches process and system behavior. It can detect a process stealing credentials, but it doesn't inventory the plaintext secrets that sit at rest in config files, caches, and history. This kind of inventory is what credential discovery provides.

Does EDR detect exposed credentials?

EDR detects credential-theft behavior, like a process reading memory to dump credentials. Some EDR and identity platforms also flag weak or exposed identity accounts and dark-web exposure. None of them enumerate the plaintext API keys, tokens, and SSH keys sitting in files on a developer's disk. Finding those at rest is credential discovery's job.

What's the difference between EDR and secrets detection?

EDR is behavioral detection and response on the endpoint. Secrets detection, also known as credential discovery, finds the exposed secrets on the endpoint. Put simply, one watches what's happening while the other inventories what's present. Mature programs use both.

Do I need EDR and credential discovery?

Yes, if you want both endpoint questions answered. EDR catches malicious behavior. Credential discovery finds the exposed credentials that an attacker would use. They each cover different risks in the same place, so they work together instead of one substituting for the other.

What does "endpoint" mean for secrets security?

It means the developer machine as a place where credentials accumulate, not only a place to defend against malware. Endpoint security for secrets is about discovering and revoking the exposed credentials on the device, alongside the behavioral protection that EDR provides.

AWS S3 Bucket Security: Find the Secrets Hiding Outside Git

Dwayne McDaniel — Tue, 22 Sep 2026 12:33:32 +0000

AWS S3 Bucket Security: Find the Secrets Hiding Outside Git

S3 buckets have quietly become a credential blind spot: years of logs, backups, and pipeline output that nobody ever scans for secrets. In one 2025 incident (Sysdig), attackers reached admin access in eight minutes using IAM keys found in a public bucket.

TL;DR

The Blind Spot: S3 buckets accumulate years of logs, backups, and pipeline output that never get scanned for secrets, and 28% of incidents now originate entirely outside code repositories.
The Attack Speed: Attackers used IAM credentials found in a public S3 bucket to reach admin access in just eight minutes, with AI accelerating the reconnaissance.
The New Coverage: GitGuardian now scans AWS S3 buckets, including supported ZIP and tar.gz archives, for exposed credentials and routes findings into existing incident workflows.

AWS S3 bucket security usually starts with the infrastructure around the bucket. Teams spend enormous effort blocking public access, encrypting data, and monitoring cloud activity. Good cloud security is essential, as S3 buckets end up holding a lot of valuable stuff.

Organizations, as they have shifted to become more cloud native, have spent years piling logs, backups, and pipeline output into Amazon S3. Snapshots and infrastructure artifacts accumulate there too. Much of that data never passed through any kind of secret scanning. It is anyone's guess which credentials live there.

For the teams accountable for cloud or application security, that is a serious visibility problem. They need to find and remediate any exposed secrets quietly surviving in some overlooked corner of their real environment.

Attackers know this, and AI is making discovery faster and easier.

For example, in late 2025 Sysdig observed an attacker gain initial access to an AWS environment using valid IAM credentials discovered in public S3 buckets containing RAG data for AI models. Sysdig found multiple indicators that the attacker used LLMs throughout the operation to automate reconnaissance, generate malicious code, and make decisions as the attack unfolded. The attacker reached administrative privileges within eight minutes.

GitGuardian researchers have documented the same broader pattern in cloud attacks involving groups such as Crimson Collective. Exposed AWS credentials provided initial access. Attackers then authenticated, enumerated infrastructure, collected available data, and used AWS cloud infrastructure and storage during collection or exfiltration. Their focus on high-privilege credentials shows how quickly a leaked secret can become a bridge into a much larger cloud environment.

This is exactly why GitGuardian now scans AWS S3 buckets for exposed secrets and brings those findings into the same discovery and incident workflows security teams already use across their monitored perimeter.

What is Amazon S3 bucket security?

AWS recommends a layered approach to securing S3 buckets. That includes blocking unintended public access, enforcing least-privilege IAM permissions, and disabling ACLs where possible in favor of policy-based access controls.

They also recommend teams encrypt data at rest, require encrypted connections, enable logging, and continuously audit bucket configurations and external access. Services such as GuardDuty and Macie add monitoring for suspicious activity and sensitive data exposure.

These controls strengthen the security posture around the bucket. Secret scanning extends that coverage into the objects themselves by identifying credentials that could provide access to other systems.

Credential discovery addresses another layer of security

A private bucket can contain an active API key. A correctly scoped read-only role can still retrieve an archive holding a database password. A compromised workload identity inherits access to every object its legitimate permissions allow it to read.

Cloud posture tells you whether an identity should be able to retrieve an object. Secret scanning tells you whether retrieving that object gives the identity another credential.

For organizations trying to achieve complete credential visibility, both questions belong in the AWS S3 bucket security conversation.

S3 became a credential blind spot as cloud environments grew

Source code is an obvious place to begin secrets detection. Developers accidentally commit API keys, passwords, and tokens. Git history preserves those mistakes. Security teams responded by adding secret scanning to repositories and developer workflows.

As organizations create more applications, their cloud footprints expand too. For AWS users, that often means adding new buckets while continuing to fill old ones.

Applications write increasing amounts of operational data to S3. CI/CD systems produce artifacts and logs. Infrastructure teams store state files and backups. Many organizations accumulate years of this data without applying credential-specific scanning to the contents.

A CI process can write a credential into a log. A backup job can preserve an .env file. Terraform state can contain sensitive values that never appeared in a repository. S3 then gives those files longevity.

AI adds scale to the discovery side of that equation. Agents and AI-assisted tooling can increasingly inspect large amounts of unstructured data, determine which objects appear relevant to a goal, and continue acting on what they find. For an attacker using AI assistance, that same general capability can accelerate reconnaissance for credentials and paths to additional access.

The GitGuardian State of Secrets Sprawl 2026 found that 28% of secret incidents originate entirely outside source code repositories. Those incidents were also 13% more likely to be critical than code-only incidents.

"We scan all our repositories" describes one part of credential coverage. Teams and security leaders increasingly need to answer a broader question: Where else can a usable credential exist in our environment, and can we prove we are looking there?

Attackers and AI agents can search the environment after they get access

The Sysdig story gives us a useful view of what happens when that visibility gap works in the attacker's favor. The first credential became a discovery mechanism for the rest of the environment.

A goal-directed system with AWS credentials, command-line access, or cloud APIs can reason over the capabilities available to it. If S3 is accessible and the goal requires finding useful data, configurations, credentials, or another path forward, searching buckets is a logical action to take.

Modern cloud-focused threat actors already identify exposed credentials at scale and test which ones remain valid. AI reduces the amount of human effort required to connect those steps. Valid secrets can lead attackers, malware, and autonomous agents to more valid secrets.

Security teams need the ability to perform that discovery, fast and at scale.

AWS S3 secret scanning starts by finding what is already there

GitGuardian's AWS S3 integration is built around discovery.

Teams select the buckets they want included in their monitored perimeter and trigger a historical scan. GitGuardian analyzes the existing objects and uses its secrets detection engine to identify exposed credentials. Findings become regular incidents inside GitGuardian.

Historical scanning is especially important for object storage. An S3 bucket may contain years of accumulated data. An initial historical scan can therefore surface a significant backlog of credentials that require triage.

A useful first pass might prioritize:

Backup buckets containing historical application data or configuration
CI/CD and logging buckets holding build output or runtime logs
Infrastructure buckets containing Terraform state or archived deployment artifacts

GitGuardian also scans supported archives, which extends discovery below the object visible in the S3 console. A credential stored inside a supported ZIP or tar.gz archive can still surface as an incident.

The goal is complete visibility into the credentials stored across the environment. Once discovered, teams can determine whether a secret remains valid, understand its context, establish ownership, and prioritize remediation through the same workflows used for secrets found elsewhere.

Discovery is the foundation of credential layer security

Credential layer security starts with knowing where credentials exist. Every subsequent security decision depends on that visibility.

You need discovery before you can remediate a rogue credential to your crown jewels, tucked away in that forgotten storage blob. You need to find it before you can determine ownership. You need context before you can understand its blast radius or decide how urgently it should be dealt with.

AWS is already building toward a world where agents can discover organizational knowledge across object stores and other enterprise systems while carrying out multi-step tasks. That makes complete credential discovery more urgent. Security teams need confidence that the data made accessible to automated systems does not quietly contain reusable credentials.

Credential layer security requires visibility across the places credentials actually live. Adding S3 to the monitored perimeter closes another major discovery gap and helps security teams prove that their credential coverage reflects their real infrastructure.

Add AWS S3 to your GitGuardian coverage today, or start with GitGuardian and begin closing credential blind spots across your credential layer.

FAQ

What is AWS S3 bucket security?

AWS S3 bucket security is the combination of access controls, data protection, monitoring, and security practices used to protect Amazon S3 resources and their contents. Common controls include S3 Block Public Access, least-privilege IAM policies, encryption, logging, and continuous configuration review. Secret scanning extends that visibility into the objects themselves by identifying exposed credentials that could provide access to other systems.

What is the right way to secure an S3 bucket?

Strong S3 security starts with blocking unintended public access and limiting each identity to the permissions its workload requires. Organizations should encrypt data, monitor activity, and regularly audit policies and external access. Securing S3 buckets also requires visibility into sensitive credentials stored inside their objects, since historical secret scanning can reveal exposure that configuration reviews cannot see.

What are the AWS S3 bucket security risks?

AWS S3 bucket security risks include public exposure, overly broad permissions, compromised AWS identities, and sensitive information stored within accessible objects. Exposed secrets can increase the impact of an initial compromise: attackers or AI-assisted tooling that retrieves a log, backup, or infrastructure file containing another valid credential may gain a path into additional systems.

How does AI change AWS S3 security risk?

AI systems increasingly use tools and retrieval mechanisms to find information across enterprise data sources, including object storage. An agent with excessive permissions, a compromised credential, or attacker-directed goals can use that access to inspect available cloud data. Secret scanning helps organizations discover reusable credentials before automated systems encounter them.

Can a private S3 bucket still contain exposed secrets?

Yes. A private bucket limits who can retrieve its contents, but credentials can still exist inside those objects. Any legitimate or compromised identity with sufficient read permissions may be able to retrieve those credentials. Secret scanning helps security teams discover that exposure before access to the bucket becomes part of an incident.

Why is secret scanning important for credential layer security?

Credential layer security depends on knowing where credentials exist across the real environment. Secret scanning provides the discovery required to identify exposed credentials, investigate their context, and prioritize remediation. Extending that visibility into AWS S3 helps cover cloud data that may never have entered source control.

AI Agent Threat Response: Why Pre-Runtime Controls Matter More Than Runtime Detection

Dwayne McDaniel — Mon, 21 Sep 2026 12:43:39 +0000

AI Agent Threat Response: Why Pre-Runtime Controls Matter More Than Runtime Detection

AI agent threat response starts before runtime. See why pre-runtime credential controls stop agent misuse that runtime detection can only observe.

TL;DR

AI agent threat response has layers. Runtime detection watches agents in motion and catches prompt injection, goal hijacking, memory poisoning, and suspicious tool chains. Preventative, pre-runtime controls limit what credentials, systems, and authority an agent can reach before execution begins.
Valid credentials within an agent's reach changes the response window. An agent using a legitimate API key can look completely normal until the surrounding sequence reveals something dangerous. At machine speed, that means detection may happen only after the credential has already been exercised, which is why exposed access has to be reduced before runtime.
Mature programs address both layers, in the right order. Inventory agents and MCP servers, discover and remediate exposed credentials, enforce AI guardrails, and use honeytokens as tripwires. Then pair those controls with runtime detection for the manipulation and behavior you cannot predict in advance.

Why "AI agent threat response" means two different conversations

There are only two possible times anyone could implement a security plan. First is after something bad has already happened, when you're reacting in real time to a breach, data theft, or some other security event. The other is before that moment, when you put security controls around what systems exist, what they can access, and what any single action could do. This is always going to be true. What has changed with AI is the time scale.

AI speed in security is good in some respects, as AI-assisted SOC analysis and machine-speed response give defenders a better chance of keeping pace with attackers who themselves are constantly moving faster due to automation and AI. Runtime detection is a necessary part of modern security, and we absolutely need faster analysis to limit the blast radius and tell us when to reboot machines.

What is AI agent threat response

AI has had a serious impact on security by giving teams a new surface to worry about. In short, AI agent threat response is about reacting to and mitigating the risks AI poses to enterprise ecosystems. While this in part means monitoring for rogue behavior in the local sandbox or contained environment, the wider concern is about the impact AI agents can have on the rest of the environment.

AI agents can access many other systems because they run on developer laptops, which have historically held access keys to all sorts of internal systems. GitGuardian's research into Shai Hulud and other infostealing campaigns has shown just how many secrets live on the average developer's laptop, with more than 10 valid plaintext credentials exfiltrated from over 44% of developer laptops.

AI agent threat response, in part, means securing what actions and systems the AI can reach with those credentials. If you wait until after something bad has happened, at machine speeds, that is far too late.

We need to shift our balance toward prevention rather than reaction.

Runtime detection can tell us when an agent is doing something dangerous or has already done something dangerous. Perhaps a more important question for security is: "What the agent was allowed to reach before that alert ever fired?" When an agent holds valid credentials and can autonomously use them to access or exfiltrate data, what does response even really mean?

What runtime detection does well when it comes to AI agents

Before we continue, let's clarify: Runtime detection is still an important part of securing autonomous agents, especially when those agents can reach production systems. These platforms, such as CrowdStrike's Falcon AIDR, Palo Alto Networks Cortex, and SentinelOne Singularity, monitor agent sessions, prompts, tool calls, memory interactions, and action sequences to identify behavior associated with prompt injection, goal hijacking, memory poisoning, tool misuse, and other forms of manipulation. Many of these approaches increasingly map detections to the OWASP Agentic AI Threats and Mitigations taxonomy, which provides a common way to describe threats across agentic systems.

One value of this approach is catching when several individually legitimate actions combine into something dangerous. A coding agent might normally be allowed to read files, execute commands, and make HTTP requests. A sequence such as read .env → extract credential → send HTTP request gives the runtime layer enough behavioral context to recognize potential tool misuse or goal hijacking.

The same approach can identify an agent whose behavior changes after reading malicious content, poisoned memory influencing a later decision, or one compromised agent passing manipulated instructions downstream. Runtime detection gives teams visibility into how those threats actually appear while the agent is operating.

Basically, these tools answer "What is this agent doing right now, and does that behavior make sense?" However, AI agents are non-deterministic by nature, so it is hard to predict and account for every conceivable path or action they could take. From the security standpoint, it means we need to do more than monitor and react.

The gap: a valid credential in an agent's hands looks legitimate

Runtime detection is a real challenge when an agent is using legitimate access exactly as designed. If an agent reads a plaintext API key from an .env file or from an MCP call, and then uses that key to call an authorized API, every individual step can look normal. The credential works and the request is well-formed. Tool use may fall squarely within the agent's expected behavior so no alarms are sounded.

By the time the system has enough evidence to decide the behavior is dangerous, the agent may already have exercised the credential and reached the system behind it.

Machine speed changes the response math

AI agents shrink the time between credential discovery and credential use. A human attacker may pause to inspect what they found, choose a target, and decide what to do next. An agent can move directly through a "read-decide-act" loop and repeat that process across multiple tasks.

GitGuardian's State of Secrets Sprawl 2026 found 24,008 unique secrets in public MCP configuration files, including 2,117 valid credentials, while AI-service credential leaks increased 81% year over year. Supply chain incidents show the same compression from credential harvesting toward potential abuse, including Shai-Hulud-style campaigns that demonstrated how automated compromise can spread through trusted developer infrastructure.

Runtime detection still plays an essential role, including detecting suspicious harvesting through behavioral signals or deception such as honeytokens. Agent speed changes the response window, though, because detection may happen only after a credential has already been used.

Security teams need to put controls in place before that credential can be used, rather than relying on intervention after suspicious behavior has already executed.

Pre-runtime controls: shrink what an agent can do before it runs

Proactive security controls, implemented pre-runtime, reduce the agent's attack and abuse surface before a prompt, tool call, or credential becomes a runtime event. It starts with inventorying the agents and MCP servers running across developer environments, including what they connect to and who owns them. From there, teams need to discover the credentials within their reach, including secrets in .env files, MCP and IDE configurations, shell history, CLI caches, and AI tool data. GitGuardian's research into endpoints found that around 40% of high and critical secrets surfaced in AI tool directories and log files.

Discovery only tells you what is exposed. The next step is remediation: revoking, rotating, or right-sizing any risky credentials before an agent has a chance to use them. GitGuardian found that more than 64% of credentials confirmed valid in 2022 were still valid when retested in January 2026. Reducing that standing access limits what an agent can reach even when every individual action looks legitimate.

Security and development teams need to embrace guardrails and tripwires wherever agent behavior meets credentials. Policy controls via IDE tools can stop secrets from being included in prompts, read during tool execution, or transmitted through agent workflows before the action completes. Honeytokens add a complementary signal by showing when something actually reaches for a credential.

Pre-runtime vs runtime: two layers, one timeline

Pre-runtime controls and runtime detection answer different security questions, and both belong in a complete AI agent security strategy.

Pre-runtime controls act before execution — inventory, revocation, guardrails, honeytoken placement. They catch exposed valid credentials, over-scoped agent identities, unknown agents and MCP servers, and harvest attempts via honeytokens. They don't see live behavioral manipulation of a running agent. Failure cost: an agent runs with more reach than anyone intended.

Runtime detection acts during execution, monitoring sessions, tool calls, and behavior continuously. It catches prompt injection, goal hijacking, memory poisoning, anomalous tool chains, and role or authority drift. It doesn't see a valid credential sitting readable in an agent config before any session starts. Failure cost: detection fires after actions already executed at machine speed.

Threat modeling the agent credential plane

The OWASP Top 10 for Agentic Applications 2026 explicitly calls out agents misusing legitimate tools and leaked credentials, allowing agents to operate beyond their intended scope. Preventive credential controls reduce those risks by removing or constraining the access an agent can exercise.

ASI02, Tool Misuse: Legitimate tool use becomes much more dangerous when the agent can also use valid credentials to access privileged systems. Discovering exposed secrets and restricting agent access reduce the damage an agent can cause if it misuses them.
ASI03, Identity & Privilege Abuse: OWASP specifically connects leaked credentials with agents operating beyond their intended scope. Revoking long-lived credentials, reducing standing privilege, and right-sizing access removes much of that available authority before an agent can assume or abuse it.
ASI04, Agentic Supply Chain Vulnerabilities: Compromised MCP servers, tools, and other agent dependencies become far more consequential when they inherit credentials from the environment around them. Agent inventory and credential discovery expose those trust paths so teams can remove unnecessary access before a compromised component exercises it.

What good looks like: response that starts before runtime

A mature AI agent security program answers both questions on the timeline:

Inventory agents and MCP servers. Build a current list of all agents and MCP servers across developer machines, with unknown ones surfaced automatically, along with ownership information.
Discover exposed credentials an agent can reach. Schedule regular scans of the locations where credentials accumulate, scored by machine, severity, and validity.
Revoke, rotate, and right-size. Prioritize findings by risk and blast radius. Adjust agent identities to least privilege.
Enforce guardrails in agent environments. Prevent agents from reading, copying, or transmitting secrets from the workstation.
Plant honeytokens as tripwires. Receive high-fidelity alerts the moment anything reaches for a decoy credential. For critical systems, trigger automated defensive actions.
Leverage runtime detection to improve policy. Behavioral monitoring of agent sessions, with alerts landing in the same response workflow as credential findings.

How GitGuardian fits

GitGuardian's Developer Endpoint Protection extends credential discovery beyond code and internal systems to developer machines, where .env files, shell history, CLI caches, IDE configurations, MCP configs, and AI coding-agent caches accumulate secrets. It also inventories the AI agents and MCP servers present on each machine.

That visibility feeds the GitGuardian cycle:

Detect. Developer Endpoint Protection surfaces credentials by machine and severity, while validity checks help determine which findings still provide usable access. NHI context connects those credentials to the identities, resources, and ownership relationships behind them.

Remediate means reducing the authority those credentials represent. Teams can prioritize revocation, rotation, vaulting, and right-sizing based on validity and identity context.

Prevent extends that control closer to the agent workflow itself. AI agent hooks can prevent secrets from being read, copied, or transmitted via supported AI coding and MCP workflows, while Honeytokens provide a high-confidence signal when something attempts to access the credential surface.

Summary: move the response window left

The rise of AI agents is forcing us to rethink where security decisions are made. Agents can move faster, chain actions together, and exercise valid credentials without ever looking obviously malicious.

The most effective response is to reduce the amount of authority an agent can leverage in the first place. Runtime detection still needs to be in place to catch behaviors you could not predict in advance from a non-deterministic system.

If you are trying to get started, begin with a simple question: Which agents are running in your environment today, and what valid credentials can they already reach? Answer that, and you have the first map of your AI agent attack surface.

Start checking your agent's access today.

FAQ

What is AI agent threat response?

Detecting, containing, and preventing threats involving AI agents: both attacks on agents (prompt injection, goal hijacking) and misuse of what agents can reach, especially valid credentials. It spans two layers: pre-runtime controls that limit what an agent could misuse, and runtime detection that monitors what an agent is doing.

Is runtime monitoring enough to secure AI agents?

It answers one of two questions. Runtime monitoring detects malicious or anomalous agent behavior during execution. It does not inventory the valid credentials sitting readable in agent configs, caches, and environment files before any session starts. A mature program runs runtime detection alongside pre-runtime credential controls.

What are pre-runtime controls for AI agents?

Controls that act before an agent executes: inventorying agents and MCP servers, discovering exposed credentials within their reach, revoking and right-sizing those credentials, enforcing guardrails that keep agents from reading or transmitting secrets, and planting honeytokens as tripwires.

How do AI agents misuse credentials?

Agents read what their environments expose: plaintext keys in .env files, MCP configuration files, CLI caches, and AI tool directories. A manipulated or misaligned agent can use those valid credentials in well-formed API calls that look legitimate, which is why exposure has to be removed before execution.

Do I need both pre-runtime controls and runtime detection?

Yes. Pre-runtime controls determine what an agent could misuse; runtime detection catches manipulation while it happens. They cover different points on the same timeline and work together rather than one substituting for the other.

How is this different from agentic AI for threat detection?

Agentic AI for threat detection uses AI agents to automate SOC work. AI agent threat response, the subject here, secures the agents themselves and what they can reach. The phrases look similar; the buying decisions are entirely different.

Agentic AI Security: Credentials and Permissions Define the Blast Radius

Dwayne McDaniel — Fri, 18 Sep 2026 07:19:45 +0000

Agentic AI Security: Credentials and Permissions Define the Blast Radius

Prompt injection can't be patched away. Three 2026 agentic AI incidents show that credentials and permissions decide the damage.

The trick matters less than the access. Three 2026 disclosures, GitLost, Claude Code's CVE-2026-21852, and Amazon Q's CVE-2026-12957, show agent manipulation determines less damage than the credentials and permissions the agent can reach.
Secrets exposure keeps climbing. GitGuardian found 28.6 million new hardcoded secrets on public GitHub in 2025 (up 34%), including 24,008 in MCP config files and 33,185 in the Shai-Hulud 2 breach alone.
Reducing blast radius means covering the full lifecycle. GitGuardian blocks secrets at the model and tool boundary, discovers exposed credentials on developer endpoints, and speeds revocation so leaked keys lose value fast.

In July 2026, researchers at Noma Labs coaxed GitHub's new Agentic Workflows into leaking data from a private repository. It wasn't from malware. They created a plausible-looking issue in a public repository containing instructions for the agent to retrieve information from other repositories in the organization. After testing variations of the prompt, they found that adding one word, "Additionally," was enough to get past GitHub's guardrails. The agent followed the instructions, fetched a private repository's README, and posted its contents as a public comment for anyone to read.

Most of the agentic AI security conversation fixates on that first part: the trick. Can an agent be manipulated into doing something its operator never intended? Yes, and GitLost shows how little it can take to bypass the safeguards designed to prevent it. But the trick only decides whether an incident starts. What the agent can reach determines how much damage follows. Across this year's most instructive agent incidents, the severity of the outcome came down to what the agent could access: credentials, permissions, and the authority attached to them.

Three agentic AI incidents with a single amplifier

Three disclosures from 2026 make the pattern hard to miss.

#1. Claude Code: opening a repository was enough to lose an API key

In February, Check Point Research disclosed three newly discovered ways developers could be exploited, including two new vulnerabilities in Anthropic's Claude Code. Two allowed remote code execution through repository configuration files (.claude/settings.json and .mcp.json) that Claude Code could load when a developer started the tool inside an untrusted project. The third, CVE-2026-21852, worked differently but exposed something immediately useful to an attacker: the victim's Anthropic API key. A malicious repository could set the ANTHROPIC_BASE_URL environment variable, and Claude Code would send API requests, credentials included, to the attacker's endpoint before it ever showed the user a trust prompt. Anthropic patched the three issues between August and December 2025, ahead of Check Point's February 2026 disclosure.

Notice what the attacker actually gets. The code execution flaws carried the higher severity scores, but the key exfiltration converts directly into durable access: authenticated API traffic redirected to attacker infrastructure, usage billed to the victim, and continued access wherever that API key remains valid. The exploit created the opening. But it was the stolen credential that extended the attacker's access.

#2. Amazon Q: one config file inherited a full cloud identity

In June, Wiz Research disclosed CVE-2026-12957 in the Amazon Q Developer extension for Visual Studio Code. The extension automatically loaded Model Context Protocol (MCP) server configurations from a .amazonq/mcp.json file in any workspace a developer opened, without requiring consent or a workspace trust check. A developer could clone a malicious repository, open it with Amazon Q installed, and unknowingly launch an attacker-controlled MCP process.

The vulnerability gave the malicious MCP process a way in. What made it dangerous was the access that came with it: live AWS credentials from the developer's environment, including AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and active session tokens. Wiz's proof of concept used aws sts get-caller-identity to identify the AWS account and role available through those credentials, then sent that information to an external server. From there, an attacker could exercise whatever access those credentials allowed, potentially reaching production data, creating new access keys for persistence, or moving into internal systems.

Amazon fixed the consent flow in language server version 1.65.0. But the broader lesson is about credential inheritance: the malicious configuration became dangerous because the process it launched inherited live credentials from the developer's environment.

#3. GitLost: a blast radius without a stolen secret

GitLost, the GitHub Agentic Workflows vulnerability Noma Labs disclosed in July, shows the same problem from a different angle. The vulnerable workflow could read public issues while also holding read access to other repositories in the organization, including private ones. A crafted public issue manipulated the agent into using access it already had to retrieve information from a private repository. GitHub's guardrails were supposed to block that request, but a one-word change to the prompt was enough to bypass them.

This is what over-permissioning looks like in agentic systems. An agent can exercise permissions on behalf of whoever controls or influences its instructions, even if that person never possesses the underlying credential. GitLost therefore reinforces the same lesson as the Claude Code and Amazon Q incidents from the opposite direction: a credential does not have to be stolen for the access behind it to be abused. Whether an attacker steals an API key or manipulates an agent into using its existing repository access, the outcome depends on how much authority that agent has. In GitLost, the prompt injection started the incident, but excessive access determined what the attacker could reach.

Why agents concentrate the blast radius

None of this would matter as much if agents had little access to sensitive credentials and systems. The data shows the opposite.

GitGuardian's State of Secrets Sprawl 2026 found 28.6 million new hardcoded secrets pushed to public GitHub in 2025, up 34% year over year and the largest annual jump on record. Secrets tied to AI services are growing even faster, reaching 1,275,105 last year, an 81% increase.

Commits assisted by Claude Code also showed a 3.2% secret leak rate compared with a 1.5% baseline across all public commits. The report cautions against treating that gap as a failure of the tool itself, since developers still decide what gets pushed. The larger point is that AI-assisted development is happening in an environment where credential exposure is already widespread and increasing.

Agents add another layer of risk because they need access to other systems to be useful. That access is often provided through credentials such as database connection strings, cloud keys, SaaS tokens, and model API keys. Those credentials increasingly represent non-human identities with real authority across cloud infrastructure, developer tooling, SaaS platforms, and internal systems. And many of them are stored in plaintext on the same endpoints where agents operate: in .env files, ~/.aws directories, shell history, and MCP configuration files. GitGuardian found 24,008 unique secrets exposed in MCP-related config files on public GitHub, including 2,117 that were verified as valid. Quickstart guides that instruct developers to paste credentials directly into configuration files only add to that exposure.

The risk becomes even clearer at the endpoint level. When GitGuardian analyzed machines compromised by the Shai-Hulud 2 supply chain attack, 6,943 infected machines yielded 33,185 unique secrets, and 59% of those machines were CI/CD runners rather than personal laptops. That campaign did not need to manipulate an AI agent; the credentials already present on developer and CI environments were valuable enough on their own. Put a coding agent with file system and tool access on top of the same environment, and those credentials become accessible to a system that can read files, execute commands, call external services, and act on instructions. If that agent is compromised or manipulated, the credentials and permissions within its reach determine how far the attacker can go.

Shrinking the blast radius before, during, and after compromise

Least privilege, isolation, approval gates, and egress controls remain essential. But coding agents also operate in environments full of credentials that grant access to cloud infrastructure, databases, APIs, developer tooling, and SaaS platforms. If those credentials are exposed, they can give an attacker access that persists long after the original agent interaction ends.

That makes secrets security a critical part of controlling an agent's blast radius. Limiting which credentials agents can discover, transmit, and continue using reduces what a successful manipulation can become. The challenge spans the full lifecycle: removing exposed credentials before an incident, stopping them from crossing model and tool boundaries during one, and quickly revoking them afterward. GitGuardian's secrets visibility and intelligence platform addresses each of those stages, including the developer and CI environments where coding agents actually run.

Before: block credentials at the model and tool boundary

Once an agent is running, the goal shifts from removing credentials from its environment to preventing those credentials from moving through the agent unchecked. GitGuardian's AI Hooks register ggshield as a checkpoint inside Claude Code, Cursor, VS Code with GitHub Copilot, and Codex. Prompts are scanned before they reach the model, while file reads, shell commands, and MCP calls are checked before execution. If a secret is detected, the action is blocked and the finding is returned to the agent so it can self-correct and continue. Tool output is also scanned after execution, and the developer is alerted if sensitive material appears. All of this runs against the same 55600+ detectors used in pre-commit and CI.

Honeytokens add a tripwire on top. Place realistic-looking decoy credentials alongside real ones in configuration files and other locations an attacker or compromised agent is likely to inspect. If a laptop is compromised, a threat actor will often test the credentials it finds to see what they unlock. A compromised agent can also discover and attempt to use credentials available in its environment. The moment a honeytoken is used, GitGuardian triggers a real-time alert, exposing credential misuse even when the agent itself is the actor.

During: remove what the agent can find

Reducing the blast radius starts with knowing which credentials are already within reach. Start by discovering the plaintext credentials AI workflows create and consume, scanning developer endpoints for credentials in .env files, cloud credential stores, MCP and agent configuration files, logs and shell history. Pair that with an inventory of which agents and MCP servers are running across the fleet and what they can reach.

GitGuardian's Developer Endpoint Protection does both through your existing Mobile Device Management (MDM) tooling, using scheduled scans with no continuous agent and the same ggshield detection engine already widely used in developer workflows. For organizations already running ggshield in pre-commit, extending that protection to developer endpoints is a configuration change within the existing MDM deployment, not a new agent or infrastructure project. Every credential removed from an endpoint before an incident is blast radius an attacker never gets.

Credentials are only half the equation. GitGuardian also maps which permissions and identities each credential is tied to, so an agent that can read one key isn't treated the same as an agent that can read a key with production access. The same credential found on an endpoint and in a secrets manager becomes a higher-priority finding than either alone, because it signals broader reach, not just exposure.

After: revoke faster than the attacker can move

Leaked credentials stay dangerous long after an incident scrolls out of the news cycle: 64% of secrets confirmed valid in 2022 were still valid and unrevoked in January 2026. That persistence makes rapid response especially important in agentic environments, where credentials can be discovered and exfiltrated quickly.

Knowing a secret leaked is not enough. You need to know whether it is still valid, what it unlocks, and who owns it. GitGuardian enriches incidents with available validity, ownership, scope, and location context. That turns "an agent may have read a key" into a prioritized list of credentials that need investigation or revocation. For secrets found in code or CI, GitGuardian can push them directly into your secrets manager (HashiCorp Vault, AWS Secrets Manager, CyberArk, Akeyless); where the provider supports it, GitGuardian can revoke the credential directly rather than walking you through manual steps. GitGuardian customers remediated five times more secrets in 2025 than in 2024. When a credential has been exposed, fast revocation removes the authority the attacker can continue to exercise.

The blast radius is defined by what the agent can reach

The GitLost writeup closes with two recommendations that get to the heart of the issue: never treat user-controlled content as trusted instruction input, and scope permissions to the minimum required. Security teams cannot fully prevent agents from being manipulated, but they can control the credentials, permissions, and authority those agents have access to. That is where the blast radius is decided. The next prompt injection may be as trivial as "Additionally." Whether it exposes a README, a cloud credential, or something more consequential depends on how much authority the agent had in the first place.

FAQ

What is prompt injection, and how did it play out in the GitLost incident?

In July 2026, Noma Labs researchers tricked GitHub's Agentic Workflows into leaking a private repository. A crafted public issue told the agent to retrieve data from other repositories, and adding one word, "Additionally," bypassed GitHub's guardrails. The agent fetched a private README and posted it publicly. The trick started the incident; the agent's existing repository access decided how much data leaked.

How can organizations prevent prompt injection attacks against AI agents?

Two controls matter most: never treat user-controlled content as trusted instructions, and scope agent permissions to the minimum required. GitGuardian's AI Hooks apply the first control by scanning prompts, file reads, shell commands, and MCP calls before execution in tools like Claude Code and Cursor, blocking detected secrets. Teams can't stop every manipulation, but they can control what the agent can reach.

Who is responsible for AI agent security?

Vendors patch the disclosed flaw: Anthropic fixed Claude Code's three issues, including CVE-2026-21852, between August and December 2025, and Amazon fixed Amazon Q's consent flow in language server 1.65.0. But patching doesn't remove the exposure. Responsibility for limiting access, least-privilege scoping, credential discovery, and fast revocation, sits with the organization running the agent.

What happens if an AI coding agent's API key or credentials get leaked?

In the Claude Code case (CVE-2026-21852), a malicious repo could redirect API requests, credentials included, to an attacker's endpoint before any trust prompt appeared, enabling continued access and billing to the victim. In the Amazon Q case (CVE-2026-12957), a malicious MCP process inherited live AWS credentials. GitGuardian found 64% of secrets valid in 2022 were still unrevoked by January 2026.

What is a honeytoken, and how does it help catch a compromised AI agent?

A honeytoken is a decoy credential that looks real. It sits alongside genuine credentials in files an attacker or compromised agent is likely to check. Attackers often test credentials found on a compromised device to see what they unlock, and a compromised agent can do the same. The moment a honeytoken is used, GitGuardian triggers a real-time alert, exposing the misuse.

How do you limit the "blast radius" of a compromised AI agent?

Blast radius reduction means covering credentials before, during, and after an incident: discovering exposed secrets in .env files and MCP configs (GitGuardian found 24,008 in public MCP config files alone), blocking secrets at the model and tool boundary during execution, and revoking leaks fast. GitGuardian customers remediated five times more secrets in 2025 than in 2024.

Reduce the credential blast radius of your AI agents

Machine-Speed Credential Abuse: What the ChainDrop npm Worm Changes

Dwayne McDaniel — Thu, 17 Sep 2026 07:57:36 +0000

Machine-Speed Credential Abuse: What the ChainDrop npm Worm Changes

ChainDrop hijacked 444 npm packages and 2B monthly downloads via a Claude Code hook. AI agents have collapsed the gap between credential theft and abuse

TL;DR

Machine-speed attacks: AI agents have collapsed the time between credential discovery and abuse to near-zero, removing the human reaction window defenders used to count on.
ChainDrop in numbers: This Shai-Hulud npm worm hijacked publishing access to hit 444 packages downloaded roughly 2 billion times per month, according to Microsoft.
Attack path: Malicious hooks in Claude Code and VS Code trigger execution the moment a developer opens an infected branch or starts a coding session, no pause needed.
GitGuardian's approach: The platform detects exposed credentials across the SDLC, prioritizes remediation by validity and severity, and uses Developer Endpoint Protection and AI hooks to prevent agents from accessing secrets.

There was a time, not too long ago, when defending against an attacker meant defending against a human taking turns down a kill chain over days or weeks. An attacker might exploit a system and steal credentials, but then they still had to stop, understand what they had found, and decide what to do next. Even when automation helped with individual steps, humans were still setting the pace.

Humans set the tempo, giving defenders something extremely valuable: human-scale reaction time.

Automation has collapsed the gap between discovery and abuse

Today, though, advancements in automation, driven largely by the rapid adoption of AI agents, have dramatically changed that model. Modern attacks now focus on discovering credentials, authenticating with them, enumerating accessible resources, and moving into the next phase without waiting for a person to decide what happens next.

As AI agents gain access to terminals, repositories, development tools, APIs, and other systems capable of taking actions on their own, that pace is only going to quicken. And the kill chain will continue to evolve along with it.

The attacker does not have to manually plot every additional move when the environment itself can execute the next step.

ChainDrop shows what machine-speed credential abuse looks like

One recent evolution in infosteals is the ChainDrop worm. This latest Shai-Hulud attack variant targets the npm ecosystem and automatically searches compromised developer environments and CI/CD systems for npm, GitHub, cloud environments, Kubernetes, Vault, and other credentials.

When it finds usable npm publishing access, it enumerates every package available to that identity, modifies package tarballs, increments their versions, and republishes them with the malicious payload. One compromised credential immediately becomes the starting point for additional malicious releases. The potential reach of ChainDrop is massive. Reports describe 444 packages from multiple publishers, collectively downloaded about 2 billion times per month, including dependencies such as keyv, flat-cache, and cache-manager, according to Microsoft.

As with almost all variants of Shai-Hulud attack, there is no meaningful pause between discovery and use. The attack propagates at machine speed.

And just like other infostealer attacks, the entire playbook depends on long-lived plaintext credentials that grant whatever uses them completely legitimate-looking authority. Once ChainDrop finds working publishing access, it uses that access to continue spreading through the software supply chain.

The whole attack is accomplished in seconds.

Exfiltration still occurs, and humans can still plan additional phases of an attack. The important change is how much damage can happen before a human needs to become involved again.

Opening an infected branch can trigger execution at the AI runtime

ChainDrop abuses the authority we grant AI agents living on developer machines in a new way, while keeping the same basic goal.

Researchers found malicious configuration placed into Claude Code and Visual Studio Code projects. In Claude Code, a SessionStart hook launched the dropper when an AI coding session began. In VS Code, a folderOpen task executes when a developer opens the infected repository.

Stolen GitHub credentials also allow the worm to push malicious configurations into branches of repositories the compromised identity can access.

Then, completely ordinary developer actions can become the trigger. If a developer opens a poisoned branch or starts an AI coding session, the attack begins executing within an environment they already trust. It happens in seconds, far faster than a human defender could reasonably react.

AI-empowered coding environments are now part of the attack surface

Agentic assistants bring a tremendous amount of value, but we need to be clear as an industry about the speed advantage attackers gain when they can abuse these automation platforms.

The AI runtime has become part of the execution environment, and it is one we must better secure. Developers increasingly grant coding agents access to repositories, local files, terminals, development tools, MCP servers, and the credentials those systems depend on.

ChainDrop is just the latest campaign showing how attackers can abuse that trusted environment. Once execution begins, defenders get no human-speed turns to react to.

AI agents have changed the credential abuse timeline

No matter what triggers code execution of any of these Shai-Hulud variants, once the malware starts, it searches local files, environment variables, shell history, cloud configurations, CLI credentials, and other locations where usable secrets can accumulate.

The credentials they find can then be used to authenticate to other services, enumerate what the compromised identity can reach, steal additional secrets, and spread the infection further.

This is the larger change AI and automation bring to credential abuse.

Traditional attack models often assume a sequence of discrete actions separated by investigation and decision-making. Agentic systems can compress those actions into a workflow. Discovery can lead directly to testing. Testing can lead directly to authentication. Authentication can lead directly to another tool call, another repository, another cloud account, or another system.

The speed comes from removing the pauses between those turns.

Valid credentials give automated attacks legitimate access

Giving your AI assistants autonomy definitely can speed up and power many useful workflows. But the same credentials make any AI-powered or triggered attacks especially dangerous because the next action can look completely legitimate.

A valid token, API key, cloud credential, or session artifact gives the system using it the authority associated with that identity. The service receiving the request sees authenticated access.

Automation can therefore move quickly through the same trusted pathways developers, workloads, and AI agents use every day.

This produces a much shorter credential abuse timeline than many security programs were built around. Detection, followed by investigation, followed by human remediation assumes there is enough time between those events to intervene. Automation increasingly consumes that window.

A discovered valid credential can become authenticated access almost immediately. The enumeration, modification, exfiltration, or propagation that follows no longer has to wait for a human in the loop.

Why credential security must start before runtime

Runtime detection remains an essential part of defending modern environments. EDR, supply chain monitoring, AI runtime controls, and behavioral detection can identify malicious activity while it is happening. They can catch unusual processes, malicious tool chains, unexpected network activity, prompt manipulation, and other behaviors defenders could not completely predict beforehand.

The amount of damage those controls have to contain depends heavily on the authority available to the compromised process or agent when execution begins.

Removing exposed credentials reduces the available blast radius

Security teams, working alongside DevOps and platform engineers, need to reduce the number of usable credentials waiting for an attacker before execution ever begins.

Every revoked token, rotated key, removed secret, and constrained identity eliminates one path an automated attacker might otherwise use at machine speeds.

As the time between credential discovery and credential abuse gets shorter, preparation becomes more important.

How GitGuardian helps stop machine-speed credential abuse

GitGuardian's mission has always been to help teams fight secrets sprawl by cleaning up plaintext passwords, API keys, tokens, and other credentials that leak into code, local files, configuration, messaging and ticketing systems, and everywhere else developers work.

Our Credential Layer Security Platform approach helps organizations get a real grasp on the underlying issue that allows infostealers to function: standing privilege represented by API keys and other secrets.

Teams need to detect exposed credentials across the places developers and machines actually work, remediate them while there is still time to remove the access they represent, and prevent new exposures from becoming the next link in an automated attack chain.

Detect exposed credentials across the software development lifecycle

The GitGuardian platform helps teams discover exposed credentials across source code, repositories, CI/CD environments, collaboration systems, and other tools touching the software development lifecycle.

Finding the secret is only the first part of the problem. Teams also need context around validity, severity, ownership, and the identity or resource associated with that credential so they can decide what deserves attention first.

That context becomes increasingly important as the time available for remediation shrinks.

Remediate valid secrets before automated attackers can use them

Organizations need remediation plans built around shortening the time between discovery and action.

That starts with prioritization. A validated, still-active credential tied to a sensitive system deserves very different treatment from an invalid secret that no longer grants access. GitGuardian helps teams use validity, severity, ownership, and surrounding context to focus remediation on the credentials that represent real standing access.

Teams can also use Honeytokens as tripwires for faster response. When a planted credential is touched, that signal can trigger automated workflows to investigate the activity, revoke or rotate related credentials, or invalidate access, limiting the blast radius and preventing ongoing access with that key.

The earlier teams can turn context into action, the less authority remains available to the next malicious package, compromised developer tool, or automated attack chain.

Prevent AI agents and developer tools from accessing exposed secrets

Prevention becomes especially important as AI agents gain deeper access to development environments.

Credentials sitting inside files, configuration, command history, or local tooling can become reachable by an agent with permission to inspect those resources. Preventing that access gives teams another opportunity to stop the credential from ever entering the agent's context or being transmitted somewhere it should not go, such as public repos or frontend JavaScript files.

Developer Endpoint Protection secures credentials around AI agents

Developer Endpoint Protection brings credential security closer to the environments where developers and AI coding tools actually operate.

Developer machines increasingly contain .env files, cloud credential stores, shell histories, AI agent configurations, MCP configurations, and application logs that can hold usable secrets. Those locations matter even more when automated tools can inspect and act on what they find.

Developer Endpoint Protection inventories local AI agents and MCP servers and scans the locations where credentials accumulate on developer machines. This gives security teams visibility into exposed credentials that may never appear in a Git repository but can still be reachable by an AI coding environment or malicious local process.

Endpoint Protection can be deployed via MDM, leveraging Jamf, Intune, Iru, and more. Scans are run on schedule, enabling organizations to extend credential detection to developer endpoints. This provides insight into the access the developer laptop holds, in what is otherwise a black box.

AI hooks prevent agents from reading and transmitting credentials

GitGuardian's AI hooks add a preventive control directly into AI-assisted development workflows.

They can stop local agents from reading, copying, or transmitting detected secrets. It does this at three steps of the agentic workflow:

Stage	What it does	Behavior
Prompt submission	Scans the user's prompt before it is sent to the AI model	Blocks the prompt if secrets are found
Pre-tool use	Scans commands, file reads, and MCP calls before the AI executes them	Blocks the action if secrets are found
Post-tool use	Scans tool outputs after execution	Sends a desktop notification if secrets are found

It creates a guardrail at exactly the point where an agent might otherwise encounter a usable credential while inspecting files or executing a development task.

If AI runtimes are becoming part of the execution surface, as ChainDrop demonstrates, security controls also need to exist around what those runtimes are allowed to consume.

Credential security has to operate at machine speed

Machine-speed attacks reward credentials that have been forgotten, duplicated, left valid, or placed somewhere nobody thought to monitor. Agentic development expands both the number of environments where those credentials can be encountered and the number of automated systems capable of using them.

We are now in a world where the time between credential discovery and credential abuse is beginning to approach the millisecond range.

Security programs have to operate with that assumption.

Detect, remediate, prevent before the attacker gets a turn

The old security model often gave defenders a turn to react at human speed.

The new AI-driven model increasingly does not.

Credential security has to begin before execution, before propagation, and before a stolen credential becomes the next authenticated action in an automated chain.

Detect what is exposed. Remediate what remains valid. Prevent new credentials from becoming available to the systems and agents attackers are learning to abuse.

The best credential for an automated attacker to discover is one that has already been found, remediated, and removed before the attack gets its turn. And that is exactly what GitGuardian was purpose-built to help you with.

Why Secrets Slip Through Every Layer of Your Security Stack

Dwayne McDaniel — Tue, 15 Sep 2026 05:27:36 +0000

Why Secrets Slip Through Every Layer of Your Security Stack

Your security stack is a set of specialists, each guarding one territory. Exposed credentials don't respect the boundaries between them, and 64% of the ones found valid in 2022 were still valid four years later.

TL;DR

Multiple locations, one credential: An API key moves from a developer's laptop to a repo, pipeline logs, a ticket, and a teammate's config; each copy carries the same access, and no single tool tracks all five.
Every tool has a job. Secrets fall between them: Your security stack is built from specialists, but no single tool is designed to track a credential across every environment it touches.
28% happens where no scanner looks: GitGuardian's State of Secrets Sprawl 2026 found 28% of secrets incidents occur entirely outside code repositories, in collaboration and productivity tools.
64% still valid four years later: Of secrets found valid in public repos in 2022, more than 64% were still valid when retested in January 2026. Revocation needs cross-tool context nobody owns.

Follow one API key for a month. It gets created on a developer's laptop, committed to a repository, echoed into a pipeline log, pasted into a ticket during an incident, and copied into a teammate's local config. Five locations hold the same credential, with the same privileges anywhere that credential remains valid. Each copy creates another path to compromise. Once an unauthorized person or system reaches one of them, the organization has to scope the credential across every place it traveled. This is secrets sprawl in miniature: one credential, five copies, no map of where they all ended up.

Now overlay your security stack on that itinerary; the repo scanner saw the commit, the endpoint agent watched the laptop for hostile behavior, and the vault protected its own enrolled copy, faithfully. Each control did its job inside its territory. The problem is that the key never stayed in one.

The security stack is fragmented by design

Modern security organizes itself into territories, and the specialization is deliberate:

Application security: finds the flaws in code.
Endpoint detection and response (EDR): watches machine behavior.
Identity and access management (IAM): governs who should hold access.
Vaults: protect the credentials enrolled in them.
Cloud security: governs infrastructure and permissions.
Security information and event management (SIEM): correlates what all of it produces.

That division of labor is why each control works. A scanner that also tries to be an endpoint agent would do both jobs worse. Fragmentation is the design principle that makes the stack possible; specialists beat generalists at every individual layer.

The design has one blind spot, and it is structural. Territories can only protect what stays inside them.

Leaked credentials do not respect the map

A long-lived credential can cross environment boundaries while retaining its authority wherever it remains valid. The key flagged in your repository may also sit in a public fork, an old build artifact, and the config of a local AI tool, and each copy carries the same access as the one you found. Movement is now the norm rather than the exception. GitGuardian's State of Secrets Sprawl 2026 found that 28% of secrets incidents happen exclusively outside code repositories, in the collaboration and productivity tools where no repository scanner will ever look.

Crossing boundaries does something subtle to detection. When exposures surface in different tools, each arrives as its own finding. Three alerts in three consoles might represent three compromised credentials or one credential exposed in three places. A control limited to a single telemetry source cannot determine the full scope on its own, because answering that question requires visibility across those environments.

And when an attacker eventually uses a copy, every control may behave correctly. The login succeeds because it was built to succeed. That is what separates credential compromise from most other attack paths: it looks like legitimate access.

The seams have no owner

The objection writes itself: plenty of tools now scan for secrets. Repository platforms do. Some application security suites carry a secrets feature. Every one of those catches is welcome, but a secrets feature scoped to a single surface can answer only that surface's question. On its own, it cannot establish everywhere else the credential exists or whether the exposure has been fully remediated.

The persistence data shows what happens to questions nobody is assigned. Of the valid secrets detected in public repositories in 2022, more than 64% were still valid when retested in January 2026. Four years exposed, unrevoked. Revoking a credential takes context no single territory holds, starting with what breaks on rotation and who owns the fix. Findings that fall in the seams stay in the seams.

What sitting in the seams would mean

Closing the gap means treating the credential as one connected object across everything it touches. For each one, that means every location where a copy exists, whether separate exposures are the same secret, whether it still works, who owns it, and what it can access.

A layer like that strengthens the territories rather than competing with them. A vault gets stronger when the organization can see which credentials escaped it, and identity governance gets stronger when it can account for every credential its identities carry.

Where the full argument lives

Our ebook, The Secrets Problem: Everyone's Dependency. No One's Job, traces this gap across every layer of the security stack. It shows where each control's visibility ends, what happens when credentials cross those boundaries, and why secrets security needs an owner of its own.

Close the seams your security stack can't see across. Book a demo with our team.

FAQs

What is a security stack?

A security stack is the set of specialized tools an organization layers together to protect its systems: application security scanners, endpoint detection and response (EDR), identity and access management (IAM), vaults, cloud security tools, and SIEM. Each tool is built to excel inside one territory rather than cover everything.

Why do security tools miss credentials that move between them?

Because each tool only sees its own territory by design. A repository scanner catches a credential when it's committed to code, an endpoint agent watches for hostile behavior on a laptop, and a vault protects the copy enrolled in it, but a credential that travels across a laptop, a repo, a pipeline log, a support ticket, and a teammate's config crosses five different blind spots, and no single tool sees the whole path.

What percentage of secrets incidents happen outside code repositories?

According to our own State of Secrets Sprawl 2026 report, 28% of secrets incidents happen exclusively outside code repositories, in collaboration and productivity tools like Slack, Jira, and Confluence, none of which a repository scanner ever looks at.

How long do exposed credentials stay valid after they're discovered?

Often for years. Of the valid secrets GitGuardian detected in public repositories in 2022, more than 64% were still valid when retested in January 2026, four years later.

Why does credential compromise look like a normal login instead of an attack?

When an attacker uses a valid stolen credential, every control behaves exactly as designed; the login succeeds because it was built to succeed for that credential. That's what separates credential compromise from most other attack paths: nothing in the stack flags it as wrong.

Who is responsible for revoking a leaked credential?

Responsibility is often distributed across teams. Security may discover the exposure, while the credential owner or platform team has to revoke it, and an application owner may need to determine what will break when it rotates. No single security tool necessarily holds all of that context, which can make leaked credentials harder to remediate quickly.

Inside the LiteLLM hack: 153GB, 433,909 Files, 2,488 Organizations

Dwayne McDaniel — Mon, 14 Sep 2026 11:53:16 +0000

Inside the LiteLLM hack: 153GB, 433,909 Files, 2,488 Organizations

Attackers dumped everything they harvested from LiteLLM builds during a 40-minute window in March. Here is what is inside and what it says about where secrets live.

TL;DR

Hudson Rock and CloudSEK confirmed the scale of the March LiteLLM PyPI hack: a 153GB archive, 433,909 files.
118,829 CI runner dumps trace back to 2,488 organizations across the exposed archive.
Many dumps carry no email, domain, or hostname — unattributable, with no way to disclose.

The March compromise of litellm lasted about 40 minutes on PyPI. This week we learned what the attackers stole in that time.

On August 12, 2026, Hudson Rock published its analysis of the exfiltration archive: a 153GB RAR containing 433,909 files. Its researchers attributed 118,829 CI runner dumps to 2,488 corporate domains. CloudSEK published parallel victim research on August 11, covering the same campaign from its own intelligence sources.

Neither report is about malware behavior. That was documented in March. These are about the loot.

The blast radius, now measured

In March we wrote about the LiteLLM supply chain attack when the infostealer harvested everything an attacker could want. We listed SSH keys, cloud credentials, Docker configuration, and crypto wallet data, and said the blast radius was likely significant. That was an inference from malware analysis. The archive turns it into counts.

On each compromised runner, the payload escalated to root. It swept SSH keys, AWS, GCP, and Azure credentials, Kubernetes service account tokens, .env files, and CI/CD secrets. On AI builds, it also took LLM API keys and gateway configuration, which is access to an organization's entire model stack rather than one credential.

In March we said the keys to your infrastructure were potentially in the hands of threat actors. Five months later, the qualifier is gone. 118,829 runner dumps, 2,488 organizations, one 40-minute window.

What is inside the dump

Hudson Rock's write-up shows environment dumps captured mid-execution:

AWS_SECRET_ACCESS_KEY
SALESFORCE_CLIENT_SECRET
SLACK_SIGNING_SECRET
Azure environment credentials
AI provider API keys
GITLAB_USER_EMAIL and CI_SERVER_FQDN, which is how attribution can be done

In one example, Hudson Rock reports a single organization with 17 compromised pipeline dumps exposing Bitbucket deployment tokens, Elastic API keys, internal JWTs, and NPM tokens. Publishing credentials in the loot is how a supply chain incident becomes a second supply chain incident.

The half nobody can attribute

The most useful finding in either report is a negative one.

Hudson Rock does not put a number on it, but reports that many dumps carry live database passwords, cloud credentials, and third-party API keys with no company email, no custom domain, and no internal hostname. Those records cannot be attributed to anyone. The organizations behind them will appear on no victim list and will receive no disclosure email.

Attributed records can still mislead. Hudson Rock describes a pipeline whose committer email ended in @siriusxm.com, while the environment dump pointed to gitlab.adswizz.com and a matching registry host. The breach sat in AdsWizz infrastructure, a SiriusXM subsidiary. Routing an alert on the email alone reaches the wrong security team.

Hudson Rock ran an ethical disclosure program. CloudSEK published a public lookup tool. Neither can notify a company it cannot name. Responsible disclosure needs an address, and a generically configured runner does not leave one. Good intentions do not close that gap.

Detection that does not need your name

If disclosure cannot reach you, detection has to start in your own environment.

Know what you had

An inventory of your non-human identities tells you which credentials lived in those pipelines on March 24, what each one reaches, and who owns it. Without that list, "were we exposed" has no answer.

Know what sits on the endpoint

The payload ran at Python interpreter startup, on developer laptops as readily as on CI runners. It never touched a repository. Developer Endpoint Protection extends secrets detection to the machines where code actually executes, which is where this campaign collected everything it collected.

Know what is still live

Continuous secrets detection with automated validity checking turns "we might be in there somewhere" into a ranked list of credentials to rotate today.

Know when someone uses them

This stealer collected environment variables and .env files, which is where honeytokens sit. The first time an attacker tries one, you get an alert. That signal reaches you without anyone having to identify you first, which is the gap this archive exposes.

Check your exposure now.

Your AI Agents Are Using Your Credentials

Dwayne McDaniel — Fri, 11 Sep 2026 13:27:41 +0000

Key findings

It's a secrets problem before it's an identity problem. Many AI agents don't have their own distinct identity, so they operate using API keys, tokens, and other credentials issued to humans or workloads.
Those credentials can sit outside agent-specific identity controls. When no enterprise IdP mediates the exchange, agent activity can create a governance blind spot that standard identity reviews may not expose.
Discovery and attribution come first. Find where agent credentials actually live and identify the human or workload that owns them.
Prevention has to run alongside cleanup. Block new secret exposure while you migrate credentials already in use.
The end state is scoped, short-lived access. Replace standing, reusable credentials with agent-specific or delegated identities backed by scoped, short-lived credentials that limit the value of anything stolen.

Every conversation with security leadership lands on the same question sooner or later: all our developers and citizen developers use AI agents now, so how do we govern what those agents can reach? The instinct is to treat this as an identity problem and reach for the identity stack, because that's where governance lives.

The instinct rests on an assumption worth poking at: that your agents have identities you can govern. Many agents running in enterprises today don't. They borrow existing human or workload identities through credentials no identity system mediates.

The agent identity spectrum has two well-lit ends

Agent identity runs on a spectrum. At one end sits the human-controlled session. An employee drives the agent through single sign-on, watches what it does, and stays accountable for the outcome, the same way they're accountable for anything else done under their login. Your identity provider (IdP) owns this end, and access is issued and revoked where everything else already is.

At the other end sits the system service account: a single-purpose, least-privilege identity that does exactly one job, running in a sandboxed environment with an egress allowlist. The design goal for this end is an environment that holds nothing worth stealing: no static credential on disk, and nothing reusable for a compromised agent to exfiltrate.

Between them can sit secure delegated identity, where both the user and the agent retain distinct, auditable identities and access is granted through scoped, short-lived tokens.

All three models are governable. The emerging playbook says deploy in one of them and stay there. Authentication is the control that defines what an agent can reach, how long it can keep reaching it, and how quickly a team can shut it down when something goes wrong.

How the agent gray zone fills up

Beside those governable models sits the agent that carries a reusable credential issued to a person or workload into systems that person isn't watching. No agent-specific identity is attached. Accountability there is ambiguous, and the standard guidance treats this gray zone as a place to avoid. That works when you're choosing where new, sanctioned agents will live. The problem is that the gray zone isn't populated by deployment decisions alone. It fills up on its own.

That gap widens as agentic tooling moves beyond traditionally trained software teams. Citizen developers can now build workflows, connect applications, and deploy MCP servers without the security background, development practices, or tooling that established software teams are more likely to have in place. A developer may recognize that an API key should not live in a configuration file. A business user wiring up their first Zapier workflow or MCP server may not know what a .env file is, let alone that credential harvesters know to look for one. They are being given the ability to create software and connect sensitive systems before they have been given the practices needed to secure them.

The mechanism is mundane. An agent is only useful with access, and many of the systems it needs, from internal APIs to databases to older SaaS tools, rely on one practical access mechanism: a static credential. So a developer pastes a personal access token into a Model Context Protocol (MCP) server config. An API key lands in a .env file. The agent now authenticates as the credential's owner, in systems no human is watching, with credentials that rarely expire.

The path isn't always a paste. AI coding tools routinely pull credentials from a developer's password manager at runtime and write them into session logs or cache directories, locations no repository scanner will ever see.

The scale is measurable. Gartner predicts that by 2028, an average global Fortune 500 enterprise will have more than 150,000 agents in use, up from fewer than 15 in 2025. Each of those agents needs credentials to reach anything. GitGuardian found 24,008 unique secrets in public MCP config files in 2025. AI-service credential leaks grew 81% year over year, with 1.27 million exposed in 2025. Claude Code co-authored commits leaked secrets at roughly twice the public GitHub baseline in GitGuardian's 2025 dataset. One over-permissioned agent can turn a single credential into reach across an entire environment. These credentials don't age out, either. Of the credentials confirmed valid in 2022, more than 64% were still valid when GitGuardian retested them in January 2026. An agent with the wrong credentials has access to everything those credentials can reach, no attacker required.

Agent identity is a secrets problem before it's an identity problem

The industry is converging on agentic identity as the next frontier of identity and access management. Directionally, that's right. Agents should hold first-class, scoped identities. The old identity model, though, was built for people and standing permissions that changed slowly. Agents provision themselves, act autonomously, and can be gone before an access review runs. That gap is structural, not a configuration problem. An IdP can only govern identities it issues or mediates. When an agent authenticates to your database with an API key it reads from a config file, no enterprise IdP mediates the exchange, and no agent-specific identity is attached to the request. It may never appear in the identity system's access reviews, and the target service generally cannot tell that an agent used it. At the authorization layer, the activity can be indistinguishable from the human or workload whose credential it borrowed.

Ask two questions of any agent in your fleet. On whose behalf is it acting, and what actor can you see when it acts? For a service account or secure delegated identity, both have crisp answers. For a reused static credential, the target system can usually identify the credential's principal. It cannot reliably tell whether a human, an AI agent, or malware exercised it.

A misaligned agent behaves like an insider moving at machine speed. Ponemon Institute's 2026 Cost of Insider Risks report puts average containment time for an insider incident at 67 days. That number describes human insiders, not AI agents, but it highlights the visibility problem. Agents execute in seconds, and breakout times; the window from initial access to lateral movement has been measured at under a minute in recent campaigns. You can't start a containment clock on a credential you don't know exists.

Attackers have already operationalized the gap. The Nx s1ngularity payload attempted to use locally installed AI CLIs with unsafe permission settings to identify sensitive files, then collected and exfiltrated credentials from compromised systems. Shai-Hulud spread through npm by harvesting credentials from compromised machines. In the Shai-Hulud 2 wave, GitGuardian found substantial duplication across the harvested data, with each live secret appearing in roughly eight locations on average. These campaigns aren't creating a new attack. They run the oldest one available: credential theft and reuse, at a scale no human attacker could sustain.

Shining a light on the AI agent gray zone

You won't empty the gray zone with a policy memo, because nobody knows what's in it. The work sequences like this.

Discovery comes first

Fleet-wide scanning of developer machines surfaces the credentials agents actually use: .env files, cloud credential stores like ~/.aws, MCP and agent config files, shell history, and logs. GitGuardian's Developer Endpoint Protection deploys through the mobile device management tooling you already run, on a schedule, with no continuous agent, and inventories the credentials stored across AI-agent and MCP configuration paths on each machine. For organizations already running ggshield in pre-commit hooks or CI, endpoint scanning is a configuration change, not an agent project: the same ggshield binary, extended with a new scan token and deployed via your existing MDM push. That inventory answers a question no single vendor console can, because each vendor console sees only its own tools and identities.

Attribution turns findings into a plan

A credential with a named owner can be governed. An anonymous one is just a liability with no return address. Each finding gets attributed to a human or workload owner and correlated with live incidents, which is what turns a pile of detections into a migration queue.

For observability in the meantime, plant tripwires

Honeytokens, decoy credentials placed in realistic-looking configuration files on endpoints and in repositories, give the gray zone the alarm it lacks. A compromised machine's attacker, or a rogue agent scanning for usable credentials, will test whatever looks real. If anyone attempts to use a honeytoken against a real service, you know in real time, and you know which machine.

Prevention runs in parallel

Agents are still creating new exposures while you clean up the old ones. GitGuardian's AI Hooks register ggshield as a checkpoint inside Claude Code, Cursor, VS Code with GitHub Copilot, and Codex, the four major AI coding environments. Prompts are scanned before they reach the model. File reads, shell commands, and MCP tool calls are scanned before the agent executes them. If a secret appears in a prompt or pre-tool action, the action is blocked, and the agent receives the exact finding so it can self-correct and continue. Tool output is also scanned after execution. Anthropic, Cursor, and GitHub each police their own console. AI Hooks is the layer that covers all of them at once, fleet-wide.

Migration happens in priority order

GitGuardian NHI Governance inventories the credential estate, scores risk, and provides the ownership and exposure context teams need to decide which delegated credentials to replace first with scoped non-human identities (NHIs) or bring under the IdP. The migration itself is your team's work. Knowing where to start shouldn't be.

Not every agent runs on a developer's laptop

Platform agents like Zapier workflows, Make.com automations, and n8n sequences carry credentials from system to system without ever touching a developer machine. GitGuardian NHI Governance extends the same discovery and attribution logic to these identities: each agent's credential, the systems it can reach, and when its access was last reviewed. The mechanism is different, but the governance question is the same: what can an agent reach, and does that still match what you intended?

The future of agent authentication

The work proceeds in two phases.

The nearer-term goal is removing plaintext credentials from the places agents read them, replacing static values in config files and environment variables with references that resolve to nothing an infostealer can harvest.
The further goal is a proxy layer where an agent requests access at runtime and receives a scoped, short-lived credential it never stores, a model where the agent connects to the service without ever holding the secret value.

No long-lived secret on disk for an infostealer to harvest, and nothing reusable if the agent is compromised. That would make the safe end of the spectrum a property of the machine, regardless of which vendor built the agent.

Attackers don't need to break in when they can log in. The governable parts of the spectrum are already well-lit, and platform vendors keep making them brighter. The advantage goes to the teams that can see the gray zone, because that's where many of their agents already are.

See how GitGuardian secures agentic AI

Vault Coverage Is the Missing Metric in NHI Programs

Dwayne McDaniel — Thu, 10 Sep 2026 14:56:53 +0000

Most large enterprises have some version of a vault program, the combination of policy, platform, process, and ownership used to manage machine credentials. It includes the secrets manager itself, the teams that operate it, the IAM policies that govern it, and the application teams expected to use it. The credentials themselves belong to machine identities: the service accounts, workloads, and AI agents actually doing the authenticating.

In an ideal world, every team would have the same stake and view into that program. Many do not.

Teams can usually see which credentials made it into the vault. But every team, from security to IAM, cannot see the full population of machine credentials still living in repositories, pipelines, cloud environments, or collaboration tools. They also cannot easily tell which vaulted credentials have active copies sitting elsewhere.

That leaves IAM and Security teams responsible for a control they cannot fully measure.

If a CISO or exec team member asks, "How much of our machine credential risk is under control?" many teams would struggle to answer. Unfortunately, they typically ask these questions after an incident, when the timing could not be worse.

All vaults, from AWS Secrets Manager to CyberArk Secrets Manager, can report metrics like uptime, secret count, request volume, and onboarding activity. Those figures show whether the platform is running. They do not show whether the organization is actually following the policy.

What you need is a full credential-layer security plan that includes vaults and wherever else secrets actually live.

Who owns vault coverage in your organization

Vault "ownership" is usually split across several groups.

Security or IAM owns the policy and risk. Platform, infrastructure, or identity engineering runs the service. Application teams own the credentials used by their workloads. The CISO remains accountable for the broader credential risk reported to executive leadership and the board.

In reality, this means a fractured governance model in which IAM can publish the policy, platform teams keep the vault available, and application teams decide how quickly they adopt it.

The team members make those separate decisions, and in many orgs there is no central authority truly accountable for adoption. Their work continues when they bypass the vault. Builds pass and deployments complete, and then those plaintext credentials remain active.

The plan for the control exists on paper. The actual compliance rate remains a big unknown. The gap becomes visible, unfortunately, most often during an audit, a manual review, or an incident. What all teams need, but especially the IAM and Security teams responsible for governance, is a shared, unified view of how many credentials exist across all surfaces.

IAM needs to see policy coverage. Platform teams need to see adoption gaps. Application and Security teams see the credentials they need to manage and remediate. And ultimately, the CISO and board need to see whether risk is moving in the right direction.

Why secrets end up outside the vault

The simple answer of "why isn't everything already in a vault?" is friction. Developers hate toil, and vaults require setup, authentication, and integration work. Each platform comes with its own intricacies, meaning developers need to leave flow state to remember how to use the CLI to set the path correctly, then test and do all the needed process management steps.

A credential placed in a local configuration file works immediately. An unmanaged CI variable also works immediately. The build passes, and the team moves on.

The credential may remain outside approved management for months or years.

The OWASP Top 10 for Non-Human Identities ranks downstream consequences, secret leakage, and long-lived, unmanaged credentials among its top items. GitGuardian's research gives the scale: 28.6 million new hardcoded secrets on public GitHub in 2025, and 64% of secrets confirmed valid in 2022 still valid years later (State of Secrets Sprawl 2026). Those numbers show the size of your credential sprawl that vault-native reporting alone cannot account for.

IAM and Security need visibility into the systems where those credentials are created, copied, and used.

How to measure vault program effectiveness

Any project needs measurable controls. IAM teams have long had a set of standard metrics that let them report on compliance and effectiveness. Access reviews have completion rates. Multi-factor authentication programs have enrollment rates. Privileged access programs track account onboarding and policy coverage.

Vault programs, though, often track only credentials that are already onboarded.

That produces a numerator. IAM still needs the denominator: the total number of known machine credentials across the organization.

Finding that number is difficult because credentials move through engineering systems without a central registration event. A credential may begin in a cloud platform. A copy may appear in a CI/CD variable. Another may end up in a Kubernetes manifest or application configuration.

How to calculate vault coverage

Vault coverage is the share of known machine credentials that reconcile to a managed vault.

Vault coverage = unique credentials matched to a managed vault ÷ unique credentials detected across connected sources

Getting these numbers requires discovery. This is where GitGuardian comes in.

GitGuardian's credential-layer security platform detects credentials everywhere they should be and everywhere they shouldn't be. This means finding plaintext API keys in places like source control systems, CI/CD platforms, cloud environments, and collaboration tools. GitGuardian deduplicates each credential by value. The same credential appearing in several locations counts once in the coverage calculation. Each secret is then hashed, and a fingerprint is taken of each hash.

GitGuardian then compares those detected credential fingerprints with the fingerprints of secrets in any connected vaults. The platform never stores the actual secrets, and your vaulted secrets always stay secure thanks to ggscout.

Why a vaulted secret can still be exposed

A service account credential may be stored correctly in Azure Key Vault or Delinea Secret Server, while the same active secret remains in multiple code repositories. That credential counts as matched for vault coverage, but the plaintext copy in the code still carries the risk.

When categorizing risks and prioritizing an action plan, GitGuardian helps IAM and Security teams broadly sort exposure risk into three cases:

A credential that is vaulted and contained.
A credential that is vaulted but still copied elsewhere.
A credential that has never reached the vault.

Those cases require different actions, and security and IAM teams need to distinguish them quickly. The GitGuardian platform makes it straightforward to address that last, and highest risk, state. With our "push-to-vault" functionality, anyone working on an incident of a discovered plaintext secret can simply place it in the correct connected vault and set the path with ease. For secrets found in code, GitGuardian can even track the file with "Secret Presence" checks to show when the secret is properly removed from the same branch of the repo where GitGuardian first detected it.

The goal is to reduce risk, and vault coverage empowers you to prove you are.

Why vault coverage matters for compliance and the board

Vault coverage shows whether the secrets management investment is reaching the credentials it was purchased to protect. This answers one of the questions executive teams often ask. The other question boards and execs ask is if their investment has lowered risk.

Part of that risk discussion is auditability and compliance.

For example, PCI DSS 4.0 policy on hardcoded application and system account credentials started being enforced in March 2025. A discovery-based coverage metric can support an assessment. The list of unmatched credentials behind the metric can drive remediation. The stored-secret count alone cannot answer whether you have met those standards. A higher count may reflect adoption, continued credential growth, or migration from another platform.

Coverage adds the missing context. It can arm your whole enterprise for when auditors show up, before or after an incident, asking what steps you have taken to meet compliance standards.

GitGuardian exposes machine credential risk in measurable terms, while giving you clear timelines and steps from the time you discovered a secret is out of compliance through how and when you remediated the incident.

How to report vault coverage to executives

Traditional vault reporting focuses on platform activity, but what exec teams care about, and what IAM and security need to understand, is total governance plan effectiveness.

How many known machine credentials are covered by the vault policy? Which teams account for the largest gaps? How many vaulted credentials still have unmanaged copies? Which credentials have no clear owner?

GitGuardian gives the whole enterprise a standing view of those questions.

You can report coverage across the organization, track production coverage separately from lower-risk systems, and prioritize the teams with the largest gaps first.

Knowing the real coverage number gives IAM a starting point, a remediation backlog, and a way to show progress over time.

The conversations with execs and the board become more specific. Instead of answers like "Teams are still adopting vaults," we can empower reporting such as "Production vault coverage is 61%. The target is 80% by Q2. Three teams account for most of the unmatched credentials. A portion of matched credentials still appear in repositories."

That is a program that shows progress, has clear goals, and is understandable by leadership and stakeholders.

We would love to help you get on the road to better vault coverage as part of your credential security planning. Set up a demo today.

Common Questions About Vault Coverage

What is a vault program?

A vault program combines the secrets manager, the operating model, the IAM policies, and the application onboarding process used to manage machine credentials. It includes the technology and the teams responsible for making the control work.

What is vault coverage?

Vault coverage is the percentage of known machine credentials that reconcile to a managed secrets vault. It is calculated by dividing unique credentials matched to a vault by unique credentials detected across connected systems.

Does a vaulted credential mean it is protected?

A vaulted credential may still have active copies in repositories, pipelines, or application configuration. IAM should review vault coverage alongside the unmanaged-copy rate to see whether a credential remains exposed outside approved storage.

Who owns vault coverage?

IAM or identity security usually owns the policy, governance model, and reporting. Platform, infrastructure, or identity engineering usually operates the vault. Application teams own the credentials used by their workloads. The CISO remains accountable for the broader risk outcome.

What does GitGuardian add to an existing vault program?

GitGuardian finds credentials across engineering systems, reconciles them with connected vaults, and shows which credentials remain unmatched or exposed outside approved storage. IAM gains a measurable coverage rate, a remediation backlog, and a clearer view of ownership.

Mini Shai-Hulud's Latest Wave: 280 New Places It Hunts for Your Secrets

Dwayne McDaniel — Wed, 09 Sep 2026 13:12:53 +0000

We have stopped counting the number of waves in the Shai-Hulud attack series, but this week has seen the rise of yet another iteration.

This campaign started with the infection of the keyv@6.0.0 npm package at 9:35 a.m. UTC on Aug. 4, 2026, and quickly spread across the ecosystem. The compromise chain reportedly affected more than 800 packages across thousands of versions, including:

@cacheable/memory
ecto
cacheable-request
flat-cache
and more

The infection spread into the npm namespace of several well-known companies, including:

OneReach
Ornikar
Qlik
Picsart

The last known malicious package was published at 12:27 a.m. UTC on Aug. 5, 2026.

How the Mini Shai-Hulud infection chain works

The infection mechanism used in this campaign is very familiar. It relies on an npm preinstall script, a mechanism that has been disabled by default since npm version 12. This script uses the same mechanism we have observed in similar campaigns: it downloads the Bun execution environment and uses it to load a heavily obfuscated JavaScript second-stage file named Math_Symbol.js.

Payload file	SHA256
setup.mjs	54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668
Math_Symbol.js	9fc2570b7cef51c1b8df116d144d11ff4096357be7d2c4c6367cfc2509cf1bcc

Once deobfuscated, it is clear that this malware is part of the Mini Shai-Hulud family, whose source code was open-sourced by the Team PCP threat actor in May 2026. The main payload shares the key characteristics we know from this family of malware:

Aims for secrets, both locally and on remote systems.
Distinctively targets developers' endpoints and CI/CD runners.
Exfiltrates secrets to GitHub, including with a previously compromised key.
Persists through poisoning of Claude and VS Code configuration files.

There are a few key novelties in this version worth noting. For example, the new version can download its command-and-control server address from the Ethereum blockchain. This mechanism is new to the Mini Shai-Hulud family, but the GlassWorm malware already used it in March 2026.

The true evolution, however, lies in the expanded scope of the collection.

469 secret locations: how the collection scope expanded

The Mini Shai-Hulud malware family is known for collecting secrets both locally and remotely. To do so, it uses distinct providers that target specific services:

The local file system
Local execution environment
CI/CD runner environments
AWS
Kubernetes
Vault

The list of collectors has not changed with the new version. Instead, the scope of what each collector accesses has changed.

The clearest example of this evolution is the file system provider, which is responsible for collecting secrets from developer machines. The open-source version of the malware collected secrets from a list of 189 hardcoded locations across Linux, Windows, and macOS environments. This new version raises the count to 469.

	Mini-Shai Hulud	Latest version
Linux	89	290
Windows	12	50
macOS	88	129

On Windows and macOS, the added paths mostly represent a catch-up with the previous version's Linux collector. On Linux, however, the changes are much more significant.

First, the malware now tries to exploit elevated privileges to collect secrets from more locations. Previous versions only targeted files stored in the current user's home directory; the new one enumerates files across all users on the system, including administrative users. This means the impact of an execution with high privileges would be much more severe.

The malware also expands the scope of its secret hunting by targeting configuration files for additional services and software, primarily AI agents, CI/CD software, cryptocurrency wallets, and cloud tools: the kinds of software most commonly found on developer machines.

AI agents: Cursor, OpenClaw, OpenAI Codex, OpenCode, Gemini, Hermes
CI/CD: ArgoCD, Jenkins, CircleCI
Cloud: Hetzner, Alibaba Cloud, Tencent Cloud
Cryptocurrency: Foundry, Brownie, Solana, Electrum

The other collectors remain unchanged. They already collect most of the data they can access.

Why npm supply chain attacks keep adapting

Every new supply chain attack campaign comes with its own set of improvements. They sometimes arise in response to security hardening efforts and are sometimes purely functional.

In recent months, we have seen threat actors adapt to the evolving security of the open-source ecosystem. The clearest example has been their adoption of OpenID Connect (OIDC) and attestations for package publication, a response to defenses introduced since the original Mini Shai-Hulud campaign in May 2026.

This new iteration does not represent a huge technological leap, but it still improves on past campaigns. The increase in the scope of endpoint harvesting is not anecdotal; it shows threat actors are refining their understanding of secrets sprawl, especially on the endpoint. It is reasonable to expect future waves will further refine this part of the malware.

With such a fast-moving threat, understanding where your credentials live has never been more important. That is why we, at GitGuardian, have been building our endpoint protection solution: so you know where your secrets live, which ones you can remove before an attack happens, and which ones you need to revoke once an infostealer campaign hits you.

Don't let attackers know where to find your secrets better than you do.