Secretless AI agents expose the limits of static secret governance

At a glance

What this is: This article argues for secretless AI agent architectures that fetch credentials at runtime instead of storing API keys, tokens, or database secrets in code, config, or environment variables.

Why it matters: It matters because IAM, PAM, and NHI teams now need to govern runtime retrieval paths, OIDC trust, and workload identity as first-class access controls, not treat them as implementation details.

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.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read Akeyless's article on secretless AI agents and MCP server access

Context

Secretless AI agents are a workload identity pattern, not a new class of intelligence. The core idea is simple: the runtime proves who it is with trusted identity such as AWS IAM or GitHub OIDC, then retrieves secrets only when needed instead of storing long-lived credentials in code or environment variables. In the context of AI agent identity, that shifts the control point from secret distribution to runtime authorisation.

The security gap this article addresses is familiar to NHI and IAM practitioners. Static API keys, hardcoded tokens, and .env files create unnecessary exposure because they make credential presence persistent even when the workload only needs access momentarily. Secretless design reduces that exposure, but it also raises the bar for governance because every retrieval path now depends on correct identity proof, policy scoping, and auditability.

Key questions

Q: How should security teams handle exposed secrets in AI-driven environments?

A: Security teams should treat exposed secrets as active access paths and respond as though misuse can begin immediately. The right sequence is to identify the owning NHI, revoke the credential everywhere it is trusted, check downstream dependencies, and then validate whether the secret was copied into collaboration or CI systems.

Q: How do AI agents change secrets governance for IAM teams?

A: AI agents increase the number of identities that need access and the frequency with which credentials are used. That makes static secrets harder to govern because the same token may be exercised across many systems at machine speed. IAM teams should treat agents like workload identities, with scoped access and short lifetimes.

Q: What breaks when AI agents rely on long-lived API keys?

A: Long-lived keys turn a single leaked secret into persistent authority, and agents create more places for that secret to leak through prompts, logs, cache layers, and tool outputs. Once the key is reused across tasks, revocation becomes slow and unreliable. Short-lived credentials are safer because they reduce the window in which exposure can be exploited.

Q: What is the difference between secretless access and secrets rotation?

A: Secretless access prevents the secret from becoming a durable artefact in the first place, while rotation only replaces an already existing credential. Rotation is still useful, but it does not solve credential distribution across code, pipelines, and runtime components that should never have held the secret.

Technical breakdown

Runtime secret retrieval vs hardcoded credentials

Secretless architecture works by removing the credential from the application state and substituting a runtime request to a secret store. The workload authenticates with a trusted identity, such as an OIDC token or IAM role, and receives a short-lived secret only when policy allows it. That is materially different from embedding a key in code, where the secret exists before the workload proves anything. In MCP and AI-native systems, this distinction matters because the secret is not merely protected at rest. It is reissued in the flow of execution, which means the trust boundary moves from repository hygiene to identity proof and retrieval policy.

Practical implication: inventory every runtime that can request secrets and treat the request path as part of the access control design.

OIDC and cloud identity as the authentication layer for AI workloads

The article uses GitHub JWT and AWS IAM as examples of workload authentication. In both cases, the workload presents a verifiable identity token rather than a reusable password or static access key. That token binds the request to a workload, an execution context, and a trust relationship with the secret platform. This is a stronger pattern than static credential reuse because it allows access to be scoped by repository, role, instance profile, or environment. The security value comes from short-lived proof, not from the secret store alone.

Practical implication: align secret issuance with federated workload identity rather than allowing shared access keys to persist across pipelines and containers.

MCP servers and secretless AI agent access

An MCP server mediates natural-language requests to downstream tools and models, which makes it a high-value identity enforcement point. If the server stores API keys locally, it becomes a credential concentration point. If it retrieves them on demand, the server becomes an access broker governed by runtime policy. That improves containment, but only if the MCP server's own identity is tightly controlled. In practice, the architecture is secure only when the server, the secret vault, and the external AI API each have separate access boundaries and auditable trust relationships.

Practical implication: separate MCP execution identity from downstream secret authority and review both paths in the same access model.

Threat narrative

Attacker objective: The objective is to turn a single exposed credential into broader access across AI services, secret stores, and connected infrastructure.

1. Entry occurs when an attacker or malicious insider finds a hardcoded API key, static token, or exposed .env file in an AI workflow or MCP server.
2. Escalation happens when that credential is reused across model endpoints, secret stores, or cloud workloads without workload-bound proof of identity.
3. Impact follows when the compromised key is used to invoke AI services, retrieve additional secrets, or access backend systems beyond the original application boundary.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secretless design is strongest as a rejection of credential persistence, not as a vault feature. The article's value is in shifting the control objective from storing secrets safely to ensuring they never become durable artefacts in the first place. That aligns with OWASP-NHI thinking because the real problem is not only leakage, but the existence of reusable credentials in systems that execute continuously. Practitioners should treat runtime retrieval as an access model, not a convenience layer.

Runtime identity is the real trust anchor for AI-native workloads. When a GitHub JWT or AWS IAM role becomes the gate to downstream secrets, identity proof replaces secret reuse as the control boundary. That strengthens governance only if the authentication chain is auditable, environment-specific, and tightly scoped to one workload or pipeline. The practical conclusion is that secretless AI depends on rigorous NHI lifecycle governance, especially around identity federation and offboarding.

Secretless AI agents still inherit an identity blast radius if the runtime broker is over-permissioned. Moving the secret out of code does not remove privilege, it relocates it to the vault, the role, and the retrieval policy. If those controls are broad, the MCP server can still become a high-value pivot point. Teams should measure the blast radius of the broker itself, not just the absence of hardcoded keys.

Secret sprawl in AI workflows is now a lifecycle problem, not just a hygiene problem. The pattern in this article shows that modern workloads can avoid static secrets at the application layer while still creating trust debt through roles, claims mappings, and short-lived session issuance. That means IAM, PAM, and NHI governance have to converge on the same runtime facts. Security teams should build governance around who can request what, from where, and for how long.

Dynamic secret delivery does not eliminate the need for zero standing privilege thinking. The article implicitly points to a world where access should exist only at execution time and only long enough to complete the task. That is a better fit for AI-native infrastructure than persistent credentials because it reduces the replay window and the value of leaked artefacts. Practitioners should use this model to question any access path that remains valid outside a live workload session.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows that discovery without revocation leaves real attack surface intact.
• Guide to the Secret Sprawl Challenge provides the next step for teams trying to reduce credential persistence across pipelines and runtime systems.

What this signals

Identity blast radius: secretless architecture reduces exposure at the application layer, but the real governance question moves to the identity that brokers retrieval. If that broker can reach too many secrets or too many environments, the control problem simply relocates rather than disappears. Teams should model the blast radius of workload identity with the same seriousness they apply to privileged human access.

The broader signal is that AI-native infrastructure is converging on identity-driven access patterns whether governance teams are ready or not. That makes NHI lifecycle controls, policy scoping, and auditability central to AI operational risk, especially where MCP servers, CI/CD jobs, and cloud workloads all depend on the same trust fabric.

For practitioners

• Replace hardcoded secrets with runtime retrieval Move API keys, database URIs, and service tokens out of source code, environment files, and image layers. Require workloads to authenticate at execution time before any secret is issued, and make the retrieval step visible in audit logs.
• Bind secret access to workload identity Use federated identity such as OIDC or cloud IAM roles so that a pipeline, container, or instance proves who it is before receiving a secret. Scope each role to a single workload pattern and avoid shared tokens across repositories or environments.
• Review MCP servers as access brokers Treat an MCP server as a privileged broker that can concentrate access to downstream models and secret stores. Separate the server's own identity from the credential authority it queries, and verify that each retrieval is logged and policy-bound.
• Map and retire long-lived credential paths Identify any workflow that still depends on static tokens, reusable API keys, or persistent session material. Replace those paths first in AI pipelines, then in surrounding build and deployment systems where secret reuse can quietly persist.

Key takeaways

• Secretless AI reduces the persistence of credentials, but it does not remove the need to govern the identity that requests them.
• MCP servers and AI pipelines become higher-risk when they broker access without tightly scoped workload identity and audit trails.
• The decisive control is no longer just rotation. It is proving that runtime identity, retrieval policy, and offboarding all align across the full credential lifecycle.

Key terms

• Secretless architecture: A secretless architecture is a model where applications and workloads authenticate with identity instead of handling reusable credentials directly. The secret may still exist in the system, but it is issued, used, and revoked behind the scenes so the workload never sees it.
• 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.
• 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.

What's in the full article

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

• Step-by-step GitHub OIDC configuration for secretless authentication in an AI workflow
• AWS IAM trust policy and role setup examples for workload-based secret retrieval
• Node.js implementation details showing runtime token loading and secret fetching
• CLI and MCP server test workflow for validating secretless access end to end

👉 The full Akeyless post covers the runtime auth flow, code sample, and MCP integration steps in detail.

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.