TL;DR: GitGuardian's October 20, 2026 demo says recent supply chain attacks keep targeting credentials across developer laptops, CI/CD runners, vaults, SaaS applications, and identity providers, and frames the problem as visibility, prevention, and remediation at scale. Secrets discovery is only useful when ownership, over-permissioning, and plaintext exposure are governed as one lifecycle problem, not separate hygiene tasks.
At a glance
What this is: GitGuardian's demo argues that credential exposure remains a supply chain problem across endpoints, CI/CD runners, vaults, SaaS applications, and identity providers.
Why it matters: This matters because IAM, PAM, and NHI programmes fail when secrets live beyond clear ownership, reach, and revocation paths.
👉 Watch GitGuardian's demo on reducing credential exposure across developer endpoints and NHI estates
Context
GitGuardian's 20-minute live demo for October 20, 2026 is built around a simple governance gap: credentials are still being exposed in places that ordinary review cycles do not cover well enough. The article frames the issue around developer laptops, CI/CD runners, plaintext storage, and identity sprawl across tools that share no single owner.
For IAM and NHI teams, the key issue is not just leakage but lifecycle ambiguity. When a secret, token, or service credential appears in code, on an endpoint, or inside a SaaS integration, the real question becomes who owns revocation, who can see the blast radius, and which control closes the loop fastest.
Key questions
Q: What breaks when leaked secrets are spread across endpoints and CI/CD runners?
A: What breaks is the assumption that a secret remains visible and governable in one place. Once credentials appear on laptops or runners, they can be copied, cached, or reused outside the system that issued them. Security teams lose a single control point and must instead govern discovery, ownership, and revocation across multiple environments.
Q: What problem does ownership attribution solve for service accounts and API keys?
A: It closes the gap between exposure detection and accountable remediation. Many organisations can find the secret, but not the human who introduced it, maintains it, or can safely replace it. Ownership attribution gives security teams a practical way to assign action without relying on informal knowledge that disappears during staff changes.
Q: What are the signs that secret visibility is failing?
A: Common signs include secrets found in code, build logs, endpoint storage, or SaaS integrations without a clear owner, plus repeated incidents where teams can detect exposure but cannot rapidly revoke the credential. If the organisation can find a leak but cannot map it to an accountable identity and scope, visibility is failing.
Q: Should organisations prioritise secrets rotation before access cleanup?
A: No. Secrets rotation helps, but access cleanup usually delivers faster risk reduction because it removes unnecessary paths in the first place. Teams should first identify where credentials are over-scoped, then rotate or retire the remaining secrets according to business criticality and exposure level.
Background and context
Why leaked credentials keep escaping standard governance
Secrets become a governance issue when they move outside the system that issued them. A token in code, a key on a laptop, or a credential inside a CI/CD runner can be copied, cached, or reused without the original owner seeing the event. That breaks ordinary access review because the artifact is no longer just an assignment problem. It is now a discovery, ownership, and revocation problem across multiple runtime surfaces. In NHI terms, the control boundary is not the vault alone; it includes every place a credential can be rendered, logged, synced, or inherited.
Practical implication: map every place secrets can appear, not just where they are stored, and tie each surface to a revocation owner.
Identity visibility across vaults, SaaS, and developer endpoints
Visibility in this context means being able to identify which credential belongs to which workload, user, or integration, and whether it is still justified. That requires correlating secrets inventory with identity ownership, permission scope, and deployment context. Without that correlation, teams can find exposed secrets but still fail to determine whether a service account, API key, or third-party integration is over-permissioned. This is where NHI governance overlaps with IAM: the same entitlement can exist in a vault, a SaaS app, and a CI/CD system, but the accountability chain must still be singular.
Practical implication: build a joined inventory of secrets, identities, and permissions so exposed credentials can be assessed in context.
Remediation at scale depends on ownership and blast-radius reduction
The operational challenge is not detection alone. It is whether remediation can happen before a leaked credential is reused, propagated, or embedded into downstream automation. At scale, teams need to know which secret can be rotated automatically, which integration will break, and which service account has excessive reach if compromise occurs. The relevant control question is therefore blast radius, not just alert volume. If ownership is unclear, remediation stalls, and a single leak can become a broader identity exposure event across cloud and development tooling.
Practical implication: predefine rotation authority, rollback dependencies, and containment steps for the credential types most likely to leak.
NHI Mgmt Group analysis
Credential exposure is now an identity governance problem, not just a secrets hygiene problem. The article's own framing points to credentials on laptops, runners, vaults, SaaS applications, and identity providers, which means the control issue spans multiple owners and runtime environments. That shifts the discipline from containment of a single leak to governance of where non-human access is allowed to exist in the first place. Practitioners should treat every exposed secret as evidence of a broken ownership chain.
Ownership gaps are the named failure mode this article exposes. If a leaked secret can sit in plaintext or move through CI/CD without a clearly assigned owner, then revocation and review are already too late. This is the classic NHI governance flaw: access exists somewhere, but no one can prove who is responsible for its lifecycle. The implication is that NHI inventory and entitlement accountability must be tied together, not managed as separate programmes.
Developer endpoints have become a primary identity exposure surface. GitGuardian's framing makes clear that compromise does not have to start with a vault breach to become an NHI incident. When secrets live on laptops or in build runners, the enterprise has effectively created shadow access paths outside the normal identity lifecycle. Practitioners should classify endpoint-held secrets as governed NHI assets, not incidental artifacts.
Blast radius is the right unit of measure for leaked secrets. A leaked credential matters less as an isolated event than as an access multiplier across SaaS, cloud, and automation layers. The governance question is how far the secret can reach before a human notices, not whether it was stored in a protected system. Teams that cannot answer that question do not have secrets governance; they have credential archaeology.
Ephemeral exposure windows: this topic reinforces that secrets are often exposed, used, and discarded faster than traditional review cycles can register them. That means governance has to move closer to issuance, storage, and detection rather than depend on periodic certification after the fact. Practitioners should redesign controls around runtime visibility and immediate ownership transfer when a leak is detected.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Credential exposure surfaces are broader than most IAM programmes model. Teams should expect secrets to appear on endpoints, in build runners, and inside SaaS integrations long before they appear in a formal audit trail. A governed NHI programme has to treat those surfaces as part of the identity estate, not as collateral storage locations.
Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That low visibility explains why leaked credentials often become ownership disputes instead of fast containment events. Practitioners should expect exposure to move faster than manual review unless lifecycle ownership is already explicit.
Third-party exposure widens the secret problem beyond internal controls. When credentials reach outside direct administrative control, revocation and assurance depend on the same governance discipline that supports vendor access, not just vault hygiene. That makes NHI lifecycle management a supply chain concern, not a narrow secrets issue.
For practitioners
- Inventory every credential exposure surface Document where secrets can appear across developer endpoints, CI/CD runners, repositories, SaaS integrations, and vault exports, then assign an owner for each surface.
- Correlate secrets with identity ownership Join secret inventories to service accounts, API keys, and third-party integrations so every exposed item has a known business owner and revocation path.
- Pre-authorise emergency revocation paths Define who can rotate or disable each credential type before an incident occurs, including dependencies that would break when the secret is revoked.
- Reduce plaintext persistence on endpoints Block plaintext secret storage on developer laptops and build hosts, and monitor for copies that persist outside approved vaults or short-lived injection flows.
- Separate detection from remediation ownership Ensure the team that finds the leak is not left guessing who must rotate it, because ambiguity is what turns exposure into prolonged risk.
Key takeaways
- Credential leaks are not isolated hygiene failures when they occur on endpoints, runners, and shared integrations. They are identity governance failures that expose ownership gaps.
- The article points to broad exposure across developer laptops, CI/CD runners, vaults, SaaS applications, and identity providers, which is why the blast radius can expand quickly.
- The limiting control is clear ownership plus fast revocation, because detection without accountable remediation only extends the exposure window.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on leaked secrets across endpoints, CI/CD, and connected systems. |
| NHI-05 — Overprivileged NHI | The demo explicitly calls out over-permissioned access tied to exposed credentials. | |
| Recommendation — Scan for exposed NHI secrets and revoke any leaked credential immediately. Review NHI entitlements and remove excess permissions from credentials that can be reached from developer surfaces. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and revocation are central to limiting leaked-secret exposure. |
| Recommendation — Apply authenticator management controls to rotate compromised secrets and retire stale credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's ownership and revocation issues align with account and credential governance. |
| Recommendation — Maintain authoritative account ownership and disable exposed access paths as soon as they are identified. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack pattern described is credential theft followed by reuse across trusted systems. |
| Recommendation — Map leaked secrets to credential-access and lateral-movement techniques to prioritise detection and containment. | ||
Key terms
- Exposure Surface: The set of data, endpoints, and signals that can be observed or queried by an external party. For identity security, the exposure surface is broader than the access surface because publicly visible fields can still be abused for recon and profiling.
- Ownership Gap: An ownership gap exists when an identity has no accountable person or team responsible for remediation and approval. For AI agents and service accounts, that gap blocks closure, weakens auditability, and turns detection into unresolved backlog instead of risk reduction.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
- Plaintext Persistence: The continued presence of credentials in readable form on endpoints, logs, build systems, or shared services after they should have been protected or removed. It is a strong indicator that secret handling controls are not aligned with the real runtime path.
What to expect at the briefing
GitGuardian's full demo covers the operational detail this post intentionally leaves for the source:
- Live walkthrough of secrets visibility across code, endpoints, CI/CD, and connected services
- Operational examples of preventing plaintext secrets from persisting on developer laptops
- Remediation workflow detail for investigating and resolving secret leak incidents at scale
- Governance context for ownership gaps and over-permissioned access in NHI estates
👉 GitGuardian's full demo covers secrets visibility, remediation at scale, and NHI governance gaps.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org