TL;DR: GitGuardian frames the credential layer as the pressure point for 2026, citing 28.7 million new secrets exposed on public GitHub in 2025 and AI-assisted developers leaking secrets at twice the usual rate. The governance problem is no longer discovery alone; runtime access, identity sprawl, and agentic code generation now define the attack surface.
At a glance
What this is: GitGuardian’s SecDays NYC event focuses on secrets exposure, AI-assisted development, and the credential layer as the control point for secure enterprise operations in the age of AI.
Why it matters: This matters to IAM and NHI practitioners because the event connects software development behaviour to credential governance, showing why secrets, workload access, and AI-driven code creation now need shared oversight.
By the numbers:
- 28.7 million new secrets were exposed on public GitHub alone in 2025, the largest jump on record.
👉 Register for GitGuardian's SecDays NYC summit on the credential layer and AI-era security
Context
GitGuardian’s SecDays NYC is an executive summit centered on the credential layer, with the article positioning secrets exposure as a software development and identity governance problem rather than a narrow developer hygiene issue. The event is scheduled for December 8, 2026 in New York, and the source frames it as a discussion about what makes a secure enterprise in the age of AI.
The core governance gap is that AI agents and non-security-trained employees can now create code paths that generate or expose secrets faster than traditional review cycles can absorb. That shifts the problem from periodic secret cleanup to lifecycle control over issuance, reuse, visibility, and offboarding across human and non-human identities.
Key questions
Q: How should teams reduce secrets exposure in AI-assisted development?
A: Start by treating AI-assisted development as a new source of credential creation. Remove hardcoded secrets from templates and sample configs, enforce secret manager use, and require owners for every service account, token, or API key. Then measure how quickly exposed credentials are rotated or revoked, because discovery alone does not reduce access risk.
A: When secrets are scattered, organisations usually lose auditability, slow down remediation, and create inconsistent rotation and revocation practices. That fragmentation makes it harder to prove who accessed what, to contain leaked credentials quickly, and to enforce policy at scale. A consistent secrets management model supports faster response, stronger governance, and fewer hidden trust paths.
Q: When should organisations prioritise just-in-time credentialing over broader vault access?
A: Prioritise just-in-time credentialing when the secret is used by agents, shared services or other identities that can execute faster than human review cycles. In those cases, standing access creates unnecessary persistence and wider blast radius. The right test is whether the credential can be issued, used and destroyed within the same task boundary.
Q: How do identity teams know whether secrets governance is actually working?
A: Identity teams know secrets governance is working when they can prove that every active secret has an owner, an approved scope, and a tested revocation path. If they cannot quickly identify where a secret is used or remove it without breaking the workload, governance is still incomplete.
Background and context
Why the credential layer is now the control point
The credential layer is the set of secrets, tokens, API keys, and certificates that let software and services authenticate and act. In modern development, that layer spans code, pipelines, runtime services, and AI-assisted workflows, so compromise is not limited to a single vault or repo. If secrets are created in one place, copied into another, and consumed by multiple systems, the effective attack surface becomes the whole path from generation to use. That is why credential governance now sits at the intersection of software delivery and identity control.
Practical implication: map every place credentials are created, copied, stored, and used before you try to secure them.
How AI-assisted development changes secret exposure
AI-assisted coding changes the failure mode because the person writing code may not understand the credential patterns the tool emits or inserts. That creates a new class of accidental leakage, where secrets appear in generated snippets, logs, examples, or pasted configuration before security review happens. The issue is not that AI makes compromise automatic, but that it lowers the friction of producing working code while weakening the human checkpoints that used to slow secret exposure. The result is more secrets entering the environment, and entering it faster.
Practical implication: treat AI-assisted development as a source of secret introduction risk, not only as a code quality concern.
Why securing secrets now requires lifecycle governance
Secrets management is no longer just vaulting and rotation. It now includes ownership, scoped issuance, revocation, and cleanup across service accounts, pipelines, and agent-created workflows. When secrets outlive the task or identity that created them, the organisation inherits standing access that may no longer match intent. In NHI terms, the governance failure is persistence without accountability: a secret continues to authorize action after the operational reason for it has changed. That is a lifecycle defect, not merely a storage defect.
Practical implication: bind secrets to explicit owners, short-lived use cases, and revocation triggers tied to lifecycle events.
NHI Mgmt Group analysis
Secrets governance is becoming a software-production discipline, not a vaulting exercise. The article’s framing around the credential layer reflects a broader shift: secrets now originate in development tools, AI-assisted workflows, and business-user experimentation, not just in formal engineering teams. That means the control problem is distributed across creation, propagation, and reuse. Organisations that still treat secrets as a back-office hygiene task will miss the real governance boundary.
AI-assisted code generation is increasing secret exposure by widening the set of people who can accidentally create credential risk. When employees without security training can generate functional applications, the historic assumption that developers are the primary source of secret handling risk no longer holds. The implication is that credential governance must be designed for low-friction creation paths, not only expert-managed pipelines.
Credential persistence is the named failure mode this summit points to. A secret that remains valid after it has been copied, reused, or embedded into a workflow becomes an identity problem, not just a secrets problem. That persistence creates a durable access path that review cycles often do not see in time. Practitioners should read this as evidence that short-lived, owned, and revocable credential patterns matter more than vault centralisation alone.
Agentic software changes the assumption that human intent precedes execution. Traditional secret governance presumes a person or team requests access before software acts on it. When AI agents generate code or credentials on their own, that assumption weakens because issuance and use can occur inside automated runtime flows. The implication is that access governance must account for machine-originated credential creation and not rely only on human approval checkpoints.
The market signal here is convergence between NHI governance and software development governance. The article is not really about a conference agenda. It is about the fact that secrets, workload identity, and AI-assisted development are now one control plane problem. Practitioners should expect future governance programmes to blend SDLC controls, NHI lifecycle rules, and access visibility into a single operating model.
What this signals
Credential persistence is the control gap this event makes visible. The problem is not simply that secrets leak, but that leaked credentials often remain valid long enough to be reused in later workflows. That pushes identity teams toward lifecycle controls for issuance, reuse, and revocation rather than relying on periodic secret cleanup.
AI-assisted development changes where governance has to start. If non-security specialists can generate working code that includes credentials, then secret management must extend upstream into tooling, templates, and approval flows. The practical shift is from post hoc detection to preventative control at the moment credentials are introduced.
Credential layer governance now spans NHI, IAM, and software delivery. That means teams should stop treating secrets as a vault-only problem and start aligning ownership, short-lived access, and offboarding across human users, service accounts, and agent-created workflows.
For practitioners
- Map credential creation points Inventory every place secrets are created or introduced, including repositories, CI/CD pipelines, AI-assisted coding tools, and business-user automation. Assign an owner for each source so discovery is tied to accountability rather than just scanning.
- Shorten secret lifetime Replace long-lived credentials with short-lived alternatives wherever the use case allows, and tie revocation to task completion, environment teardown, or offboarding events.
- Review AI-assisted development paths Add controls for generated code, copied snippets, and prompt-driven workflows so security teams can detect when secrets are introduced outside normal engineering review.
- Govern credential reuse Track whether the same secret is reused across environments, services, or teams, and treat reuse as a lifecycle defect because it expands blast radius when one credential is exposed.
Key takeaways
- The article frames secrets exposure as a governance problem that spans software development, AI-assisted code generation, and identity control.
- The source cites 28.7 million new secrets exposed on public GitHub in 2025 and says AI-assisted developers leaked secrets at twice the usual rate.
- Practitioners should focus on credential creation, lifetime, reuse, and revocation, because vaulting alone does not eliminate standing access.
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 CSF 2.0 and NIST SP 800-53 Rev 5 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 summit centers on exposed secrets and credential-layer governance. |
| NHI-07 — Long-Lived Secrets | The article frames credential lifetime as the core governance issue. | |
| Recommendation — Scan for leaked secrets and remove exposed credentials from code, logs, and workflows. Replace long-lived credentials with short-lived credentials tied to explicit business use. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Credential scope and authorization are central to the event's theme. |
| Recommendation — Review authorization scope for secrets and remove unnecessary entitlements. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article concerns lifecycle control of secrets and authenticators. |
| Recommendation — Apply authenticator management controls to rotate and revoke credentials on lifecycle events. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Secret exposure is directly tied to credential access risk and reuse. |
| Recommendation — Map exposed secret patterns to credential access techniques and prioritize detection coverage. | ||
Key terms
- Credential Layer: The credential layer is the operational layer where teams track where secrets live, what they unlock, who owns them, and whether they are still valid. It sits across application, infrastructure, and identity controls, because a credential’s risk depends on its placement and its remaining access.
- Hidden Persistence: Hidden persistence is a durable foothold that continues to operate while avoiding ordinary user-facing signs of compromise. In browser contexts, it can sit inside extension state or profile metadata, allowing code to survive restarts and remain difficult to notice with standard UI checks.
- AI-Assisted Secret Exposure: AI-assisted secret exposure is accidental credential leakage that occurs when code-generation tools, prompt-driven workflows, or copied snippets introduce secrets into source, logs, or configuration. The risk is less about malicious intent and more about faster, less reviewed production of working code.
- Credential Reuse: Credential reuse happens when the same password, token, or secret can unlock multiple systems or sessions. It increases breach impact because one stolen credential can become a wide-ranging access path. The control problem is not only theft, but the amount of trust packed into each reusable secret.
What to expect at the briefing
GitGuardian's full event page covers the agenda and speaking program this post intentionally leaves at a higher level:
- Session timing and format for the half-day SecDays NYC summit in New York
- Fireside chat agenda on governing the agentic enterprise and measuring emerging AI access risk
- Two focused presentations on credential security at scale and where GitGuardian says the field is heading
- Networking and registration details for security leaders attending by invitation
👉 GitGuardian's full event page covers the agenda, speakers, and registration details for SecDays NYC.
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 building or maturing an IAM programme, 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