DEV Community: Dwayne McDaniel

Public Secrets Monitoring: Find a Credential Leak Beyond Your Borders

Dwayne McDaniel — Thu, 08 Oct 2026 15:07:18 +0000

TL;DR

A credential leak far beyond company walls: 28.65 million new hardcoded secrets in public GitHub commits in 2025 (up 34%), and almost 80% of one customer's corporate leaks traced back to developers' personal repositories, a risk echoed by the CISA leak found in May 2026.
New verdicts cut through the noise: GitGuardian's Agents Analysis now cleanly labels each public incident, reorganizing the Public Monitoring queue around company relevance so analysts start where the risk actually is. It is available now for all customers.
Reasoning and feedback close the loop: A new Analysis tab shows exactly why an incident got its verdict, and analysts can thumbs up or down each call, helping GitGuardian sharpen company attribution as Agents Analysis becomes the default experience.

Your credential layer extends much farther than the systems your company owns.

Credentials move through company repositories, developer environments, and CI/CD systems. Some eventually cross into places your organization and security team do not control. That crossing point is a credential leak, and it doesn't wait for your team to notice it.

Public GitHub gives us a very clear picture of how often this happens.

GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% from the previous year. About 5.6% of public repositories contained at least one secret, according to the State of Secrets Sprawl 2026.

GitHub itself has independently reported tens of millions of secret leaks across its platform. Different methodologies produce different totals, but the direction is clear. Credentials continue to escape into public development activity at enormous scale.

For a security team, finding secrets across that public surface creates another hard set of problems: "Which of those credentials are actually yours and which ones require action?"

Ever since GitGuardian was founded, we have been helping customers answer exactly that question with the platform's Public Monitoring capabilities.

Our latest update gives security, DevSecOps, and developer teams a much clearer, consistent, and actionable answer.

Your public credential exposure extends beyond the repositories you own

GitGuardian has scanned every commit that has been pushed to public GitHub repositories since 2017, as well as all private commits that became public. That visibility powers our Good Samaritan program, where we alert developers after detecting compromised credentials they accidentally exposed.

GitGuardian customers using the Public Monitoring capacity gain access to the same massive public dataset to identify exposures associated with their organization. Every public GitHub commit is scanned in real time, alongside historical scanning designed to uncover earlier exposures.

One former CISO explained why this visibility was so important after her team expanded its view beyond the repositories they controlled.

"What was very interesting and what we didn't anticipate was that most of the alerts came from the personal code repositories of our developers." - Anne Hardy, Talend

Our case study with Talend found that almost 80% of corporate credential leaks detected on GitHub occurred in developers' personal repositories. They knew this was such a serious issue that the team had even attempted to build its own solution. Personal repositories remained a major blind spot.

The CISA GitHub leak shows what that blind spot can look like

We got another very concrete reminder of this in May 2026. GitGuardian found a public GitHub repository named Private-CISA containing 844 MB of data connected to CISA. Some of the leaked credentials were still valid.

The repository included plaintext passwords and AWS tokens. It also contained Entra ID SAML certificates. There was plenty of operational context around those credentials too. CI/CD logs and Kubernetes configuration exposed details about how systems were deployed. Terraform code and internal documentation provided even more information about the environment.

Developers work across corporate and personal environments. They contribute to open source projects and experiment in their own repositories. Credentials can travel with that work. The repository might belong to the developer, but the credential can still grant the company access.

That is exactly the kind of visibility Public Monitoring was built to provide.

What is public secrets monitoring

Public secrets monitoring watches public development activity for compromised credentials connected to an organization.

GitGuardian Public Secrets Monitoring builds a company public perimeter using developers and GitHub organizations. Company-specific secret graspers add another layer of context. This lets us identify exposures in repositories the company does not administratively control.

The scale makes context essential.

A public repository might contain a perfectly real AWS credential that has nothing to do with your organization. Another repository might belong to someone you have never heard of while containing a credential surrounded by strong signals pointing back to your infrastructure.

Both are secrets. Only one might be yours.

Once a credential becomes public, the identity and permissions behind it determine the real risk.

Finding the secret is easier than deciding whether it belongs to you

Public Monitoring has always had to solve two problems.

First, detect secrets across an enormous public surface. This is rather straightforward to solve and is what drives our work on our secrets detection engine.

The second issue is determining which incidents deserve the attention of a particular company. This gets difficult rather quickly. A cloud credential appears in a developer's personal repository. The developer works for your company, but the credential could belong to a personal cloud account.

Another credential appears in a third-party repository. The repository has no obvious ownership connection to your company, but the surrounding context points to one of your internal services. This was the case with the CISA contractor who used a Yahoo email address.

Simple rules can provide useful clues, but at scale, they leave analysts with a lot of investigative work.

The new Agents Analysis experience makes GitGuardian's company-relevance analysis much easier to understand and use directly from the Public Monitoring workflow.

Company-related verdicts answer the question analysts actually have

Agents Analysis is enabled automatically for GitGuardian customers utilizing the public monitoring capability. All analyzed public incidents receive a Company-related verdict:

A Related verdict means the analysis concluded that the leak belongs to your company.
An Uncertain verdict means the available evidence could not support a definitive conclusion.
An Unrelated verdict means the analysis concluded that the incident does not belong to your organization.
Incidents awaiting analysis remain empty. Only deep analysis can positively confirm an incident as Related.

This gives analysts a much clearer place to begin.

The UX now reflects the question security teams actually need answered: "Does the available evidence indicate that this leaked credential belongs to us?"

The incident list now starts with relevance

The Public Monitoring incident list has also been reorganized around company relevance.

Users now see three new saved views alongside "All" and "Open."

Company-related collects incidents that the analysis connects to the organization.
Unclear if company-related gives analysts a focused queue for ambiguous cases.
Not company-related separates incidents that do not belong in the remediation workflow.

The Company-related and Risk score columns also appear by default.

This creates a much cleaner workflow. Public Monitoring starts with an enormous public dataset. Every irrelevant incident consumes investigation time. Repeatedly pulling a developer into an investigation that turns out to have nothing to do with the company also erodes confidence in the process. Relevance needs to be visible from the moment an analyst opens the queue.

Agent risk scores bring the real credential exposure toward the top

The release of the new Agents Analysis also marks a meaningful evolution in how public incidents are scored. The agent-generated score now accounts for how strongly the incident appears connected to the company, rather than a risk score focused primarily on the secret's characteristics and its exposure.

An incident determined to be Unrelated receives a score of zero. For example, if the platform can determine this was a test credential for an open-source project the developer contributes to, there should be no action needed, just an informational tag added. Any incident awaiting analysis has no score yet, further reducing the number of alerts that require no attention.

A public leak can stay dangerous long after everyone has forgotten the workflow that produced it. Prioritization based on your connection to your org becomes even more valuable when legacy credentials remain active for years. Our State of Secrets Sprawl 2026 revisited valid credentials originally found in 2022. Sixty-four percent were still active and exploitable in January 2026.

The Analysis tab exposes the reasoning behind the verdict

The biggest improvement in this release is the new Analysis tab.

Customers can now open an incident and see how GitGuardian reached its conclusion.

The tab shows the identified company and Company-related verdict. It also provides the reasoning behind that verdict. The Investigation details section shows how the incident moved through triage and deeper analysis when needed.

This gives analysts evidence they can inspect. The analysis might identify a connection with a known developer. It might find company-specific information near the credential. Several signals can combine into a strong case for ownership.

The analyst can compare those findings with their own knowledge and decide what to do next.

Public Monitoring has been doing the difficult work of finding relationships across public exposure for years. The new UI makes much more of that work visible.

Users can tell us when the analysis needs to improve

The Analysis tab now includes feedback controls too.

Users, for the first time, can give the result a thumbs up or thumbs down and optionally leave a comment. This will help us improve results over time and eliminate false positives faster.

Company attribution is a hard problem because every organization leaves a different trail across development infrastructure. Feedback gives us direct evidence about where the agents are getting the analysis right and where they need to improve.

If an incident is clearly yours and the analysis catches it, please tell us. If the analysis gets the relationship wrong, tell us that too.

Public Monitoring is part of a much larger credential layer problem

Public GitHub is only one place where credentials surface. The larger credential layer starts much earlier.

Plaintext credentials can spread through private repositories, local .env files, and internal ticketing systems. Those locations often feel controlled enough that teams tolerate secrets living there longer than they should.

Our data showed that 28% of secrets incidents occur entirely outside code repositories, including collaboration and productivity systems. Only 4% appear in both code repositories and those other sources.

Over time, copies accumulate. A developer can move code into a new repository. Someone can copy configuration into a support thread. A credential that once lived in an internal environment eventually appears somewhere in a public repo.

A public incident can therefore reveal credential sprawl that already existed elsewhere in the organization.

This is why GitGuardian frames the broader problem as credential layer security. We recently explored the same problem in more detail by following how credentials slip through the gaps between security tools.

Public Monitoring extends visibility into public sources where credentials can appear after crossing organizational boundaries. Coverage currently includes public GitHub commits and historical Gists, with additional public sources such as Docker Hub expanding that perimeter.

The goal is a clearer picture of where credentials exist and where they travel. Public Monitoring shows you the part of that credential layer that has crossed beyond your borders.

Agents Analysis is becoming the default Public Monitoring experience

Agents Analysis is now enabled by default for new Public Monitoring workspaces.

New users immediately get the Company-related verdict, agent risk score, Analysis tab, and new saved views.

Existing customer workspaces are being rolled over more gradually because Agents Analysis remains in beta and has not yet been enabled in every dashboard.

We recognize many existing customers already have workflows built around the previous tags and scoring. We want teams to understand how the updated analysis affects those workflows before changing the experience underneath them.

Customers who want to try the experience can work with their Customer Success Manager or contacts at GitGuardian.

Go find out how far your credential layer really extends

Public Monitoring gives you a useful place to start examining your true credential exposure.

We would be happy to show you the credentials GitGuardian believes belong to your organization and let you inspect the Analysis tab and inspect the evidence.

You should be asking how much of your credential layer exists outside the systems your security team currently controls. The GitGuardian platform can give you visibility into your part of that problem.

See the GitGuardian Platform's Public Monitoring workflow in action, including how we define your perimeter, how you can automate remediation, and how to leverage the explore functionality.

FAQ

How does the GitGuardian Platform monitor public GitHub for leaked secrets?

The GitGuardian Platform scans every commit pushed to public GitHub in real time and performs historical scanning to uncover earlier exposures. It connects those findings to your company's public perimeter using signals such as developers, GitHub organizations, and secret graspers.

Can company credentials leak through developers' personal GitHub repositories?

Yes. Personal repositories are a major blind spot because developers routinely work outside company-owned GitHub organizations. In our Talend case study, former CISO Anne Hardy said most of the alerts her team discovered came from developers' personal code repositories.

How does GitGuardian know whether a public secret belongs to my company?

The GitGuardian Platform first uses organizational context to connect a public incident to your company perimeter. Agents Analysis then evaluates the available evidence and can classify the incident as Related, Uncertain, or Unrelated.

How does Agents Analysis help reduce noise from public secret monitoring?

Agents Analysis brings company relevance directly into the investigation workflow. Analysts can start with the Company-related view, focus human review on Unclear if company-related incidents, and move unrelated exposures out of the primary remediation queue.

Can I see why GitGuardian classified a public secret as company-related?

Yes. The Analysis tab shows the Company-related verdict and the reasoning behind it. Analysts can also inspect the risk-score rationale and see how the incident progressed through triage and deeper analysis.

What happens if Agents Analysis gets a verdict wrong?

Users can give the analysis a thumbs up or thumbs down directly from the Analysis tab and optionally leave a comment. That feedback helps improve company attribution over time and gives GitGuardian direct evidence about where the analysis needs to get better.

AI Agent Authorization Beyond Authentication: A Look At AWS Dogwood

Dwayne McDaniel — Wed, 07 Oct 2026 12:32:13 +0000

TL;DR:

Credentials conflate authentication and authorization: Long-lived API keys, tokens, and certificates grant standing access to whoever holds them, making blast radius depend on permissions, not just validity.
AWS Dogwood adds temporal policy for agents: Released in August 2026 and built on Cedar, Dogwood evaluates sequences of prior actions, not just point-in-time requests, to authorize AI agent tool calls.
GitGuardian secures the credential layer underneath: Secret Analyzer adds permission context and the Exploration Map traces consumers and resources, helping teams migrate off long-lived secrets as leaks tied to AI grew 81% in 2025.

Most credentials grant standing privilege to the identity holding them

Credentials have always sat at the intersection of authentication and authorization. Unfortunately, we have historically combined these two related but separate ideas into single bits of data used by users, workloads, and increasingly, AI agents.

Every time someone in the org creates an API key, access token, certificate, or other secret, what they are really generating is an access path. That same credential also carries permissions. If and when the credential is copied into a CI/CD pipeline, application configuration, or local development laptop, that standing access becomes available to anyone who can gain access to it.

That model powered modern software for decades. It also created one of the hardest security problems security teams now face.

Short-lived, verifiable authentication grants are a move in the right direction

The industry has been steadily moving toward workload identity, short-lived credentials, and stronger separation between proving identity and deciding what that identity should be allowed to do. SPIFFE established a practical standard for workload identity, while SPIRE provides a production-ready implementation based on workload and node attestation. SPIFFE itself focuses on identity and authentication, leaving authorization policy to other systems.

Cloud-native approaches have been moving in the same direction for years. AWS Security Token Service lets workloads exchange trusted identity for temporary security credentials rather than depending on permanent access keys. AWS itself recommends temporary credentials for workloads to reduce the exposure created by long-lived keys.

While many teams focus on authentication, authorization is also on the minds of the identity professionals. The IETF's WIMSE working group is extending the conversation with standards work around workload identity across multi-system environments to explicitly address authorization for workloads while reducing their dependence on long-lived secrets.

AI agents make the authorization side of this evolution much more urgent. Agents can authenticate successfully and still make a dangerous decision. It may have a valid identity, use an approved tool, and call a resource it is technically permitted to reach. The harder question is whether that agent should be allowed to take this particular action, at this particular moment, based on everything it has already done.

AWS Dogwood is one of the most interesting new efforts aimed directly at that question.

Authentication vs. Authorization for Workloads and AI Agents

Authentication answers who or what is making a request. Authorization answers what that identity is allowed to do. Static credentials often blur those two concepts.

For most IT and SaaS, whoever possesses the key someone generated once, for likely a well-intentioned reason, can exercise those permissions until the key expires, is rotated, or is revoked.

That means the blast radius of a leaked secret depends on more than whether the secret is valid. Security teams also need to understand the permissions, roles, resources, and systems behind it.

This is becoming a central problem in non-human identity security, as we saw many people discuss at Identiverse 2026. Identity teams now talk about architectures that separate attestation, identity, and authorization. The goal is to move away from long-lived credentials and toward short-lived, attributable access that can be evaluated at runtime.

Autonomous agents are forcing us to have this conversation faster than most teams are ready for it. Proving that an agent has a trusted identity only answers the first part of the access decision. Security teams still need to decide what that identity should be able to reach and which actions should be permitted.

From RBAC and ABAC to Runtime AI Agent Authorization

Authorization is not a new concept, and we have already seen it go through several major evolutions.

Role-based access control (RBAC) associates an identity with a role and gives that role permissions.

Attribute-based access control (ABAC) adds more context by considering information about the identity, resource, requested action, or environment.

Relationship-based systems can evaluate how an identity relates to a resource. Cedar, the AWS open-source access control language, or Open Policy Agent, move those authorization decisions into centrally managed policy that can be evaluated consistently at runtime and represented as code or configuration.

Every evolution has added the same thing: more context. But the fundamental question remains: "should this identity be allowed to perform this action on this resource?"

Agentic systems introduce one more dimension. And sometimes the answer depends on what happened before. That is where AWS Dogwood comes in.

What Is AWS Dogwood?

AWS Dogwood was introduced in August 2026 as an open-source governance language for AI agents and their tools. Dogwood builds on Cedar while adding the ability to evaluate sequences of events through temporal policy.

Policy engines like Cedar are designed for point-in-time authorization decisions. A policy can evaluate a principal, action, resource, and the context surrounding the current request, then determine whether the request should be permitted.

That works well for questions such as whether an agent can read a file, whether a workload can invoke an API, or whether a service can write to a particular resource.

Agent workflows create situations where the safety of the current action depends on earlier actions.

Imagine a trading platform where someone has deployed an agent to sell shares when certain trends appear. Any individual sale, by itself, may meet normal authorization policy. An organization may also require a human to approve that exact sale within the previous hour. Evaluating only the current request cannot prove that the required sequence occurred.

Dogwood adds temporal conditions that let policies examine recent event history alongside the current request. This missing context is why so many rule-based systems struggle with event-based architectures.

This central focus of historical action context is what allows their authorization policies to express rules requiring human approval before an action, limits the number of tool calls during a period, maintains a running total across multiple transactions, and restricts later actions after an agent has accessed sensitive information.

For autonomous systems, leveraging history for making these decisions at machine speed becomes critical in many situations. Security teams set policy that asks whether an agent should call this tool given everything relevant that has already happened during the session, not just if, in isolation, the request should be allowed.

Why AI Agent Authorization Needs Workflow Context

Agentic systems can create risk across an entire sequence of individual turns that each appear benign.

Reading a sensitive file may be permitted. Making an outbound request may also be permitted. Reading sensitive information and then sending that information to an external system creates a very different security outcome. The ability to do all three is what security researcher Simon Willison calls the "lethal trifecta."

AWS designed Dogwood around exactly that sequence and the real-world risks it introduces.

Dogwood's temporal conditions can examine prior tool requests and their outcomes. The system can generate an action schema from tools exposed through the Model Context Protocol (MCP), which are the basis for the majority of emerging agent architectures in the enterprise.

AI agent security increasingly comes down to the credentials and permissions an agent can reach. Manipulating an agent becomes far more damaging when that agent can access highly privileged credentials or systems. In other words, credentials and permissions determine the real blast radius of agentic AI security incidents.

Agents are also frequently operating with credentials originally created for humans, applications, or development workflows. That creates another identity problem because the agent inherits the authority of whoever supplied the credential.

Runtime authorization at the tool boundary gives organizations another control point for limiting that authority.

How Dogwood Fits With OAuth, AuthZEN, and Modern IAM

Dogwood is part of a larger modernization of identity and access management.

It fits with the general evolution where OAuth provided a framework for delegated authorization and where OpenID Connect added an identity layer. Technology like SPIFFE and SPIRE increasingly let machines exchange trusted identity for short-lived access without storing permanent shared secrets.

AuthZEN adds context pointing towards intent

The OpenID Foundation finalized AuthZEN Authorization API 1.0 in January 2026. The specification defines a common interface between a Policy Enforcement Point and a Policy Decision Point. Applications can request an authorization decision without needing to understand the implementation of the policy engine producing it.

AuthZEN and Dogwood are largely complementary and are both attempts to broadly answer the question of authorization intent.

AuthZEN can standardize how the authorization request reaches the decision point. Dogwood can make that decision point capable of answering harder questions by evaluating the current request together with the agent's recent history.

The broader architecture starts to become much clearer.

Modern IAM is increasingly moving toward stronger workload identity, shorter credential lifetimes, externalized policy decisions, and more context around authorization.

We are increasingly seeing teams adopt access paths where each workload proves its identity via short-lived credentials or tokens that carry that identity to another system. This identity is carried to an enforcement point where an authorization service evaluates the identity, requested action, resource, current context, and potentially the sequence of events that led there.

That enforcement point then allows or blocks the action.

Any authentication modernization has to be paired with privilege containment, ownership, lifecycle governance, and continuous exposure monitoring. Otherwise, how do you have enough context about what to authorize?

Modern IAM Authorization Does Not Erase Legacy Credentials

There is a practical problem inside almost every established organization.

Teams are designing new systems around workload identity, OAuth, OIDC, federation, temporary credentials, and richer authorization policies. Years of existing infrastructure still depend on API keys, personal access tokens, service account credentials, certificates, database passwords, and other long-lived secrets.

Those credentials continue to carry standing access. That standing access is part of the organization's existing identity infrastructure.

Directories and IAM systems may understand the identity and policy, while the credential itself has been copied through repositories, pipelines, tickets, developer machines, or application configurations. GitGuardian found 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34% year-over-year increase. Credential leaks associated with AI services grew 81%.

Teams need a map of the standing permissions they already have in order to embrace future-looking authentication via modern workload identity and authorization tech like Dogwood.

GitGuardian Secret Analyzer Shows What a Credential Can Do

Finding a secret answers one important question: where is the credential exposed?

Remediation requires understanding what access sits behind it.

GitGuardian Secret Analyzer enriches supported credentials with information such as roles, permissions, ownership, and related context. This helps teams distinguish between credentials of the same type that carry very different levels of authority.

A narrowly scoped read token presents a different risk from a token with administrative permissions. A valid secret capable of modifying critical resources represents a much larger blast radius. This is where secrets security and IAM authorization meet.

As organizations move toward workload identity and short-lived access, they need to understand the standing privileges attached to the long-lived credentials they plan to remove. Secret Analyzer provides the context for what permissions a secret grants that can help teams prioritize which credentials require immediate attention and understand what access needs to be reduced, recreated, or eliminated during migration.

GitGuardian is also extending privilege context across non-human identities. NHI Governance can surface admin and overprivileged identities across AWS, Microsoft Entra, and Okta, connecting credential exposure to the authority behind the identity.

The Exploration Map Reveals Credential Blast Radius

Permissions are only one part of the migration problem; security and IAM teams also need to understand where a credential lives, what consumes it, which resources it reaches, and what might break when it is revoked.

GitGuardian's Exploration Map brings those relationships together.

For a non-human identity, the map can show where secrets are stored in secret managers, which consumers use them, which resources those consumers access, the permissions associated with those resources, and the public or private incidents connected to that identity.

That context becomes especially useful while replacing long-lived credentials.

A team may discover an AWS key in source code and decide that the workload should move to temporary credentials or workload identity. Before revoking the key, responders need to identify every application, job, deployment pipeline, or service that still depends on it.

They also need to understand the permissions currently attached to the credential. Otherwise, the replacement identity can easily recreate years of accumulated privilege.

The Exploration Map gives security, development, and IAM teams a shared picture of that transition.

Secure the Credential Layer While Modernizing Authentication and Authorization

Dogwood is an important step in the evolution of AI agent authorization because it recognizes that identity and point-in-time permissions only tell part of the story. Autonomous systems create sequences of actions, and authorization policy increasingly needs to understand those sequences.

Workload identity, temporary credentials, standardized authorization APIs, and runtime policy are giving organizations better ways to authenticate machines and control what they can do. GitGuardian is helping teams make that transition with visibility into the credential layer they already have.

The GitGuardian platform is focused on detecting secrets across the places developers, workloads, and agents actually use them, wherever they are living in plaintext.

As you adopt workload identity and authorization approaches such as Dogwood, start by understanding the credentials that still carry your existing access. Detect them. Understand what they authorize. Remediate the standing access they represent. Prevent the next generation of workloads and AI agents from rebuilding the same credential sprawl.

Get started with GitGuardian and secure your credential layer as your organization moves toward short-lived workload identity and runtime authorization.

FAQ

What is AWS Dogwood?

AWS Dogwood is an open-source governance language for AI agents and their tools, introduced in August 2026. It builds on Cedar by adding temporal policy that evaluates sequences of prior actions alongside the current request, rather than authorizing each request in isolation.

How is authorization different from authentication for AI agents?

Authentication answers who or what is making a request. Authorization answers what that identity is allowed to do. An agent can authenticate successfully with a valid identity and still take a dangerous action if the authorization decision doesn't account for what it has already done.

Why do AI agents need authorization based on history, not just current requests?

Individual actions like reading a sensitive file or making an outbound request may each be permitted on their own. Reading sensitive data and then sending it externally creates what security researcher Simon Willison calls the "lethal trifecta," a risk that only becomes visible when policy considers the sequence of events rather than a single point-in-time request.

How does AWS Dogwood fit with AuthZEN and OAuth?

These technologies are complementary. AuthZEN, finalized by the OpenID Foundation in January 2026, standardizes how an authorization request reaches a policy decision point. Dogwood makes that decision point capable of evaluating harder questions by examining an agent's recent history alongside the current request, building on the broader shift toward workload identity, OAuth's delegated authorization, and OpenID Connect's identity layer.

Does workload identity and modern authorization eliminate the need for credential security?

No. Most organizations still depend heavily on long-lived API keys, personal access tokens, and other static credentials that carry standing access. GitGuardian found 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34% year-over-year increase, with leaks tied to AI services growing 81%. Modernizing authentication and authorization has to be paired with visibility into those existing credentials.

How does GitGuardian help teams migrate to workload identity and runtime authorization like Dogwood?

GitGuardian Secret Analyzer adds permission context to exposed credentials, showing roles, ownership, and authority so teams can prioritize which secrets need immediate attention. The Exploration Map connects identities, consumers, secrets, resources, and incidents so teams can see what depends on a credential before revoking and replacing it with short-lived, workload-based access.

Generative AI Security: Are Your Developers Pasting Secrets Into LLMs?

Dwayne McDaniel — Tue, 06 Oct 2026 12:53:15 +0000

TL;DR

81% jump in AI-service leaks: GitGuardian detected over 1.27 million leaked secrets tied to AI services in 2025, an 81% jump from the previous year, with AI-assisted code leaking secrets at roughly twice the GitHub-wide rate.
Hundreds of incidents in weeks: One customer deployed GitGuardian behind their internal AI gateway and surfaced hundreds of secret incidents within weeks, a significant share valid at detection, none of which ever touched a git repository.
Four-step scan via Custom Source: The AI gateway forwards each payload to GitGuardian's scan API tagged with a Custom Source UUID, scans it in memory through 600+ detectors, and creates incidents without storing the content.
Two-week non-blocking test: Non-blocking mode lets a request through and logs the incident so revoking valid findings and measuring real exposure over two weeks is possible, while blocking rejects the request before the provider is called, skipping rotation.

One customer deployed GitGuardian behind their internal AI gateway. Within weeks, we had surfaced hundreds of secret incidents flowing through it, a significant share of them valid at the time of detection.

None of them ever touched a git repository. They went straight from a developer's terminal or IDE into a prompt or a tool call, and out to a third-party model provider.

This tracks with what we see at scale. Across 2025, secrets leaked from AI-assisted code at roughly twice the GitHub-wide rate, and GitGuardian detected over 1.27 million leaked secrets tied to AI services, an 81% jump from the previous year. Those figures come from code we can see. Prompt traffic is the part nobody is counting.

The channel nobody scans

The behavior that creates the exposure is mundane. A developer debugs a failing request and pastes the whole curl command, headers included. Someone drops a .env file into a chat window and asks the model to explain a variable. An agent reads a config file and forwards it as context on a tool call. Nobody is being careless on purpose. They are pasting a hundred lines and not reading all hundred.

Secrets detection matured around code. Repositories, CI logs, container images, ticketing tools. Prompts are newer ground, and coverage is uneven.

Part of it is already solved at the source — ggshield AI Hooks scan prompts, tool calls, and tool output inside Cursor, Claude Code, Codex, and VS Code with Copilot, and block the action before it reaches the model. Deploy them across your fleet. It is the earliest and cleanest place to catch a secret.

The two controls do different jobs, and the parallel with git will be familiar. AI Hooks are your pre-commit: closest to where the mistake happens, best remediation experience, scoped to the tools and machines you deploy them on. The AI gateway is your pre-receive: further from the developer, but it sees every request that crosses it. The agent running in CI. The batch job calling a model API. The internal app nobody classified as an AI tool, classic shadow AI territory. You want both.

Three things make this worse than the equivalent paste into a Slack thread:

The content leaves your perimeter immediately. It goes to a third party, under that provider's retention terms, not yours.
Nothing persists on your side by default. A commit sits in a repo you own and can scan retroactively. Prompt traffic is gone the moment it is sent, unless you capture it in flight.
Agent traffic carries more. An agent ships whole files as context. A human question ships a sentence.

Why your AI gateway is the right place to catch it

A growing number of engineering organizations already route LLM traffic through a single internal AI gateway, sometimes called a LLM proxy or LLM gateway. They do it for cost attribution, rate limiting, model routing, and to avoid handing provider API keys to every developer. The AI gateway gives their developers one service with a single base URL regardless of which provider serves the request.

That AI gateway also sees every prompt, every tool call, and every response. It is the one place where this traffic is already in cleartext and already yours.

One detail makes the idea practical: latency matters far less here. A model call already takes seconds. A scan on top is noise against that baseline. Put the same approach on a standard network proxy, and the delay becomes unacceptable. On an AI gateway, the budget is already there.

How it works

The pattern is four steps.

Your AI gateway receives a request headed for a model provider.
The AI gateway forwards the payload to GitGuardian's scan API, tagged with your Custom Source UUID. We scan in memory and return findings. The content is not stored.
GitGuardian runs it through 600+ detectors and creates incidents in your dashboard.
The AI gateway either forwards the request or blocks it, depending on the mode you choose.

Blocking or non-blocking

Both work. The trade-off is real, so decide deliberately.

Non-blocking. The request goes through, and you get the incident. The credential reached the provider, so revoke every valid finding. In exchange, you get measurement: two weeks tells you how much you are actually leaking.

Blocking. The AI gateway rejects the request and never calls the provider. The developer removes the credential and retries. That costs a minute and saves you a rotation. Settle one thing first: how a developer reports a false positive.

Start non-blocking to size the problem, then switch once you trust the signal.

Implementation

Prerequisites

A GitGuardian account with Custom Sources (BYOS) enabled
An AI gateway you control
A service account with scan and scan:create-incidents permissions

Step 1: Create the Custom Source

In your GitGuardian dashboard, go to Settings → Integrations → Sources, then Secrets scanning → Add Custom Source. Name it something like "AI Gateway". Copy the UUID it generates.

Step 2: Create a service account

Create a dedicated service account with the scan and scan:create-incidents permissions. Store the token in your secrets manager, not in the AI gateway config.

Step 3: Send the payload to GitGuardian

Post the content to /v1/scan/create-incidents. The body takes your source UUID and a list of documents:

{
  "source_uuid": "YOUR_SOURCE_UUID",
  "documents": [
    {
      "filename": "prompt.txt",
      "document": "<content to scan>",
      "location": { "url": "https://ai-gateway.internal/v1/models/<model>/invoke" }
    }
  ]
}

location.url is optional and worth setting. It points back to your AI gateway log entry, so whoever triages the incident can find the request that produced it.

From inside the AI gateway, that is one call:

import requests
response = requests.post(
    f"{GITGUARDIAN_API_URL}/v1/scan/create-incidents",
    headers={"Authorization": f"Bearer {GITGUARDIAN_API_KEY}"},
    json={
        "source_uuid": GITGUARDIAN_SOURCE_UUID,
        "documents": [
            {
                "filename": "prompt.txt",
                "document": prompt_payload,
                "location": {"url": request_log_url},
            }
        ],
    },
    timeout=5,
)

Set GITGUARDIAN_API_URL to:

https://api.gitguardian.com for SaaS US
https://api.eu1.gitguardian.com for SaaS EU
https://gitguardian.example.com/ if you self-host.

Two limits shape your batching: 20 documents per call, and a maximum scan size that depends on your plan.

Step 4: Decide what to send

Start with the request: the prompt itself, plus the arguments of any tool call. That is where credentials show up.

Model responses are worth scanning too, because an agent that reads a config file and summarizes it back will happily repeat the credential. This only applies in non-blocking mode. If you block, you reject the request before the provider is ever called, so there is no response to look at.

Step 5: Route the incidents

Filter your dashboard by the Custom Source name to isolate AI gateway findings, and set up a dedicated notification rule.

Remediation is more contained here. There is no artifact of your own to clean up, because the copy that matters now sits with a third party. Assess the blast radius of the credential first, then rotate it, or revoke it and issue a new one if the provider does not support rotation in one step.

Check out this example implementation.

What this costs you

Be honest about the hard part. The scan integration is a few hours of work. Getting all LLM traffic through the AI gateway in the first place is a network and IT project.

You need provider endpoints resolved through your gateway, enforced across the fleet via MDM or VPN policy. And you need to accept that a developer who disconnects from the VPN can bypass the whole thing. This is coverage, not containment. It still beats zero visibility.

The pattern generalizes

An AI gateway is one instance of a broader idea. Anywhere content passes through a chokepoint you own, on its way somewhere you do not control, you can scan it. File-sharing services can scan an upload before generating the public link. Outbound mail gateways can bounce a message carrying a credential back to the sender. Diagnostic bundle generators can flag secrets before the file reaches a support ticket.

Same shape every time: a chokepoint, an acceptable latency budget, and content leaving your control. More on these in a future post.

Where to start

Pick a chokepoint you already own where text leaves for a third party. For most engineering organizations today, the AI gateway is the obvious one. Create a Custom Source, wire it in non-blocking mode, and run it for two weeks to size the problem. Then turn on blocking.

Book a demo | BYOS documentation

This is the fifth post in our "Bring Your Own Source" series. The previous ones covered n8n workflow integration, Salesforce, GitLab CI, and GitHub Gists.

This article was written by Romain Jouhannet, Product Manager at GitGuardian.

FAQ

What is an AI gateway?

An AI gateway is an internal proxy or control layer that engineering teams place between their applications and AI model providers. Instead of every application calling OpenAI, Anthropic, or another provider directly, model traffic can flow through a common endpoint. Teams use AI gateways for capabilities such as centralized credential management, cost attribution, rate limiting, observability, and model routing. In this post, we use AI gateway and LLM proxy broadly to describe this same architectural pattern, although some platforms distinguish between a lightweight proxy and a more feature-rich gateway.

What is an LLM proxy?

An LLM proxy is an endpoint that sits between applications, agents, or CI jobs and the model providers they call. When model traffic passes through the proxy, it can inspect prompts and responses before forwarding them upstream, making it a practical enforcement point for detecting exposed secrets. GitGuardian's Bring Your Own Source integration can be used to send this traffic to GitGuardian's secrets detection engine for scanning.

What is generative AI security?

Generative AI security includes protecting credentials and other sensitive data from leaking through the ways developers, applications, and agents interact with generative AI systems, for example through pasted commands, configuration files, prompts, or model API calls. Complementary controls can operate at different points in that flow: developer-side protections can catch secrets before they reach a model, while an AI gateway or LLM proxy can inspect model traffic further downstream across applications, agents, and automated workflows.

AI Coding Agents Are Leaking Credentials: Cursor, Claude Code, Copilot, and MCP

Dwayne McDaniel — Sun, 04 Oct 2026 15:51:12 +0000

TL;DR

The hidden trail: Cursor, Claude Code, and GitHub Copilot store credentials across config files, env variables, logs, shell history, and temp files that repository and CI scanners never inspect.
The evidence: GitGuardian's State of Secrets Sprawl 2026 found 24,008 unique secrets in public MCP configuration files, 2,117 of them valid, plus a 3.2% leak rate in Claude Code-assisted commits.
The fix: GitGuardian Developer Endpoint Protection discovers this trail fleet-wide with local agent inventory, machine scanning, AI hooks, and honeytokens, so security teams can remediate before compromise.

How AI coding agents handle credentials

Agentic coding tools can read files, run commands, and call external services. Authentication to model providers, source-control platforms, and connected tools creates several ways for credentials to remain on the endpoint:

Stored: API keys and tokens can be placed in agent or MCP configuration. Some tools instead use an OS keychain or OAuth flow.
Copied: a credential retrieved from a vault or environment can be written to a local file for debugging or reuse, leaving an unmanaged copy.
Recorded: prompts, command output, debug logs, and session history can capture a credential when redaction is absent or incomplete.

Some of these files can be committed accidentally but many never enter a repository at all.

On one well-managed workstation, these artifacts may look like isolated hygiene issues but in a large organization with decentralized tooling, contractors, multiple business units, and inconsistent endpoint policy, the same pattern multiplies across the fleet. Security may know which repositories it scans while still lacking an inventory of the agents, MCP servers, and standing credentials on the machines that access them.

Here's what the trail looks like, tool by tool.

Cursor

Cursor keeps two MCP configurations: one inside the project, which travels with the repository, and one in the user's home directory, which never enters a repository. Both accept inline credentials, as environment variables for local servers or as request headers for remote ones. Cursor's MCP docs also describe OAuth for remote servers and variable references in place of values, but neither is enforced.

The project file sits inside the repository, so one inline token can be committed and distributed to every developer who clones it. The user-level file creates the opposite problem: credentials and server definitions can remain entirely outside repository controls. In a large fleet, different teams can connect Cursor to different internal systems with different tokens, scopes, and storage practices. Without endpoint inventory, security has no reliable way to see that population or determine which machines hold access to sensitive services.

Claude Code

Claude Code keeps user state in a home directory plus a companion JSON file that holds the sign-in session, user-level MCP servers, and per-project trust decisions. The login token is the best-protected item on the machine: it lives in the OS keychain on macOS and in a permission-protected file on Linux and Windows. Anthropic's docs add that macOS falls back to that file when the Keychain is unavailable, such as in an SSH session. Protecting the primary login token does not inventory the API keys, connection strings, and tool credentials the agent can encounter elsewhere on the machine.

Claude Code's project-scoped MCP file is designed to be checked into version control so a team can share its setup. The tool supports environment-variable references and keychain storage for OAuth tokens, but nothing prevents a team from writing a token inline. When that happens we know the story, the file is pushed and pulled everywhere, copying the token into repository history and onto every machine that receives the configuration.

GitHub Copilot

Copilot's endpoint footprint varies across the editor, CLI, operating system, and authentication method. That variation is itself a governance problem: a security team cannot apply one file-path rule and assume the fleet is covered. Copilot CLI and Claude Code both let a developer relocate their entire state directory with an environment variable.

Copilot CLI stores its OAuth token in the operating system's keychain by default. When no keychain is available, GitHub's docs describe a prompt to store it in a plaintext config file instead, and a setting that makes that the default.

The primary token is only part of the trail. The same directory holds MCP server definitions, session logs, command and session history, a SQLite session store, saved permission decisions, and fallback storage for MCP OAuth material when no keychain is available (directory reference). Across a large fleet, even a minority of machines using plaintext fallbacks, environment tokens, or overprivileged MCP configurations creates a material credential inventory that repository scanning cannot reach.

Where each tool keeps its state

Paths as documented by each vendor in September 2026. They change often, so check the linked page before writing a policy rule on one of them.

Tool	MCP configuration	Other user-level state	Vendor docs
Cursor	`.cursor/mcp.json` in the project, `~/.cursor/mcp.json` for the user	`~/.cursor/`	MCP
Claude Code	`.mcp.json` in the project, user-level servers in `~/.claude.json`	`~/.claude/` and `~/.claude.json`. Login token in `~/.claude/.credentials.json` on Linux, the same file under the user profile on Windows, and as the macOS fallback. Relocatable with `CLAUDE_CONFIG_DIR`	MCP, authentication
Copilot CLI	`~/.copilot/mcp-config.json`	`~/.copilot/`: `config.json` (plaintext token fallback), `logs/`, `session-state/`, `session-store.db`, `permissions-config.json`, `mcp-oauth-config/`. Relocatable with `COPILOT_HOME`	authentication, directory reference

MCP servers: when configuration becomes a credential store

Model Context Protocol servers let agents reach systems such as source control, cloud providers, databases, SaaS applications, and internal services. Each new connection can introduce another non-human identity and another credential with real organizational access. MCP supports OAuth, environment-variable references, credential stores, and runtime helpers, but those safer patterns are not automatically enforced across unmanaged installations.

When credentials are written inline, the MCP configuration files of all three tools become plaintext credential stores. Project-scoped files may also be shared through version control. GitGuardian's State of Secrets Sprawl 2026 analysis found 24,008 unique secrets in public MCP-related configuration files, including 2,117 valid credentials. Public repositories expose the visible portion but enterprise endpoints and internal repositories can hold the same pattern outside public view.

Why this trail grows faster than your hygiene

Shadow AI scales faster than policy. Individual teams can add agents and MCP servers in minutes, while security reviews, procurement, MDM policy, and identity governance move on a different timescale. Fleet inventory can be outdated before it is complete.
The surface compounds across the fleet. Each integration can introduce another identity, credential, configuration path, permission decision, or history store. Multiplied by thousands of developers, small local exceptions become governance issues fast.
AI-assisted workflows show a higher observed leak rate. GitGuardian's State of Secrets Sprawl 2026 analysis found a 3.2% secret-leak rate in public commits assisted by Claude Code versus a 1.5% baseline across all public GitHub commits. For sure, the measurement does not assign causation to the tool alone, but it shows that faster development has not removed the underlying credential failure problem.

What your existing controls miss here

Existing controls can work exactly as designed and still leave this layer uncovered:

Repository, pre-commit, and CI secret scanning cover tracked content, working-tree changes, or pipeline inputs according to their configuration. They do not traverse unrelated home-directory config, browser stores, shell history, or temporary files.
IdP, IAM, and PAM govern identities and sessions they issue or observe. Locally copied API keys and unmanaged third-party tokens fall outside that perimeter.
Secrets managers protect credentials stored in and retrieved through the vault. They cannot govern an unmanaged copy after it has been written to a log, history file, or temporary file unless another control discovers it.

In a large enterprise, that unmeasured gap grows every time a developer adds an agent, connects a new MCP server, or copies a token to make local work move faster. The missing control is a fleet-wide credential discovery on the device.

How GitGuardian Developer Endpoint Protection closes the gap

Developer Endpoint Protection turns this invisible endpoint problem into a fleet-level security program, with four independently deployed capabilities:

Local agent and MCP inventory: visibility into which supported AI agents and MCP servers run on each endpoint, plus the data and tools they can access and how they are used.
Machine scan: scheduled filesystem scans covering config files, dotfiles, logs, IDE and agent caches, shell history, temporary directories, browser storage, archives, and other supported formats. Findings are scored by severity and access scope.
AI hooks: real-time scanning through supported AI coding-tool hooks. Prompt submission and pre-tool checks can block secrets in prompts, commands, file reads, and MCP calls. Post-tool checks notify the developer because the tool has already run.
Honeytoken protection: a decoy AWS credential planted on each protected machine. It grants no access, and any attempt to use it raises an alert tied to that endpoint.

Three design choices matter for how it fits your environment.

Privacy: detection happens locally. GitGuardian receives a 256-bit Scrypt fingerprint through the HasMySecretLeaked protocol, finding metadata such as file path and timestamp, and machine and user inventory metadata. GitGuardian does not receive the plaintext secret or source-file contents. Optional validity checks send the credential directly from the endpoint to its provider, not through GitGuardian.
Deployment: the recommended approach is an MDM-scheduled script, not a continuously running EDR-style agent; launchd, systemd, and configuration-management deployments are also documented.
Fit: it complements repository and CI scanning, vaults, IdP, PAM, EDR, and DLP rather than replacing them. After a compromise, teams can rank findings by severity and privilege, create incidents, and follow the remediation workflow to revoke or relocate credentials and redact supported local occurrences.

How the GitGuardian Mixin Kit Extends Docker Sandboxes for Safer AI Coding

Dwayne McDaniel — Fri, 02 Oct 2026 12:34:10 +0000

TL;DR

A partnership for security: Our new Sandbox Mixin Kit pairs Docker's isolated agent environments with GitGuardian's secret-scanning hooks for safer AI-assisted coding.
Two layers of protection: Docker Sandboxes isolate and protect what a coding agent can reach on a developer's machine, while GitGuardian's ggshield checks prompts, actions, and tool output for exposed credentials.
Ready to use: The mixin installs ggshield and configures AI hooks automatically, so teams get deterministic secret protection the moment a sandboxed agent starts working, no manual setup required.

GitGuardian is proud to partner with Docker to secure secrets

GitGuardian is focused on securing the credential layer. We help teams discover what credentials exist, remediate the ones that pose risk, and prevent secrets from continually sprawling across the enterprise.

That work, and the secrets layer itself, now includes the rapidly growing world of agentic development.

We are proud to partner with Docker as GitGuardian has published a Docker Sandbox Mixin Kit

This kit automatically installs GitGuardian's ggshield and enables AI hooks, giving developers a safer way to use autonomous coding assistants inside a controlled environment.

Agent security needs more than one control. The environment itself needs boundaries, and the credentials moving through that environment need protection too. Docker Sandboxes and GitGuardian address those two parts of the problem together.

Before digging into how the mixin kit works, let's first look at what it is designed to protect. Coding agents can read, execute, connect, and act across a surprisingly large part of a developer's environment, and those capabilities change the way teams need to think about credential security.

Why You Should Use Docker Sandboxes

Coding assistants are now a common part of everyday software development. Developers of all backgrounds and skill levels, including the rapidly growing ranks of "citizen developers," use tools like Claude Code, Cursor, Codex, and GitHub Copilot to write applications and automate work that once required a lot of manual steps.

To do anything meaningful, the agent needs access.

Docker Sandboxes treat the coding agent as an autonomous workload and give it its own environment. Each sandbox runs inside an isolated microVM where the agent can execute commands, install dependencies, and use development tools without gaining unrestricted access to the host machine.

That boundary is vital, as laptops have become dense credential stores. Our research found an average of roughly 150 secrets per developer endpoint in its early access program, with some systems containing thousands. Around 40% of the high and critical secrets discovered appeared in AI tool directories and log files.

Credentials accumulate across .env files, shell histories, MCP configurations, cloud CLI profiles, local configuration files, and AI agent caches. When an agent operates directly in that environment, those credentials can become part of its reachable attack surface.

Docker Sandboxes reduce that reach before the agent starts working. Workspace scoping limits which local files exist from the agent's perspective, network policy controls where it can connect, and sensitive credentials can remain outside the microVM and be injected by Docker's host-side proxy only when an approved request needs them.

Docker SandBox architecture with GitGuardian's Mixin Kit

This gives developers enough freedom to let an agent install, build, test, and iterate while giving security teams a much clearer boundary around what that autonomy can touch.

Docker Sandbox Mixin Kits turn isolation into a paved path

A fresh sandbox gives an agent isolation, but it also starts without any of the tools, configuration, network permissions, and integrations developers expect in a working environment. Docker created Kits, including mixin kits, to package those capabilities so they can be applied consistently when a sandbox is created.

A mixin can install tools, add configuration and files, define network rules, configure credential handling, and provide instructions to the agent. Multiple mixin kits can be stacked together for a particular workflow simply by adding additional --kits <targeted mixin> when invoking sbx. The developer is no longer starting with an empty security boundary, but with an environment where an agent can actually get work done.

Mixin kits can drive sandbox adoption

When developers have to spend time reinstalling packages, rebuilding configuration, resolving blocked services, or manually supplying credentials every time they enter an isolated environment, running the agent directly on the host becomes the easier path. That is not a good thing.

One of the most promising security trends has been the platform-engineering lessons of paved roads and golden paths. The CNCF describes standardized, tested paths as a way to make common capabilities easier to consume, while research around developer experience consistently emphasizes self-service workflows and built-in guardrails as ways to reduce cognitive load and friction.

For Docker Sandboxes, mixins are the mechanism that turns isolation into that paved path: the secure environment arrives with the capabilities developers need instead of asking every developer to rebuild it themselves.

GitGuardian's ggshield AI hooks add deterministic secret checks

Docker Sandboxes control what an agent is allowed to reach, while GitGuardian's AI hooks add credential-aware checks to what moves through the agent workflow. Via ggshield, developers can easily integrate with the native hook systems in Cursor, Claude Code, Codex, and VS Code with GitHub Copilot, using GitGuardian's detection engine to scan for secrets.

Once installed, these checks happen automatically as the agent works, creating deterministic security checkpoints inside an otherwise non-deterministic workflow. The full setup and behavior are documented in GitGuardian's Secret scanning for AI coding tools documentation.

The three current ggshield AI hooks

While each agent provides hooks for multiple workflow events, GitGuardian has started with the three where an agent would most likely have encountered a secret outside of its environment.

The first hook runs when a prompt is submitted. Before a developer's prompt reaches the AI model, ggshield scans it for secrets and blocks the prompt when one is detected. This protects against a common development workflow where someone pastes a configuration file, log output, debugging information, or credential into the conversation while trying to solve a problem. The developer sees which type of secret was detected and can remove it before anything is sent to the model.

The pre-tool use hook moves that protection into actions chosen by the agent itself. File reads, shell commands, and MCP calls can be scanned before execution, and the action is blocked when a secret is detected.

The post-tool-use hook covers the other side of that interaction by scanning output returned from a tool. Because that action has already happened, GitGuardian sends a desktop notification when a secret appears in the result so the developer knows sensitive material has entered the workflow and can respond.

The power of the Docker Sandbox Mixin kit is that it not only installs ggshield in the sandbox, but takes the needed installation steps to set up AI hooks automatically. You get the full protection of the scans from the first prompt the agent sees.

How to get started with the GitGuardian Docker Sandbox mixin

The GitGuardian mixin is designed to make this setup repeatable, so developers do not have to install and configure each security control by hand.

Navigate to the GitGuardian Docker Sandbox Mixin kit on Docker Hub. Alternatively, you can find the code for this mixin kit on the GitGuardian published GitHub repository.
Choose the mixin for your coding assistant. The published GitGuardian kit includes support for Claude Code, Codex, GitHub Copilot, and Cursor.
Provide your GitGuardian API key through Docker's credential handling.

sbx secret set gitguardian

Enter the token when prompted. The real credential stays outside the sandbox and can be supplied through Docker's host-side proxy rather than being placed directly inside the agent environment.

Launch the sandbox with the GitGuardian mixin enabled. The mixin installs ggshield and configures the appropriate Agentic AI hooks for the selected coding assistant.
Start working normally. Once the sandbox is running, ggshield automatically checks supported prompt submissions, pre-tool-use actions, and post-tool-use output for secrets as the developer and agent work.
Respond to findings as they happen. When a secret is detected, the relevant interaction can be blocked or surfaced to the developer so the credential can be removed, rotated, or otherwise remediated before it travels farther through the workflow.

This gives teams a repeatable way to launch an isolated agent environment with credential-aware controls already in place, instead of asking every developer to assemble the same setup themselves.

Build the guardrails into the path developers already want to take

AI coding assistants are going to keep getting more capable, and developers are going to keep finding new ways to use them. The goal for security teams should be to make the safer path just as easy to use as the unrestricted one.

Docker Sandboxes are also only one way to use GitGuardian's AI hooks. Teams already using Claude Code, Cursor, Codex, or GitHub Copilot can install ggshield hooks directly into those environments and get the same deterministic checks around prompts, tool use, and tool output. That means teams can start protecting agentic workflows today, whether Docker Sandboxes are already part of their development platform or something they are still evaluating.

Try the GitGuardian mixin kit with Docker Sandboxes and see what that paved path looks like for your developers. Wherever your agents run, enable GitGuardian AI hooks and put credential protection closer to the moment those agents read, act, and move information. If you want to use GitGuardian at scale in your organization, we would love to help you get started.

FAQ

What is the GitGuardian Docker Sandbox Mixin Kit?

It is a Docker Sandbox mixin that automatically installs GitGuardian's ggshield and configures AI hooks inside a sandbox, giving developers a controlled environment for using autonomous coding assistants safely.

What are Docker Sandboxes and why do they matter for AI coding agents?

Docker Sandboxes run a coding agent inside an isolated microVM so it can execute commands, install dependencies, and use developer tools without unrestricted access to the host machine. That boundary matters because GitGuardian's research found an average of roughly 150 secrets per developer endpoint, with about 40% of high and critical secrets appearing in AI tool directories and log files.

What is a Docker Sandbox mixin kit?

A mixin kit packages tools, configuration, network rules, credential handling, and agent instructions so they can be applied consistently whenever a sandbox is created, turning isolation into a ready-to-use environment instead of an empty one that developers have to rebuild themselves.

What are ggshield's three AI hooks?

The prompt-submission hook scans a developer's prompt for secrets before it reaches the model. The pre-tool-use hook scans file reads, shell commands, and MCP calls before execution and blocks the action if a secret is found. The post-tool-use hook scans tool output and sends a desktop notification if a secret appears in the result.

How do I get started with the GitGuardian Docker Sandbox mixin?

Choose the mixin for your coding assistant on Docker Hub, set your GitGuardian API key with "sbx secret set gitguardian," then launch the sandbox with the mixin enabled. Once running, ggshield automatically scans prompts, pre-tool-use actions, and post-tool-use output for secrets as you work.

Do I need Docker Sandboxes to use GitGuardian's AI hooks?

No. Teams using Claude Code, Cursor, Codex, or GitHub Copilot can install ggshield hooks directly in those environments and get the same deterministic secret checks around prompts, tool use, and tool output, whether or not Docker Sandboxes are part of their platform.

What a Supply Chain Attack Is Really After: Your Credentials

Dwayne McDaniel — Thu, 01 Oct 2026 12:43:08 +0000

TL;DR

Credential theft is becoming central to software supply chain attacks: Across the major 2025–2026 campaigns we analyzed, credential harvesting was the primary objective.
Developer environments are valuable targets: Developer machines and CI/CD runners hold credentials for repositories, cloud infrastructure, package registries, and other systems.
Automation gives attackers speed: A poisoned package can reach downstream environments through normal update and dependency workflows before defenders know it is compromised.
Containment has to account for stolen access: Removing malicious code addresses the infection. Teams also need to understand which credentials were exposed, what they can reach, and whether they have been revoked.

A poisoned package may be where a software supply chain attack starts. The credentials it can reach determine what happens next.

Across the supply chain campaigns GitGuardian analyzed from 2025 through 2026, the initial access varied widely. Attackers compromised maintainer accounts, abused CI/CD workflows, rewrote GitHub Action tags, and poisoned trusted packages.

The objective was remarkably consistent: get credentials.

That changes how security teams need to think about software supply chain security. Protect against malicious code, yes, but also protect the access waiting for it once it executes.

Compromised software is a path to trusted access

Modern development environments need credentials to work. Developers authenticate to source code repositories, cloud environments, package registries, internal tools, and infrastructure. CI/CD pipelines need credentials to publish packages, deploy software, and interact with protected systems.

Attackers know where to look. Campaigns such as Shai-Hulud 2.0 and the Trivy compromise harvested GitHub tokens, package publishing credentials, SSH keys, cloud credentials, and other secrets that could provide access beyond the initially compromised package or machine.

That access can serve several purposes. A stolen credential might open another system, expose additional secrets, or give the attacker the publishing rights needed to push malicious software to another set of victims.

In other words, credential theft can become part of the propagation mechanism itself. The supply chain gives attackers distribution. Credentials give them somewhere to go next.

Developer machines and CI/CD runners concentrate access

There is a reason these campaigns keep landing on developer endpoints and build infrastructure. A production server usually holds credentials associated with the services it runs. A developer machine may contain credentials accumulated across repositories, cloud environments, CLIs, project directories, configuration files, and years of work.

CI/CD runners have their own concentration of access. A single pipeline may need permission to pull private code, publish artifacts, deploy applications, or communicate with production infrastructure.

The Shai-Hulud 2.0 dataset makes that concentration visible. GitGuardian analyzed 20,649 exfiltration repositories containing 33,185 unique secrets, with 3,760 confirmed valid at the time of analysis. For an attacker executing code in one of these environments, compromising the machine may only be the first step. The more important question is what that machine can authenticate to.

Automation makes the window painfully short

The same automation that keeps software current can move a compromised release quickly. When a poisoned Axios version appeared on npm, Dependabot opened its first pull request within five minutes. Across the attack window, 895 repositories were affected.

No developer has to deliberately download a malicious package for this model to work. Dependencies are installed during builds, bots propose updates, CI workflows fetch Actions automatically, etc. Coding agents can increasingly make package changes on a developer's behalf.

This is part of what makes modern supply chain incidents difficult to contain. By the time the malicious release is identified, execution may already have happened across developer machines and pipelines. And once credentials have been harvested, stopping the original package does not invalidate the access it collected.

The response question changes after execution

Traditional supply chain response naturally starts with the compromised artifact: Where was it installed? Which version ran? Which machines and pipelines were affected?

A credential-harvesting campaign adds another layer: Which identities were exposed, and what could they reach?

If malware accessed a cloud credential, GitHub token, SSH key, or package publishing credential, cleaning the affected machine does not close that access path. Responders have to establish the credential scope, identify ownership, prioritize the highest-risk access, and revoke or rotate it. That becomes much easier when the organization already knows where its secrets and non-human identities live. Waiting until the incident to build that map means reconstructing it while the response clock is already running.

See the full anatomy of a credential-harvesting supply chain attack

Our ebook, When the Supply Chain Becomes a Credential Attack, traces this shift across the major supply chain campaigns of 2025 and 2026.

It follows the attack chain from initial compromise through propagation, credential harvesting, exfiltration, and reuse, then breaks down the controls that can reduce both the chance of compromise and the access available afterward.

For security teams responsible for developer environments, CI/CD, secrets, or incident response, the bigger question is becoming clear: if trusted software turns hostile, what credentials are waiting within reach?

Download the ebook

FAQ

What is a software supply chain attack?

A software supply chain attack compromises a component or process that organizations trust to build, distribute, or update software. Attackers may target packages, developer tools, CI/CD workflows, package maintainers, or other parts of the development ecosystem to reach downstream users.

Why do software supply chain attacks target credentials?

Credentials can extend an attacker's access beyond the initially compromised machine or package. Tokens, SSH keys, cloud credentials, and publishing credentials may provide access to repositories, infrastructure, additional secrets, or software distribution channels.

Why are developer machines targeted in supply chain attacks?

Developer machines often hold credentials for many different systems, including source code repositories, cloud services, package registries, and internal development tools. That concentration of access makes them valuable targets for credential-harvesting malware.

Why are CI/CD pipelines high-value targets?

CI/CD pipelines need significant permissions to build, publish, and deploy software. Depending on the workflow, a runner may have access to publishing credentials, source code, deployment credentials, or other secrets. If attacker-controlled code executes in that trusted context, those credentials may become accessible.

How should organizations respond to a credential-harvesting supply chain attack?

Teams need to contain the compromised execution environment and determine which credentials or identities may have been exposed. Response should include scoping affected access, reviewing evidence of credential use, and revoking or rotating exposed credentials based on their permissions and potential impact.

AI Autonomy: How to Find the Autonomy Your Agents Already Have

Dwayne McDaniel — Wed, 30 Sep 2026 12:35:43 +0000

TL;DR

A framework for measuring autonomy: The Cloud Security Alliance's six-level model (Level 0 to Level 5) gives security teams language for how independently an AI agent can act, from human-executed tasks to full autonomy.
Credentials reveal an agent's real reach: Intended boundaries often don't match actual access. GitGuardian found AI-service credentials rose 81% to over 1.27 million, and 64% of credentials valid in 2022 were still active in January 2026.
Detect, remediate, prevent: GitGuardian's Developer Endpoint Protection and AI hooks inventory agent access, rank credentials by risk, and block secrets from spreading through tools like Claude Code, Cursor, and Copilot.

What is AI autonomy?

Merriam-Webster defines autonomy as "the quality or state of being independent, free, and self-directing." Historically, this has applied primarily to people. But like all terms, the definition will continue to evolve with the culture that coined it. Today, that means dealing with agentic AI.

When we talk about AI autonomy, we need to limit this definition a bit further. For AI agents, it means how much an AI system can pursue a goal without direct human involvement.

At lower levels, a person still directs most of the work. The system recommends an action, drafts content, or performs a tightly bounded task. At higher levels, an agent can build a plan, select tools, execute several steps, react to results, and keep working toward an objective with limited human input.

While anecdotally, we can sort any actions based on how much a human is involved, we need a framework that helps us communicate levels of human involvement.

Five-level framework of AI autonomy

Fortunately, groups like the Cloud Security Alliance have been working on this problem and proposed a useful five-level framework. The model intentionally takes inspiration from the Society of Automotive Engineers' levels of vehicle automation, where increasing autonomy is paired with different expectations for oversight, governance, and control.

The CSA framework runs from Level 0 through Level 5:

Level 0: No Autonomy
Level 1: Assisted
Level 2: Supervised
Level 3: Conditional
Level 4: High Autonomy
Level 5: Full Autonomy

Cloud Security Alliance Levels of Agentic AI Autonomy

This framework gives us a useful language for recognizing that progression, from Level 0 human execution through Level 5 full autonomy. The goal is not to force every agent into a rigid governance tier. It is to understand what agents can actually do today.

That requires looking beyond prompts and stated policies to the credentials and access paths underneath them.

This means one of the more critical questions security teams need to ask about an agent is "What data and systems can it reach, and what elevated autonomy would that grant it?"

Organizations need to detect any exposed credentials across the credential layer, remediate any access that creates unnecessary risk, and prevent agents from gaining or spreading plaintext credentials that expand their reach even further.

Types of AI autonomy

The CSA framework gives organizations useful language for recognizing increasing autonomy. It should be read as a spectrum of how human involvement changes as an agent becomes capable of acting more independently.

Level	CSA autonomy model	Human involvement	What to look for
Level 0: No Autonomy	AI provides information or recommendations	Humans perform every action	Can the AI expose sensitive information through what it reads or returns?
Level 1: Assisted	AI can execute actions after explicit approval	Human approves each action	What credentials and systems become reachable once an action is approved?
Level 2: Supervised	Human approves a plan or batch	Agent executes multiple steps independently	How much authority is hidden inside one approval?
Level 3: Conditional	Agent decides and acts inside defined boundaries	Humans handle exceptions	Do technical access and credentials actually enforce those boundaries?
Level 4: High Autonomy	Agent works broadly with minimal supervision	Humans monitor and intervene	How much standing authority can the agent exercise continuously?
Level 5: Full Autonomy	System can direct goals and potentially alter behavior	Strategic oversight	CSA considers this unsuitable for enterprise deployment today

The CSA calls out Level 3 as the point where things get especially interesting, where humans define boundaries, and the agent makes decisions independently inside them. Those boundaries could involve environment, action type, financial value, or other conditions. These boundaries need technical enforcement.

A policy may say that an agent is restricted to development. If the credential available to that agent can authenticate to production, the technical environment allows more than the intended boundary.

The agent has potential reach beyond the autonomy the organization believes it granted.

The same thing happens when an agent intended to modify one repository inherits an organization-wide token, or when an assistant expected to work with local files can call a cloud CLI already authenticated as the developer.

The assigned autonomy level is only part of the picture.

Teams also need to understand the effective authority the system makes available to the agent, especially if it is unintended.

4 credential risks associated with AI autonomy

Every useful agent eventually needs access. Reading a repository, querying a service, or calling an API to talk to a database all require authentication and authorization, which we have traditionally delivered via credentials. These secrets, in the form of keys, tokens, and certificates, connect those agents to the rest of the enterprise.

That makes credentials a useful way to uncover autonomy that may otherwise remain invisible.

1. Reach

Start with knowing which systems the agent can authenticate to. This includes credentials intentionally configured for the agent and credentials sitting within its environment.

A coding agent might have a GitHub token explicitly added to its configuration. It may also run on a developer laptop containing AWS credentials, SSH keys, database passwords, package registry tokens, browser sessions, .env files, and an already-authenticated cloud CLI.

The agent's reach can therefore extend well beyond the credentials anyone remembers assigning to it.

One credential can, and probably will, easily lead to another. An agent with access to a repository can find a hardcoded database password. The database may expose another token. An MCP server may pull a secret into a local configuration file.

Credentials create paths through an organization. Understanding the agent means understanding those paths.

2. Frequency

Autonomy also changes how quickly that authority can be exercised.

At CSA Level 1, a human approves each action. At Level 2, one approved plan may unleash dozens of credential-backed actions.

At Level 3, those actions continue without approval as long as the agent believes it is within its boundaries. Level 4 can turn that authority into continuous machine activity.

A credential originally issued for occasional human use can suddenly support hundreds of automated requests. The danger comes from the agent, which had not yet found or used these keys, changing behavior unexpectedly and treating those secrets as a path to accomplishing a seemingly unrelated goal.

3. Review

Human review gets further away from individual actions as autonomy rises.

A person may believe they are reviewing what an agent is going to do because they approved the initial task. The actual workflow can contain dozens of intermediate decisions, tool calls, file reads, and authenticated actions that were never individually reviewed. This is especially important with agentic systems because the exact execution path can change from run to run.

Security teams need visibility into the authority available before those paths are chosen.

4. Persistence

Agents are often very temporary while their credentials are extremely long-lived. GitGuardian found that more than 64% of credentials confirmed valid in 2022 remained valid when retested in January 2026. This is much longer than any AI agent using a current model could have been running.

A developer may add a token to make an agent work for one afternoon. The configuration survives. The token survives. Another tool discovers it later.

What looked like temporary access becomes part of the standing credential layer.

Mapping AI agent autonomy level vs credential risk

The CSA framework becomes especially useful as a diagnostic tool when we combine the levels with known risks brought by secrets.

This is a good place to remind ourselves that the goal is not to look at every agent and simply stamp "Level 2" or "Level 3" on it. A useful exercise is comparing the autonomy you expect with the authority the agent can actually exercise. This will help guide your security conversations moving forward.

Since the CSA marked Level 3 as the place where things get interesting, let's take a closer look there.

Imagine an infrastructure agent that is supposed to autonomously troubleshoot development environments while escalating anything involving production. On paper, that sounds like a Level 3 boundary.

Now imagine the AWS credential available to the agent has permissions covering development and production. The agent's prompt may say not to touch production. Its operating policy may say not to touch production. The credential layer says production is available, and there is nothing stopping the agent from using it as a means to accomplish the goal.

Those mismatches are what organizations need to find. A prompt instruction is a behavioral boundary. Credential scope is an access boundary. When the two disagree, the agent has more potential reach than the organization intended.

Why AI autonomy magnifies existing credential exposure

Useful AI agents are almost never deployed into completely clean environments with perfectly managed identities and narrowly scoped credentials.

They are entering enterprises already dealing with secrets sprawl.

GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits during 2025, up 34% year over year. Credentials tied to AI services reached more than 1.27 million, an 81% increase. In that same report, 24,008 unique secrets were found in public MCP configuration files, including 2,117 valid credentials.

AI agents are being added on top of this existing credential layer.

Agents inherit access from the environments where they run

Developer endpoints make the problem particularly visible.

A developer's laptop can contain cloud keys, .env files, SSH keys, shell history, package registry credentials, browser sessions, CLI caches, MCP configuration files, and agent transcripts. At the same time, agents are increasingly creating and writing credentials into local files without a human explicitly deciding where those secrets should live.

The developer's laptop is a credential store.

An agent running there can inherit an enormous amount of potential reach simply because of where it operates.

More integrations quietly mean more autonomy

Agent ecosystems also encourage teams to keep connecting tools. MCP servers, plugins, APIs, CLIs, and integrations are what make an agent useful. Each integration usually needs some kind of authority.

The result is additive.

An agent that could originally edit code can now open tickets. Then it can access GitHub. Then the cloud. Then a database. Then an internal documentation system.

No single change necessarily feels like a major autonomy decision. The combined system may look very different six months later.

It is a self-perpetuating cycle, where more integrations create more credentials, and more credentials create more possible routes through the credential layer.

Agents can gain authority without gaining a new identity

The situation becomes harder to see when agents operate through existing credentials. An agent may inherit the developer's shell, use a service-account key created years ago, or authenticate with a personal token stored in a configuration file.

An organization may have good visibility into the nominal owner of the identity while having much less visibility into which human, script, agent, or MCP workflow is currently exercising its authority. This is a central challenge in AI agent identity.

As agents gain the ability to make more decisions independently, understanding these inherited access paths becomes part of understanding their real autonomy.

What good looks like: matching controls to the level you grant

Your immediate goal should be visibility. Start by inventorying the agents in use and understanding where they operate. Then map the tools and systems available to them.

From there, ask: What credentials are explicitly configured for the agent? What credentials exist on the machine or workload where it runs? Which are valid? Which are long-lived? Which grant access far beyond the agent's expected task?

The most important comparison is between intended autonomy and available authority.

An agent designed for Level 1 behavior can still present substantial risk if every approved action executes with an administrator credential.

An agent you think is at CSA Level 3 may appear tightly bounded while carrying credentials that ignore those boundaries entirely.

The exercise therefore works in both directions. Start with the CSA framework to understand how independently the system can act. Then inspect its credential reach to understand the consequences of that independence.

That gives security and AI platform teams something concrete to investigate without forcing a prescriptive autonomy architecture onto every use case.

Where AI autonomy is heading

Agents will continue gaining tools, integrations, longer-running tasks, and deeper access to enterprise systems. Some of that autonomy will be intentional. Some will arrive as feature updates, new MCP connections, modified permissions, reused credentials, developer experiments, or agents created outside the formal AI program.

That second category should concern security teams most.

Autonomy can change after deployment. CSA even raises the question of dynamic classification because a single agent may operate at different levels depending on the capability or context involved.

The same agent might behave like Level 1 when deploying to production, Level 3 when modifying development systems, and effectively Level 0 when merely analyzing documentation.

Its access can change just as quickly. The agent you approved three days, or weeks, ago may have more tools today. The developer machine underneath it may contain new production credentials, or a new MCP server may have been connected.

Understanding autonomy therefore cannot be a one-time review. Organizations need continuous, near real-time visibility into the credential layer beneath their AI systems.

3 steps to evaluate your AI autonomy use and mitigate credential risks

Every part of the modern enterprise depends on credentials to connect people, applications, infrastructure, and services. Those credentials cross team and department boundaries. Together they form a credential layer underneath the entire enterprise.

Agents increasingly operate across that same layer. If you want to know how autonomous an agent can become, start by understanding the authority available to it.

This is where GitGuardian's mission as the Credential Layer Security Platform directly intersects with AI autonomy.

Step 1: Detect the access agents already have

The first part of addressing your credential layer is detecting any and all credentials. Organizations need to see credentials across the entire credential-carrying surface, because that's ultimately what AI agents will access.

That includes source code and CI/CD systems, along with collaboration platforms, developer endpoints, AI agent directories, MCP configurations, local caches, secret managers, vaults, and the other places where credentials live or travel.

Teams need visibility into developer workstations. This is what GitGuardian delivers with Developer Endpoint Protection. It can discover plaintext credentials across local files, shell histories, config files, IDE caches, browser data, MCP configurations, and files created by AI coding agents. GitGuardian also inventories local AI agents and MCP servers, including what tools and data they can access.

That inventory begins to answer the autonomy question in concrete terms:

Which agents exist?
Where are they running?
Which credentials are within reach?
Which systems do those credentials unlock?

The answer can reveal an agent whose real access has grown far beyond the workflow anyone originally approved.

Step 2: Remediate access that expands the agent's reach

Teams need to gather as much information as possible during the detection phase of any plan in order to remediate the situation.

Not every secret presents the same danger. A test token used only in a dev environment and a valid production cloud credential should produce very different responses. GitGuardian can rank endpoint findings by severity and access scope and route them into existing security workflows.

No team has unlimited time or resources. Every team needs to reduce the noise and focus on what areas carry the most risk. The goal of securing agent access is to address credentials that create dangerous access paths.

That can mean revoking a credential the agent no longer needs, rotating an exposed secret, reducing permissions, eliminating duplicates, or moving a plaintext credential into an appropriate secret manager or vault.

For AI autonomy, remediation has another important effect. It can bring the agent's actual reach back in line with the autonomy the organization intended to grant.

The infrastructure agent restricted to development should carry development-scoped authority. The coding agent working in one repository should not inherit access to every repository in the company.

Credential remediation turns those intended boundaries into real limits on what the agent can reach.

Step 3: Prevent autonomy from expanding through secrets sprawl

As teams work to rein in agents' access paths, they also need to prevent new credential exposure from quietly expanding agent access again.

This has to happen close to where agents work. GitGuardian AI hooks provide guardrails inside tools such as Claude Code, Cursor, and Copilot. They can prevent agents from reading, copying, or transmitting detected secrets across files, tool calls, and chats.

Developer Endpoint Protection also gives centralized visibility into credentials accumulating on local machines, while honeytokens can alert teams when credential-harvesting activity reaches an endpoint.

These controls address a fundamental problem with autonomy creep: Every new plaintext credential can become another access path, and every new access path can expand what an agent can reach. Every increase in reach can increase the autonomy that agent already has.

Understanding CSA levels gives organizations a useful language for recognizing how independently agents operate.

Understanding the credential layer shows organizations what those agents can actually affect.

Organizations need both views.

As agents become more autonomous, sometimes intentionally and sometimes simply through the accumulation of tools and access, security teams need to continuously understand those paths.

Detect the credentials within reach. Remediate the access that creates real danger. Prevent new plaintext credentials from expanding that reach further.

That is how organizations can understand the autonomy they already have and bring security to the credential layer underneath it. That is the mission of GitGuardian as a credential layer security platform.

Start gaining control of your agent autonomy today.

Service Account Credential Rotation: The Blast-Radius Checklist

Dwayne McDaniel — Tue, 29 Sep 2026 13:47:57 +0000

TL;DR

The problem: Service account credentials pile up with no clear owner, and teams avoid rotating them for fear of breaking production dependencies nobody has mapped.
The checklist: Answer eight questions before rotating: validity, exposure, access scope, consumers, vault location, duplicate copies, ownership, and rollback plan.
The fix: GitGuardian's Exploration Map links a credential to its incidents, permissions, consumers, and owner, turning rotation into a controlled change instead of a guess.

Every security team has credentials they know should already be gone.

They might want them gone because they were leaked. It might be because they are older than internal governance policies allow. They showed up in code and system config years ago. And with no clear owner, or owners who have already departed the company, nobody can remember why they still exist.

Nobody wants to touch these secrets out of fear that some mission-critical system, somewhere, might still depend on them. Touching in any way, and especially a credential rotation, might cause downtime, a very real risk teams want to avoid. After all, the "A" in security's CIA triad is "Availability."

For human access to accounts like email or CLI tools, you can usually ask the person what they use and figure out a secrets rotation plan that go through IAM or PAM tooling.

Machine identities, on the other hand, do not answer Slack requests about how they are used, nor do they raise their hands when they lose access. When a workload's secrets stop working, the whole app might stop working.

Making matters worse, their credentials may be buried across repositories, pipelines, scripts, vaults, applications, and infrastructure that has changed hands several times.

So how do we act in a way that balances the security risk with production risk?

Before you rotate a credential, you need enough context to know what will break, what could be exposed, and who needs to be involved when you make the change.

Why rotating a service account password breaks production

Machine identities now outnumber human identities by at least 109 to 1, according to Palo Alto Networks' 2026 Identity Security Landscape report. These identities include service accounts, workloads, bots, and increasingly AI agents.

Every one of those identities needs some way to authenticate.

That creates a huge credential layer underneath modern infrastructure. API keys, passwords, tokens, certificates, and other secrets get created for one workload, copied into another environment, stored in a vault, dropped into configuration, embedded in CI/CD, and occasionally forgotten altogether.

OWASP reflects the same problem in its Top 10 for Non-Human Identities. Improper Offboarding is the number one risk, followed by Secret Leakage, with overprivileged identities, long-lived secrets, and NHI reuse also appearing on the list.

GitGuardian's own research shows how long the problem can survive. Of the valid secrets GitGuardian identified in public repositories in 2022, 64% were still active when retested in January 2026.

For most orgs, answering the question of "Why would anyone knowingly leave an exposed credential active for four years?" is a real challenge. No one fully or confidently understands everywhere a service account is in use. The account might have a documented owner while the credentials appear in three repositories, two vaults, and an old script that somehow is keeping production running. Revoke the value and every live dependency finds out at once.

Credential rotation becomes a production system update, and that sounds risky to an already running system processing real customer requests.

What we need is a dependency graph view of every secret and to understand what effects any change will bring.

The service account credential rotation checklist: The eight questions to answer first

This set of questions is intended to help you standardize your processes when a service account is found to be out of policy, due to a leak, or a governance violation. If you cannot answer one of these questions, filling that knowledge gap becomes part of the remediation and secrets governance work ahead of you.

1. Is it still valid?

Usability tells you whether you are dealing with a historical artifact or a possible live security risk that might still be in use.

A credential that can no longer authenticate presents a very different operational problem from one potentially used by a production service account an hour ago.

GitGuardian uses validity as an important signal when investigating and prioritizing secret incidents, while also accounting for secrets whose validity cannot be automatically checked. GitGuardian will never mislead you if the platform can not confirm the key is active. The platform allows for API integration with any tools you might already use that can confirm if an internal key or secret is still live for a homegrown system, helping maturing teams improve their holistic posture.

But this is just one signal, and when a credential can not be validated, teams should answer the other questions quickly.

2. Has it leaked?

Exposure greatly increases the risk, and therefore the priority of remediating this secret.

A credential that exists only in an approved secrets manager can go through a planned secrets rotation process. A valid credential found in a public repository may already be available to automated attackers.

Public exposure can turn a scheduled maintenance task into incident response.

That does not remove the need to understand dependencies. It means you may have to build that understanding very quickly and accept some operational disruption to close the access path.

3. What can it actually access?

Look at the permissions the identity has today. What standing access do they allow, and what is the worst harm a malicious actor could do with those permissions?

A credential documented as read-only but attached to an identity with administrative privileges creates a much larger security blast radius. It may need faster remediation, while those same privileges increase the care needed during the change.

GitGuardian can add this permission context for supported identities and surface overprivileged NHIs as part of posture assessment.

4. What consumes it?

Map the services, scheduled jobs, pipelines, scripts, workloads, and other systems that authenticate using the credential.

This is the operational blast radius in its most literal form. Anything depending on that value can fail when the old credential stops working.

One service account can have multiple consumers, especially after years of copied configuration and shared automation. Find those dependencies before they find you during the secrets rotation.

5. Is it vaulted, and where?

Determine if the credential has a managed "source of truth." This is where security teams, IAM, and DevOps overlap quite a bit.

If it already lives in a secrets manager, identify the vault and path and determine which consumers retrieve it from there. GitGuardian can identify when an exposed secret also exists in a connected secrets manager and show its storage location during investigation.

If the credential is hardcoded everywhere, avoid turning secrets rotation into an exercise in replacing one unmanaged value with another. Push the secrets into the best vault and open the pull request to account for it in code, tracking if those changes are accepted before swapping out the secret.

The goal is not just to make the next credential rotation easier than the last one; the goal should be to work across teams to move towards short-lived credentials or federated workload identity where the architecture supports it.

6. Where does this actually live?

It is vital to find every copy across every surface, from communications platforms and ticketing systems to developer laptops. One copy in the right, unexpected place might be holding up surprising parts of your applications and pipelines.

Duplicate copies complicate secrets rotation and end up consuming operations and dev teams alike. An overlooked replacement path can also leave teams believing remediation is finished when the old credential is still sitting somewhere exposed.

GitGuardian specifically tracks issues such as duplicated, reused, cross-environment, internally leaked, and publicly leaked secrets.

7. Who owns it?

This is harder to answer for most teams than they would like to admit. Finding a named, current human who can confirm why the identity exists and why it needed that access seems like a reasonable thing on the surface. But over time, as things evolve, a lot can get lost.

The person who minted the credential might not be there anymore, and even if they are, do they own the application the credential belongs to? Answers like "The team and dev that used to own this application is " gives you history. You need someone who can make a decision today, though.

Ownership matters because someone has to validate dependencies, coordinate the change, and determine whether the service account should survive at all. A credential attached to an orphaned identity deserves a very different remediation plan from one supporting a business-critical workload.

8. What is the rollback plan?

There should be a plan for what happens if the credential rotation fails. Even if the previous plans were around swapping plaintext credentials in the code, there should be a set of policies in place to reduce downtime. Your plans need to also update this plan.

Many providers support multiple simultaneously valid credentials, allowing staged rotation for a safer path. Create the replacement, update consumers, verify them, then invalidate the old credential.

Where overlapping credentials are unavailable, prepare and test the restore process. Have someone watching the consumers identified earlier as the change lands.

The rollback plan should come from the dependency map. You cannot watch the right systems if you never figured out what depends on the credential.

How to see a credential's blast radius before you act

GitGuardian's Exploration Map was built to help teams answer those vital questions from the checklist.

Instead of treating a secret as an isolated string found in a file, GitGuardian can connect the credential to the surrounding machine identity context.

The Exploration Map provides an end-to-end view that can include:

Internal and public secret incidents associated with the same identity
Accessed resources and the permissions used to reach them
Secrets managers where associated credentials are stored
Consumers such as services, scripts, and jobs using the secret
Owners responsible for the non-human identity

This is how the GitGuardian platform gives teams a straightforward way to understand an NHI's connections, usage, and potential impact, including evaluating what will be affected when a secret is revoked.

That changes the starting point for rotation today and provides a reliable source of truth to build automation around for future remediation.

From one platform, you can identify affected consumers, coordinate the replacement, and verify that the old credential stops working. Along the way, you can find or assign the owner and start the conversation for moving towards better access patterns and architecture.

This is the difference between credential detection and secrets security at scale.

GitGuardian helps teams detect credentials across the places they accumulate, remediate them with the context needed to act safely, and prevent the same credentials from spreading again.

Before you rotate the next service account credential, find out exactly what is attached to it. Let's talk about how GitGuardian helps you map credential blast radius and remediate secrets with context.

FAQ

What is credential rotation?

Credential rotation is the process of replacing an existing password, API key, token, certificate, or other authentication secret with a new credential and invalidating the old one.

For machine identities, rotation also requires updating every legitimate consumer that depends on the old credential. Successful rotation ends with the old credential invalid, authorized consumers working with the replacement, and unmanaged copies removed or rendered useless.

When should secrets be rotated?

Rotate a credential when policy or its configured lifetime requires it, when ownership or access changes, when the credential is believed to be compromised, or when exposure creates a credible risk of unauthorized use.

Exposure and validity should influence urgency. A publicly leaked valid credential deserves incident-response speed. A healthy credential approaching a scheduled expiration can usually move through a planned change process.

Longer term, teams should reduce dependence on manually rotated, long-lived credentials by adopting managed secrets, dynamic credentials, workload identities, and short-lived authentication where possible.

How do you rotate a secret without causing downtime?

Start by mapping every consumer of the current credential.

Where supported, use a staged or blue/green rotation. Create a second valid credential, place it in the approved secrets manager, update applications to retrieve the new value, deploy the change, and verify that traffic succeeds before revoking the original.

Applications should retrieve the credential from a managed source rather than requiring the credential value to be changed throughout the codebase.

The sequence becomes: Create replacement -> update managed value -> deploy consumers -> verify -> revoke old credential.

When the provider cannot support overlapping credentials, a dependency map, tested rollback, coordinated deployment, and active monitoring become even more important.

What is a credential's blast radius?

A credential's blast radius is the complete impact associated with that credential.

From a security perspective, it includes the resources, data, permissions, and systems an attacker could reach if the credential were compromised.

From an operational perspective, it includes every service, pipeline, job, script, workload, or other consumer that could stop working when the credential is rotated or revoked.

You need both views.

That is why the best question before rotating a service account credential is not simply, "Is this key old?"

Ask: Who owns it, where is it used, what can it reach, and what breaks when it disappears?

Once you can answer those questions, rotation stops being a gamble and starts looking like any other controlled production change.

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.