1Password developer credential security webinar on AI agents and EPM

At a glance

What this is: This is a 1Password live demo focused on extending enterprise password management into developer workflows, with the key finding that developer secrets and machine identities create a fast-growing governance blind spot.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern developer credentials that behave like high-risk machine identities, especially where AI agents, code repositories, and CI/CD pipelines intersect.

👉 Register for 1Password's live demo on developer security in EPM

Context

Developer secrets are credentials such as API keys, SSH keys, tokens, and certificates that engineers use to access code, infrastructure, and internal services. When those credentials live in code, local machines, and CI/CD pipelines, the security model stops being a simple vault problem and becomes an identity governance problem across non-human access.

The article frames a familiar failure mode for NHI programmes: high-privilege developer access is spread across too many execution contexts to be tracked consistently. That creates delayed revocation, uneven visibility, and policy drift, especially as AI agents begin to depend on the same credentials and machine identities.

The practical question is not whether developers need fast access. It is whether existing IAM and PAM controls can extend into developer workflows without breaking delivery speed or creating parallel credential systems.

Key questions

Q: How should security teams govern developer secrets in modern engineering workflows?

A: Security teams should govern developer secrets as lifecycle-managed non-human identities. That means mapping where credentials live, assigning ownership, setting rotation and revocation rules, and reducing shared use across code, endpoints, and pipelines. The goal is to make secret use visible enough that access can be reviewed and withdrawn without disrupting delivery.

Q: Why do developer credentials become a blind spot for IAM and PAM teams?

A: Developer credentials become a blind spot because they are distributed across places that traditional access reviews do not fully cover, including code, local machines, and CI/CD systems. That distribution breaks the assumption that privileged access exists in one controllable location, which makes governance, certification, and revocation incomplete.

Q: What breaks when secrets are reused across developers, agents, and pipelines?

A: When secrets are reused, the same credential can authenticate multiple actors and workflows, which destroys accountability and widens blast radius after exposure. A single compromise then affects more systems than intended, and the organisation loses the ability to prove which identity actually acted at a given point in time.

Q: How should teams respond when an AI agent depends on developer credentials?

A: Teams should treat that dependency as delegated machine access and review it with the same seriousness as privileged service access. The credential should have a narrow purpose, clear ownership, and a defined retirement path. If the agent can act only because a human secret still exists, the workflow is already carrying hidden risk.

Background and context

Why developer credentials become an NHI governance blind spot

Developer credentials are often treated as operational plumbing rather than identities with lifecycle, scope, and revocation requirements. That is the root of the blind spot. API keys, SSH keys, and tokens can exist in source code, on endpoints, and inside CI/CD systems at the same time, which fragments visibility and makes entitlement review incomplete. In NHI terms, the problem is not just storage. It is the absence of a single control plane for issuance, discovery, rotation, and retirement across multiple credential locations.

Practical implication: map where developer secrets actually live before you decide how to govern them.

Why AI agents intensify developer secret exposure

AI agents change the access model because they are not merely consuming credentials, they are acting through them. When an agent depends on an API key or token, that secret becomes part of a runtime delegation chain, not just a login artifact. This raises the stakes for credential scope, inheritance, and revocation. The operational challenge is that secret use may be triggered by code, prompts, pipelines, or automated tasks, which makes ownership harder to assign and review cadence less effective.

Practical implication: treat agent-linked credentials as delegated machine access with explicit ownership and revocation paths.

Why CI/CD pipelines remain the highest-friction control point

CI/CD pipelines are a concentration point for developer trust because they combine code execution, build permissions, and access to downstream services. If a secret is exposed there, the credential can be replayed quickly and across environments. The issue is not only theft, but persistence through over-broad privileges and inconsistent rotation discipline. For identity teams, this is where NHI governance, secrets management, and pipeline security overlap most visibly.

Practical implication: prioritise pipeline credential discovery and rotation before expanding developer access into more automated workflows.

NHI Mgmt Group analysis

Developer credential sprawl is now an identity governance problem, not a tooling problem. When API keys, SSH keys, and tokens sit across code, endpoints, and pipelines, the programme loses a coherent view of who or what can still act. That makes revocation, certification, and least-privilege enforcement partial at best. The implication is that developer secrets must be governed as NHIs with lifecycle controls, not as incidental implementation details.

AI agents amplify the weakness because they inherit and reuse the same credentials that developers already struggle to contain. The article points to a growing reality: machine identities are no longer isolated from developer workflows. As agents begin to depend on the same tokens and keys, the boundary between application access and identity access becomes thinner. Practitioners should expect that any gap in developer secret control will be inherited by agentic workflows.

Hidden credential locations create an identity blast radius that most access reviews never see. Secrets in local machines and CI/CD pipelines are outside the places where many teams think to look during recertification or audit. That means the access path can remain active long after the business owner thinks it has been removed. The named concept here is developer secret blind spot: access that is operationally real but governance-invisible. Practitioners need to treat discovery scope as part of the control itself.

Extending an existing trusted control surface is often more practical than introducing a parallel developer-security stack. The article’s central operational message is that governance fails when teams force developers into entirely separate workflows. If the security model adds friction, users route around it and secrets spread further. The more durable pattern is to bring developer credentials into the same governance lifecycle already used for other privileged identities, while keeping the workflow intact.

The market signal is clear: credential governance is converging across human, NHI, and AI-driven access. Teams can no longer separate password management, secrets management, and machine identity governance into disconnected programmes. That segmentation leaves review gaps exactly where modern engineering work now happens. The practitioner conclusion is to unify governance language first, then align controls around the credential lifecycle rather than the user interface.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• For a broader breach perspective, 52 NHI Breaches Analysis helps teams connect secret exposure to repeatable governance failures.

What this signals

The signal for practitioners is that developer secret governance now needs to sit inside the same operating model as NHI lifecycle control, not beside it. Once credentials are spread across repositories, endpoints, and pipelines, the main risk is not just theft, but loss of revocation certainty and ownership clarity.

Developer secret blind spot: this is the point where access exists operationally but disappears from governance sightlines. That concept matters because AI agents and pipeline automation will inherit whatever credential discipline already exists, which means weak developer controls become the default for machine access.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the scale of exposure is now large enough that periodic review is insufficient. Teams should expect discovery, rotation, and retirement workflows to be measured as continuously operating controls rather than audit-time tasks.

For practitioners

• Inventory developer secret locations across the full workflow Catalogue secrets in code repositories, local developer machines, CI/CD pipelines, and shared tooling so you know where credentials can actually be used or leaked. Tie each location to an owner and a revocation process.
• Apply lifecycle governance to developer credentials Define issuance, rotation, review, and retirement rules for API keys, SSH keys, and tokens the same way you would for other privileged non-human identities. Make revocation possible without waiting for a manual cleanup cycle.
• Separate human login from machine access paths Use distinct controls for engineer authentication and for secret-bearing automation so one compromised workstation does not automatically expose pipeline or application access. Limit each credential to a narrow operational purpose.
• Tighten CI/CD credential scope before expanding automation Review build and deployment permissions, then shrink secret scope to the minimum service and environment required. Remove broad reuse of the same token across multiple pipelines or environments.
• Build secret discovery into audit and review cycles Use recurring discovery of exposed credentials in repositories, documents, and pipeline definitions so governance reviews are based on current state, not assumptions. Treat undiscovered secrets as active risk until proven otherwise.

Key takeaways

• Developer credentials are governed identities, not just implementation details, once they are used across code, endpoints, and pipelines.
• The exposure problem is amplified when AI agents reuse the same secrets that human engineers already spread too widely.
• Practical control now depends on discovery, ownership, and revocation across the full credential lifecycle, not on storage alone.

Key terms

• Developer Secret: A developer secret is a credential used to access code, services, or infrastructure, such as an API key, SSH key, token, or certificate. In practice, it becomes an identity artifact when it can authorize action, not just authenticate a person. Its risk lies in spread, reuse, and weak revocation.
• Credential Sprawl: Credential sprawl is the uncontrolled distribution of secrets across systems, repositories, endpoints, and automation layers. It creates visibility gaps because no single team can confidently say where access exists, how long it remains valid, or which workflow still depends on it. That makes governance and revocation slower than exposure.
• Developer Secret Blind Spot: A developer secret blind spot is the gap between where credentials are actually used and where the governance programme believes they are controlled. It appears when secrets sit in code, local machines, or CI/CD pipelines outside normal review boundaries. The result is active access that remains invisible to certification and audit processes.
• Machine Identity: A machine identity is a non-human identity used by software, services, or automation to authenticate and act. It can be a token, key, certificate, or workload identity. The governance requirement is the same as for any privileged identity: ownership, scope, lifecycle control, and timely retirement.

Deepen your knowledge

Developer secret governance and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending controls into engineering workflows, it is a relevant place to start.

This post draws on content published by 1Password: Live Demo Discover built-in developer security in 1Password EPM. Read the original.