OpenAI Codex and secrets governance: why model context matters

At a glance

What this is: This is an Akeyless analysis of how coding agents change secrets handling, with Codex as the example and secretless runtime access as the core pattern.

Why it matters: It matters because developer workflows increasingly blend human intent, NHI credentials, and agentic execution, so IAM teams need controls that keep secrets out of model context while preserving usable access.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Akeyless' analysis of secretless access for OpenAI Codex

Context

Coding agents change the secrets problem because they can operate across the same files, terminals, test commands, and deployment paths that human developers use, but with far broader reach inside a session. In practice, that means application secrets that once sat in local config files or shell history can be read, copied, and reused by the agent unless the workflow is designed to keep the secret value out of model context from the start.

For identity teams, this is not just an application security issue. It is an NHI governance problem because the agent is interacting with credentials as an execution layer, while humans still retain accountability for the task. Akeyless frames the pattern as secretless orchestration, where the model sees names, paths, and redacted output, but not the underlying values.

That starting point is typical now: many organisations still rely on plaintext environment files, local configs, and ad hoc developer access patterns even as AI-assisted coding becomes routine. The governance gap is that those controls were built for human-paced workflows, not for agents that can touch multiple systems in a single task cycle.

Key questions

Q: How should security teams keep AI agents useful without letting them see secrets?

A: Use a credential broker or proxy so the agent can make authorised requests without ever handling the underlying tokens, API keys, or certificates. The agent should submit a request, and the broker should attach credentials on the outbound path. That keeps secret custody outside the agent runtime and reduces exfiltration risk from prompt injection or malicious content.

Q: Why do AI coding assistants create new NHI governance risks?

A: They create risk because they run with delegated execution authority, local context, and access to developer workflows. That makes them part of the identity perimeter, not just productivity software. If an attacker can influence the assistant environment, they can suppress prompts, alter startup state, or use the tool as a persistence and exfiltration path.

Q: What breaks when secrets are stored in local files and developer tools?

A: What breaks is visibility, attribution, and revocation speed. Secrets in local files, .env artifacts, and developer tools can be copied and reused outside the systems that security teams monitor most closely. If the organisation cannot discover and trace those credentials, it cannot confidently govern their use or prove they were controlled.

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 is a new credential boundary

Model context is the working memory an AI system uses to plan and continue a task. If secret values enter that context, they can leak through prompts, generated code, logs, or copied output even when the original file was never intended to be shared. The security problem is not only exfiltration. It is also uncontrolled reuse, because the agent can propagate sensitive values across steps and tools faster than human review can catch. In NHI terms, the model becomes an exposure surface, not just a consumer of instructions.

Practical implication: Keep secret values outside the agent’s context and expose only names, paths, and redacted results.

How MCP changes access control for coding agents

The Model Context Protocol creates a structured way for an agent to ask for tools or data without directly holding the underlying credential. In the pattern described here, Codex calls a local MCP server, and the server brokers access through Akeyless instead of handing secrets to the agent. That means policy, redaction, audit, and secret injection stay in the control plane, while the agent receives only enough information to continue the workflow. This is a practical identity boundary, not just an integration convenience.

Practical implication: Treat MCP servers as governed access brokers and place approval, policy, and audit at that boundary.

Why runtime authority is different from plaintext developer access

Runtime Authority shifts the security model from static credential possession to server-side execution of an approved action. Instead of giving the agent a database password, cloud key, Kubernetes credential, or GitHub token, the system brokers the request and returns the result. That reduces standing exposure, but it also changes what must be governed: the action itself, the scope of the target, and the evidence trail. For NHI programmes, this is closer to task-scoped authority than traditional secret distribution.

Practical implication: Use brokered runtime access for operational actions so the credential never leaves the governed boundary.

NHI Mgmt Group analysis

Secretless coding is now an identity governance pattern, not just a developer convenience. The article shows that coding agents can operate across the same tools and systems as developers while still needing strong separation from the credentials they use. That makes the identity boundary the real control point, because the agent should orchestrate work without becoming a secret store or a standing access holder. Practitioners should treat this as governed execution, not assisted scripting.

Model context is an exposure boundary that existing secrets processes do not fully govern. Secrets management has traditionally focused on storage, rotation, and distribution, but AI-assisted coding adds a new place where credentials can leak: the agent’s runtime context. When a secret is visible to the model, it can be reproduced in generated code, terminal output, or chained tool actions. The implication is that secrets governance now has to account for a runtime representation layer, not just a vault and a developer laptop.

Runtime Authority is the right concept for task-scoped access in agentic development. The article describes a pattern where the agent requests an approved action and the credential is used server-side, with only the result returned. That is materially different from granting the agent direct possession of credentials. For NHIMG, this is the emerging control model for AI-assisted operations: scope the action, not the secret, and keep the credential inside the governed service boundary.

Least privilege was designed for human-paced work with stable review windows. That assumption fails when the actor is autonomous enough to traverse files, tools, and systems within a single task cycle because the relevant access may appear and disappear faster than review processes can capture it. The implication is that teams must rethink whether their current IAM and secrets governance can even observe the privilege state they are trying to certify.

Secret sprawl in developer workflows is becoming a composite NHI problem. Environment files, shell exports, local configs, and source code all act as alternate secret stores once an agent can read them. That creates a larger blast radius than any single vault issue because the credential can exist in multiple ungoverned places at once. Practitioners should map where secret values can surface in agent-assisted workflows and then eliminate those uncontrolled copies.

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, which helps explain why developer-side leakage remains persistent across modern workflows.
• That same research found organisations maintain an average of 6 distinct secrets manager instances, a fragmentation pattern that makes agent-era secret governance harder to centralise.
• Use the Guide to the Secret Sprawl Challenge to trace how scattered secret storage becomes operational exposure in developer and AI-assisted environments.

What this signals

Secretless access will become a programme requirement once AI-assisted coding moves from pilot to production. The practical issue is not whether agents can use secrets, but whether security teams can prove the secrets never entered model context in the first place. That pushes IAM and secrets teams toward brokered execution patterns, central policy enforcement, and auditable redaction as default design choices.

Runtime-brokered access is where NHI governance and developer productivity finally meet. The value is not in hiding complexity from developers. It is in making the credential lifecycle visible to the security programme even when the workflow is agent-driven, ephemeral, and multi-tool. Teams should expect more pressure to tie developer access, workload identity, and secret retrieval into one governed path.

With 27 days as the average estimated time to remediate a leaked secret, per The State of Secrets in AppSec, the operational window is already too slow for agent-assisted development. That means teams need preventative boundary design rather than relying on detection after exposure. The next control question is whether the workflow can complete without the secret ever becoming visible.

For practitioners

• Move secrets out of model-visible workflows Replace plaintext .env files, shell exports, and local config secrets with Akeyless-managed references or equivalent brokered retrieval so the agent never sees raw values.
• Put MCP access behind policy and audit Require every agent tool call to pass through a governed MCP server that records access, enforces RBAC, and returns redacted output only.
• Use runtime authority for live system actions Broker database queries, Kubernetes checks, and cloud operations server-side so the credential is consumed outside the agent and never cached in prompts or output.
• Scan developer workspaces for exposed secrets Search repositories, scripts, terminal history, and generated files for credential material, then migrate discovered values into managed storage before enabling agent workflows.

Key takeaways

• AI coding agents turn secrets handling into a runtime identity problem because credentials can leak through model context, generated code, and tool output.
• The strongest governance pattern is secretless orchestration, where the agent requests work and a controlled boundary injects credentials only when needed.
• IAM and secrets teams should rework developer workflows around brokered access, redaction, and auditable policy enforcement before agent adoption widens exposure.

Key terms

• Model Context: The working state an AI system uses to plan and continue a task. In practice, it becomes a security boundary when secret values, commands, or tool outputs can be reproduced or carried forward by the model. For agentic workflows, context must be treated as a potential exposure surface, not a safe holding area.
• 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.
• Secretless Orchestration: An access model where an AI agent can complete work without ever seeing raw secret values. The agent uses names, paths, or references, while a governed service injects credentials only at execution time. This reduces secret sprawl and keeps credential handling inside audit-ready controls.
• 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.

What's in the full announcement

Akeyless' full post covers the operational detail this post intentionally leaves for the source:

• Step-by-step MCP setup for connecting OpenAI Codex to Akeyless without exposing raw secret values
• Configuration guidance for environment organisation, RBAC, and approval settings in production deployments
• Runtime Authority flow details for database, cloud, Kubernetes, and GitHub operations
• Examples of redaction behaviour and how returned command output is filtered before Codex sees it

👉 Akeyless' full post covers MCP integration, runtime authority, and production configuration details

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.