Topic starter
10/06/2026 10:59 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by 1Password: “1Password is now a trusted access layer for OpenAI’s Codex”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
12/06/2026 4:45 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Codex access to secrets exposes the limits of agent governance
This post was modified 2 days ago by NHI Mgmt Group