TL;DR: Secretless AI agents replace hardcoded secrets with runtime retrieval through trusted identity, but Akeyless’s walkthrough also shows how much current AI infrastructure still depends on static assumptions about credential storage, access scope, and secret usage. The governance challenge is no longer just rotation; it is proving that identity, policy, and retrieval are aligned at the moment an MCP server or AI workload executes.
NHIMG editorial — based on content published by Akeyless: Secretless AI Agents and secure MCP server access
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Replace hardcoded secrets with runtime retrieval Move API keys, database URIs, and service tokens out of source code, environment files, and image layers.
- 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.
- Review MCP servers as access brokers Treat an MCP server as a privileged broker that can concentrate access to downstream models and secret stores.
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
👉 Read Akeyless's article on secretless AI agents and MCP server access →
Secretless AI agents and MCP servers: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Secretless AI agents expose the limits of static secret governance