1Password’s Codex integration reframes just-in-time AI access

At a glance

What this is: 1Password's Codex integration is an identity-layer approach to AI coding workflows that keeps secrets out of model context and delivers them just in time.

Why it matters: It matters because IAM teams now have to govern credentials used by coding agents with the same discipline they apply to human and workload access, but under faster runtime conditions.

👉 Read 1Password's analysis of Codex access and just-in-time credential delivery

Context

Coding agents change the access problem because they need credentials to execute real development tasks, but those credentials are often handled in ways that expand exposure across prompts, local files, and repositories. The primary governance question is no longer whether secrets exist, but whether access is bounded to the exact runtime context in which the agent is allowed to operate.

For IAM and NHI programmes, this is the same old trust problem showing up in a new operational shape. The difference is that the actor is now an AI agent embedded in the development path, so controls have to account for task-scoped access, execution context, and approval boundaries at runtime.

Key questions

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

A: Use just-in-time delivery, keep credentials outside prompts and generated output, and bind access to the exact task the agent is performing. The right control is not broader secrecy, but narrower exposure. If the agent never sees the secret value except at execution time, the chance of leakage into code, logs, or downstream tools drops materially.

Q: Why do coding agents create new NHI governance problems for IAM teams?

A: Coding agents behave like non-human identities that need real credentials to complete work, but they operate fast enough that traditional review cycles often lag behind their access needs. That means the programme has to govern runtime access, not just vault storage. IAM teams must also align approval, issuance, and revocation to the agent's actual execution window.

Q: What breaks when secrets are allowed into model context windows?

A: Once a secret enters model context, it can be reproduced in prompts, logs, code suggestions, or other tool outputs. That turns a protected credential into a transferable object. The failure is not only disclosure. It is the loss of control over where the secret can reappear and who can reuse it later.

Q: Should organisations give AI coding tools standing access to databases and APIs?

A: No, not if the same work can be done with task-scoped credentials. Standing access makes the blast radius larger than the actual task requires and creates persistence that outlives the workflow. The safer pattern is approval-bound, time-limited access that expires as soon as the coding task is complete.

How it works in practice

Runtime credential injection for coding agents

Runtime injection means a credential is delivered only when an authorised process starts, then withheld from the surrounding environment once the session ends. In this model, secrets are not written into prompts, terminals, or source files, which reduces the number of places an attacker can harvest them from. The design also shifts the control point from storage to execution. That matters because agent workflows often span multiple tools, each of which can persist data differently if the access pattern is not tightly scoped.

Practical implication: align secret delivery to session start and session end, not to repo or workstation convenience.

Model context windows and secret exposure

A model context window is the information the agent can see and reason over during a run. If secrets enter that window, they can be copied into logs, prompts, or generated output, even when nobody intended them to persist. Keeping credentials outside the context window is therefore an exposure control, not just a hygiene measure. It narrows the attack surface for prompt leakage, accidental disclosure, and downstream misuse by tools that process the agent's output.

Practical implication: treat model context as an exposure zone and keep secrets out of it by design.

Just-in-time access for agentic development

Just-in-time access gives a credential only for the duration of a specific task, then removes it automatically. In AI-native development, that reduces the value of a stolen secret because the usable window is shorter and the access path is more constrained. The governance challenge is that the agent may need to reach databases, APIs, and deployment pipelines within a single workflow, so the access model must support fast issuance without creating standing privilege. That makes runtime identity policy central to secure agent use.

Practical implication: map every agent workflow to a task-scoped entitlement and avoid persistent developer or agent credentials.

NHI Mgmt Group analysis

Just-in-time secrets are becoming the baseline control for agentic development. The article reflects a wider shift in which coding agents are no longer treated as read-only assistants but as actors that need live credentials to complete work. That means static secret storage is increasingly misaligned with how software is now produced, especially when prompts, terminals, and repositories all become accidental disclosure channels. Practitioners should treat runtime credential delivery as the control boundary, not the vault alone.

Model context exposure is the hidden trust boundary in AI coding workflows. Secrets lose protection the moment they enter the agent's context window, because the model can reproduce or route them into other systems. This creates a named concept worth tracking: context-window secret leakage. Once the secret is in context, the exposure problem extends beyond storage to inference, logging, and tool chaining, which means the relevant governance question is where the credential is permitted to exist at all.

Standing credential assumptions break down when the actor is an AI coding agent. Least privilege was designed for conditions where access could be provisioned, reviewed, and revoked over a stable lifecycle. That assumption fails when the actor needs to act inside a fast-moving development session and may only require access for minutes rather than days. The implication is that access governance must be timed to execution, not to human review cadence.

Unified access for humans, agents, and machine identities is now an identity governance problem, not a tooling add-on. The article points to a single access model spanning people and non-human actors, which is the right direction for programme design. Separate control planes create blind spots when the same credential classes are used across developer, workload, and agent workflows. Practitioners should re-evaluate whether their identity architecture can express the same policy across all three actor types without manual exceptions.

Secret visibility is no longer the only metric that matters. A credential can be technically vaulted and still be unsafe if the workflow leaks it into context, code generation, or local artefacts. The real governance test is whether an agent can complete its task without turning the secret into a reusable object. Teams that only count vaulted secrets will miss the operational exposure created by runtime use.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to Astrix Security.
• For a broader control baseline, review Ultimate Guide to NHIs for lifecycle, rotation, and offboarding patterns that apply across non-human identities.

What this signals

Context-window secret leakage: AI coding workflows are turning the model context itself into a governance boundary. If secrets can enter prompts or generated output, then storage controls alone are no longer sufficient. Teams should prepare for identity policies that distinguish between vaulted credential custody and runtime exposure inside agent sessions.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, per The State of MCP Server Security 2025, the market signal is clear: developers will keep embedding access into workflows unless governance makes safer patterns easier to use than unsafe ones. IAM teams should expect runtime access policies to move closer to the developer experience layer.

This also pushes agent governance into the same control family as workload identity and secrets lifecycle management. Where credentials are issued, how long they remain valid, and whether they are ever visible to the agent are becoming the practical decision points that determine risk.

For practitioners

• Define task-scoped secret issuance for coding agents Issue credentials only for the duration of a specific build, test, or deployment task, then revoke them automatically when the session closes. Tie issuance to an approved process rather than a general developer workstation or long-lived agent profile.
• Keep secrets out of prompts and generated code Block patterns that allow credentials to be copied into prompts, checked into repositories, or echoed into terminals. Use vaulted references and runtime resolution so the agent can act without ever seeing the secret value.
• Map agent workflows to explicit authorization boundaries Document which databases, APIs, and deployment pipelines a coding agent may reach, and require approvals for any expansion beyond that boundary. Re-certify those boundaries as code paths and environments change.
• Separate context handling from credential storage Treat model context as an exposure surface and design controls so sensitive values are never present in the prompt, memory, or output stream. This reduces leakage from both accidental disclosure and downstream tool reuse.

Key takeaways

• Coding agents create a new governance problem because they need credentials to perform real work, yet those credentials can leak through prompts, logs, and generated output.
• The scale of exposed secrets in agent-facing workflows shows that runtime access design, not vault storage alone, now determines the usable attack surface.
• Teams should move to task-scoped, approval-bound access for AI coding agents and keep secret values outside the model context wherever possible.

Key terms

• Model Context Window: The model context window is the set of information an AI system can see and use during a run. For identity governance, it matters because secrets placed here can be echoed, stored, or reused by downstream tools, turning a temporary credential into an exposure event.
• Just-in-Time Access: Just-in-time access is a credential pattern that grants permission only when a task needs it and removes it when the task ends. In agentic workflows, it reduces the lifespan of credentials and limits how long a compromised secret can remain useful.
• Runtime Credential Injection: Runtime credential injection is the practice of delivering a secret only inside an authorised execution session instead of storing it in files, prompts, or code. It keeps the credential available long enough to do the work while reducing the number of places it can be copied or leaked.
• Context-Window Secret Leakage: Context-window secret leakage is the failure mode where a credential enters the AI model's working context and becomes visible to prompts, logs, or generated output. The issue is not storage alone. It is the loss of control over how the secret moves once the agent can reason over it.

Deepen your knowledge

Coding agents, runtime credentials, and secrets exposure are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building access controls for AI-native development, it is worth exploring.

This post draws on content published by 1Password: 1Password secures coding agents with new OpenAI Codex integration. Read the original.