TL;DR
- The credential layer is every surface holding a secret: Code, cloud, laptops, SaaS, collaboration tools, and public sites all hold plaintext credentials, and a single key can travel through all of them during its lifetime.
- Six controls form a connected program: Discover, prioritize by access risk, connect to owners, remediate copies, prevent spread, and detect harvesting with honeytokens, working alongside IAM, PAM, vaults, EDR, and cloud security.
- Endpoints and AI agents raise the stakes: Developer laptops average about 150 secrets each, and agents can read files, run commands, and call MCP servers, so credential scope and deterministic controls matter more.
What is credential layer security?
Before we define the full credential layer, let's start by defining "credential." In the context of information technology, we define a credential as any piece of data that grants access to a system, service, resource, or data. We also commonly call these "secrets." Some credentials require additional authentication conditions to be met, but most grant access through possession of the data alone.
These take the form of passwords, API keys, access tokens, private keys, and other authentication material, which, on its own, allows an entity, be it human, workload, or AI, to authenticate to another system or platform.
The credential layer enables your organization's connectivity and encompasses every place a credential can exist, in any state or condition. That is a very wide definition, but that is also the honest scope. Any surface that can hold plaintext is part of the credential layer's surface. This includes code, cloud infrastructure, laptops and dev environments, and SaaS applications. All can hold plaintext credentials. That is the reality security teams are up against.
Putting this all together, we get to our definition: Credential layer security is the practice and focus of protecting every surface where credentials can be created, stored, transmitted, or used. In practice, that means finding all plaintext secrets and connecting identity context, remediation, and prevention across the enterprise.
Why are credentials a security concern?
Credentials don't just allow access to systems that contain private data; they also provide access to control an organization's infrastructure.
An exposed customer record can reveal personally identifiable information, which is highly regulated. An exposed credential can provide ongoing access to systems, giving adversaries more time to plan and explore. Secrets also enable administering your infrastructure, which can be very costly when abused.
The credential layer stretches across the entire digital environment, including systems that were never designed to manage credentials.
Protecting it requires understanding where credentials exist, what they can access, who owns them, and how to prevent their exposure or abuse.
The credential layer includes every surface that can hold a credential
The credential layer has no single technology boundary. It permeates the systems where software is developed, operated, and maintained.
A useful way to understand its scope is to group credential surfaces according to their intended purpose and the organization's ability to control them.
Each surface creates a different remediation challenge.
A credential inside a vault can be governed through access controls and rotation policies. You can remove a credential from source code, but its history may remain accessible. A credential in a backup may be difficult to erase. A credential published to the internet must be treated as potentially copied by anyone.
The same credential can, and often does, move through all four groups during its lifetime, most often moving through the laptop.
An API key might originate in a cloud service, be stored in a vault, copied onto a local .env file, used by an AI coding assistant, written into a build log, and eventually committed to a public repository.
Every location becomes part of the credential layer, and the credential can retain its original access throughout that journey.
The credential layer and the identity layer work together
The identity layer establishes who or what is requesting access. This is the bedrock for IAM and how authentication and authorization are governed. The credential layer includes every surface where the authentication material associated with those identities can exist.
A developer might use their authority to create a service account for a cloud service. That new identity is granted access to a production database with a plaintext key. That API key can exist in a developer's local configuration, a deployment pipeline, and an archived support ticket.
Every credential security program needs to go beyond just discovering secrets. They need to answer several connected questions around identity and access:
- Which identity does this credential map to?
- Who owns that identity?
- Is the credential valid?
- What can it access,
- Where else does it exist?
That context turns a discovered string into a security risk that can be understood and addressed.
Why attackers target the credential layer
Attackers know that a single plaintext string can let them act as identities with access to systems that already trust them.
An attacker who obtains a valid credential can authenticate to a service, retrieve protected data, or perform actions within the permissions assigned to that identity. No zero days or deep system knowledge needed.
The initial exposure may come from a repository, a compromised laptop, a collaboration message, or an external dependency. The pattern is always that an attacker obtains an authentication mechanism and then uses the access it provides. This is why Credential Access is tactic 6 of the MITRE ATT&CK framework.
A single credential can lead to many more credentials.
Access to a developer workstation might reveal cloud tokens and SSH keys. Access to a CI/CD platform might reveal deployment credentials. Access to a cloud environment might reveal service account permissions or configuration containing more authentication material.
Each successful step can lead to another part of the credential layer.
Machine credentials make access easier for attackers
Human authentication increasingly includes MFA, device verification, and contextual access policies.
Most machine-to-machine systems still depend on reusable bearer tokens or API keys. A valid credential alone can be sufficient to authenticate a request without additional proof of who possesses it.
These credentials are often broadly scoped and long-lived. The goal is to keep production running, which means stability and avoiding permission issues while the application operates.
A pipeline token might have permission to publish packages for years. A cloud key might access production storage long after the related systems have been decommissioned. A service account can retain privileges from a project completed years earlier. By default, most credentials have no expiration date; they keep working forever unless configured otherwise.
At machine speed, an attacker can harvest, test, and use a credential before a human analyst begins investigating the original exposure.
Supply chain attacks demonstrate the power and danger of local credentials
The Shai-Hulud npm supply chain attacks, while just one of many similar campaigns, show how attackers exploit the credential layer across multiple systems.
The attack used compromised packages to harvest credentials from developer and CI/CD environments. Stolen tokens enabled further malicious activity, including propagation through package publishing and exposure of harvested secrets.
The GitGuardian analysis of one wave identified 33,185 unique secrets across 294,842 occurrences, including 3,760 credentials confirmed valid during analysis.
Alt: top 10 types of unique valid secrets from gitguardian report on Shai-Hulud
The infostealer malware moved through developer endpoints, package registries, CI/CD infrastructure, and public GitHub, publishing copies of itself forward wherever possible. Each surface it touched had differently managed security strategies, but the credentials layer connected all of those surfaces, regardless of governance policies.
This is the challenge with treating credential exposures as isolated incidents. A secret discovered in one system may already have been copied into several others, and its permissions can make those other systems reachable.
Where credential layer security fits in defense in depth
Enterprise security has been built around specialized controls, separating logical concerns from an IT perspective. Each stack addresses an individual enterprise need: IAM, PAM, secrets managers, EDR, cloud security, and application security are all needed.
Credential layer security operates across these existing investments because credentials move between the environments they protect.
Every one of these controls remains necessary. Credential layer security provides a way to connect the findings from where they overlap or leave gaps.
Credentials are essential operational resources for most organizations and, at the same time, potential security liabilities. Developers and applications need reliable access to do their work. Controls that introduce excessive friction can encourage unmanaged copies and workarounds.
A mature program combines visibility and enforcement with practical workflows for securely creating, distributing, using, and retiring credentials.
The six controls of credential layer security
Organizations need a consistent approach that works across all credential surfaces. We propose there are six controls that provide that foundation.
1. Discover credentials wherever they exist
Visibility across the credential layer is vital. This extends well beyond what is just known and vaulted.
Scanning source repositories is an important starting point, as applications connect to our most important resources. Coverage also needs to extend into pipelines, developer endpoints, AI configuration, operational data, collaboration tools, public repositories, and other environments where credentials appear.
GitGuardian's State of Secrets Sprawl 2026 reported 28.65 million new secrets exposed on public GitHub just during 2025. That's a 34% year-over-year increase. At the same time, the report found that approximately 28% of secret incidents occurred entirely outside code repositories.
The objective of discovery is to find credentials across the environments where they actually exist, including historical exposure and copies that persist long after their original purpose has ended.
2. Prioritize credential findings by their access risk
A long, high-entropy string, on its own, is not a danger. Any string that grants access is. Context determines which require attention first. Validation is a good place to start. A credential's validity, type, permissions, exposure location, and associated systems help establish its risk.
Thinking of extreme examples, a valid production API key with administrative privileges presents a higher risk that requires attention, vs. an expired test credential which is no good for anyone.
However, some credential providers offer limited or no direct validity checking. For many secrets found by our generic detectors, like SSH keys or custom tokens, it can be impossible to map these back to the issuing system. Security teams need to rely on additional signals, including recent use, credential structure, associated identities, and the environments where the secret appears.
Prioritization should consider what the credential can reach and the consequences of unauthorized use.
Security teams should focus remediation efforts on exposures that pose the greatest risk to critical business systems.
3. Connect credentials to identities and owners
Every credential had a purpose when created. This means someone created it. Is that same person the owner now, and are they accountable for it?
Answering this is increasingly difficult as organizations create more non-human identities.
Their original owners of any minted keys or tokens may change roles or leave the company entirely, while the credentials remain active. After the applications that needed them are retired, these service account passwords, cloud workload tokens, and AI agent keys retain their permissions, granting access to systems for anyone who finds them.
A complete credential-layer view connects each secret to its associated identity, responsible team, permissions, and rotation requirements. It also identifies orphaned identities, overprivileged accounts, and credentials with uncertain ownership.
When a critical credential is exposed, the security team will invariably need to identify who has the authority and technical understanding to rotate or revoke it safely.
4. Remediate the credential and its exposed copies
For any security team, the immediate instinct when a secret is found is to revoke it, stopping abuse and attacker access. But this carries the risk of reducing the availability of the systems relying on those credentials. After all, if we fail at keeping things running, we have fallen short of the CIA triad: Confidentiality, Integrity, and Availability,
How you respond to a leak, or exposure, differs by surface. Consider an internal collaboration message; even if deleted, you need to consider exports, notifications, and backups that may retain copies. A credential exposed in a public repository must be treated as potentially copied outside the organization's control. Logs, snapshots, traces, and backups can retain credentials long after the original exposure.
Rotation, meaning replacing the secret with a new one and invalidating the compromised secret, or simply revoking it, will always need to be a case-by-case decision. Security, platform, and application owners need coordinated workflows to replace it without disrupting operations.
A mature credential layer security program needs to treat related copies of an exposure as one connected incident. Tracking remediation by confirming the old credential no longer works is the only way to know when it is safe to resolve leak occurrences.
5. Prevent credentials from spreading in plaintext
While discovery and remediation make up the core of any credential layer program, preventing the need for scanning and incident management should be a significant part of the mission. Preventing new credentials from entering unmanaged environments is the most cost-effective way to tackle the issue of secret sprawl.
Teams need to implement controls at the local level. With pre-commit hooks, teams can make sure credentials never make it to shared repositories. This, in turn, keeps them out of pull requests, CI/CD execution, and any logs or build artifacts.
Developers can get immediate feedback and guidance while any keys are in plaintext in the IDE, when it is far easier to correct. If it never reaches production, revoking and replacing is much safer, since nothing should break when it is invalidated.
AI coding assistants, now commonplace, are another place where preventive controls are needed. Deterministic hooks can check for secrets in prompts, file reads, commands, and supported tool actions at defined points in an agent workflow, stopping the agent from taking further action if any are found. This prevents secret sprawl and, importantly, adds controls against the AI abusing keys it encounters while working to complete a task.
Reducing unnecessary credential movement should be the central focus, but security teams need to work with developers to reduce risk further. Short-lived credentials, narrowly scoped permissions, secure injection, and workload identity federation can reduce reliance on reusable secrets.
For supported machine-to-machine interactions, federation using standards such as OIDC can replace standing API keys with temporary credentials issued for a particular workload or session. Those decisions need to be implemented by platform, DevOps, and development teams.
6. Detect suspicious credential harvesting with honeytokens
Some credential exposure becomes visible only when someone attempts to use the information they have obtained.
Honeytokens provide a way to detect this activity.
A honeytoken is a decoy credential planted in a location where legitimate workflows have no reason to use it. When someone attempts to authenticate with the decoy, the attempt generates an alert.
Placed on developer endpoints, honeytokens can help reveal infostealers or other software harvesting local credentials.
They can also provide useful evidence during incident response, including which protected environment contained the decoy and when an attempted use occurred.
Honeytokens complement discovery and prevention by identifying attempted abuse of planted credentials.
Six controls, one goal
Considered together, these six controls support a connected program.
Discovery establishes visibility. Validation identifies risk. Ownership establishes accountability. Remediation removes exposed access. Prevention reduces future exposure. Deception helps reveal unauthorized credential activity.
Combined with a broader defense-in-depth strategy, using the other systems and tools previously outlined, organizations are far more resilient when it comes to access and security.
Why developer endpoints and AI agents demand attention
Developer laptops have become some of the richest credential surfaces in the enterprise.
During an ordinary workday, a developer may authenticate to source control, cloud infrastructure, package registries, CI/CD services, databases, and internal applications.
Those credentials can accumulate in .env files, shell history, local scripts, CLI configurations, browser storage, caches, and other developer tooling.
GitGuardian's Developer Endpoint Protection research found an average of approximately 150 secrets per developer laptop. Many of these credentials never enter a repository. Traditional downstream scanning has no opportunity to discover them.
AI coding assistants extend exposure
AI coding assistants and other local agents, like OpenClaw, offer many advantages for automating tasks and saving everyone toil. They are helpful precisely because they can read files, execute commands, call APIs, and communicate with MCP servers. But this is also where the danger lies.
When they can encounter credentials, either already present on a developer's machine or introduce new exposures through prompts, generated code, tool responses, and configuration files, their non-deterministic nature means they might act as an insider threat. And they encounter such secrets very often, increasingly due to their own architectures.
The 2026 State of Secrets Sprawl report identified 24,008 unique secrets in publicly exposed MCP configuration files, including 2,117 valid credentials. Many of them should be considered highly critical and dangerous. While at the same time, credentials related to AI services increased 81% year over year. These findings show how rapidly development practices can create new credential locations.
For security teams, the challenge remains consistent: discover what credentials an agent can encounter, understand the access they provide, establish ownership, and prevent unnecessary exposure.
An agent's intended behavior may be defined in its instructions. Its actual ability to affect enterprise systems depends on the tools, credentials, and permissions available to it.
This makes credential scope and deterministic access controls increasingly important.
From isolated controls to mature credential layer security
Organizations can begin securing the credential layer with relatively simple controls. The challenge is connecting those controls as coverage expands.
At lower maturity levels, a secret in a repository, a developer laptop, and a collaboration ticket may create three unrelated security incidents.
At higher levels, those discoveries can be connected to the same credential, its issuing system, the identity behind it, and the access it provides.
The GitGuardian Credential Layer Security Maturity Questionnaire provides a starting point for organizations assessing their current coverage and maturity.
How GitGuardian fits
GitGuardian's mission is to detect, remediate, and prevent secrets sprawl across the credential layer.
The GitGuardian platform's capabilities cover the six controls described above and provide a unified workspace experience that IAM, DevOps, Security, Platform, and any other team involved in credential creation and management can leverage.
GitGuardian's Secrets Monitoring discovers exposed credentials across the whole exposed surface, including repositories, CI/CD environments, collaboration tools, and public GitHub. Developer Endpoint Protection extends that same level of discovery into developer machines, which can be deployed via MDM, identifying credentials in local files and tools and scoring exposure by machine, severity, and validity.
The platform connects credentials to identity ownership, surfaces permissions the credentials hold, and provides context for what is affected if a secret is rotated or revoked. From a security operations perspective, the platform fully supports prioritization and remediation. Honeytoken provides deception signals when decoy credentials are used.
For prevention, GitGuardian extends the power of the platform to the developer, where they work, through ggshield. Developer-focused tools, like the VS Code Extension and automated ggshield commands such as pre-commit hooks, give your team commit-time checks and guardrails without asking them to change their workflows. AI hooks can inspect credential exposure at defined checkpoints along coding agents' working paths.
These capabilities complement the IAM, IGA, PAM, vault, EDR, ITDR, and cloud controls organizations already operating.
Together, they support a coordinated approach to securing credentials across the many environments where those credentials exist and move.
Where credential layer security is heading
The credential layer will continue expanding as software becomes more automated and enterprise systems become more interconnected.
AI agents, automated workflows, and new integrations will create additional places where credentials are issued, used, cached, and exposed.
At the same time, changes in authentication architecture offer opportunities to reduce reliance on persistent secrets. Workload identity federation, short-lived tokens, and more narrowly scoped permissions can reduce the number of reusable credentials that remain valuable after exposure.
Any improvements like these do not eliminate the need for credential-layer visibility. Temporary credentials can still appear in logs or tooling, and systems will continue to depend on authentication material in different forms.
The future of the credential layer is a connected security program that understands credentials throughout their lifecycle, following where they are created, where they travel, what identities they represent, what systems they can reach, and how they are retired.
Secure the credential every other control trusts
Every part of the modern enterprise relies on credentials. The credential layer includes every surface where those credentials can exist. Its boundaries extend across security tools, development processes, organizational departments, and the public internet.
Securing the credential layer from attackers, insider threats, and AI abuse requires treating those connected exposures as one enterprise-wide security concern. Organizations need visibility across surfaces, knowledge of the identities and permissions behind each credential, and coordinated processes to remove dangerous access and prevent new exposure.
As automated systems create and use credentials at increasing speed, the ability to secure this layer becomes fundamental to protecting the enterprise.
Take the interactive GitGuardian platform tour to see how credential discovery, identity context, remediation, and prevention work together.
Soujanya Ain
Dwayne McDaniel
Cybersecurity research team
FAQ
What is credential layer security?
Credential layer security is the practice of protecting every surface where credentials can be created, stored, transmitted, or used. In practice, that means finding all plaintext secrets and connecting identity context, remediation, and prevention across the enterprise.
What is the credential layer?
The credential layer encompasses every place a credential can exist, in any state or condition, including code, cloud infrastructure, laptops and dev environments, and SaaS applications. It has four surface groups: governed stores like vaults, working surfaces like pipelines and developer endpoints, spilled surfaces like Slack and Jira, and escaped surfaces like public GitHub and paste sites. A single credential often moves through all four during its lifetime.
Why do attackers target the credential layer?
A valid credential lets an attacker act as an identity that systems already trust, with no zero-days or deep system knowledge needed. One credential can also lead to others. Access to a developer workstation might reveal cloud tokens and SSH keys, and access to a CI/CD platform might reveal deployment credentials. Credential Access is tactic 6 of the MITRE ATT& CK framework.
What are the six controls of credential layer security?
The six controls are discovering credentials wherever they exist, prioritizing findings by access risk, connecting credentials to identities and owners, remediating the credential and its exposed copies, preventing credentials from spreading in plaintext, and detecting suspicious credential harvesting with honeytokens. Together, they support a connected program rather than isolated incident response.
How does credential layer security fit with IAM, PAM, and secrets managers?
It complements them. IAM, PAM, vaults, EDR, ITDR, cloud security, and SIEM each remain necessary, but credentials move between the environments those controls protect. Credentials tied to managed identities may exist outside managed systems, and copies of vaulted secrets can persist elsewhere. Credential layer security connects findings from the places where those controls overlap or leave gaps.
Why do developer endpoints and AI agents need special attention in credential security?
Developer laptops hold an average of approximately 150 secrets each, in places like .env files, shell history, and CLI configurations that never reach a repository. AI coding assistants can read files, execute commands, and call MCP servers, they may encounter those credentials. The 2026 State of Secrets Sprawl report found 24,008 unique secrets in public MCP configuration files, including 2,117 valid credentials.
How does GitGuardian help secure the credential layer?
GitGuardian covers the six controls across the credential layer. Secrets Monitoring discovers exposed credentials across repositories, CI/CD environments, collaboration tools, and public GitHub. Developer Endpoint Protection extends discovery to developer machines and can be deployed via MDM. The platform adds identity ownership, permissions, and remediation context, honeytokens provide deception signals, and ggshield, the VS Code extension, pre-commit hooks, and AI hooks prevent exposure where developers work.
