TL;DR: AI coding tools are pushing more builders to handle real secrets, and 1Password says that often means plaintext credentials end up in .env files, chat messages, scripts, or notes that later become hard to govern. That shifts secrets management from an engineering-only task to a broader identity and access problem.
At a glance
What this is: This is a vendor analysis of how AI coding tools are expanding who handles secrets, with plaintext credential sprawl emerging as the main governance risk.
Why it matters: IAM and NHI teams need to treat AI-assisted building as a broader identity governance issue because secrets are now being created, stored and reused outside traditional engineering controls.
Context
AI coding tools are lowering the barrier to application building, which means more people outside traditional engineering now touch secrets, tokens and service credentials. The security problem is not just fast prototyping. It is that access material gets copied into places that are convenient for the builder but opaque to governance.
For IAM and NHI programmes, that changes the operating model. Secrets management now spans developers, analysts, founders and operations teams, not only software engineers. The control challenge is no longer whether a secret exists, but whether it can be found, rotated, revoked and kept out of long-lived plaintext storage.
Key questions
Q: What breaks when AI builders store credentials in chat messages or .env files?
A: The secret stops behaving like a controlled identity artefact and starts behaving like unmanaged content. It becomes difficult to inventory, rotate or revoke, and it can persist in places security teams do not scan. That is why plaintext credential handling creates governance risk even before an attacker is involved.
Q: Why do AI-assisted development workflows increase secret exposure risk?
A: They increase exposure because developers move faster, paste more context into prompts, and review output for function before security. That combination makes secrets more likely to appear in code, logs, or old commits, and those secrets can remain valid long after discovery.
Q: How do security teams know when secret sprawl is becoming unmanageable?
A: When they cannot confidently answer where each secret exists, which workloads depend on it, and how quickly it can be retired without breaking business services. If the answer requires manual archaeology across code, tickets, and pipelines, the sprawl is already beyond routine control.
Q: Should organisations prefer service accounts over shared personal credentials for automation?
A: Yes, because automation should use a non-human identity with explicit scope and ownership rather than inherit a person’s access. Service accounts only improve control if they are inventoried, limited, and retired when the workflow changes. Otherwise they simply replace one unmanaged credential with another.
Technical breakdown
Why AI-assisted building increases credential sprawl
AI coding tools accelerate the creation of working prototypes by steering users toward the shortest path to a functioning app. In practice, that often means a user pastes an API key, token or SSH key into a .env file, a script, a chat thread or a note. That pattern creates credential sprawl because the secret becomes embedded in multiple places outside any governed inventory. Once that happens, rotation, revocation and ownership become harder, especially when the builder is not a trained software engineer or security practitioner.
Practical implication: model AI-assisted development as a secret-creation channel and govern it at the point of issuance, not after the credential has spread.
Runtime secret retrieval versus hardcoding credentials
The technical distinction that matters here is whether an application reads secrets at runtime or whether the secret is written into code and configuration. Runtime retrieval keeps the credential out of source files and local notes, which reduces exposure during sharing, review and compromise. Hardcoding does the opposite: it makes the secret easy to reuse, copy and forget. The article’s key governance point is that accessibility for builders should not depend on manual discipline when the safer pattern can be built into the workflow.
Practical implication: standardise runtime secret retrieval for AI-assisted builds and remove hardcoded credential patterns from approved development paths.
Service accounts and delegated automation for non-engineers
As more non-specialists build internal tools, automation often needs its own identity rather than a shared human credential. Service accounts provide that delegation layer, but only if they are managed as non-human identities with ownership, scope limits and offboarding. The failure mode is borrowed human access that gets reused across prototypes and workflows. Once that happens, the environment inherits hidden privilege and unclear accountability, which is exactly what identity governance is meant to prevent.
Practical implication: assign automation to service accounts with explicit ownership and lifecycle control instead of letting builders reuse personal credentials.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI coding tools turn secrets management into a governance problem, not a developer hygiene problem. The article makes clear that designers, analysts, founders and operations staff are now handling API keys, tokens and SSH keys. That means the control boundary has moved beyond engineering teams and into the broader identity programme. The implication is that secrets policy, ownership and lifecycle oversight must cover every builder role, not just application developers.
Plaintext credential storage is the new shadow inventory for app builders. When secrets are placed in .env files, chat messages, scripts or notes, they become distributed assets with no reliable source of truth. That is not just poor practice. It is a governance blind spot because the organisation cannot confidently answer where the secret exists, who copied it, or whether it was later revoked. Practitioners need inventory discipline that spans the entire builder workflow.
Runtime access changes the shape of least privilege for AI-assisted development. Least privilege is no longer only about which permissions a developer receives. It is also about whether the secret ever has to exist in a recoverable form on a workstation. That shifts the security question from authorisation after creation to controlled retrieval during execution, which is a more durable identity pattern for modern build workflows.
Secret sprawl now extends the same lifecycle risk seen in machine identities to non-traditional builders. A founder shipping a prototype, a data analyst wiring a pipeline, and an engineer deploying a service all create the same governance burden when they use long-lived credentials in plain text. The named concept here is builder-driven secret sprawl: access material proliferates because the people creating it are not operating inside a mature secrets lifecycle. The practical conclusion is that lifecycle governance has to follow the builder, not just the workload.
Service accounts are the right abstraction only when they replace human credential sharing. The article points to service accounts as the safer route for automation, but their value disappears if they become another unmanaged credential bucket. That is why identity programmes should treat them as governed non-human identities with explicit ownership, scope and retirement. The broader lesson is that automation should reduce credential sharing, not rename it.
From our research library:
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Builder-driven secret sprawl: AI-assisted development is expanding the population that handles production-grade credentials, so secrets governance now has to cover designers, analysts and founders as well as engineers. The practical shift is from controlling a narrow developer workflow to governing every place a secret can be created, copied or forgotten.
When secrets move into .env files, chat threads and scripts, the issue is not only leakage. It is lifecycle loss. That means rotation, revocation and ownership tracking need to be designed for distributed builder behaviour rather than for a single secure coding team.
Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
For practitioners
- Standardise runtime secret retrieval Require AI-assisted builds and internal tools to fetch secrets at execution time instead of storing them in source files, notes or local scripts.
- Ban plaintext secret storage in build paths Treat .env files, chat threads and desktop notes as prohibited storage locations for API keys, tokens and SSH keys used in app development.
- Assign automation to governed service accounts Use service accounts for repetitive workflows and prototype automation so teams do not reuse personal credentials across apps and scripts.
- Build a secrets inventory for non-engineers Extend ownership, rotation and revocation tracking to designers, analysts, founders and operations teams who are now creating and handling credentials.
Key takeaways
- AI coding tools are widening the group of people who handle sensitive credentials, which turns secrets management into an organisation-wide identity control problem.
- Plaintext storage in files, chats and scripts creates inventory and lifecycle gaps that make rotation and revocation harder than the original build task.
- The right control shift is toward runtime retrieval, governed service accounts and broader ownership of secret handling across non-engineering roles.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 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 article centres on plaintext credentials being scattered across files, chats and scripts. |
| NHI-07 — Long-Lived Secrets | The risk comes from credentials persisting beyond the prototype that created them. | |
| NHI-05 — Overprivileged NHI | Service accounts and reused credentials can widen access beyond the task they support. | |
| Recommendation — Scan builder workflows for exposed secrets and remove plaintext storage from approved development paths. Replace long-lived secrets with runtime retrieval and enforce lifecycle ownership. Constrain automation credentials to task-scoped permissions and explicit owners. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle management is central to the article’s secrets risk. |
| Recommendation — Apply IA-5 to govern secret issuance, rotation and revocation for build workflows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about controlling who and what can use sensitive credentials. |
| Recommendation — Align secret access with PR.AA-05 by reviewing entitlements for all builder roles. | ||
Key terms
- Credential Sprawl: Credential sprawl is the uncontrolled accumulation of machine secrets, keys, and tokens across systems, teams, and environments. It usually starts with a single use case and ends with overlapping permissions, unclear ownership, and a larger attack surface than the organisation expected.
- Runtime Secret Retrieval: Runtime secret retrieval is the practice of fetching credentials from a vault or controlled service only when they are needed. It reduces secret exposure in repositories and configs, but it only works when the retrieval path is scoped, logged, and tied to a specific workload or agent.
- Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
- Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
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