Notifications
Clear all
Topic starter
10/06/2026 10:56 pm
TL;DR: As coding agents move into developer workflows, teams are under pressure to stop copying secrets into files or keeping long-lived credentials in local environments; 1Password’s demo argues that runtime injection, read-only access, and per-environment targeting reduce risk while preserving speed. The governance shift is real because least privilege has to be enforced at execution time, not after the secret has already been exposed.
NHIMG editorial — here’s why we think this discussion matters
Questions worth separating out
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.
Q: When do long-lived secrets become a governance problem for AI-powered development?
A: Long-lived secrets become a governance problem as soon as they are used in workflows where software can request, reuse, or spread credentials faster than a human can review them.
Practitioner guidance
- Move secrets delivery to runtime injection Replace local secret copies and synced environment variables with runtime-controlled injection so credentials exist only for the execution window.
- Bind agents to per-environment credentials Issue separate credentials for dev, staging, and production-like systems so a coding agent cannot drift across boundaries.
- Default coding agents to read-only access Use read-only permissions until a task truly requires write access, then escalate only for that specific execution path.
What to expect at the briefing
1Password's full demo covers the operational detail this post intentionally leaves for the source:
- Live walkthrough of 1Password Environments used with Cursor Hooks for runtime secret delivery.
- Practical demonstration of how read-only access and per-environment targeting are applied during execution.
- Speaker-led explanation of how developer speed and enterprise governance can be combined into a single workflow.
- Implementation examples that show why runtime injection is safer than local secret management.
👉 Watch 1Password's demo on just-in-time secrets for secure agentic development →
Just-in-time secrets for coding agents: what changes for teams?
Explore further
12/06/2026 4:40 am
Just-in-time secrets is becoming the operational baseline for AI-assisted development. Coding agents need credentials in motion, not credentials parked in developer files or long-lived environment stores. That shifts secrets handling from static provisioning to execution-scoped access, which is exactly where conventional secret sprawl starts to create governance debt. The implication is that teams must treat runtime delivery as the normal control plane, not an exception.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How can organisations tell whether runtime secrets controls are working?
A: They should look for evidence that secrets are not stored locally, not reused across environments, and not available outside the agent’s execution window. A working model produces narrow access paths, observable delivery, and minimal residual credential exposure after the task ends. If developers still depend on copied secrets, the control is incomplete.
👉 Read our full editorial: Just-in-time secrets for agentic development are now the default
