Codex access to secrets exposes the limits of agent governance

At a glance

What this is: This is an analysis of how AI coding agents change secrets handling, with the key finding that credentials must be scoped and issued at runtime rather than copied into prompts, files, or repositories.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern agent access without relying on controls built for static credentials and human-paced review cycles.

By the numbers:

• 27 days

👉 Read 1Password's analysis of Codex access to secrets and runtime injection

Context

AI coding agents are not just writing code. They are executing tasks that touch databases, APIs, and deployment pipelines, which means they need credentials to do useful work. The governance gap appears when those credentials are treated like ordinary development artifacts and end up in prompts, files, or repositories.

The control problem is simple to describe and hard to solve: secrets that are visible to the agent are also available to be logged, cached, reused, or exposed in outputs. For IAM and NHI teams, the question is no longer whether agents need access, but how to grant it without turning the model context into a shadow vault.

This is a classic NHI lifecycle issue with a new runtime shape. The access object is still a secret, but the execution pattern is faster, more ephemeral, and more tightly coupled to code generation and deployment workflows.

Key questions

Q: How should security teams handle credentials used by AI coding agents?

A: Security teams should keep credentials outside the agent context and issue them only for the task that needs them. That means using runtime injection, explicit approval, and short-lived scope so the model can orchestrate work without ever holding raw secret values. The control objective is custody reduction, not just secret storage.

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: What breaks when secrets are placed inside model context?

A: What breaks is the assumption that a secret stays visible only to the authorised process. Once it is inside model context, it can be logged, cached, surfaced in outputs, or reused across sessions. That makes the context window part of the trust boundary, which is a poor place to store anything that should remain tightly controlled.

Q: Who should own access decisions for AI agent secrets?

A: Access decisions should be owned by the identity and security function, with approval tied to the task and the actor's scope, not left implicit inside the developer workflow. That gives teams a way to preserve oversight while still supporting automation. If approval is unclear, the secret will drift into places that governance cannot reliably inspect.

How it works in practice

Why secrets in model context create a new exposure surface

A coding agent can only act on systems if it can reach credentials, but putting those credentials into model context changes the trust boundary. Once a secret is inside prompts, local files, or conversation history, it becomes part of the agent's working memory and may be copied, cached, or surfaced in outputs. That is different from normal secrets storage, where the secret stays outside the execution layer. The technical issue is not just theft. It is uncontrolled replication across developer tooling, logging layers, and inference workflows.

Practical implication: keep credentials outside prompts and repositories so the agent can act without ever seeing raw secret values.

Just-in-time credential injection for coding agents

Just-in-time access changes the execution model by issuing credentials only when a task needs them and only for that task. In this pattern, the agent orchestrates work, but the secret is injected into the application process at runtime rather than handed to the model itself. The article describes a local MCP-based workflow where access requests are validated through the desktop client, user approval is required, and variables are made available without exposing the underlying values. That preserves function while narrowing custody.

Practical implication: scope credentials to the task and inject them at runtime, not into persistent agent context or shared files.

MCP access layers and the boundary between orchestration and custody

Model Context Protocol connects the agent to tools and data sources, but it also creates a policy question about what the agent can invoke versus what it can actually possess. In this architecture, the agent can create environments, list variable names, and trigger tasks, while the access layer holds the secret itself. That separation matters because it makes the agent a requester and orchestrator rather than a vault. The architecture is strongest when approval, authorization, and secret retrieval are clearly split across components.

Practical implication: design MCP workflows so the agent can request actions without gaining custody of the secret material itself.

NHI Mgmt Group analysis

Secrets-in-context is a trust failure, not just a storage problem. The article describes a workflow where coding agents can act on systems without ever being given raw secret values, which is the right boundary for this class of identity. Once credentials enter prompts, terminals, or repositories, the trust model collapses into uncontrolled exposure paths that normal secrets tooling was not designed to govern. Practitioners should treat model context as an untrusted execution surface, not a credential container.

Ephemeral access is now the baseline assumption for agentic workflows. The combination of task-scoped access, user approval, and runtime injection reflects a broader shift away from static secrets and toward non-persistent entitlement. That shift matters because coding agents do not need standing custody to perform useful work, but many IAM programmes still behave as if access must exist long enough to be reviewed later. Practitioners should re-evaluate whether their current governance model assumes secrets are stable artefacts instead of transient execution inputs.

Context-window containment is becoming an identity control, not just an AI control. The key risk here is not simply that a model can read a secret. It is that once an NHI secret is inside the agent context, it can be reused far beyond the intended task boundary. This reframes secrets management as a runtime identity boundary problem spanning NHI, developer tooling, and AI execution. Practitioners should govern where secrets can exist, not only where they are stored.

Least privilege for agents must be defined at task time, not provisioning time. Static entitlement models assume that the access need can be known in advance and certified later. Coding agents break that premise by combining code generation, environment setup, and execution in one flow, which means privilege must be bounded around the task, not the actor label. The implication is that entitlement review, secret issuance, and execution telemetry need to move closer together.

Runtime access layers will become the control plane for agent identity. The article points toward a future in which coding agents, operational agents, and customer-facing agents all need the same access pattern: request, approve, inject, execute, and expire. That is a material shift for identity programmes because it moves the control point from secret inventories to access orchestration. Practitioners should expect NHI governance to converge with agent governance around runtime authorisation.

From our research:

• 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.
• For a deeper NHI perspective, see Guide to the Secret Sprawl Challenge for the cleanup patterns that reduce secret spread across code and pipelines.

What this signals

Secrets discipline will need to move closer to runtime identity governance. As AI coding agents become normal in delivery pipelines, the programme boundary shifts from stored secrets to how access is issued, approved, and expired during execution. Teams that still separate secrets management from identity governance will find that agent workflows expose the gap immediately.

The practical signal is that developer productivity tools are now part of the identity surface. If a workflow can copy a secret into a prompt, terminal, or repository, it is already in scope for NHI governance, access review, and detection engineering. That is why task-scoped delivery and centralised control matter more than file hygiene alone.

For practitioners

• Separate orchestration from custody Keep coding agents able to request actions without exposing raw secrets in prompts, terminals, or repositories. Use an access layer that injects credentials only into the application process at runtime and expires them after the task completes.
• Review every workflow that still depends on .env files Map which development and deployment flows still rely on shared environment files, hardcoded values, or copied secrets. Replace those patterns with centrally managed secret delivery and task-scoped access where feasible, using the Guide to the Secret Sprawl Challenge for cleanup patterns.
• Treat agent approval as part of the identity control path Make explicit user approval, request validation, and scoped task authorisation part of the access decision rather than an informal developer step. The goal is to preserve human oversight without forcing the secret itself into the agent context.
• Instrument secret exposure paths across developer tooling Look for logs, caches, shells, and repository artifacts that can duplicate credentials once an AI agent touches them. Tie detection to the places secrets can leak, and use the Reviewdog GitHub Action supply chain attack case study to pressure-test repository exposure assumptions.

Key takeaways

• AI coding agents create a governance problem when credentials are copied into prompts, files, or repositories, because those secrets become easy to duplicate and hard to audit.
• The evidence gap is already visible in secrets operations, where leaked credentials can take 27 days to remediate even when organisations believe their controls are strong.
• Practitioners should shift from static secret custody to task-scoped runtime injection, approval, and expiry so the agent can act without holding the secret itself.

Key terms

• Model Context: The working memory an AI system uses to interpret prompts, tools, and intermediate state during a session. In security terms, it is a sensitive execution surface because anything placed there may be logged, cached, reused, or surfaced beyond the original task boundary.
• Runtime Injection: A pattern where credentials or configuration are delivered to an application only when it executes, rather than being stored in code or prompts. This reduces exposure because the secret is available to the process, but not to the agent or the surrounding developer workflow.
• Task-scoped Access: Access granted for one defined job, with limits tied to the work being performed. For AI-driven workflows, task scope matters because the actor may execute quickly and repeatedly, so privileges should expire as soon as the task is complete or the approval window closes.

Deepen your knowledge

Secrets handling for AI coding agents is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are redesigning secrets governance around runtime access and agent workflows, it is worth exploring.

This post draws on content published by 1Password: Codex access to secrets and runtime injection with 1Password Environments. Read the original.