Should organisations allow AI agents to use hardcoded secrets?

No. Hardcoded secrets should be treated as an architectural bug, not a temporary shortcut. They spread into code, logs, prompts, and chat histories, and they are difficult to discover or revoke once exposed. A mature programme should replace them with managed, short-lived identity wherever possible.

Why Hardcoded Secrets Fail for Autonomous AI Agents

Hardcoded secrets are especially dangerous in agentic environments because an AI agent does not behave like a fixed application path. It can call tools, chain actions, retry tasks, and expose credentials in logs, prompts, memory, or downstream systems. That makes a static secret both overpowered and undercontained. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework points toward runtime controls, not embedded secrets, because intent and context change from one action to the next.

GitGuardian’s State of Secrets Sprawl 2026 found that AI-related credential leaks surged 81.5% year over year in 2025, which is a strong signal that agentic systems amplify an old problem rather than solve it. The right question is not whether an agent needs access, but whether that access should exist only for the exact task, time, and context required. In practice, many security teams encounter hardcoded agent secrets only after a prompt leak, a build log exposure, or a lateral-movement incident has already occurred.

How It Works in Practice

The practical alternative is to give the agent a workload identity, then broker access just in time. That usually means short-lived tokens or ephemeral secrets issued for a single task, with automatic expiration and revocation when the task completes. For agentic systems, best practice is evolving toward intent-based authorisation, where the policy engine evaluates what the agent is trying to do at request time rather than trusting a static role assigned weeks earlier. The OWASP Non-Human Identity Top 10 and OWASP Top 10 for Agentic Applications 2026 both reinforce the need for identity-centric controls instead of credential stuffing.

In a mature design, the agent authenticates as an NHI, the platform mints a scoped credential, and the policy layer checks the request against workload identity, data sensitivity, tool risk, and session state. That approach aligns with zero standing privilege and with runtime policy evaluation using tools such as OPA or Cedar. A typical implementation includes:

• OIDC, SPIFFE/SPIRE, or equivalent workload identity for the agent process.
• JIT issuance of credentials with a very short TTL and automatic revocation.
• Secret brokers or vaults that return only task-scoped access, never reusable static keys.
• Policy-as-code that evaluates each tool call in context, not just at login.

NHIMG has repeatedly shown why this matters in real incidents, including the Moltbook AI agent keys breach and the Analysis of Claude Code Security, where exposure often came from broad access, not a single broken control. These controls tend to break down when agents are allowed to write to shared collaboration tools or long-lived CI/CD runners because secrets then persist beyond the task boundary.

Common Variations and Edge Cases

Tighter secret controls often increase orchestration overhead, so organisations have to balance developer convenience against containment. There is no universal standard for every agent pattern yet, especially for multi-agent workflows, delegated tool use, and MCP-connected environments. For low-risk read-only agents, some teams accept ephemeral API tokens with narrow scopes; for write-capable or internet-facing agents, the bar should be much higher and closer to ZTA, with per-action policy checks and immediate revocation. NHIMG research on the Guide to the Secret Sprawl Challenge shows why static secrets keep leaking into places that security teams do not monitor.

Edge cases usually appear where infrastructure is shared or automated at scale. CI/CD runners, prompt templates, collaboration tools, and MCP configuration files can all become secret carriers if teams try to “just make it work” with embedded keys. GitGuardian reported 24,008 unique secrets exposed in MCP configuration files in 2025 alone, which is a useful reminder that new agent interfaces create new leakage paths before governance catches up. The safest default is simple: do not hardcode, do not reuse, and do not let a secret outlive the exact action it authorises. Where an exception is temporarily unavoidable, document the business need, constrain the scope, and time-box the exception aggressively.

Related resources from NHI Mgmt Group

• What is the difference between managed identities and hardcoded secrets for AI agents?
• How can organisations govern AI agents that use service accounts and tokens?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• Why do secrets create disproportionate risk in NHI environments?