Secretless AI agents expose the limits of static secret governance

At a glance

What this is: This is a walkthrough of secretless AI agents and MCP server patterns that replace hardcoded keys with runtime retrieval from trusted identity.

Why it matters: It matters because IAM and NHI programmes need controls that govern retrieval-time access, not just storage-time secrecy, across AI workloads and agentic integrations.

👉 Read Akeyless's walkthrough of secretless AI agents and MCP server access

Context

Secretless AI agent architecture is a governance problem as much as a design pattern. When an MCP server or AI workload retrieves credentials only at runtime, the control question shifts from where secrets are stored to whether identity, policy, and retrieval are aligned at the moment of execution.

The older model assumes a secret exists as a durable asset that can be copied, rotated, and audited after the fact. In this article's pattern, the more relevant control boundary is the trusted identity that requests access, because the credential may never exist in code, config files, or environment variables.

That makes this primarily an NHI governance issue with agentic implications. The article is about secretless retrieval for AI-native infrastructure, so the important change is how workload identity, secret issuance, and access scope are enforced together.

Key questions

Q: What breaks when AI systems rely on shared secrets instead of per-workload identity?

A: Shared secrets make attribution, containment, and revocation much harder. If one key leaks, multiple workloads may be exposed at once, and defenders cannot easily tell which system used the credential. Per-workload identity improves blast-radius control, supports cleaner audit trails, and makes it easier to revoke access without disrupting unrelated services.

Q: What is the difference between secret management and NHI governance for AI agents?

A: Secret management protects the credential itself, while NHI governance controls what the credential can do, where it can be used, and when it should be revoked. For AI agents, both matter, but governance is broader because it covers authorization, privilege scope, lifecycle review, and detection of shadow access paths.

Q: How do security teams know whether runtime secrets are actually protected?

A: They test whether keys, environment variables, or tokens can be recovered from live processes, memory, or execution paths. If decryption material is reachable during runtime, the secret is exposed even if storage is encrypted. Effective governance measures runtime exposure, not just stored encryption status.

Q: Should organisations treat MCP servers as part of the identity control plane?

A: Yes. An MCP server that brokers access to secrets, models, or downstream services is effectively making authorisation decisions on behalf of machine workloads. That makes its retrieval policy, identity trust chain, and audit trail part of identity governance. If those controls are weak, the server becomes a privileged access path rather than a neutral integration layer.

Technical breakdown

How secretless retrieval changes the credential model

Secretless design removes the persistent secret from the application and shifts authentication to a trusted identity such as AWS IAM or a GitHub JWT. The workload authenticates first, then retrieves the secret only when needed. That means the credential is no longer a stored configuration artefact but an on-demand output of the secret platform. The security difference is important: compromise has to target the identity and retrieval path, not a hardcoded value sitting in source, .env files, or CI variables.

Practical implication: govern the identity used to request secrets as tightly as the secret itself.

Why MCP servers still create secret governance risk

MCP servers often sit between user input and model execution, so they become a policy enforcement point as well as an access broker. If the server fetches an API key at runtime, the key may be absent from code but the runtime path still determines who can reach it, when, and under what identity. That makes the server a control plane for NHI access, not just an application component. The core failure mode is assuming that removing static storage automatically solves governance when the real issue is scoped, observable retrieval.

Practical implication: treat MCP servers as privileged secret brokers and audit their retrieval policy, not just their source code.

Static secret governance versus just-in-time secret delivery

Static governance assumes a credential persists long enough to be inventoried, rotated, and revoked on a schedule. Just-in-time delivery inverts that assumption by issuing access only for the duration of the workload action. In NHI terms, the control point moves from post-issuance administration to issuance-time authorisation. This is why long-lived tokens, hardcoded API keys, and manual rotation are so often named as the wrong pattern: they preserve a standing trust model in a system that now executes on demand and at machine speed.

Practical implication: redesign governance around issuance-time checks and short-lived access rather than rotation after exposure.

NHI Mgmt Group analysis

Static secret governance is the wrong control model for secretless AI workloads. The article's pattern replaces stored credentials with runtime retrieval, which means the valuable control boundary is the identity requesting access, not the location where a key sits. In NHI terms, that shifts the governance problem from secret custody to access issuance and policy alignment. Practitioners should stop treating storage removal as the control outcome and start treating retrieval authorization as the control surface.

Runtime secret retrieval creates identity blast radius, not secret sprawl. When an MCP server can fetch a credential only after authenticating, the risk concentrates around the workload identity, the secret policy, and the trust path into the broker. That is a different failure mode from copied keys in code repositories, but it is still an NHI problem because access is delegated to a machine actor. The practical conclusion is that secretless does not mean riskless; it means the blast radius has moved.

Trust assumptions for static configuration collapse when access is consumed inside execution. Static models assume a secret exists independently of the workload and can be reviewed, rotated, or removed later. This assumption fails when the agent or MCP server acquires access only at the moment of use and discards it after the task. The implication is that governance has to move from artefact review to runtime authorization, because there may be no durable secret state to inspect.

Ephemeral credential trust debt: the longer teams rely on runtime-only access without matching lifecycle controls, the more governance debt accumulates in the identity layer. Akeyless's walkthrough shows the pattern clearly: identity is used to fetch the secret, but the organisation still needs traceability, scope control, and offboarding logic for that retrieval path. In NHI governance terms, the risk is not only leakage but unreviewed dependency on a control plane that can become invisible in ordinary secret inventories. Practitioners should govern the retrieval path as a first-class identity asset.

From our research library:

• 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
• Read next: NHI Authentication Guide

What this signals

Ephemeral credential trust debt: runtime-only secret delivery reduces exposure in code, but it also pushes governance into identity policy, retrieval telemetry, and revocation discipline. Teams that keep measuring only where secrets are stored will miss the more important question of who can mint them on demand and whether that access is still justified. That is where NHI governance now has to mature.

The operational signal is clear: secretless AI architectures are forcing IAM, PAM, and NHI teams to govern runtime issuance, not just secret inventories. If the trusted identity behind an AI workload is not clearly bounded, the secretless design simply relocates risk rather than reducing it.

For practitioners

• Classify secret retrieval as NHI access Map every runtime secret fetch path to a specific workload identity, secret scope, and approving policy so retrieval is governed as access, not convenience.
• Replace hardcoded credentials with short-lived auth Eliminate API keys, static tokens, and .env-stored secrets from AI workloads and use short-lived identity tokens for retrieval instead.
• Audit MCP servers as privileged brokers Review which secrets an MCP server can request, which identities it trusts, and whether its retrieval policy is narrower than the model or tool access it exposes.
• Instrument secret usage and revocation trails Log each secret retrieval event, tie it to the authenticated workload identity, and make revocation visible when the workload or role changes.

Key takeaways

• Secretless AI agents change the security problem from protecting stored credentials to governing runtime retrieval through trusted identity.
• The article shows that MCP servers and AI workloads can avoid hardcoded keys, but that does not remove the need for scoped access, auditability, and revocation control.
• For IAM and NHI teams, the practical shift is to treat secret issuance as a governed access event rather than a background infrastructure detail.

Key terms

• Secretless Authentication: Secretless authentication is a pattern that keeps long-lived credentials out of application code and runtime memory wherever possible. Instead of exposing secrets directly to workloads, the access path mediates credential delivery at connection time, reducing the chance that stolen configuration or code reveals reusable access.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Runtime Secret Retrieval: Runtime secret retrieval is the practice of fetching credentials from a vault or controlled service only when they are needed. It reduces secret exposure in repositories and configs, but it only works when the retrieval path is scoped, logged, and tied to a specific workload or agent.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.

What's in the full article

Akeyless's full article covers the implementation detail this post intentionally leaves for the source:

• Step-by-step GitHub OIDC setup for secretless authentication in Akeyless
• AWS IAM trust policy flow for runtime secret retrieval from workloads
• Node.js MCP server example showing how the Gemini API key is fetched at execution time
• CLI token handling details for loading and using short-lived credentials

👉 The full Akeyless article includes the GitHub OIDC, AWS IAM, and MCP server implementation steps.

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 building or maturing an IAM programme, it is worth exploring.