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.
At a glance
What this is: This webinar looks at developer credential security and argues that AI agents and machine identities are amplifying the risks around API keys, SSH keys, and tokens stored outside controlled systems.
Why it matters: It matters because IAM, PAM, and NHI teams need a way to govern developer access without breaking engineering workflows or leaving high-privilege credentials exposed across modern delivery pipelines.
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.
Context
Developer credential security is the practice of controlling API keys, SSH keys, and tokens used in software delivery and automation. The gap in this article is that those credentials are often managed outside the systems security teams already trust, which leaves governance fragmented across code, endpoints, and pipelines.
The article frames this as a growing identity problem because AI agents and machine identities increase the number of non-human actors that need access. That shifts the question from whether developers can get work done to whether access can be governed, revoked, and audited without slowing delivery.
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. Secrets can spread across local machines, .env files, repositories, and agent context windows without clear ownership. That creates exposure, weakens auditability, and makes credential theft or accidental reuse much easier.
A: AI agents can read, edit, and execute across multiple systems, so any overly broad permission becomes operational power. If an agent can access logs, shells, or repositories, it may expose secrets, overwrite config files, or run unsafe commands. The risk rises when teams assume tool calls are harmless instead of treating them as real production actions.
Q: How do security teams know if secrets governance is actually working on developer workstations?
A: Secrets governance is working when sensitive material is not recoverable from local paths, environment variables, or build scripts, and when imported dependencies cannot read them without triggering detection. Good signals include reduced secret presence on endpoints, enforced rotation after developer compromise, and audited ownership for every deployer credential.
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.
Background and context
Why developer secrets become governance blind spots
Developer secrets often move through code repositories, local workstations, build agents, and CI/CD tooling faster than security reviews can follow. Once a token or key is embedded in a workflow, the control problem is no longer just storage, it is lifecycle governance across every place the credential is copied, cached, or reused. This is a classic NHI issue because the secret grants machine-accessed privilege, yet the control plane is usually designed around human-centric administration. The article is pointing at a structural mismatch between where secrets live and where teams think ownership sits.
Practical implication: map every place developer credentials can exist, not just where they are issued.
How AI agents change credential exposure
AI agents increase credential pressure because they frequently need programmatic access to tools, services, and data sources. That does not automatically make the system autonomous, but it does widen the set of non-human actors dependent on secrets and delegated permissions. The security issue is not only more credentials, but more runtime paths where a credential can be requested, stored, or inherited outside ordinary developer controls. When agents and machine identities share the same access fabric, credential scope and revocation become harder to reason about in advance.
Practical implication: separate AI agent access paths from human developer credentials wherever possible.
Why revocation and visibility fail in fast-moving pipelines
Visibility alone does not solve developer credential risk if the organisation cannot revoke access fast enough to contain misuse. In CI/CD and automated workflows, privileged secrets can be used, copied, and propagated before manual review ever happens. That makes lifecycle control more important than static policy. A high-privilege credential that cannot be quickly tracked back to an owner or an environment creates an identity governance gap, not just a secrets management issue. The operational failure is delayed containment, especially when the same secret spans code, local tooling, and pipeline execution.
Practical implication: bind credentials to owners, environments, and expiry rules so revocation is actionable.
NHI Mgmt Group 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.
Ephemeral developer access should be the default assumption, but many programmes still govern secrets as if they were stable assets. The practical failure is not only leakage, but delayed revocation when access outlives the task, pipeline, or engineer who needed it. That creates a standing-privilege effect in dynamic workflows, which is exactly where conventional manual controls become slow to matter. Practitioners should reframe the problem around credential lifetime, not credential storage alone.
AI agents intensify the credential lifecycle gap because they expand non-human access without simplifying accountability. Each new agent or automation path increases the number of places where access must be issued, observed, and revoked. The more those paths resemble developer workflows, the easier it is for organisations to lose track of which identity is actually acting. Practitioners should align machine access governance with the same lifecycle discipline used for service accounts and privileged human accounts.
Developer credential governance now needs one named concept: credential blast radius. When secrets are stored in code, endpoints, and pipelines, the damage from one exposed token is determined by how far that credential can travel before it is revoked. That is a governance design issue, not just a detection problem. Practitioners should focus on narrowing the reachable scope of each developer secret so a single compromise does not become platform-wide access.
From our research library:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
- Read next: Guide to NHI Rotation Challenges
What this signals
Developer credential blast radius: the important metric is no longer whether secrets exist, but how far one exposed credential can move across code, pipelines, and machine workflows before revocation. That shifts the programme conversation from storage hygiene to enforceable lifecycle control.
Access reviews are weak when the identity under review is not a person but a secret embedded in automation. If the organisation cannot link a credential to an owner, an environment, and an expiry condition, the review process is too slow to govern the risk it is meant to contain.
AI-driven workflows make it easier for non-human identities to accumulate hidden access paths unless teams enforce separate issuance and offboarding logic. For practitioners, the signal to watch is not just secret volume, but whether revocation is measured in minutes or in audit cycles.
For practitioners
- 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.
- Reduce standing privilege in delivery workflows Replace persistent high-privilege tokens with narrowly scoped access that can be withdrawn as soon as the workflow or task ends.
- Harden CI/CD secret handling Treat build runners and pipeline variables as credential-bearing systems that require logging, access review, and offboarding controls.
Key takeaways
- Developer secrets are a governance issue because they spread across code, endpoints, and pipelines faster than manual controls can track.
- The article's core evidence is that secrets commonly live outside managed vaults, which widens the blast radius of one exposed credential.
- Practitioners need lifecycle ownership, scoped access, and fast revocation if they want to keep developer workflows secure without adding friction.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Developer secrets stored in code and pipelines are a direct secret leakage problem. |
| NHI-05 — Overprivileged NHI | The article focuses on high-privilege credentials that are difficult to contain or revoke. | |
| NHI-07 — Long-Lived Secrets | The article's governance gap is the persistence of credentials across workflows and tools. | |
| Recommendation — Scan code, endpoints, and pipeline variables for leaked developer secrets and revoke them immediately. Scope developer credentials to the minimum access needed and eliminate persistent overprivilege. Replace long-lived developer secrets with short-lived credentials and defined expiry rules. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 directly governs credential lifecycle, including issuance, rotation, and revocation. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and track developer credentials. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Exposed developer secrets are a common route to credential access and subsequent lateral movement. |
| Recommendation — Map exposed developer secrets to credential-access tactics and hunt for downstream movement. | ||
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 Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- CI/CD secret exposure: CI/CD secret exposure is the accidental or unauthorized disclosure of credentials used by build and deployment pipelines. It includes API keys, tokens, certificates, passwords, and signing material appearing in logs, code, artifacts, environment variables, or pipeline configuration. Exposure creates immediate risk because attackers can impersonate systems, alter releases, or move laterally.
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 June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org