Notifications
Clear all
Topic starter
12/07/2026 12:20 pm
TL;DR: OpenAI Codex can plan, write, test, and run code on a developer’s behalf, but that also expands exposure to secrets hidden in .env files, scripts, logs, and configs, according to Akeyless. The real governance problem is that access review and rotation controls assume credentials remain visible and reviewable, while model context can become an un-auditable secret pathway.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
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.
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.
Q: What breaks when secrets are stored in local files and developer tools?
A: What breaks is visibility, attribution, and revocation speed.
Practitioner guidance
- 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.
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
👉 Read Akeyless' analysis of secretless access for OpenAI Codex →
OpenAI Codex and secretless access: what IAM teams need to know?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
12/07/2026 12:33 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OpenAI Codex and secrets governance: why model context matters
