Topic starter
17/08/2026 4:38 pm
TL;DR: Akeyless shows that secretless AI agents and MCP servers can retrieve API keys at runtime through trusted identity instead of storing them in code, but the article also exposes how much current AI infrastructure still assumes static credential storage and manual rotation. Static secret governance breaks when access is issued just in time and consumed inside the execution path, not managed as a persistent artefact.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Architecting Secretless AI Agents: Akeyless in Action”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Secretless AI agents change the security problem from protecting stored credentials to governing runtime retrieval through trusted identity.
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
👉 Read Akeyless's walkthrough of secretless AI agents and MCP server access →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
17/08/2026 4:44 pm
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.
A few things that frame the scale:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
A question worth separating out:
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.
👉 Read our full editorial: Secretless AI agents expose the limits of static secret governance