TL;DR: Akeyless warns that OpenAI Codex can plan and run developer tasks across databases, APIs, cloud services and deployment pipelines, expanding exposure to secrets hidden in files, logs and model context. The governance problem is that access review and rotation assume credentials stay visible and auditable, while coding agents can turn them into an unreviewable runtime pathway.
At a glance
What this is: This is an analysis of how OpenAI Codex changes secrets governance when coding agents need access to development and operations systems without bringing secret values into model context.
Why it matters: It matters because IAM, PAM and NHI teams must govern agent-assisted workflows without treating prompts, local files and generated output as safe places for credentials to appear.
👉 Read Akeyless's analysis of OpenAI Codex and secrets governance
Context
OpenAI Codex is a coding agent that can plan, write, test and run code on a developer’s behalf. The governance gap is that once an agent can operate across databases, APIs, cloud services and deployment pipelines, traditional secrets handling breaks down if credentials are still stored in .env files, scripts, shell history or source code.
The central issue is not whether the agent is helpful, but whether secret values ever enter the agent’s working context. For IAM and NHI programmes, this is a model-context control problem: the secret must remain governed outside the agent while still being usable at runtime.
Akeyless frames its integration as a way to keep Codex orchestrating work while secrets remain in the access layer, which is the right problem statement for practitioners. The starting position here is typical of modern developer environments, where convenience has outpaced secrets governance.
Key questions
Q: How should security teams prevent coding agents from exposing secrets in generated output?
A: Place secrets detection at the agent request and response path so exposure is intercepted before delivery. Use block for high-risk material and redact when the surrounding code is still useful. Post-exposure scanning remains valuable for audit trails, but it cannot stop a secret from entering a repository, log, or downstream system.
Q: Why do coding agents increase secrets risk in ways normal developer automation does not?
A: Coding agents can inspect files, run commands, read output and move across multiple tools within one task, which makes secret exposure much broader than a single automated step. The risk rises because the agent can carry context from one action to the next, increasing the chance that credentials are surfaced or reused outside policy.
Q: What are the signs that model-context secrets governance is failing?
A: Common warning signs include secrets appearing in generated code, terminal output, copied files, CI logs or redacted results that still reveal sensitive structure. If developers rely on local .env files or shell exports for agent-assisted tasks, the programme is already depending on a context boundary that can leak credentials.
Q: What should teams do when an AI agent needs access to a database or cloud service?
A: Teams should broker the action through a server-side authority layer so the agent receives the result, not the credential. That approach reduces standing exposure and keeps database passwords, cloud keys, and service tokens inside the governed boundary instead of inside the model session.
How it works in practice
Why model context becomes a secrets boundary
Model context is the information a coding agent can see and use while it plans and executes work. If secret values are present in files, terminal output, prompts or generated code, the agent can surface them, copy them or propagate them into logs and artefacts. That changes the trust boundary from a human workstation to an AI-assisted execution path. The important detail is that the model does not need to know the secret value to perform the task. It only needs names, paths and redacted results. Once teams accept that distinction, they can treat context as governed metadata rather than a credential store.
Practical implication: keep secret values outside agent-visible context and expose only names, paths and redacted outputs.
How just-in-time injection changes developer workflows
Just-in-time secret injection means the credential is supplied only at execution time, then withheld from the agent itself. In the workflow described here, the MCP server fetches the secret from the access layer and injects it into the child process environment for the command that needs it. That preserves application function while preventing the agent from becoming a persistent holder of the credential. The mechanism matters because it shifts control from storage-time protection to issuance-time protection. For NHI governance, this is closer to runtime authority than static configuration management.
Practical implication: move credential delivery to the point of execution and remove reusable secrets from local developer state.
Why redaction and brokerage are not the same as visibility
A brokered access path is not simply a logging layer. The article’s pattern has the access layer mediate the request, inject the credential, and redact secret values from stdout and stderr before results return to Codex. That means the agent sees the outcome of the action, not the credential used to produce it. This is important for databases, Kubernetes clusters and GitHub workflows because the credential itself is authority over live systems. If the agent receives that authority directly, governance becomes much harder to prove and much easier to bypass.
Practical implication: use brokered execution for live-system access so the agent receives results, not reusable authority.
NHI Mgmt Group analysis
Model context is now part of the credential boundary: Traditional secrets governance assumed the main risk was where a secret was stored. That assumption breaks when a coding agent can read, transform and replay workspace data in the course of ordinary tasks. The implication is that governance has to treat prompt-visible context, not just vault storage, as a control surface.
Runtime brokerage is more defensible than agent-held credentials: The integration pattern described here keeps secret values in the access layer and injects them only for the command that needs them. That matters because an AI-assisted workflow can span tests, builds and infrastructure checks in one session. Practitioners should recognise that the access decision now belongs at execution time, not inside the agent.
Secretless access is an NHI design pattern, not an AI novelty: The same lifecycle issues seen with service accounts, tokens and deployment credentials now apply to coding agents. What changes is the speed and breadth of exposure, because an agent can traverse many tools in one run. Teams should therefore govern Codex as a non-human identity path that must never become a secret repository.
Access review is a weak fit for ephemeral agent context: Access review processes were designed for credentials that remain stable long enough to be certified. Codex-style workflows can obtain, use and discard access within a single task, leaving little meaningful artefact for later review. The implication is that approvals, issuance and redaction become more important than post-hoc recertification.
Secret context leakage is the right named risk to track: The real failure mode is not simply that a secret exists, but that it enters model context and can be replicated through outputs the developer does not notice. That is a governance problem because the evidence trail becomes fragmented across prompts, logs and generated files. Practitioners should focus on preventing secret context leakage rather than only cleaning up exposed files.
From our research library:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, 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.
- Read next: NHI Authentication Guide
What this signals
Secret context leakage: The governance problem is no longer limited to leaked files or mismanaged vault entries. When an AI coding agent can read workspace artefacts, the boundary that matters is whether secret values ever enter model context in the first place.
Teams running AI-assisted development need to shift from post-hoc clean-up to issuance-time control. That means governing runtime injection, redaction and brokered execution as first-class identity controls for both developer workflows and NHI access paths.
For practitioners
- Enforce secretless model context Keep secret values out of prompts, generated code, terminal output and local files that the coding agent can observe. Expose only names, paths and redacted results so the agent can complete the task without becoming a credential store.
- Broker runtime access through a control layer Route database, cloud and deployment access through an access broker that injects credentials at execution time and returns only the result. Use that pattern for tasks where the agent needs live-system authority but should not receive reusable secrets.
- Replace plaintext environment files with governed references Move .env values, shell exports and config file secrets into centrally managed references so developers and agents cannot copy raw credentials into workspaces. Keep the environment usable, but remove the secret from the workspace surface.
- Scan for secret exposure in agent workflows Look for secrets in generated code, command output, copied files and workflow logs created during AI-assisted development. Treat any exposed value as a credential lifecycle event, not just a hygiene issue, and revoke or replace it through the governed source of truth.
Key takeaways
- Codex-style coding agents create a new governance boundary because secrets can leak through model context even when they are not stored in the agent itself.
- The most defensible pattern is to keep secret values in a governed access layer and inject them only at execution time.
- IAM, PAM and NHI teams should treat agent-assisted development as a runtime access problem, not just a secrets storage problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets entering Codex-visible context and surfacing through files, logs and output. |
| NHI-04 — Insecure Authentication | The article depends on governed runtime access rather than direct agent-held authentication. | |
| NHI-07 — Long-Lived Secrets | The article argues against storing standing secrets in workspaces that coding agents can access repeatedly. | |
| Recommendation — Prevent secret leakage into agent-visible context and revoke any credentials exposed during AI-assisted development. Use governed runtime authentication paths so the coding agent never receives reusable credentials directly. Replace long-lived workspace secrets with just-in-time issuance and centrally managed references. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Codex must not gain privileges beyond the task it is executing across tools and systems. |
| Recommendation — Constrain agent authority so runtime access cannot outgrow the approved task scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing what the coding agent may access and when. |
| Recommendation — Apply least-privilege entitlement controls to agent-assisted workflows and review runtime access paths. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Secrets exposure through workspace artefacts maps directly to credential access and exfiltration paths. |
| Recommendation — Map exposed secret pathways to credential access and exfiltration tactics in detection and response. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Just-in-time secret injection: A credential delivery pattern where secrets are supplied only when a verified workload needs them, instead of being stored persistently in files or environment variables. This reduces the value of runtime compromise because stolen code cannot automatically read reusable credentials.
- Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.
- Secret Context: Secret context is the metadata that explains what a credential is, who owns it, when it was created, and what it can access. Without that context, a secret is only a string. With it, teams can judge exposure severity and decide whether to rotate, revoke, or investigate.
What's in the full announcement
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step MCP server workflow for injecting secrets into child processes without exposing them to Codex
- Configuration guidance for authentication, environment organisation and RBAC in production deployments
- Runtime Authority examples for querying PostgreSQL and other live systems without sending credentials to the agent
- Repository examples for scanning exposed secrets and migrating them into Akeyless-managed references
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on July 12, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org