Join our Newsletter — 33% off our NHI Course

Developer secrets and AI agents: what changes for IAM teams?

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 16497
Topic starter  

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.

Q: Why do AI agents increase the risk of secrets exposure and unsafe changes in engineering environments?

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 →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 16988
 

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:

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



   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.