Just-in-time secrets for agentic development are now the default

At a glance

What this is: This is a practical demo on secure agentic development that argues just-in-time secrets should replace long-lived secret handling for coding agents.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that preserve developer speed while preventing secrets from being embedded in files, environments, or reusable workflows.

Context

Coding agents change the secret-handling problem because they need access to real credentials while they execute, not just at provisioning time. That shifts the control point from storage and distribution to issuance and runtime governance.

The governance gap is not whether secrets exist, but whether they are exposed in durable places such as files, synced environment variables, or long-lived local contexts. For agentic development, the relevant identity question is when access is granted, how narrowly it is scoped, and whether it disappears when the task ends.

This article is about coding-agent workflows, so the identity concern is agentic and NHI-adjacent rather than human authentication. The practical issue is how to preserve speed without turning every development session into a reusable secret repository.

Key questions

Q: How should security teams handle secrets for coding agents?

A: Security teams should move from static secret placement to runtime delivery, using just-in-time injection, narrow scoping, and task-specific access. Coding agents should receive only the credentials they need for the current execution path, with separate handling for each environment. That approach reduces persistence, limits reuse, and makes least privilege operational instead of theoretical.

Q: When does just-in-time secrets management matter most in agentic development?

A: It matters most when agents need real credentials to call APIs, run code, or reach production-like systems, because those are the moments when durable secret storage creates the largest exposure window. The control is most valuable where the task is fast, repeated, and difficult to supervise manually.

Q: What breaks when secrets are written into agent environment files?

A: Environment files stop being harmless configuration and become credential carriers. That breaks repository hygiene, weakens access separation across team members and runs, and makes revocation harder because the secret is now embedded in code-adjacent configuration. The practical result is exposure that outlives the task that created it.

Q: How do security teams keep agent speed and enterprise governance in the same workflow?

A: Build the policy into runtime access so the secure path is also the fastest one. If developers must choose between speed and protection, the process is already misaligned. The goal is to make short-lived, scoped access the default way agents obtain credentials.

Background and context

Runtime injection changes the secret exposure model

Runtime injection means a secret is delivered only when the task executes, rather than being stored in a file, shell profile, or broadly shared environment variable. That matters because the attack surface shifts from durable secret presence to transient in-memory use. In agentic development, the secret is not meant to live as an asset the developer or agent can reuse later. It is meant to exist only long enough for the bounded operation that needs it.

Practical implication: move secrets delivery to execution time so the secret is never present in a persistent developer-controlled location.

Read-only access and per-environment targeting reduce blast radius

Read-only access limits what a coding agent can do with a credential, while per-environment targeting ensures the same secret does not grant identical reach across dev, test, and production-like systems. These are governance controls, not convenience features. They make the credential useful for the exact operation requested, but much less useful for lateral reuse, accidental writes, or environment drift. The core security value is reducing the blast radius of a secret that must be temporarily exposed to an autonomous workflow.

Practical implication: scope agent credentials by environment and permission level, not by developer convenience.

Why long-lived secrets fail in agentic workflows

Long-lived secrets assume the secret can safely sit in a stable location until a human later uses it. Coding agents break that assumption because they execute quickly, repeatedly, and across multiple tools and contexts. If a secret is copied into a file or synced environment, the credential can outlive the task and become reusable outside the intended workflow. The result is not just higher exposure, but weaker accountability because the same secret may be touched by multiple processes over time.

Practical implication: retire persistent secret patterns where the secret can survive beyond the single execution it was meant to enable.

NHI Mgmt Group analysis

Just-in-time secrets are now a governance control, not a developer convenience. Coding agents require secrets at execution time, which means the traditional assumption that credentials can be safely staged ahead of use is already under pressure. The important shift is not tooling preference but control timing, because durable secret placement creates unnecessary exposure in agentic workflows. Practitioners should treat execution-time issuance as the control boundary for agent-assisted development.

Persistent secret storage creates an identity trust debt for development teams. When a secret is copied into files, synced environments, or reused across tasks, the organisation inherits exposure that outlives the session that needed it. That debt accumulates because the credential is no longer tied to one bounded action. The practical conclusion is that governance should follow the credential into runtime, not wait for post-hoc clean-up.

Read-only access and environment scoping are the minimum viable constraints for agentic development. The combination of limited privilege and per-environment targeting narrows what an agent can do if a secret is exposed during execution. That does not eliminate risk, but it materially reduces the blast radius of a compromised or overreached workflow. Teams should measure secret governance by how much access is denied by design, not by how quickly secrets can be handed out.

Agentic development collapses the gap between developer velocity and enterprise control only when policy is embedded in execution. If the governance model still depends on developers manually protecting secrets, the programme has already accepted a control failure. The better pattern is to make the secure path the fast path, so the workflow itself carries the enforcement burden. Practitioners should redesign development access so speed and control are implemented in the same step.

NHI-07 Long-Lived Secrets becomes a development problem when coding agents inherit the same secret patterns as traditional automation. Agent workflows intensify the risk because the secret can be copied, synced, and reused faster than a human workflow typically would. The lesson is that NHI governance does not stop at service accounts; it reaches into developer tooling where machine use of credentials now happens continuously. Practitioners should align agent development controls with NHI lifecycle governance, not ad hoc developer habits.

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.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Runtime secret delivery shifts governance from storage to issuance. Coding agents do not behave like static automation, so the old model of parking credentials in files or synced environment variables is increasingly the wrong control point. What matters now is whether the credential exists only long enough to complete a bounded task, then disappears before reuse becomes possible.

Just-in-time secrets create a narrower identity blast radius for development workflows. That is the real policy value of per-environment targeting and read-only scope: the agent can do the work, but the credential cannot easily travel with it. For teams building agent-assisted development, the question is whether current controls still assume a human-paced workflow.

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. That pattern shows why coding-agent workflows need secret governance at execution time rather than after exposure has already occurred.

For practitioners

• Use just-in-time secret issuance Deliver credentials only at execution time so coding agents never receive a reusable secret in a persistent location.
• Enforce read-only agent access Scope credentials so the agent can perform the task but cannot modify systems or expand access beyond the intended action.
• Target secrets by environment Issue different credentials for development, test, and production-like environments so a single secret cannot cross boundaries.
• Remove long-lived secrets from developer workflows Replace copied files, synced environment variables, and other durable secret stores with runtime delivery and short exposure windows.
• Treat agent access as lifecycle-governed NHI Track where coding-agent credentials are created, used, and retired so offboarding and rotation are tied to the workflow rather than the user’s machine.

Key takeaways

• Coding agents force teams to treat secret delivery as a runtime control problem rather than a storage problem.
• The core risk is persistent credential exposure through files, synced environment variables, and other durable developer contexts.
• Just-in-time issuance, read-only scope, and environment targeting are the control trio that shrinks exposure without slowing the workflow.

Key terms

• Just-in-time secrets: Just-in-time secrets are credentials issued only when needed and for a short period. They reduce the time a secret exists and can be abused. In practice, a system generates or unlocks a token, password, or key at request time, binds it to a task or identity, and revokes it after use or expiry.
• Runtime injection: Runtime injection is the practice of supplying credentials or tokens directly into an application or agent at execution time instead of storing them locally. It keeps secrets out of files and shared environment variables, but only works well when the runtime boundary is tightly controlled and observable.
• Per-environment targeting: Per-environment targeting means a credential or access path is bound to one specific environment such as development, staging, or production-like systems. It prevents broad reuse, limits accidental drift across systems, and helps prove that machine access stays within a defined operational boundary.
• Read-only access: Read-only access allows a machine or agent to inspect data or systems without changing them. In AI-assisted development, it is a practical least-privilege default because it lets teams validate behaviour and gather context while reducing the chance of unintended modification or privilege escalation.

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.