TL;DR: AI coding agents need credentials to write, execute, and prepare code for production, but secrets placed in prompts, .env files, or repositories remain easy to exfiltrate and hard to govern, according to 1Password. The real issue is not just secret storage but the assumption that access can stay visible and reviewable once an agent is executing at runtime.
At a glance
What this is: This is an analysis of how AI coding agents need secret access to do useful work, and why placing credentials in prompts, files, or repositories creates a governance gap once execution moves into runtime.
Why it matters: It matters because IAM, PAM, and NHI teams have to govern agent access without letting the agent become the custodian of the secret itself.
Context
AI coding agents change the control problem because they do not just suggest code, they execute against databases, APIs, and deployment pipelines. That means the identity question is no longer whether a human developer can see a secret, but whether the agent can act without becoming a durable holder of that credential.
Traditional secrets handling assumes the credential can be stored, reviewed, and reused under human-paced governance. Once the agent is in the workflow, that assumption weakens: the useful access window is task-scoped, runtime-bound, and too short for conventional review cycles to govern cleanly.
Key questions
Q: What breaks when AI agent access relies on long-lived secrets?
A: Long-lived secrets let AI agents carry persistent access far beyond the task they were created for. That increases theft risk, complicates offboarding, and makes it harder to prove scope at audit time. Secretless, short-lived access is safer because the credential exists only for the current task and runtime context.
Q: Why do AI coding agents complicate secrets management?
A: AI coding agents complicate secrets management because they combine prompting, execution, and environment setup in one workflow. If secrets are copied into prompts, .env files, or repositories, they become easy to duplicate and hard to audit. The problem is not the agent alone, but the speed at which it can spread access material across tools.
Q: How can security teams tell whether agent access is actually under control?
A: Look for evidence that the team can trace every tool call, secret use, and cross-system action back to a named owner and a valid approval path. If an agent can reach messaging, browser, and infrastructure tools without a revocation chain, access is not truly governed. Control exists only when the runtime can be stopped as fast as it can act.
A: Runtime secret injection supplies the credential only when the workload starts or requests it, so the secret is not embedded in the deployment definition. Direct storage in Kubernetes configuration places the secret into manifests or environment settings, which increases persistence and exposure. The practical difference is whether the secret remains transient or becomes part of the workload record.
How it works in practice
Why model context is the wrong place for secrets
Model context is the working memory an AI system uses to reason and act during a session. If a secret enters that context through prompts, environment files, scripts, or repository text, it can be logged, cached, reused, or surfaced in output paths the operator did not expect. In other words, the credential has crossed from controlled storage into an execution substrate designed for fluid exchange, not custody. For coding agents, that is the central architectural mistake: the agent needs access to act, but it does not need possession of the secret value itself.
Practical implication: keep credentials out of prompts, code, and model context, and treat the agent as an access consumer rather than a secret store.
Just-in-time secret issuance for agentic workflows
Just-in-time secret issuance means the credential is provided only when a specific task requires it, and only for the scope and duration of that task. In the article's model, 1Password injects variables at runtime into the authorized process, so the application can run while the secret value remains outside the agent channel. That is materially different from copying a secret into a file or prompt, because the agent can orchestrate work without ever receiving custody of the underlying value. The control shifts from secret distribution to runtime authorization.
Practical implication: scope agent access to the narrowest task window possible and issue secrets only at execution time.
MCP changes access plumbing, not trust assumptions
Model Context Protocol connects the agent to tools and data sources, but it does not eliminate the need for governance. In this pattern, MCP is the transport for invocation, while identity and authorization still sit with the user-approved access layer. That distinction matters because teams can mistake tool connectivity for trust. The article's architecture keeps secret values inside the vault and lets the agent request actions against them, which preserves separation between orchestration and custody. Governance still has to decide who can authorize what, and under which conditions.
Practical implication: govern MCP-connected workflows as access pathways, not as safe containers for credentials or policy by themselves.
NHI Mgmt Group analysis
Runtime access has become the new governance boundary for AI coding agents. The article shows that the meaningful control point is no longer where the secret is stored, but when and how it is issued to the process that needs it. That shifts governance from repository hygiene to task-scoped authorization, which is a different operating model for IAM and NHI teams. Practitioners should treat agent execution as a runtime access event, not a documentation problem.
Human review cycles do not map cleanly onto agentic execution. Access review assumes a credential persists long enough to be observed, sampled, and recertified. AI coding agents compress that window into a task, which means the review artifact may never exist in a stable form. The implication is not simply tighter controls, but a rethink of whether access certification can govern ephemeral machine action at all.
Ephemeral credential trust debt: The article exposes a structural debt created when teams keep issuing durable secrets to systems that only need transient authority. Every reused secret adds future exposure and audit friction because the credential outlives the task that justified it. The practitioner conclusion is to reduce standing secret custody wherever runtime injection can replace it.
Codex-like workflows collapse the distinction between orchestration and custody. An agent can now prepare, configure, and execute work while the secret itself remains outside its context window. That is exactly where traditional secrets management has to get sharper, because the security model must decide which actor may trigger access without ever becoming the holder of record. Teams should redesign controls around delegated use, not delegated possession.
AI coding agents are an NHI governance problem before they are an AI tooling problem. The article is about a non-human identity needing access to real systems, with all the usual problems of scope, review, auditability, and revocation. Once that is recognised, the right governance frame becomes OWASP-NHI, zero standing privilege, and runtime authorization rather than workflow convenience. Security teams should evaluate agent access with the same seriousness they apply to any other privileged NHI.
From our research library:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- 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.
- Read next: AI Coding Agents Security Guide
What this signals
Runtime secret injection is becoming the control boundary for agentic workflows. Security teams should assume that any credential copied into prompts, repositories, or local files is now part of the agent's attack surface. The more useful model is a task-scoped access pattern where the process receives what it needs at execution time and nothing else.
Agent governance and NHI governance are converging. AI coding agents are already acting like privileged non-human identities, which means the same lifecycle questions apply: who approves access, how scope is constrained, and how revocation happens when the task ends. Teams that keep treating this as a developer convenience issue will miss the governance shift.
Ephemeral credential trust debt: Every durable secret handed to an agent adds future audit friction because the secret outlives the task that required it. That is why access review alone is not enough once the agent can execute in real time; the control has to move upstream to issuance and approval.
For practitioners
- Separate orchestration from secret custody Allow coding agents to invoke tasks, but keep raw credential values in the vault and out of prompts, terminals, and repository text.
- Issue secrets only at task runtime Use just-in-time access so credentials appear only for the authorized process and only for the duration of the execution window.
- Remove hard-coded credentials from repositories Scan codebases for .env files, scripts, and embedded values, then replace them with runtime references that resolve at execution time.
- Require explicit user approval for agent access Keep a human authorization step in front of every scoped access request so the agent cannot silently expand its privilege set.
- Audit agent access as an NHI lifecycle Track who can authorize the agent, what systems it can reach, and how access is revoked when the workflow changes or ends.
Key takeaways
- AI coding agents need credentials to be useful, but handing them raw secret values creates a custody problem that conventional governance is not built to absorb.
- The exposure risk is not theoretical because secrets in prompts, .env files, scripts, and repositories can be exfiltrated, reused, or left behind in audit blind spots.
- The practical response is to shift governance to task-scoped, runtime access so the agent can execute without ever becoming the secret's custodian.
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, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Secrets in prompts, files, and repositories are the article's primary exposure problem. |
| NHI-07 — Long-Lived Secrets | The article argues against durable secrets for short-lived agent tasks. | |
| Recommendation — Keep raw credentials out of prompts, code, and model context to prevent secret leakage. Replace standing credentials with just-in-time issuance for task-scoped agent access. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The agent is acting with delegated privileges across tools and execution paths. |
| Recommendation — Constrain agent privileges so tool use and runtime access stay within approved scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on task-level authorization and scoped access decisions. |
| Recommendation — Apply PR.AA-05 to enforce least-privilege, task-scoped authorization for coding agents. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed secrets enable credential access that can be reused across systems and workflows. |
| Recommendation — Map exposed secrets to TA0006 and TA0008 to prioritise containment of reused credentials. | ||
Key terms
- Runtime Secret Injection: A pattern that retrieves credentials only when a process starts, rather than storing them in files or source control. For AI developer tools, it reduces secret persistence, limits accidental disclosure, and keeps the credential tied to a specific execution session.
- Task-Scoped Access: Task-scoped access is permission granted for one defined purpose and removed once the task is complete or the session expires. For non-human identities, it reduces standing privilege and limits how long an attacker can exploit a stolen credential.
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Agent Custody: Agent custody describes a state where an AI system does not merely request access but effectively holds or can reproduce the credential itself. That is a governance failure for coding agents because it turns a temporary access need into persistent secret exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, 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