DEV Community: Dwayne McDaniel

Shifting Security Left for AI Agents: Enforcing AI-Generated Code Security with GitGuardian MCP

Dwayne McDaniel — Fri, 26 Jun 2026 12:02:04 +0000

The rise of AI-powered coding agents promises to revolutionize software development, boosting productivity and accelerating iteration. Over the past year, AI in software development has started to evolve from locally embedded assistants to asynchronous cloud agents. However, this powerful new paradigm introduces a critical, industry-wide challenge: how do we ensure the code generated by these agents is secure by design?

The DevSecOps approach to code security is a great start. We can still utilize "security gates" like Pull Request (PR) checks and code reviews to help us identify when an agent has introduced a vulnerability. However, now that AI is able to iterate so quickly, these check-ins have become the new bottleneck. Every time an agent pauses to wait for a human to analyze scan results or request changes, it adds a significant amount of time to the development cycle.

The Industry Challenge: Securing AI-Generated Code

The fundamental challenge in securing code generated by AI agents stems from the training data that the underlying AI models were trained on. Humans are notoriously bad at writing vulnerability-free code, so LLMs have "learned" a lot from both bad and good examples. This means every line of code an agent suggests has a non-zero probability of introducing a known bad pattern or a vulnerability.

Developers can get instant vulnerability feedback via IDE plugins, but cloud coding agents like GitHub Copilot operate in isolated environments that are fundamentally incompatible with IDE plugins. This incompatibility makes it challenging to utilize state-of-the-art security tools early in the development cycle.

Another challenge with securing code was touched on in the introduction. The speed and autonomy of coding agents has completely changed the math on productivity. An agent can generate and commit dozens of complex PRs in the time a human developer would write a few functions. This volume of code overwhelms human developers with manual code reviews and security scan analyses from the CI/CD pipeline, turning them into a choke point.

The industry needs a solution that can integrate directly into the agent's workflow, identifying and correcting vulnerabilities at the moment the code is being generated or modified, without reliance on human analysis and feedback. GitGuardian MCP provides this capability by acting as an agent-native security tool directly available within the AI development environment.

Technical Implementation: Enforcing Security for Coding Agents with MCP

This section provides a step-by-step guide on how to integrate the GitGuardian MCP server directly into GitHub Copilot coding agent's configuration. This setup allows the agent to use the secret_scan tool to perform real-time security checks, ensuring code is secure before it is committed to a Pull Request branch and reviewed by humans.

If you just want to see the results, you can skip to the Demonstration section below.

1. Repository Setup

The first step is to establish an environment for the integration. In this example, we will set up a new empty repository in GitHub.

2. GitGuardian MCP Server Configuration

To integrate the MCP server, we need to add it to the agent's configuration and ensure the agent has the necessary permissions and network access.

We will add the GitGuardian MCP server to the Copilot coding agent configuration as shown below, referencing an environment secret for the personal access token variable (we will create this later).

{
  "mcpServers": {
    "GitGuardian": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/GitGuardian/ggmcp.git",
        "developer-mcp-server"
      ],
      "env": {
        "ENABLE_LOCAL_OAUTH": "false",
        "GITGUARDIAN_PERSONAL_ACCESS_TOKEN": "COPILOT_MCP_GITGUARDIAN_PERSONAL_ACCESS_TOKEN"
      },
      "tools": ["scan_secrets"]
    }
  }
}

Next, add https://api.gitguardian.com and https://dashboard.gitguardian.com to the Copilot coding agent internet access custom allowlist.

3. Service Account and Secret Management

To authenticate the agent's security scans, a dedicated GitGuardian service account with minimal permissions is required.

We can set do this in the GitGuardian settings. Create a new service account, and give it "scan" permissions.

Use the button at the bottom to create the service account and save the new service account's token for a later step.

4. Configuring the Environment Secret

The service account's token must be securely stored as an environment secret so that it's only accessible by the Copilot agent's MCP config.

Go to the GitHub repo's environment settings and navigate to the copilot environment or create one if it doesn't exist.

Add the environment secret we referenced earlier named COPILOT_MCP_GITGUARDIAN_PERSONAL_ACCESS_TOKEN, and paste the value of the service account token that was created in step 3.

5. Agent Instructions

The final piece of the setup is instructing the Copilot agent to use the new security tool as part of its standard workflow.

Create a Copilot instructions document that tells the agent to check all modified code with the secret_scan tool.

The GitGuardian MCP server is now set up and ready to be used by the Copilot coding agent.

Demonstration: MCP Security Tools in Action

To validate the MCP integration and Copilot's adherence to our new security rules, we can observe the agent's behavior during a typical development task.

1. Assign a task to Copilot

First, we will ask Copilot to generate code by creating an issue and assigning it to Copilot. In this example, we are asking for a boilerplate Flask API that supports authentication.

For demonstration purposes, we will explicitly ask Copilot to hardcode the secret key (this is a contrived example to force a finding, but hardcoded secrets may occur without explicit instructions).

2. Observe Copilot's behavior

Once assigned a task, Copilot will create a draft PR to track its work. Navigate to the PR and view the coding session to observe its activity in real time.

When the session kicks off, we can see the GitGuardian MCP server starting up.

As the agent implements the Flask API, we can see it has hardcoded the secret key.

Once Copilot is done making changes, it calls the secret_scan tool as instructed and finds the hardcoded secret key.

Because we explicitly asked Copilot to hardcode the secret to demonstrate this example, the agent only adds warnings instead of actually remediating the issue. In a real scenario, Copilot would not have conflicting instructions about how to handle the secret findings and would remediate the issue automatically.

Conclusion

In this blog post, we demonstrated how GitGuardian MCP can be used to shift security left in the absence of traditional security tools like IDE plugins. While hardcoded secrets are a prevalent and critical finding, the challenge of securing AI-generated code extends beyond secret exposure. This approach of providing agents with state-of-the-art security tools should be replicated to automate the detection and resolution of many issues.

Agents, like humans, aren't perfect, but we can secure AI-generated code. By embedding security directly into the AI agent's control plane and instructions, organizations can enforce security checks at the earliest possible stage, significantly accelerating the safety and productivity of agentic software development.

Protecting Developers Means Protecting Their Secrets

Dwayne McDaniel — Thu, 25 Jun 2026 16:57:12 +0000

When most people think of "Enterprise Security," they immediately think of hardened data centers, locked-down cloud environments, and SOC teams watching dashboards late into the night. They picture firewalls, SIEM alerts, and tightly controlled production systems.

What they rarely picture is the most active piece of enterprise infrastructure in the company: the developer workstation. Yet that laptop is where credentials are created, tested, cached, copied, and reused across services, bots, build tools, and now local agents. Attackers have noticed.

Let's take a closer look at how developers have become the entry point for evolving supply chain attacks and what we can do about it.

Why Developers Have Become Targets For Supply Chain Attacks

Developers have always been attractive targets for attackers. To do their work, devs need access to internal systems and codebases, and attackers have always tried to leverage that access. In the past, that often meant physical theft, shoulder-surfing, risky Wi-Fi, or waiting for a developer to accidentally commit a secret publicly. Credentials were issued more deliberately, usually as long-lived API keys, with the expectation that the developer would guard them against human-scale snooping and loss.

But the developer reality has changed. Today, developers regularly create and connect new credentials for services, bots, build systems, agents, and every other kind of non-human identity (NHI). Approval workflows can not keep up with escalating delivery pressure, so many developers create "temporary" credentials to get things working quickly. Those get stored in local .env files and other plaintext configs, which still feel "safe" because they are on their own machines.

Adversaries Evolved Right Alongside Enterprise IT

Attackers no longer need physical access to a laptop or Remote Desktop Protocol (RDP) connections. Instead, they slip into the toolchain. The Shai-Hulud campaigns combined dependency compromise with systematic local environment harvesting. The attack involved harvesting local environment data, running structured secret scans, and exfiltrating what they found at scale, with the same valid secret often duplicated across many locations.

And now, AI agents can be turned into accomplices. For example, the S1ngularity attack used malware that weaponized local AI agents to facilitate credential theft, starting from a familiar supply-chain entry point. Ecosystems like OpenClaw normalize installing "skills" that can include links, scripts, and copy/paste commands, turning documentation into an execution path on machines holding enterprise credentials.

No matter how the malicious code is executed on the machine, the net result is the same: attackers are not just trying to steal code, they are trying to steal the locally stored secrets that unlock everything else. Any theft of valid credentials brings a much higher risk of unauthorized access, exactly what security leads are worried about.

Reducing Risk On Development Machines

Let's take a closer look at some steps and best practices you can implement right now, and some longer-term strategies you can adopt to mitigate the risks that secrets on the developer workstation can pose.

Understand Your Exposure

Start with visibility on the developer machine, because attackers do not need a dramatic intrusion when secrets are already sitting in plaintext across workspaces and tool caches. You need to treat the workstation as the primary environment for secrets scanning, not an afterthought.

In practice, that means running scans with ggshield, the command-line tool that extends the power of the GitGuardian platform to the developer's terminal, to identify secrets in obvious and not-so-obvious places.

ggshield detecting a secret in a specific file from a path

Of course, you should scan local repositories to catch credentials that slipped into the code and to detect anything still lingering in Git history. Once committed, even if removed in the next commit, secrets remain in your shared repository's history forever.

You should also scan across the filesystem paths where secrets accumulate outside Git, because that is where most of the real exposure lives. Project workspaces, dotfiles, and build output are the obvious culprits, but agent folders matter just as much now. Local agents generate logs, caches, and "memory" stores that often include pasted tokens, copied config blocks, and troubleshooting output.

Even when a developer never commits a secret, those "other" folders and files can still become a reliable second source of plaintext credentials sitting on disk.

Don't Forget Environment Variables

Do not assume environment variables are "safe" just because they are not in Git. On developer machines, environment variables are often persisted and duplicated in ways that are easy to forget and easy for malware to harvest.

Shell profiles, terminal session files, local run scripts, devcontainer configs, IDE settings, and generated artifacts can all end up storing environment values on disk, sometimes indefinitely.

Treat these locations as part of your normal exposure surface, and scan for them the same way you scan repos and workspaces, because attackers are increasingly harvesting local environment data as a direct path to valid credentials.

Stop the Bleed

Once you start scanning locally, add ggshield pre-commit hooks so you stop creating new leaks while you clean up the old ones. This turns secret detection into a default guardrail that runs as part of normal work, catching mistakes immediately and giving developers a clear next step to fix the issue before it turns into an incident.

ggshield pre-commit command catching a secret

Move Valid Secrets Into A Vault Or Password Manager

Stop making .env files the place where "real" values live. Keep a tracked .env.example (or similar) with variable names and safe placeholders. From there, switch local runs to pull values at execution time from your vault or password manager, so the secret only exists in the process environment for the moment it is needed.

For example, if your team uses 1Password, the practical pattern is to store project secrets in a shared vault or an Environment, then launch your app with secrets injected at runtime using the CLI. 1Password documents using op run to run a command with secrets available only as environment variables for that subprocess, and op inject when you need to resolve secret references in config templates without keeping plaintext values sitting around.

If your team has already invested in CyberArk Conjur, for example, the pattern looks very similar with their command-line tool summon which is explicitly built to load secrets from a secret store into a subprocess environment. You keep a small secrets.yml mapping environment variable names to Conjur variables, then run your app with summon -p summon-conjur -- <command> so the values are pulled from Conjur just-in-time and never need to live in plaintext files on disk.

There is another benefit to this approach: governance. Once inside a secrets manager, your security and operations team can start tracking the state of these secrets with tools like GitGuardian's NHI Governance platform, checking for policy breaches against the riskiest states, as defined by OWASP's Top 10 for NHIs.

GitGuardian Analytics showing the state of secrets being monitored

When .env Is Required, Use SOPS and Embrace a Global .gitignore

Sometimes an .env file is the simplest way to run a service locally, and pretending otherwise just pushes developers into weirder, less visible workarounds. The goal is not to ban .env. The goal is to stop plaintext secrets from becoming durable artifacts that linger on disk. When .env is required, treat it as a controlled exception, then wrap it in guardrails that make the safe path the easy path.

First, when a team truly needs to keep environment values in a file for repeatable local setup, use SOPS so the file is encrypted at rest and can be safely stored and shared without being usable by an attacker. The developer experience stays familiar, but the risk profile changes because secrets are no longer sitting in plaintext.

SOPS guidance from the Secrets Management Guide resource

Next, adopt a global .gitignore that ignores .env and the other usual local-only files across every repo a developer touches. This can easily be done by editing your git config to use a defined .gitignore file, where you can specify file names and entire file types that git should not add to any commit. This is how you prevent the muscle-memory mistake of git add . or git add -A sweeping up a credential file during a busy day.

This is the posture shift you want to communicate: .env is OK as a workflow, plaintext .env is not fine as a storage model. A global ignore reduces accidental commits, and SOPS reduces the damage when files are copied, backed up, or otherwise exposed.

Treat Agentic AI Like a Secret-Leaking Machine Until Proven Otherwise

Agentic tools feel like productivity helpers, but operationally, they behave more like a new kind of automation account that can read files, run commands, and move data between systems. Treat them that way from day one.

With OpenClaw-style agents, the "memory" is not an abstract concept. It is literally files on disk, commonly SOUL.md and MEMORY.md, stored in predictable locations and often in plain text. That changes the risk model for developers because anything you paste into an agent session, plus anything the agent decides to remember, can become a durable local artifact that other malware can simply steal.

Never paste credentials into agent chats, never teach the agent secrets "for later," and treat agent memory files as sensitive data stores that must be kept secret-free and routinely reviewed and scrubbed.

When scanning for secrets, we must take these new files and workflows into account.

Eliminate Whole Classes of Secrets with WebAuthn and OIDC

The other suggestions so far have been very achievable in the short term. Let's now look at longer-term strategies. For most teams, these changes usually mean changing how people log in, how services authenticate, and how platforms are wired together. It also pays off the most. The fastest way to reduce secret sprawl is not to store secrets "better," it is to remove the need for entire categories of shared secrets in the first place.

On the human side, WebAuthn (passkeys) replaces passwords and a lot of the brittle recovery and MFA bypass paths that attackers love. On the workload side, OIDC federation replaces long-lived cloud keys and service account secrets with short-lived tokens issued at runtime.

The practical way to roll this out is in slices. Start with the highest-risk paths where leaked credentials hurt the most, then expand. Move developer access to passkeys as teams adopt compatible identity providers and devices. In parallel, migrate CI and deployment workflows to OIDC-based auth so pipelines stop relying on stored cloud keys, registry tokens, and shared secrets.

This is a program, not a weekend task, but every piece you migrate is one less secret that can leak from a workstation, a repo, or an agent's local memory.

Move To Ephemeral Secrets And Identity-Based Authentication Workflows

If you cannot eliminate secrets yet, the next best move is to make them short-lived, narrowly scoped, and automatically replaced. Ephemeral credentials change the economics of theft. A token that expires quickly and cannot do much is far less useful than a long-lived key that sits quietly on disk for months. This is how you reduce the blast radius when a developer machine gets hit by a dependency compromise or an infostealer.

This is also where SPIFFE fits cleanly into the story. SPIFFE is built around issuing short-lived cryptographic identity documents called SVIDs (either X.509 certificates or JWTs) to workloads, so services can authenticate using identities that rotate automatically instead of relying on static API keys embedded in configs.

In rollout terms, "ephemeral by design" means you deliberately replace the worst offenders first. Start with long-lived cloud keys, deployment tokens, and service credentials that developers or runners keep locally for convenience. Shift those paths to short-lived tokens, automatic rotation, and workload identity patterns like SPIFFE/SPIRE wherever they fit. Each migration is one less durable secret that can be stolen, reused, and quietly weaponized later.

Closing the Developer Secret Gap

Developer workstations are part of the software supply chain, sitting at the intersection of rapid delivery, expanding NHI creation and use, and local automation tools. This is exactly why attackers have shifted their tactics. They no longer need to wait for a secret to be pushed to a repo or gain hands-on access to a laptop.

If a credential exists in plaintext anywhere on the machine, including build output, dotfiles, and agent "memory" files, it can be harvested and reused to unlock systems that were never meant to be reachable from a single endpoint compromise.

GitGuardian is here to help. The GitGuardian platform is built to help teams eliminate secrets sprawl across the full surface area where it appears, from source code to developer machines to emerging agent workflows. With ggshield as the developer-side control plane and platform-backed detection, remediation, and governance, teams can move from occasional cleanup to continuous prevention.

The end goal is smaller exposure, shorter secret lifetimes, and fewer opportunities for attackers to turn one compromised developer environment into enterprise-wide access. We would love to help you on your journey.

Claude Code Security: Why the Real Risk Lies Beyond Code

Dwayne McDaniel — Tue, 23 Jun 2026 12:50:25 +0000

Many cybersecurity professionals have been following Anthropic's announcement about the release of Claude Code Security on Friday. This created the beginning of a panic on the cybersecurity stock market. It also raised a lot of questions from domain experts, investors and security enthusiasts.

Anthropic's announcement

Anthropic introduces Claude Code Security: a tool that scans full codebases for security vulnerabilities, and can propose fixes directly in developer workflows. The tool leverages the latest foundational model's reasoning capabilities to provide a new experience. In a world where code will be generated only by AI, this can sound very much like code security is dead.

Our vision

18 months ago, SAST, SCA, and IaC security were areas where we had real traction and could see ourselves expanding. But as AI tooling started reshaping how code gets written, we made a tough call. We decided to stop these initiatives and go all-in on what we believed would matter most: Protecting enterprises against leaked secrets and mismanaged NHIs.

We envisioned a future where identity is crucial for the AI era security, with secrets enabling AIs to access data and take actions. After pioneering in secrets detection for years we witnessed how amplified the problem became as LLM emerged: more API keys for AI services, more code generated, often less secure, more agents requiring sophisticated access to a myriad of tools. All in all, this resulted in more secrets exposed. Yet the problem of overseeing and managing these secrets in a secure way remains unsolved.

The paradigm shifted from human hardcoding secrets in their code, to AIs having wide access levels on several systems with humans, coders and non-coders, prompting them and creating new vulnerabilities.

18 months later, let me describe where we stand.

What isn't changing

Best in class secrets detection

GitGuardian is the leader in secrets detection. We are the only solution able to scan large volume of data at scale (50 MB/s per core at negligible cost) in addition to +30 different data sources (ticketing systems, messaging apps, container registries, …).

Our latest State of Secrets Sprawl report (will be released in March) clearly shows that AI-assisted coding has boomed over the last 12 months, with the number of AI generated commits growing a 10x factor over the past year. We also see that these commits used to contain more secrets in the first half of 2025; however, the number of secrets per commit started decreasing at the end of the year, probably reflecting the improvements of foundational models.

Remediation is where the real work begins

Our value proposition is very different from static analysis, or vulnerabilities in dependencies. Remediating a secret exposure is a hard problem: One that involves manual actions and human control. It's not just about fixing the code. It's about not breaking production, mapping the infrastructure, assessing the blast radius of a secret rotation and coordinating this effort across your org.

GitGuardian has been spending the last 7 years exploring and pioneering in this area.

Because secrets are not only a vulnerability when they are exposed but also when they are mismanaged, a year ago, we released NHI governance: a product specifically aiming at providing a 360 view of how your secrets are spread and used in your org. We're not only looking at leaked secrets, but thanks to ggscout, we are able to also observe the dissemination of your secrets across servers, apps and vaults with context.

You cannot manage what you can't see. You need this inventory to remediate leaked secrets and spot weaknesses in your organization. Secrets used across multiple environments, overpermissioned, not being rotated, exposed publicly or sprawling across all your vaults.

Enterprises are not looking for point solutions

One key learning we have seen in the past is the importance of being able to orchestrate your identities security, at scale. Serving Fortune 500 enterprises for the past 7 years has taught us that point solutions are not enough. Our customers are looking for a unified experience with several key capabilities.

Think integrations with multiple data sources, notifications, aggregated analytics and metrics, RBAC, users management, fine tuning and customization.

This is what we are proposing at GitGuardian.

Emerging threats, new horizons

In the past months, GitGuardian has been pushing in several directions to provide an even better security posture as the attack surface grows.

We believe that endpoint security becomes critical. Developers' laptops are the next frontier for attackers. We've seen the emergence of sophisticated attacks (such as NX/s1ngularity or Shai-hulud) that specifically took advantage of machines weaknesses.

This is why we built our local scanning and identities inventory tool. This solution is the ultimate tool for security engineers to get a clear understanding of which machines hold which secrets. You can deploy it across your workforce via an MDM, and GitGuardian will re-surface all the weaknesses and points of attention: overprivileged credentials, production credentials ending up on a developer's laptop.

In the past 12 months, we have also worked hard on agentic security. Managing your attack surface has become THE biggest challenge for security engineers in the AI era.

I love to think of agent as LLM + Context + Ability to perform actions. Your agent will be more and more powerful as each of these dimensions increase.

The problem is: both context and ability to perform actions require authentication. How do you secure these?

On top of that, and to get a sense of the scale we are talking about: AI does not enter your enterprise in a perfectly supervised manner. Shadow IT, experimentations launched in all your departments by all types of profiles, third party tools being used by your SaaS providers make the agentic footprint bigger than what you think.

All in all, having a 360 view over your agents and identity security is harder than ever. This is what we are committed to achieving at GitGuardian.

Because of these concerns regarding endpoint security and managing the attack surface, we are also doubling down on our historical HoneyTokens offering to proactively detect breaches. We are now able to support a handful of custom providers, and to disseminate these traps at scale in your organization.

"The road ahead"

Anthropic describes the road ahead, how attackers benefit from AI, and how Claude Code Security will make code bases more secure. We are living exciting times for sure. But remember: Hackers don't break in, they log in. With AI generating more and more code, and models being trained to generate safer code, the attack surface is different. But different does not mean smaller; it now spans far beyond code. GitGuardian and all our teams are committed to making AI a safe place. This starts with securing your non-human identities and secrets across your whole organization.

Who Actually Owns This Service Account?

Dwayne McDaniel — Mon, 22 Jun 2026 13:23:47 +0000

When that AWS service account gets compromised, who do you call?
A question that shouldn't be hard.

If you're in security or platform engineering, you already know the answer is usually "I have no idea." Maybe you search through GitHub commit history. Maybe you ping three different Slack channels. Maybe you can check the wiki that hasn't been updated since 2023. And while you're doing all that detective work, the clock is ticking, and the compromised credential is still active.

This isn't a tooling problem or a people problem, it's an accountability problem. Your organization has spent years hardening human identity security. MFA everywhere, least privilege enforcement, and regular access reviews. But machine identities? Those service accounts, API keys, CI/CD tokens, and bot credentials that outnumber your employees by orders of magnitude? Nobody owns them. Nobody's responsible. And when something goes wrong, everyone pays the price.

We provide ownership in GitGuardian NHI Governance to fix this. With automatic owner suggestions pulled from your existing tools and the flexibility to assign accountability however it makes sense for your team.

The problem everyone is finally talking about

When 2 AM incidents expose the accountability gap

Let's walk through what actually happens during a credential leak. Your secrets detection tool catches a GitHub personal access token in a public repo. It has write access to the production infrastructure. It's the middle of the night.

The race starts: Can you find the owner and rotate the credentials before an attacker finds them?

Without ownership metadata, here's what your security engineer does:

Check the commit that exposed it (the author left the company six months ago)
Search Slack for the repo name (find twelve threads, none conclusive)
Look up the org chart (the team was reorganized twice this year)
Page someone who might know someone who might know

Forty-five minutes later, you've got a "pretty sure" answer. The credential gets rotated. Maybe nothing bad happened. Maybe you got lucky.

This happens all the time. Not because people are careless, but because accountability for machine identities simply doesn't exist in most organizations. They're created during product sprints, inherited through team transitions, and forgotten when projects end.

Why machine identities are the forgotten stepchildren of IAM

Think about how your company handles human identity governance. There are clear owners for every account. Access gets reviewed quarterly. When someone leaves, offboarding workflows kick in automatically. You have audit trails, approval chains, the works.

Now think about your service accounts. How many do you have? (Most teams guess low by at least 50%.) Who created them? Who uses them? Who's responsible for rotating or deprovisioning when needed? The answers usually range from "unclear" to "absolutely no clue."

We built ownership into NHI Governance

Here's how it works: GitGuardian now assigns and tracks owners for every non-human identity in your inventory. You can see who's responsible, filter by ownership status, and update assignments whenever you need to. It starts working automatically and gives you full control.

How it works (and why we made it automatic)

The last thing you need is another system to manually populate. So we built ownership to learn from your existing tools and data.

GitGuardian analyzes your integrated sources(IAM systems, cloud providers, incident history, and even commit data) and suggests owners based on the strongest available signals. The ranking goes like this:

If your IAM or IdP has an explicit owner field, we use that (highest confidence). Next, we check resource tags for owner metadata. Then we look at who configured the integration, who last edited or created the resource, which developers' commits triggered incidents involving this identity, and who detected associated secrets in public scans.

The system picks the best candidates and suggests up to five owners per identity. You'll see them labeled "Set automatically by GitGuardian" in the detail view. You can keep them, remove them, add more, or replace them entirely. Automatic suggestions never overwrite manual assignments.

Owners suggested automatically by GitGuardian can be confirmed, removed, or supplemented with manual assignments—including external users.

You can override everything

We're opinionated about defaults but flexible about exceptions. Every NHI has an Owners section in its detail view where you can:

Add owners manually (workspace members or external users by email)
Remove suggested owners you disagree with
Replace the entire owner list if needed

External owners don't need GitGuardian accounts. Contractors, external partners, people in other divisions—anyone with an email can be assigned accountability.

The inventory view shows up to two owners per identity in an Owner column. Use the filter to narrow your view: identities with no owner, everything owned by you, or a specific person's responsibilities.

Filter the NHI inventory by owner to find unassigned identities or see all credentials you're responsible for.

If you want to automate ownership assignment during provisioning or sync with your CMDB, the public API has you covered. Use the nhi:ownership: read and nhi:ownership: write scopes to list, add, remove, or replace owners programmatically.

What changes when every identity has an owner

Incident response that doesn't require a manhunt

Remember that 2 AM credential leak scenario? With ownership, the process is completely different.

Alert fires. Security engineer opens the NHI detail view. Sees the owner. Pings them in Slack. Credential gets rotated. Done.

That time savings compounds. When your team isn't spending half their day tracking down owners for incidents, they can focus on the actual security work: threat modeling, control improvements, risk reduction.

The orphaned account problem actually gets solved

Orphaned identities (machine credentials that outlive their projects or creators) are some of the easiest targets for attackers. They typically have over-provisioned permissions, no rotation schedule, and zero monitoring. They're just sitting there waiting to be abused.

Ownership doesn't magically delete orphaned accounts, but it creates the conditions for hygiene at scale. Filter the inventory for "No owner" and you instantly see every identity that needs attention. Assign owners so that when projects shut down or people leave, their associated identities get reviewed and deprovisioned.

Auditors stop asking the same question twelve times

If you've been through SOC 2, PCI-DSS, or HIPAA audits, you know the drill. Auditors want proof of accountability for privileged access. They ask questions like:

"Who is responsible for this service account?"
"How do you enforce least privilege?"
"What happens when someone with access leaves the company?"

Without ownership data, you pull together spreadsheets, dig through tickets, and reconstruct timelines from memory. It takes weeks. Findings pile up because you can't definitively prove accountability.

With ownership, you export the data. The audit that used to take three weeks takes three hours. Every identity has a clear owner. You can show assignment history, prove continuous accountability, and demonstrate segregation of duties. Auditors get their evidence, you get back to work.

Try it yourself

Ownership is now live in GitGuardian NHI Governance. Here's how to get started:

Open NHI Governance → Identities, and you'll see the new Owner column. Filter by "No owner" to see which identities need attention. Click into any NHI and use the Owners section to add, edit, or confirm ownership. If you want to automate things, check out the API docs.

Learn more: NHI Ownership documentation

Get started: Sign in to GitGuardian or request a demo

Stop spending your nights hunting down owners for compromised credentials. Make accountability part of your identity model from the start.

Security First, Transparency Always: Inside GitGuardian's Responsible Disclosure Process

Dwayne McDaniel — Wed, 17 Jun 2026 15:31:52 +0000

Since its creation in 2017, GitGuardian has automatically detected secret leaks in all public commits on GitHub, and sent warning emails to the developers concerned through its Good Samaritan Program. Although this method is efficient and enables secrets to be revoked quickly, it does have certain limitations. Indeed, there are a number of problematic scenarios. For example, a secret may be deleted from GitHub following our email, but remain valid because it has not been revoked. Likewise, a secret may belong to a company, and the person who leaked it is no longer part of it or is a contractor who doesn't know how to deal with it.

Overall, we find that 70% of the valid secrets we detect are still valid 3 years after their initial exposure. This clearly requires a call to action, as leaked corporate secrets are probably not being remediated as they should be. As a matter of fact, the most sensitive secrets we uncover are, unsurprisingly, linked to the critical components of modern business: code and artifact repositories, databases or virtual machines. Their exploitation is often straightforward, yet they represent a direct and major security risk.

Responsible Disclosure

Aware of the potentially devastating impact of some of the highly sensitive secrets we uncover, such as those of private Artifactory instances or Azure Storage Accounts, to name but a few, we have decided to overcome the limitations mentioned above by identifying corporate secrets and contacting the corresponding companies.

The secret to your Artifactory: A Deep Dive into Critical Exposures

In this context, the use of responsible disclosure practices makes perfect sense. Vulnerability disclosure is a well-known and documented process that provides a structured approach to cybersecurity collaboration. By following well-defined rules and best practices, such as using encrypted emails, or respecting disclosure delays, organizations and cybersecurity researchers can effectively work together to remediate leaked secrets.

Six months ago, GitGuardian set up a clear procedure for notifying companies of leaks of sensitive secrets, based on two fundamental points.

Firstly, we are committed to ensuring that "security comes first." To achieve this, our first priority is to get in touch with the security teams who are best placed to assess and deal with the leak quickly. In our exchanges, we prefer to use GPG-encrypted e-mails to preserve the confidentiality of the data exchanged.

Secondly, the content of our exchanges is as transparent as possible. We present precisely where the leak is (i.e. GitHub, DockerHub, or private resources), the nature of the associated secret, how it can be detected, and whether it is valid or not.

Key Takeaways

In the time we've spent helping to fix tens of incidents, we've witnessed every kind of behavior: from a fix in minutes to no response at all. While some of the critical secrets we uncovered are still valid today, the positive outcome is that most of the leaks disclosed have been remediated, or will be soon.

Along, the clear responsible disclosure process that we put in place, we also maintain a dedicated registry that tracks the disclosed leaks and the state of the corresponding communications. This ensures fairness and transparency and makes it possible to externally audit this activity.

Since October, we have disclosed 24 leaks to an equivalent number of different companies. Most of them - 15 to be precise - have been resolved. This excellent result is due to the fact that we were able to contact the security teams of the companies concerned directly.

Of the 9 remaining leaks, 4 have been acknowledged and are currently under investigation. We are therefore very confident that they will be resolved too. For the other 5, we have received no response to our emails despite our efforts to find the right contact (i.e. a Staff Security Engineer, the CISO or the DPO). This is quite worrying as we are talking about large organizations putting their security at risk.

Like many other researchers, we also get much better response rates when security teams are contacted directly. Having an easily identifiable address makes it easier for researchers. This reinforces the need for every organization to identify the right contacts in the event of security incidents, and publish them on their sites or via ad hoc mechanisms such as the security.txt file. Sadly, a disclosure email concerning a 6-year-old secret from an oil company's Artifactory went unanswered. The leak, meanwhile, was silently fixed several months after its disclosure.

Public Acknowledgments

While some companies do not behave according to the accepted rules of responsible disclosure, and forbade us to communicate on our findings, others are exemplary in their communications with researchers and the way they credit them.

We are pleased to have worked closely with such companies, and honored to be credited in their hall of fame following the responsible disclosure of secrets leaks:

And this is just the beginning! We are proud to help build a safer world for both individual developers and companies.

Extending Our Mission With Developer Endpoint Protection

Dwayne McDaniel — Tue, 16 Jun 2026 20:15:24 +0000

Since day one, our mission at GitGuardian has been clear: prevent accidental secret exposure and stand alongside developers as they build. We've helped thousands of teams secure their code repositories and other data sources, preventing credentials from leaking.

The risk has moved. Developer workstations have always carried more credential exposure than most teams realize: shell histories, config files, local caches accumulating credentials for years. AI coding agents are accelerating that risk. Tools like Cursor, GitHub Copilot, and other AI assistants are now running on thousands of developer machines with access to every credential and sensitive file on the laptop, creating accumulation paths that traditional security tools don't see.

Every developer laptop is a credential store. Infostealers and supply chain attackers treat it exactly that way. Credentials don't just live in Git. They end up in .env files, shell histories, AI agent configs, and local caches, sitting in plaintext outside your perimeter controls. A single compromised laptop can hand attackers the keys to your entire infrastructure. Our early access program data puts the average at 150 secrets per developer laptop, with some machines ranging into the thousands.

The partition between code-resident and endpoint-resident credentials no longer exists for attackers. And with AI coding agents now running on every developer machine, the surface is growing faster than most security stacks can track. That raises the question: how do we make sure companies can deploy AI safely?

What We've Built

Today we're releasing Developer Endpoint Protection: the ability to find every credential on every developer machine, built directly into ggshield, the GitGuardian CLI already in use across our customer base.

We rebuilt the scanning engine in Rust from scratch. In our latest tests, it scans 500,000 files in under one minute, then uses intelligent caching to complete subsequent scans in seconds. All scanning happens locally on the endpoint. Credentials are never sent to GitGuardian in clear text, and we never see the credentials.

Traditional endpoint tools chase binaries. Developer Endpoint Protection tracks the credentials and the AI tooling generating them. Each credential found maps back to the production systems it unlocks and every other place that same credential lives, building a continuous inventory you can monitor, alert on, and push into the tools you already use.

But scanning is only half the story. We also place honeytokens on developer machines. If an infostealer finds and uses one of those credentials, the honeytoken fires immediately, with attribution, before the attacker has used it. Instead of discovering a breach weeks later in a log review, you know the moment it happens and which machine was hit.

Why This Matters Now

1. Finding Credentials Beyond Repositories and Collaboration Tools

For years, we've been catching credentials leaking into code repositories and collaboration tools. Developer machines have always had the same problem: shell histories, config files, temp directories, and AI tool caches pile up credentials over time, invisible to the rest of your stack. Endpoint Protection takes that mission to the machine.

2. Closing the NHI Governance Blind Spot

Machine endpoints are a blind spot in NHI governance. Over-privileged service accounts, API keys, and machine credentials don't just live in vaults and cloud platforms. They're scattered across developer workstations. By surfacing endpoint findings in the GitGuardian dashboard, you can finally answer: "Where are our credentials actually living across our entire infrastructure?" and prioritize remediation based on what's sensitive and in active use.

3. Securing the Agentic AI Era

AI coding agents expand the attack surface. These agents operate with access to everything on a developer's machine: the credentials developers intentionally use and the ones that accumulate in shell histories, browser storage, and AI agent config files. In our analysis, around 40% of high and critical secrets surfaced in AI tool directories and log files, locations no traditional scanner looks at. Endpoint Protection gives you a full picture of that credential exposure as your AI footprint grows. We scan at three points in the AI workflow: prompt submission (before content reaches the model), pre-tool execution (before file reads or commands run), and post-tool output (after the agent responds). Each stage is an exposure path that traditional repository scanning never sees.

The platform also inventories which AI tools and MCP servers are running on each machine, surfacing unauthorized or potentially malicious MCPs before they can access or exfiltrate data.

Three Core Capabilities

Remediate at the source. Redact credentials from shell and command histories, migrate active credentials into vaults and local secrets managers, and prevent AI coding agents from spreading credentials across the machine through GitGuardian agent hooks. The goal is focused action, not endless triage.

Limit the blast radius. Continuously hunt plaintext credentials across the fleet, score each finding by severity and actual access scope, and route high-risk findings directly to your SOC, SIEM, and SOAR. When a breach lands, you can answer immediately: what was on this machine, what services does it reach, and what do we revoke first?

Detect live attacks. Honeytokens placed on developer machines fire the moment an infostealer validates a credential, confirming an attack before it's used against you. You get attribution-rich alerts in real time, not noise.

Because these signals are most powerful when correlated with your existing credential sources, endpoint findings feed directly into GitGuardian's NHI and Secrets Security platform, connecting your endpoint exposure to vaults, repos, and cloud environments in one place.

Designed for Real-World Enterprise Deployment

We know enterprise security teams need more than a cool demo. We're building for:

Deployment at scale: MDM-based rollout (Windows/Intune, Jamf) with MDM-compatible authentication for large fleets
Developer-friendly: minimal performance impact with intelligent caching, configurable exclusions, and CPU/memory limiting
Privacy-first architecture: local scanning with no credential exfiltration; only structured metadata leaves the endpoint
Integration with your existing stack: forward structured outputs to SIEM, pull data via API, correlate with vault and identity systems
Cross-platform: Windows, Linux, macOS

Built on ggshield: One CLI, Expanded Mission

We deliberately built this as an extension of ggshield rather than introducing another tool. One CLI, expanded mission. If your team already uses ggshield for pre-commit hooks and CI/CD scanning, it slots into the same workflow your team already trusts.

We're already in conversations with Fortune 500 enterprises across financial services and technology where AI coding agent deployment has made endpoint credential visibility a real priority. The ask is consistent: give us endpoint credential visibility that fits our MDM rollout, our privacy requirements, and our SIEM.

Start Your Pilot

Developer Endpoint Protection finds credentials on developer machines and blocks them from moving into shared systems. It does not rotate credentials, manage vaults, or enforce remediation workflows; that's where Internal Secrets Monitoring and NHI Governance come in. Used together, the GitGuardian platform gives you coverage from endpoint to repository to identity.

Developer endpoints are the most unmonitored surface in secrets security. The organizations that know what credentials are on their machines recover faster from supply-chain incidents. The ones that don't find out during the breach.

We've extended our mission from the repo to the machines so that you can find every credential on every developer laptop before infostealers do.

Ready to see what's on your fleet? Contact your GitGuardian customer success team or book a demo.

The State of Secrets Sprawl 2026: AI-Service Leaks Surge 81% and 29M Secrets Hit Public GitHub

Dwayne McDaniel — Fri, 12 Jun 2026 12:24:02 +0000

In less than a year, AI-assisted coding went from novelty to habit.

What used to be a specialized workflow for experienced engineers is now accessible to almost anyone with an idea, a prompt, and a few minutes.

In 2025, that shift became impossible to ignore. Software creation sped up, public GitHub activity surged, and a new generation of services, agents, integrations, and configuration patterns entered the stack all at once. That speed came with a cost.

According to our latest "State of Secrets Sprawl" report, 28.65 million new hardcoded secrets were added to public GitHub commits in 2025 alone, a 34% increase year over year and the largest single-year jump we've recorded.

The year software changed forever

2025 was a banner year for software production. Public GitHub commits climbed to about 1.94 billion, up 43% year over year, and the developer base increased by 33%.

Public GitHub commits grew by 43% and active developers base grew by 33% since 2024

AI is creating a new generation of leaks

AI makes it easier and faster to build, integrate, and ship. But every new tool, API, workflow, agent, and service account also creates new credentials to manage and more surface area for attackers to target. When organizations scale creation faster than governance, secrets begin to spread everywhere.

One of the clearest signals in the data is that the composition of leaked secrets is changing. In 2025, AI service secrets reached 1,275,105, up 81% year over year. The report points to 113,000 leaked DeepSeek API keys as one example of how these windows of exposure open.

The report also found that eight of the ten fastest-growing detectors were tied to AI services. LLM infrastructure, such as orchestration, RAG, and vector storage, leaked 5× faster than core model providers.

New AI providers, wrappers, gateways, registries, and integration layers are entering production workflows quickly, often before developer protections have caught up.

Claude Code-assisted commits showed a 3.2% secret-leak rate, versus a 1.5% baseline across all public GitHub commits. That gap is meaningful, but it should not be read as a simple tool failure. Developers remain in control of what gets accepted, edited, ignored, or pushed. Even as coding assistants improve their guardrails, people can still override warnings or ask the model to behave insecurely.

The leak still happens through a human workflow. This is an important nuance.

AI is changing the pace and shape of software development, but the underlying failure mode is still familiar: people under time pressure making local decisions in complex systems.

Number of secrets per 1000 commits

Hardcoding secrets into MCP configs

Taking a closer look at AI infrastructure, we identified 24,008 unique secrets exposed in MCP-related configuration files across public GitHub, including 2,117 unique valid credentials. This is 8.8% of all MCP-related findings.

The problem is often driven by the fact that the documentation itself encourages unsafe patterns. The report notes that popular MCP setup guides often recommend putting API keys directly into configuration files, command-line arguments, or embedded connection strings. When insecure credential handling is normalized in official quickstarts, it is no surprise that sprawl follows. This is the kind of pattern security teams should pay attention to early. New standards often arrive with convenience-first examples. If those examples assume hardcoded credentials, the problem can spread at ecosystem speed.

Public leaks are only half the story

One lesson security teams should take away from this report is that public GitHub is only the visible edge of the problem. Internal repositories remain a much larger reservoir of secrets sprawl. Internal repos are roughly 6× more likely than public ones to contain hardcoded secrets. This is the security debt created by private-by-default thinking. Teams are often less disciplined inside internal codebases because the exposure feels less immediate, but that private buildup becomes the material that attackers exploit once internal systems are reached.

The story gets broader from there. About 28% of incidents originate entirely outside repositories, in places like Slack, Jira, and Confluence. Those leaks outside of code are also 13 percentage points more likely to be categorized as critical than secrets found only in code.

Secrets shared in collaboration tools are often passed around during urgent troubleshooting, incident response, or operational debugging. They are copied into messages and tickets precisely because someone needs fast access. The context is urgent, and urgent contexts tend to produce high-impact exposures.

Developer workstations are now a prime target for secrets theft

As AI agents gain deeper local access to terminals, files, editors, environment variables, and credential stores, the laptop itself becomes a more meaningful attack surface. The report connects this to prompt injection and supply-chain attacks such as Shai-Hulud, which turn local secrets into organizational risk. GitGuardian's analysis of the Shai-Hulud 2 dataset offers a rare empirical window into what actually lives on developer machines. Across 6,943 compromised machines, the team found 294,842 secret occurrences, corresponding to 33,185 unique secrets.

Shai-Hulud 2.0: the supply chain attack that learned

The report also notes that 59% of the compromised machines were CI/CD runners rather than personal workstations, which expands the problem well beyond the individual endpoint.

For years, secrets management was framed mostly around shared code repositories and cloud platforms. But agentic workflows are redrawing the perimeter. When local environments hold credentials that connect across systems, the machine itself becomes part of the NHI problem.

64% of valid secrets from 2022 are still active and exploitable

In the 2025 report, we found that nearly 70% of credentials confirmed as valid in 2022 were still valid in January 2025, which means they had not been remediated. When we retested that same dataset in January 2026, the validity rate was still above 64%.

This gap is even more concerning because 46% of critical secrets are missed by validation-only prioritization, meaning many high-risk exposures remain underprioritized simply because they cannot be automatically verified.

The full State of Secrets Sprawl 2026 report dives deeper into all of these trends, from AI-assisted commits and MCP configuration leaks to internal repositories, collaboration tools, self-hosted infrastructure, and the long-term remediation gap.

From secrets sprawl to NHI governance

That phrase, "NHI governance," can sound abstract until you reduce it to the questions security teams actually need to answer:

What non-human identities exist in the environment?
Who owns them?
What can they access?

If a team cannot answer those questions, AI adoption is likely outpacing identity maturity. That is the deeper lesson of the 2026 report. AI did not invent secrets sprawl. It accelerated the conditions that make it worse: faster shipping, broader participation in software creation, more integrations, more service accounts, more local tooling, and more configuration surfaces where credentials can end up by mistake.

The future will contain many more non-human identities. That means the path forward cannot be just "scan harder." It has to include prevention, ownership, context, lifecycle control, and remediation workflows that are built for speed.

2,622 Valid Certificates Exposed: A Google-GitGuardian Study Maps Private Key Leaks to Real-World Risk

Dwayne McDaniel — Wed, 10 Jun 2026 12:02:51 +0000

This post is a companion piece to our presentation at Real World Crypto (RWC) 2026 in Taipei, Taiwan on March 11, 2026, where GitGuardian and Google researchers will present the full findings of this collaboration.

When a private key leaks on GitHub or DockerHub, detecting it is easy. What's harder, sometimes impossible, is understanding its real-world impact. Unlike AWS keys or OpenAI tokens, which are tied to their respective service, a leaked private key is just a mathematical object without an obvious owner.

Private keys are challenging to attribute at scale: they are used in many different contexts, ranging from SSH authentication to JWT signatures. When one leaks, where do you start assessing the impact? Among leaked private keys, those used in X.509 infrastructure are most critical. They authenticate web servers in HTTPS: a compromised key enables attackers to impersonate websites or intercept data. That's why GitGuardian partnered with Google's researchers to answer a deceptively simple question: what happens when private keys leak?

In the TLS ecosystem, a private key leak poses a critical threat, as attackers on the appropriate network path can impersonate websites, intercept or manipulate data, and decrypt past communications, particularly if the same private key is used for a long period of time prior to the widespread adoption of PFS.

The Numbers Behind the Threat

Since 2021, GitGuardian has detected about one million unique private keys leaked across GitHub and DockerHub. Using Google's internal Certificate Transparency database, we successfully mapped more than 40,000 of these keys to 140,000 real TLS certificates. As of September 2025, 2,600 of these certificates were valid, with more than 900 actively protecting Fortune 500 companies, healthcare providers, and government agencies.

Our disclosure campaign revealed worse news: we sent 4,300 disclosure emails to 600 organizations about their exposed certificates, but only 54 responded. That's a 9% response rate. Even for high-confidence identifications, only 36% bothered to reply. National CERTs? Only 2 out of 20 responded within a week. Bug bounty programs? Three asked us to prove that having a website's private key was actually a security problem.

Research pipeline

This reveals a widespread misunderstanding of private key risks. Months after disclosure, 84 certificates remain valid; 40% from Certificate Authorities (CA) we contacted but who failed to revoke.

This is the first Internet-scale analysis of private key leaks, made possible by combining two unique capabilities: GitGuardian's real-time secret detection across millions of repositories and images, and Google's infrastructure for querying Certificate Transparency logs containing billions of certificates.

Certificate Transparency (CT) is a public database of all certificates issued by major CAs since 2015, created after CA compromises like the 2011 DigiNotar breach. CT is a decentralized architecture with multiple operators hosting what are called logs, subsets of the CT database.

In theory, CT is perfect for mapping leaked keys to certificates using public key hashes. The mathematical properties of asymmetric cryptographic keys make it easy to link a certificate's public key information with its corresponding private key. In practice, storage and persistence are massive challenges. In 2025 alone, over 5 billion unique certificates have been submitted, representing more than 10 terabytes of storage. Moreover, log operators can disconnect logs once all their certificates have expired, which makes sense in the context of TLS but breaks OSINT and historical attribution.

As of September 2025, 2,600 of the mapped certificates were valid (6% of mapped keys). We validated 921 (35%) through direct online checks; the remaining 1,701 (65%) required simulated TLS stack validation.

Querying TLS revocation mechanisms revealed a widespread misunderstanding of the impacts: of all the certificates we found compromised, only 24 were revoked via Certificate Revocation Lists (CRL) – with just 1 marked as actually compromised – and 56 via OCSP – with only 2 marked as compromised. More troubling: nearly 22% of offline-validated certificates were found to differ from those served online. This usually indicates that a new certificate has been issued after the key leak, without revoking the compromised one. Owners either don't know about the leak or don't understand revocation.

Finally, since revocation is rarely used, we simulated historical validity by checking if the private keys leaked during their associated certificate's lifetime. This revealed that 24,000 certificates (17.16%) were valid at the time of the leak, and more than 4,000 are exposed per year.

Valid certificates at the time of first leak (in September 2025)

Responsible Disclosures

With certificates mapped, the next challenge emerged: finding and contacting their owners. Mapping private keys to certificates was indeed easy. Finding who owned them proved harder, but essential.

Our primary goal was to contact owners directly. As security researchers, we aim to fix root causes and alert owners to enable proper remediation. Without addressing the source of the leak, private keys remain in repositories and container images, ready for reuse.

Of 2,600 valid certificates, only 430 (16%) included organization information. For the rest, we deployed different attribution techniques: extracting domains from certificates, scraping security.txt and Whois records, analyzing MX records, and LLM-assisted web crawling. We identified entities for roughly half the certificates, leaving 1,300 certificates untraceable.

After three weeks of poor response rates, we contacted the major Certificate Authorities directly. Revocation processes vary by CA, but all require proof of ownership: a signature performed with the leaked private key. We submitted 2,200 valid certificates; most were revoked within 48 hours.

Concluding Remarks

This joint research between GitGuardian and Google represents a systematic analysis that maps leaked private keys to real-world certificate usage at Internet scale. This collaboration demonstrates that protecting the Internet at scale requires both technical innovation and cross-organizational partnership. The results speak to both success and systemic challenges. Our disclosure campaign achieved 97% remediation, but at the cost of 4,300 emails sent, 1,706 entities contacted, 9 bug bounty submissions, countless follow-ups, and days of meticulous attribution work employing multiple OSINT techniques. The high success rate masks the extraordinary effort required to protect organizations that fail to protect themselves.

Despite our efforts, in January 2026, 84 certificates remained valid: 27 from small CAs that didn't revoke, 6 from unresponsive government entities, and 51 from organizations that took no action. We re-contacted the relevant CAs and are still working with them to have the certificates revoked.

The research exposes hard truths: a widespread global misunderstanding of certificate security exists. Fortune 500 companies and governments leave leaked keys unrevoked. Private keys outlive multiple certificate renewals, remaining valid years after public exposure. This is a systemic failure, not isolated incidents.

The solution is clear. Cryptoperiods must be shortened, and private keys should never outlive certificates; ideally, they should be single-use. This isn't new: Let's Encrypt and Certbot already rotate keys with every renewal.

This practice should become industry standard, and CAs must forbid private key reuse. Compromised keys should be permanently blacklisted across all authorities. Combined with upcoming 47-day certificate lifetimes and mandatory rotation, this dramatically reduces vulnerability windows.

At RWC 2026, we present the full findings and roadmap. Private keys are leaking, and the industry can no longer afford to ignore them.

GitGuardian NHI Governance Now Gives More Comprehensive Visibility

Dwayne McDaniel — Tue, 09 Jun 2026 11:45:48 +0000

If you're an IAM lead, you've probably spent the last five years perfecting your human identity security. MFA everywhere. Privileged management locked down. Just-in-time access is working like a charm. Your employees' identities are pretty well governed overall.

But here's what's keeping us up at night, and I suspect you too: for every employee identity you're managing, roughly hundreds of machine identities are doing who knows what. API keys in places you didn't know existed. Service accounts that three different teams think someone else is managing. Bot tokens with access to production data that were created by an engineer who left the company two years ago.

And the worst part is that when AWS credentials get exposed, attackers are probing them in under 17 minutes (according to research). That's less time than it takes most of us to grab coffee and check Slack.

We've expanded GitGuardian NHI Governance with integrations across your entire infrastructure stack—giving you a single, identity-first view of every machine credential, automatic risk scoring based on OWASP's Top 10 for NHIs, and one-click revocation when secrets are exposed. Instead of logging into a dozen different platforms to piece together which service accounts exist and what they can access, you now get complete visibility and control from one place.

Why your IAM platform isn't cutting it for machine identities

Your IAM platform can be great at what it was designed to do. But it was designed in an era when "identity" meant Bob from accounting logging into Salesforce. It wasn't built for a world where your infrastructure runs on hundreds of service accounts, your data pipelines are orchestrated by API keys, and your AI agents are making autonomous decisions with privileged credentials.

The problem isn't that these identities don't matter; they do. The issue is that your organization lacks clear visibility into everywhere they are:

Scattered across different secrets managers (because different teams picked different tools)
Living in SaaS platforms your security team doesn't even know about
Provisioned with way too many permissions because "we'll lock it down later"
Never rotated because nobody's quite sure what will break if they do

And 70% of the secrets that leaked in 2022 are still active. Not because people don't care, but because they literally don't know those credentials exist.

What we're covering now (and why it matters)

We've expanded our integration coverage across your entire infrastructure. Here's what's available and why each piece matters.

The foundation: Secrets managers

First, we cover everywhere you're supposed to be storing secrets:

Enterprise vaults: HashiCorp Vault, CyberArk (both SaaS and self-hosted), Akeyless, Delinea Secret Server

Cloud-native: AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager

Our ggscout agent pulls metadata without ever touching the actual secret values. We hash everything locally before it leaves your environment, because the last thing you need is another tool that could leak your secrets.

Infrastructure & CI/CD: Where it all runs

Kubernetes: Service accounts and secrets across your clusters, because if you're running containerized workloads, these credentials are everywhere and notoriously hard to track.

GitLab CI: Pipeline credentials and job tokens that your CI/CD workflows depend on. These often have elevated permissions and rarely get rotated.

Cloud IAM: Because context is everything

Knowing a credential exists is step one. Understanding what damage it could do? That's the real question you need answered at 2 AM during an incident.

Microsoft Entra ID: We pull in users, service principals, managed identities, security groups—the whole picture. And we map out what permissions they actually have.

AWS IAM: Same deal. Users, roles, and groups, with full policy analysis.

Both of these use OIDC authentication. Why? Because we're not going to tell you to eliminate long-lived secrets while using them ourselves for integrations.

The platform automatically figures out which credentials are the highest risk, like that leaked API key that has admin access to your entire AWS environment. Those bubble to the top.

The stuff that keeps you up at night: SaaS platforms

This is where it gets interesting, because this is where traditional IAM tools just... stop. But it's also where a ton of your sensitive data actually lives.

AI platforms (Anthropic, OpenAI): With everyone rushing to build AI features, these API keys are multiplying like rabbits. We need to know where they are and who's using them.

Workflow automation (N8n, Airbyte): These tools are the "plumbing" of modern infrastructure. They have credentials that touch everything.

Observability (Datadog): Your monitoring tools have the keys to your entire infrastructure. If those get compromised, attackers know everything about your environment before they even start.

Collaboration (Slack): Bot tokens might seem low-risk until you realize they have access to every private channel where your engineers discuss security issues.

Data platforms (Snowflake): This one's obvious. If you're storing customer data there, you need to know exactly which service accounts can access it.

Identity providers (Okta, Auth0): Even your IdP has service accounts. They just happen to be the most privileged ones in your entire environment.

Artifact management (JFrog): Credentials that can push to or pull from your artifact repositories, critical for supply chain security.

Business intelligence (Metabase): Service accounts accessing your BI tools often have broad data access that needs governance.

What you can actually do with all this

Building a giant inventory is neat, but if it just sits there, who cares? Here's what's different:

One place to see everything: Instead of logging into five different secrets managers, three cloud consoles, and a dozen SaaS admin panels, you get one view. Identity-first. You pick the service account, you see everywhere it exists, everything it can access, and everyone who's using it.

Automatic risk scoring: We built this on OWASP's Top 10 for NHIs because that's the framework everyone's using. The platform automatically flags:

Leaked secrets (we're pretty good at finding those)
Secrets living in both production and dev
The same credential used in multiple places
Secrets that haven't been rotated in forever
Orphaned accounts that nobody owns anymore

The graph view that actually helps: When you find a compromised credential, the platform shows you the whole dependency chain. What services are using it? What data can they access? What will break if you revoke it? This is the stuff that used to take hours of Slack messages and emergency meetings.

Kill switch for leaked secrets: For GitHub, GitLab, and OpenAI secrets, when we detect exposure, you can revoke them with one click. Right from the alert. No copying tokens, no logging into different consoles, no delay while attackers are already poking around.

Metrics that matter: MTTR for secret remediation. Policy compliance trends. Secrets' age distribution. The stuff your manager actually wants to see when they ask, "How are we doing on this?"

This works in the real world

We built this to be enterprise-ready from day one:

ggscout never exposes your secret values
OIDC auth means no long-lived integration credentials
SOC 2 Type II compliant
Self-hosted option for the "nothing leaves our datacenter" crowd
Scales to thousands of integrations without turning into molasses

Why this matters right now

Regulators are starting to pay attention to machine identity governance. It's no longer enough to say "we manage our employees' access really well" while ignoring the 100x larger population of service accounts and API keys.

The identity perimeter changed. Most security programs just haven't caught up yet.

If you're a CISO, this gives you the visibility to actually answer when the board asks about your attack surface. With receipts.

If you're an IAM lead, this lets you extend the same lifecycle governance you've built for humans to the machine identities that actually run your business.

If you're a security architect building zero trust, this gives you the telemetry you need to validate that "never trust, always verify" actually means something.

Getting started

If you're already a GitGuardian NHI Governance customer:

Go to Settings > Integrations > Sources > NHI Governance
Connect whatever platforms you use
Start discovering what's been hiding in plain sight

Not using us yet? Talk to our team or check out our interactive demo.

Because at some point, we all need to admit that managing human identities while ignoring machine identities is like locking the front door while leaving every window open.

Let's close those windows.

GitGuardian provides secrets security and NHI governance for enterprises that are tired of machine identities being an afterthought. Learn more at gitguardian.com/nhi-governance.

Trivy's March Supply Chain Attack Shows Where Secret Exposure Hurts Most

Dwayne McDaniel — Mon, 08 Jun 2026 11:58:05 +0000

Update: On March 24, the campaign moved to PyPI. The Litellm packages in versions 1.82.7 and 1.82.8 have been poisoned with the same infostealer malware as the one used in the original campaign, and later on NPM.

A new exfiltration endpoint is used: https://models.litellm[.]cloud/
Other IoCs stay the same.

On March 24, the campaign targeted Checkmarx KICS scanner and poisoned it with an infostealer.

The Trivy story is moving quickly, and the latest reporting makes one thing clear: this is no longer just a GitHub Actions tag hijack. What started as a compromise of trivy-action, setup-trivy, and the v0.69.4 release has expanded into malicious Docker Hub images, a suspected service-account compromise spanning Aqua's internal GitHub organization. Researchers tied the new artifacts to the same TeamPCP infostealer seen earlier in the campaign, and Aqua has said the March 19 incident reused credentials retained from the previous breach because remediation was not fully atomic.

That matters because it sharpens the contrast with Shai Hulud. Both attacks targeted the CI/CD pipeline. Both went after secrets instead of the application itself. Both used GitHub as a practical exfiltration surface because GitHub traffic looks routine in engineering environments. But Trivy looks like a fast-moving credential theft campaign that keeps finding new ways to capitalize on. Shai Hulud was a broader supply chain operation designed to persist, propagate, and cause downstream damage.

Attack Timeline

The attack path and timeline

Late February 2026 — Initial CI Compromise

An automated bot ("hackerbot-claw") exploited a misconfigured workflow, stealing a privileged Personal Access Token (PAT) from the CI environment. Using that credential, the attacker pushed a malicious artifact to the Trivy VS Code extension on Open VSX.

March 1, 2026 — First Disclosure & Partial Remediation

Aqua Security publicly disclosed the incident via a GitHub discussion and rotated credentials. However, subsequent investigation revealed the rotation was incomplete, leaving residual access paths still open to the attacker.

March 19, 2026 — Supply-Chain Weaponization

Using still-valid credentials and a compromised aqua-bot service account, the attacker published a malicious Trivy binary release (v0.69.4) and force-pushed malicious commits to 75–76 of 77 tags in aquasecurity/trivy-action and all 7 tags in aquasecurity/setup-trivy, silently turning pinned tags into payload delivery channels. The injected payload contained two Python infostealers. One was specially crafted to run on a CI/CD runner and exfiltrated sensitive elements from the runner process memory and environment. The second stealer, more generic, exfiltrated SSH keys, cloud tokens, and other secrets, mostly collected from the local file system. Both payloads sent the information to an attacker-controlled domain or to public GitHub repositories as a backup channel.

March 20–22, 2026 — Public Post-Mortems & Guidance

Aqua Security released detailed post-incident blogs with a formal attack timeline, indicators of compromise (IoCs), a list of compromised tags, and guidance for rotating CI/CD and cloud credentials.

Trivy was surgical. Shai Hulud was systemic.

The original Trivy compromise was already serious. The attacker force-pushed 75 version tags into aquasecurity/trivy-action, turning trusted version references into a malware-delivery path for any workflow pinned to a tag rather than a commit SHA. The payload harvested environment variables and secrets from runner memory, searched self-hosted systems for cloud and infrastructure credentials, encrypted the results, and exfiltrated them to attacker-controlled infrastructure or as a release file to public GitHub repositories created in the victim's own account under the name tpcp-docs. Because the legitimate Trivy scan still ran afterward, many users would have seen normal output and missed the theft entirely.

Shai Hulud 2.0 operated on a different level. It backdoored npm packages, used TruffleHog offensively to harvest local secrets, leveraged self-hosted GitHub runners as command-and-control infrastructure, propagated into downstream packages, and carried a destructive wiper. That is a bigger playbook and a wider blast radius. Trivy moved fast through trusted automation and harvested what it could reach. Shai Hulud was built to spread.

The fresh reporting on Trivy makes that distinction even more useful. The campaign now appears to have expanded from GitHub Actions into Docker images and follow-on malware, including a worm that spreads through SSH keys and exposed Docker APIs, plus a Kubernetes wiper in specific environments. That does not make Trivy the same as Shai Hulud. It makes Trivy a good example of how a credential theft operation can evolve when remediation leaves one valid path behind.

The real lesson is remediation, not just detection

The biggest takeaway here is not that secrets were stolen. That part is already obvious. The bigger lesson is that incomplete cleanup turns one breach into a campaign. Aqua's own account of the incident points to compromised credentials retained from the earlier breach and a rotation process that did not fully sever access. In practice, that gap is the line between containment and recurrence.

That is where strong secrets security stands out. Teams need to detect exposed credentials quickly, but detection is only the start. They also need to know which machine identities were reachable from that workflow, which of those secrets are still active, what each credential unlocks, and which ones must be rotated first to cut off attacker movement. Public monitoring matters here because both Trivy and Shai Hulud used public GitHub repositories as part of the exfiltration path. Early alerting matters because once an attacker starts harvesting secrets inside CI, every minute counts. Governance matters because non-human identities, especially long-lived service accounts and PATs, create the bridges attackers use to move from one repo, org, or registry to the next.

That is the sharper value proposition in this story. The teams that recover fastest are not the ones that merely discover a leak. They are the ones that can trace blast radius, prioritize rotation, verify remediation, and prove that the same credential cannot be reused tomorrow.

Why this matters now

Trivy and Shai Hulud belong in the same conversation because they both show where modern supply chain attacks pay off. They do not need to own your application. They need to reach the systems that build, sign, scan, and deploy it. Once they get there, secrets do the rest.

But they should not be described as the same kind of event. Shai Hulud was a sprawling, self-propagating supply chain operation. Trivy was initially a more surgical compromise of trusted automation, and the last 48 hours of reporting show what happens when that kind of operation meets incomplete remediation and a reusable service account. The result is not just one bad release. It is a long tail of exposure across GitHub Actions, Docker images, internal orgs, and cloud infrastructure.

That is the story prospects should remember. The hard problem is no longer finding a secret after it leaks. The hard problem is stopping that secret from becoming the attacker's next foothold.

Top 10 Non-Human Identity Security Tools and Platforms for 2026

Dwayne McDaniel — Fri, 05 Jun 2026 12:52:23 +0000

TL;DR: Non-human identities (service accounts, API keys, workload identities, certificates, OAuth apps, machine-to-machine access) now outnumber humans over 1:1 in most cloud-native orgs.
The biggest security risks are unmanaged lifecycle, overprivileged access, and exposed credentials across SDLC and cloud environments, not just secret storage.

The best NHI security tools in 2026 fall into four major categories:

Secrets Detection and Exposure Prevention
NHI Lifecycle and Governance Platforms
Machine Identity and Certificate Management
Vault and Authorization Extensions

Most enterprises require layered coverage across detection, governance, and lifecycle automation. Adopting this multi-layered strategy enables organizations not only to find leaks but also to close the structural gaps that allow them to occur.

Why Non-Human Identities Are the Fastest-Growing Attack Surface in 2026

In 2026, attackers rarely try to "hack passwords". Instead, they exploit the massive, often unmonitored web of non-human identities (NHIs) that power modern automation.

They specifically look for hardcoded API keys, overprivileged service accounts, stale OAuth tokens, misconfigured workload identities, unrotated certificates, and shadow SaaS integrations that slip through the cracks of traditional security programs.

This is a problem because machine identities far outnumber human users. However, most security programs rely on frameworks designed for human-centric access.

IAM Strategy for CISOs: Securing Non-Human Identities

Thankfully, top non-human identity protection tools help secure this critical attack surface. By understanding the categories of enterprise NHI security solutions, you can build a strategy that provides complete visibility and robust security controls across your entire infrastructure.

What Do Non-Human Identities (NHIs) Include Today?

Non-human identities are the digital identities used by machines, services, and applications to authenticate and communicate with other systems without human intervention. They include:

Service Accounts: Specialized accounts used by operating systems and/or applications to run background processes and access local or network resources.
API Keys and Tokens: Credentials that allow software to communicate with external services and internal systems, acting as a kind of "passport" for data exchange.
SSH Keys: Access credentials for the Secure Shell (SSH) protocol. They're commonly used to authenticate automated processes and privileged users to remote systems.
Certificates: Digital documents that verify the identity of a machine, service, website, or individual user. They use public key infrastructure (PKI) to exchange sensitive data.
OAuth Apps: An authorization framework that allows apps to obtain delegated access to resources on behalf of a user or service, without exposing the underlying credentials.
Workload Identities: A set of credentials assigned to specific cloud resources, like a Kubernetes cluster or cloud IAM roles, to define access limits within an environment.
Machine-to-Machine Access Credentials: Any credential used by one automated system to authenticate with another. Examples include service tokens, client secrets, and shared keys embedded within automated processes.

Why This Problem Is Urgent Now

Given the complexity of modern environments, a single security gap can lead to data breaches. As such, managing non-human identities is a primary concern for security teams.

Multi-Cloud Sprawl: Organizations now distribute workloads across AWS, Azure, GCP, and more, creating fragmented identity silos that are difficult to monitor.
Kubernetes and Ephemeral Workloads: The rise of containers means identities are often created and destroyed in seconds, making manual tracking impossible.
SaaS-to-SaaS Integrations: Modern businesses rely on a web of interconnected tools, each requiring its own set of OAuth tokens and permissions.
CI/CD Automation: Rapid deployment cycles require high-speed access to sensitive credentials. Oftentimes, these keys are hardcoded or poorly managed in the software development cycle, and devastating security breaches become a reality.
AI Agents and Autonomous Services: Supposedly secure AI agents build their own identities to perform tasks, which further expands the non-human attack surface.

Credential-based attacks are one of the most common initial access vectors for cyber threats. Because of this, the non-human identity lifecycle is a top priority for risk reduction.

Key Capabilities of Modern NHI Security Platforms

Modern NHI security platforms provide a comprehensive layer of protection across the entire identity management landscape. The best ones include five key capabilities:

1. Discovery and Inventory

You can't secure what you can't see. Leading non-human identity security solutions provide complete visibility by cataloging every machine identity in use. This includes the detection of shadow service accounts that developers create outside of official channels. It also includes coverage across SaaS and cloud environments, and cross-environment mapping that connects identities to resources.

2. Exposure Detection

This capability finds sensitive credentials where they shouldn't be. Platforms scan git history and monitor public repositories to ensure secrets haven't leaked. They also provide continuous monitoring during the development process by integrating with developer workflows and CI/CD pipelines. Doing so enforces security policies before code reaches production.

3. Lifecycle Management

To properly manage the non-human identity lifecycle, streamline the "birth, life, and death" of credentials. This includes automating secret rotation and certificate renewals to ensure that no identity remains active longer than necessary. The platform should also provide workflows for revoking credentials and monitor for upcoming expirations to prevent service outages.

4. Authorization and Least Privilege

Many NHIs receive excessive privileges. Top security platforms use access relationship mapping and identity graphs to visualize what each identity can access. By detecting overprivileged accounts, they help teams enforce least-privilege policies and reduce the potential impact of a compromised account. As such, this capability is essential.

Why the Principle of Least Privilege Is Critical for Non-Human Identities

5. Governance and Compliance

To meet regulatory compliance standards such as SOC 2 and ISO 27001, organizations need detailed audit trails and reporting. Non-human identity management tools provide risk scoring for different identities, helping teams prioritize those that need attention. In addition, reporting dashboards offer a high-level view of the organization's security posture. This makes it easier to demonstrate control to auditors, ensure compliance, and avoid expensive fines.

Now that we've covered key capabilities, let's analyze top NHI security platforms in 2026—starting with the leader in secrets detection and NHI exposure prevention.

Top NHI Security Tools and Platforms for 2026

The market for machine identity security tools has matured. The solutions below represent the best options across detection, governance, lifecycle management, and authorization.

Here's what each does well, where they fall short, and who each platform is best suited for:

1) GitGuardian

Category: Enterprise Secrets, Security, and NHI Exposure Intelligence

GitGuardian is an enterprise-grade secrets-detection and non-human identity protection tool. It was built to prevent credential-based security breaches at scale and delivers an unmatched breadth of exposure detection across public and internal repositories, collaboration tools, and CI/CD systems. As such, it provides deep secrets intelligence and governance for large DevSecOps organizations in a wide range of industries.

Key Features:

Exposure Detection Excellence: Scans full git history for all internal and public repositories in real time, continuously monitors public GitHub for external exposure, and covers multiple source types, including multiple VCS, CI/CD pipelines, and collaboration tools.
Secrets Intelligence: Delivers analytics on secret hygiene and distribution across the organization, including secret validity analysis, exposure window tracking, identification of unused and stale secrets, and risk-based prioritization with breach policy enforcement.
Vault Integration Mastery: Integrates with major platforms like HashiCorp Vault and CyberArk, and acts as a "single source of truth" across vault and non-vault environments. That way, developers can migrate hardcoded secrets into secure storage systems. It also rates alignment between detection workflows and vault lifecycle controls.
Proven Detection Accuracy: Uses ML-enhanced detection combined with entropy analysis and contextual validation to deliver a high signal-to-noise ratio with reduced false positives. In addition, continuous detector updates cover cloud providers, SaaS platforms, internal tokens, and custom patterns to stay current with new credential types.
Agentic AI Security: Protects your organization across the entire AI value chain, from AI-powered CLI tools to autonomous agents running in production. As such, GitGuardian minimizes vibe coding risks, LLM exposure, AI agent sprawl, and risky developer endpoints.

Pros of GitGuardian:

Unmatched breadth of detection across public and internal sources.
Advanced secrets intelligence for effective risk prioritization.
Strong integration with existing vault ecosystems.
High detection accuracy with low false positives.
Enterprise-ready governance and reporting.

Cons of GitGuardian:

GitGuardian specializes in exposure detection and prevention, not full privileged access management. So, your desired use case will determine product fit.

Pricing: The "Starter" tier is free, while the "Teams" and "Custom" tiers offer individual pricing.

Enterprise Fit: Well-designed for mid-market and enterprise organizations in multi-cloud, Kubernetes-heavy, and CI/CD-driven environments that require scalable exposure detection, secrets intelligence analytics, and vault-aligned remediation workflows to reduce breach risk.

Website: https://www.gitguardian.com

2) Astrix Security

Category: SaaS and OAuth NHI Governance

Astrix focuses on discovering and securing non-human identities across SaaS environments. It is particularly strong at managing OAuth apps and third-party integrations that bypass traditional identity providers. These capabilities make it a strong option for NHI governance.

Key Features:

SaaS Identity Discovery: Automatically maps connections between SaaS tools.
OAuth App Inventory: Provides a detailed risk analysis of every third-party app connected to the corporate environment, improving security.
Shadow SaaS Detection: Identifies integrations added without approval from the IT or security team, so they can be eliminated for security reasons.
Token Exposure Visibility: Tracks where OAuth tokens might be exposed or misused.

Pros of Astrix:

Focused NIH-first approach.
Deep visibility into SaaS-to-SaaS communication.
Strong governance controls, specifically for OAuth.

Cons of Astrix:

While Astrix includes secret scanning capabilities, the platform's architecture prioritizes SaaS governance and third-party risk over developer-native SDLC prevention. Detection depth and developer workflow integration may not match specialized secrets platforms.

Pricing: Enterprise-tier pricing for commercial SaaS companies.

Enterprise Fit: Strong for organizations with complex SaaS ecosystems and OAuth sprawl.

Website: https://astrix.security/

3) Clutch Security

Category: NHI Governance Platform

Clutch is built on two philosophical principles: zero trust enforcement and ephemeral, short-lived credentials. It uses these philosophies to provide centralized visibility and governance over non-human identities across cloud and SaaS environments.

Key Features:

Machine Identity Discovery: Builds a complete inventory of machine-related identities.
Risk Prioritization: Ranks identities based on their potential risk to critical resources.
Policy Enforcement: Allows security teams to set and enforce global policies for NHIs.
Lifecycle Visibility: Tracks the status of identities throughout their entire existence.

Pros of Clutch:

Strong focus on governance and an identity-first architecture.
Good fit for large enterprises with complex compliance needs.

Cons of Clutch:

Clutch Security offers less developer-workflow-native detection compared to secret scanning specialists. This is a turn-off to some enterprise organizations.

Pricing: Enterprise SaaS pricing.

Enterprise Fit: Suitable for enterprise teams that need NHI governance and policy enforcement.

Website: https://www.clutch.security/

4) Oasis Security

Category: Non-Human Identities Security Platform

Oasis Security delivers discovery, inventory, and risk management for non-human identities across various cloud and SaaS ecosystems. Its main goal is to help teams understand the "who, what, and where" of machine access so they can act accordingly.

Key Features:

NHI Mapping: Visualizes relationships between identities and cloud resources.
Credential Risk Analysis: Evaluates the strength and security of existing credentials.
Exposure Tracking: Monitors systems for signs of compromised or leaked credentials.
Governance Reporting: Generates reports to assist with regulatory compliance.

Pros of Oasis Security:

Focused NHI security approach.
Strong multi-environment discovery.

Cons of Oasis Security:

Oasis Security's exposure detection features may not be as deep or specialized as dedicated secret-scanning vendors. So, potential customers might prefer other options.

Pricing: Enterprise-tier pricing for commercial SaaS.

Enterprise Fit: Solid for a dedicated NHI security platform with multi-cloud discovery needs.

Website: https://www.oasis.security/

5) Entro Security

Category: Machine Identity Management Solutions

Entro provides machine identity discovery and lifecycle management to reduce secret sprawl and unmanaged credentials. The platform provides visibility into where secrets exist, what lifecycle stage they're in, and how to maintain a clean identity posture across environments.

Key Features:

Secret Sprawl Discovery: Finds unmanaged secrets scattered across the environment.
NHI Inventory: Keeps a running list of every machine identity.
Lifecycle Governance: Manages credential rotation and expiration.
Risk Posture Monitoring: Continuously assesses the security status of all NHIs.

Pros of Entro:

Strong lifecycle visibility allows users to maintain excellent identity hygiene.

Cons of Entro:

Entro wasn't specifically designed for SDLC-based exposure detection. It's also less focused on developer-native prevention, which could lead to unexpected breaches.

Pricing: Enterprise SaaS pricing.

Enterprise Fit: An ideal solution for lifecycle governance and machine identity management.

Website: https://entro.security/

6) Veza

Category: Authorization and Identity Governance

Veza delivers authorization graph intelligence to map and manage identity relationships across systems. For non-human identities, this means visibility into service account permissions, overprivileged workload identities, and access relationships that span multiple cloud and enterprise systems. In a nutshell, Veza answers the question, "Who has access to what data?"

Key Features:

Access Relationship Mapping: Uses identity graphs to visualize complex permissions.
Overprivilege Detection: Highlights accounts with more access than they actually use.
Policy Governance: Helps teams create and enforce consistent access policies.

Pros of Veza:

Deep authorization intelligence and powerful visualization.
Strong enterprise governance capabilities.

Cons of Veza:

While Veza solves the "access governance" problem, it doesn't find leaked keys. As such, Veza isn't a secret detection platform, so some users might prefer a different app.

Pricing: Enterprise commercial pricing.

Enterprise Fit: Best for enterprises that need to manage access management complexity and enforce least privilege across human and non-human identities.

Website: https://veza.com/

7) Apono

Category: Cloud Access Governance

Apono concentrates on just-in-time (JIT) access and privilege management. It helps minimize the risk of "standing privileges" across environments, including service accounts and workloads.

Key Features:

JIT Access Provisioning: Grants limited-time access when it's needed, not before.
Cloud IAM Governance: Manages roles and permissions within AWS, Azure, and GCP.
Temporary Credential Automation: Automates the creation of short-lived access keys.
Access Workflows: Provides a structured way to request and approve machine access.

Pros of Apono:

Reduces the attack surface by enforcing least-privilege principles via JIT access.

Cons of Apono:

Apono is not a tool for scanning code or detecting leaked secrets. For access to these features, you'll need another app, which will increase your tech budget.

Pricing: Enterprise SaaS pricing.

Enterprise Fit: A strong addition for enterprise teams that want to reduce standing access and implement time-bound credential models in a reliable way.

Website: https://www.apono.io/

8) Aembit

Category: Workload Identity Security Tools

Aembit provides identity federation and access control for secure communication between machines and workloads. It helps eliminate long-lived static credentials by replacing them with short-lived, workload-attested tokens, thus reducing the risk of credential theft and misuse.

Key Features:

Workload Identity Federation: Allows workloads to trust other identities securely.
Access Policy Enforcement: Defines which services can talk to one another.
Secure Service-to-Service Authentication: Ensures that machine-to-machine communication is verified and prevents unauthorized data leaks.

Pros of Aembit:

A strong workload identity security model that aligns with cloud-native architectures.

Cons of Aembit:

Aembit doesn't scan code repositories for existing leaked credentials. If you've already experienced a data breach, Aembit won't help you recover.

Pricing: Enterprise-tier pricing for commercial SaaS.

Enterprise Fit: Well-suited for cloud-native and Kubernetes-heavy organizations that plan to modernize their organization's workload identity security tools.

Website: https://aembit.io/

9) AppViewX

Category: Certificate Lifecycle and PKI Automation

AppViewX specializes in certificate lifecycle management and PKI automation for enterprises, especially those managing large and complex machine identity environments. With digital certificates underpinning most machine-to-machine communication, expiry monitoring and automated renewal workflows are critical to security and uptime.

Key Features:

Certificate Discovery: Inventories certificates across networks to prevent outages.
PKI Orchestration: Automates the deployment and management of certificates.
Expiry Monitoring: Alerts teams before certificates expire to ensure security.
Compliance Reporting: Tracks certificate usage for audit purposes.

Pros of AppViewX:

Best-in-class certificate automation and enterprise PKI support.

Cons of AppViewX:

AppViewX does a fantastic job on certificates, but it doesn't do much else. For a tool that can handle the full breadth of NHI types, like API keys or OAuth apps, look elsewhere.

Pricing: Enterprise commercial pricing.

Enterprise Fit: A solid option for complex certificate environments and PKI compliance needs.

Website: https://www.appviewx.com/

Implementation Strategy for Enterprise NHI Security

Deploying non-human identity security tools requires a phased approach to minimize critical risks and build long-term operational efficiency. Here's the three-step process we recommend:

Phase 1: Exposure Risk Elimination (Immediate Risk Reduction)

Many breaches begin with an exposed credential, according to Verizon's 2025 DBIR. With that in mind, your first goal is to reduce the likelihood of these breaches within the first 90 days. Focus on identifying and removing already-exposed sensitive credentials.

Priority Actions: Implement continuous scanning of source code repositories (including full git history), real-time monitoring of CI/CD, public repository exposure detection, centralized triage and remediation workflows, and established MTTR targets for leaked secrets.
Executive Outcome: A reduced external attack surface, faster remediation cycles, and immediate measurable breach-risk reduction to deliver peak ROI in the short-term.

Phase 2: Comprehensive NHI Inventory and Governance

Once you put the "fires" out, you can shift your approach and eliminate blind spots.

Priority Actions: Catalog all NHIs, from service accounts and API keys to certificates and OAuth apps; map identity-to-resource access relationships; establish identity ownership models across AppSec, IAM, and Platform teams; and define enterprise-wide NHI policies, like least privilege, rotation frequency, and approval workflows.
Executive Outcome: Reduced systemic identity risk, clear accountability for machine identities, and a stronger audit posture for SOC 2, ISO 27001, and PCI DSS standards. That way, NHI risk becomes a governed security domain, not an operational issue.

Phase 3: Lifecycle Automation and Preventive Controls

Finally, you can build a mature environment that prioritizes preventative identity security. Even better, you can automate these processes to ensure security at all times.

Priority Actions: Implement automated secret rotation and expiration enforcement, just-in-time (JIT) access provisioning for machine identities, certificate lifecycle automation and renewal, vault-backed secret storage standardization, and continuous policy validation across multi-cloud and SaaS environments.
Executive outcome: The elimination of standing credential risk, a reduced manual workload for security teams, sustainable compliance and audit readiness, and improved resilience against lateral movement attacks. Put simply, this phase embeds NHI security into your cloud operating model rather than treating it as a scanning function.

The Future of NHI Security in 2026 and Beyond

The NHI security space is evolving quickly, with several trends emerging.

First, AI agents autonomously create identities, which poses challenges for security teams. As AI-driven services proliferate, the ability to secure AI agents and their associated identities becomes a baseline requirement rather than an advanced capability.

We are also seeing a move toward continuous identity graph monitoring, in which every relationship is mapped in real time. Organizations need immediate visibility into identity relationships and access paths, not periodic access reviews, which are all too common.

Last but not least, the lines between tool categories are blurring, as secrets detection becomes integrated with governance and reactive scanning shifts to preventative lifecycle automation. After all, it's better to prevent credential exposure than respond to a breach.

To stay ahead of cyber threats, we suggest layering a best-of-breed NHI security tool with your existing pipeline stack. GitGuardian is a strong option for enterprises, offering top-level governance and remediation features on a single platform. Book a free demo of GitGuardian today.

FAQs About Non-Human Identity Management Tools

What's the difference between NHI exposure detection and NHI governance?

NHI exposure detection focuses on identifying leaked or hardcoded credentials across repositories, CI/CD pipelines, collaboration tools, and public sources. NHI governance goes further by managing the lifecycle of machine identities through access controls, rotation policies, and least-privilege enforcement. Mature security programs require both layers to reduce machine identity risk and prevent credential misuse.

How do we determine whether we need a secrets security platform or an NHI platform?

If your primary concern is preventing exposed API keys, tokens, or credentials in code and pipelines, a secrets-security platform is the right starting point. If your organization faces challenges with overprivileged service accounts, unmanaged OAuth integrations, or large-scale machine identity sprawl across cloud and SaaS systems, broader NHI governance capabilities are necessary to manage the full machine identity lifecycle.

How does NHI security integrate with existing IAM, PAM, and vault solutions?

Modern NHI security platforms integrate with IAM providers such as AWS IAM, Azure AD, and Google Cloud IAM, as well as PAM and vault solutions like HashiCorp Vault and CyberArk. Detection systems identify exposed or unmanaged credentials, while vault platforms securely store and rotate them. Together, these integrations ensure secrets are detected, migrated, and governed within secure lifecycle-controlled systems.

How do NHI security tools scale across multi-cloud and Kubernetes environments?

Enterprise-grade NHI platforms rely on API-based integrations to continuously discover and inventory machine identities across cloud environments and Kubernetes clusters. Centralized visibility, automated discovery, and policy enforcement allow organizations to manage hundreds of repositories and thousands of workloads without manual oversight.

What ROI can enterprises expect from investing in NHI security?

The primary return on investment comes from preventing credential-based breaches, one of the most common attack paths in modern environments. Additional benefits include reduced incident response costs, stronger compliance posture, improved prioritization of remediation activities, and lower operational overhead through automation.

Are open-source secret scanning tools sufficient for enterprise environments?

Open-source scanners can provide baseline detection within developer workflows. However, they often lack centralized governance, public monitoring, advanced prioritization, remediation orchestration, and compliance reporting. Many enterprises combine OSS tools for local scanning with enterprise platforms that provide organization-wide visibility and policy enforcement.

What does a mature NHI security program look like in 2026?

Mature programs combine continuous secret exposure detection, centralized NHI inventory, lifecycle automation with credential rotation and expiration, least-privilege access controls, certificate management, and compliance-ready reporting. Leading organizations layer detection, governance, and vault-backed storage to achieve end-to-end machine identity protection.

Key Leaks, Vault Failures, and TEE Attacks: Highlights from RWC 2026

Dwayne McDaniel — Thu, 04 Jun 2026 14:17:15 +0000

In early March, the GitGuardian cybersecurity research team joined several hundred cryptographers, security engineers, and practitioners in Taipei for the tenth edition of the Real World Cryptography Symposium (RWC 2026). Held from March 9 to 11, the conference lived up to its name: three dense days of talks grounded in the reality of production-deployed crypto-systems.

Beyond oolong drinking and the night markets, Taipei had more serious business to offer: GitGuardian was there to present our own research. We took the stage on Day 3 to share the findings behind "Private Key Leaks in the Wild", mapping 945,560 leaked private keys to 139,767 certificates through Certificate Transparency logs, evidence that key material escaping into the wild is not a niche incident but a systemic problem.

Extract from GitGuardian's presentation: four to five thousand certificates are compromised every year because of a leaked private key.

Across the three days, recurring themes emerged: the industry-wide migration toward post-quantum algorithms and its hard engineering trade-offs; formal verification maturing into a practical tool; privacy-enhancing technologies finding their way into production systems; and secure channels and PKI infrastructure proving more fragile than assumed. All talks are worth a read or a replay, and the recordings are already available online.

This article, however, focuses on what resonated most with GitGuardian.

When secret managers fail: a cryptography nightmare

Matteo Scarlata and Giovanni Torrisi represented their team of four researchers in this presentation about password managers' security. Their talk was titled Zero Knowledge (About) Encryption, a pointed jab at the "zero-knowledge" marketing promise that cloud-based password managers like Bitwarden, LastPass, and Dashlane use to sell themselves: the claim that the provider never sees your plaintext secrets. This is usually the definition of what is called end-to-end encryption (E2E).

This research focused on studying the security of four cloud-based password managers under the E2E encryption hypothesis, especially in a malicious server attack model. Matteo Scarlata et al demonstrated serious attacks against all four password managers. 27 attacks in total. Most issues stem from a weak cryptography protocol, especially related to "advanced" features:

Key recovery
Partial vault synchronization
Secret sharing
Backward compatibility

Notable attacks included:

BitWarden's server being able to enforce the key recovery for any client, recovering a master decryption key.
Servers acting as a public key server for password sharing, where they can provide malicious keys to recover shared passwords.
Password leak through favicon resolution resulting from field-level encryption and no key separation (LastPass, Bitwarden).

The full paper backing this research is available online and is a must-read.

Password-based authentication has been an open problem for decades now, and this research shows that this is still the case, despite the existing vaults and other storage solutions. The whole industry has been pushing toward vaults and password managers to manage authentication secrets, which makes sense considering the state of authentication. That said, this research reminds us that the threat model of a compromised vault is important to consider.

Under the assumption of a compromised secret vault, having a good understanding of one's own secret landscape is paramount, a situation where NHI governance and secrets observability can help.

Should you trust your trusted execution environment?

Somehow on the same line, Christina Garman and Daniel Genkin presented their talk "TEE.fail: Breaking Trusted Execution Environments via Memory Bus Interposition", where they also found and exploited vulnerabilities in a technology everyone would deem the state-of-the-art of security: trusted execution environments. They targeted both AMD and Intel's latest TEE technologies, which shifted significantly in how they are implemented. Especially, both now rely on AES-XTS for memory encryption, which offers no integrity protection.

Through a brilliant live demonstration, Christina and her team showed how, using hobbyist-level hardware, it is possible to set up an interposition attack on a server's physical memory. They later used this setup to recover private keys from the TEE in an otherwise simple attack.

Although the threat model for this attack is quite convoluted, making it difficult to perform outside a state-sponsored operation, and, more specifically, an adversarial law enforcement situation, this talk puts some perspective on best-of-breed security mechanisms. As showcased with the password safes example above, even the best-protected secrets can leak, and we should keep that in mind when designing our risk analysis.

The tools are not enough

In one rather interesting talk, Yubiko's Christopher Harrell explored a fundamentally interesting question: how did we get from a mostly-unencrypted internet to 95% of Chrome page loads being HTTPS? His main point is that it did not occur in a blast after a single breakthrough: the cryptography to make it happen has been as old as the internet itself. However, real adoption stemmed from a mix of policies, standards evolution, or accessible infrastructure (Let's Encrypt in that case).

Harrell then traced the same pattern through human identities and authentication, with the example of passkeys and FIDO. Human authentication has gone through three recognizable phases:

Shared secrets (passwords)
Second factors (mostly TOTP and SMS OTP)
Device-bound phishing-resistant credentials (Passkeys, FIDO)

Similar to the encryption on the Internet, while the technology required for secure human authentication exists, the adoption is not there yet.

What resonated particularly with GitGuardian's activities is how we can parallel human authentication evolutions to the Non-Human Identities world. Non-human identities (the API keys, service account passwords, and OAuth tokens that machine-to-machine communication relies on) are still largely stuck in phase one. Long-lived API keys are, functionally, passwords: static, shareable, leak-prone, and with no equivalent of origin binding. OAuth tokens represent an improvement analogous to MFA, but they remain stealable and, in many configurations, reusable beyond their intended context.

The FIDO moment for non-human identities has not arrived yet, and the scale of the problem is already visible in the data. As showcased in the State of Secret Sprawl report, the number of leaked secrets, largely linked to NHIs, has never been higher. While the technology evolves, hopefully, before we get locked in the insecure defaults, you'd better be equipped with a good secret security solution.

Until next time

There is so much more that could be told about the content that was presented at RWC 2026, and so many more presentations are worth watching – just like Nadia Heninger's talk about the encryption technologies used in space and technical debt, a topic that could very much find parallels in the NHIs world. If you want to know more, the slides of all the presentations are available on the conference website. Video recordings should also be made available soon.

We can only hope GitGuardian's research team will be able to attend Real World Crypto again in the future. Presenting at such a conference is an honor, and we need to thank the organizers and chairmen for allowing us to promote our work there this year.

Until next time, if you want to have a peek at GitGuardian research topics and results, now is the perfect time to have a look at our fresh release of the State of Secret Sprawl report.