TL;DR: Developer secrets stored in code, local machines, and CI/CD pipelines create a growing blind spot as AI agents and machine identities increase credential use, according to 1Password. The governance gap is that high-privilege access is hard to track, revoke, or contain when workflows outpace manual controls.
Editorial analysis by NHI Mgmt Group, based on content published by 1Password: “Live Demo Discover built-in developer security in 1Password EPM”.
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
Key questions
Q: What breaks when credentials are left in developer tools and pipeline configurations?
A: When credentials remain in developer tools and CI/CD configurations, teams lose control over who can use them, where they travel, and whether they are still needed.
A: AI agents can read, edit, and execute across multiple systems, so any overly broad permission becomes operational power.
Practitioner guidance
- Inventory developer credential locations Map where API keys, SSH keys, and tokens exist across source code, local machines, CI/CD tooling, and shared automation so ownership is explicit.
- Separate human and machine credential paths Give AI agents and automation their own scoped identities instead of reusing the same credentials that developers use interactively.
- Bind secrets to lifecycle owners Assign an accountable owner, environment, and expiry expectation to each developer credential so revocation is possible without manual archaeology.
Bottom line: Developer secrets are a governance issue because they spread across code, endpoints, and pipelines faster than manual controls can track.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Developer credential security is now an identity governance problem, not just a secrets problem. The article shows that API keys, SSH keys, and tokens are spread across code, local machines, and CI/CD systems, which means the control failure spans multiple execution surfaces. That is why the issue sits across NHI governance, IAM, and delivery operations rather than in one tool category. Practitioners should treat developer secrets as governed identities with ownership, scope, and offboarding requirements.
A few things that frame the scale:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
A question worth separating out:
Q: Should organisations treat developer workstation secrets as part of secrets management?
A: Yes. If a secret exists on a developer machine, it is part of the credential estate and must be governed alongside vaulted secrets, repository secrets, and rotation processes. The distinction matters because unmanaged local copies can outlive the controls that protect centrally stored credentials.
👉 Read our full editorial: 1Password developer credential security webinar on AI agents and EPM