AI agent credentials need runtime governance, not embedded secrets

At a glance

What this is: This is an analysis of how AI agent access breaks traditional IAM assumptions when credentials, secrets, and service-level permissions must be governed at runtime.

Why it matters: It matters because IAM, PAM, and NHI programmes need to control agent access to enterprise systems without losing visibility, auditability, or revocation discipline.

👉 Read 1Password's analysis of secure AI agent access and runtime secrets control

Context

AI agent identity risk starts where traditional IAM stops. Human login controls do not automatically extend to shared credentials, API keys, tokens, and service-level access paths used by agents inside workflows. When those secrets sit in code, configuration files, or internal tools, the organisation loses the point-of-use control it needs for governance.

The practical problem is not that agents need fewer permissions, but that they can reuse the same credential repeatedly across workflows and downstream tools. That creates a governance gap across NHI and emerging agentic AI programmes, because access is no longer tied cleanly to a single person, session, or review cycle.

Key questions

Q: How should security teams govern AI agent credentials in enterprise workflows?

A: Security teams should store agent credentials centrally, retrieve them at runtime, and enforce policy at the point where the agent interacts with each system. That approach reduces secret sprawl and gives IAM, PAM, and NHI teams a control surface they can audit, scope, and revoke. The key is to manage reuse and propagation, not just initial issuance.

Q: Why do AI agents create more risk than normal service accounts?

A: AI agents can reuse the same credential across multiple tools and workflows, which makes the access path harder to scope and revoke than a typical service account session. If the secret is embedded in code or a configuration file, the organisation loses visibility into where it moves and whether it is still governed at the point of use.

Q: What breaks when credentials are embedded in agent configurations?

A: Embedded credentials break point-of-use governance. The secret can be invoked repeatedly, passed downstream into other tools, and remain active long after the original workflow changes. That makes revocation slower, audit trails weaker, and access reviews less meaningful because the control is attached to storage, not actual use.

Q: How do organisations know if agent access governance is working?

A: Governance is working if teams can answer three questions quickly: which agent used which credential, where that credential was used, and whether policy constrained the interaction consistently across systems. If those answers require manual reconstruction, the programme still depends too heavily on scattered secrets and weak runtime visibility.

Technical breakdown

Shared credentials and runtime retrieval for AI agents

AI agents often operate through the same enterprise systems as employees, but they do so through shared passwords, API keys, tokens, and service accounts. The technical failure mode appears when those secrets are embedded in code or configuration rather than held in a centrally governed store. Runtime retrieval changes the mechanics: the agent does not own a secret at rest, it receives access context only when the workflow needs it. That reduces secret sprawl, but the governance value depends on whether the retrieval point, usage policy, and audit trail are all enforced together.

Practical implication: Keep agent credentials out of code and require runtime retrieval from a centralized secret store.

Why traditional IAM stops at the login boundary

Traditional IAM is built to authenticate a human and then hand off to a session that is easy to attribute. AI agents break that model because the sensitive action happens after login, often across multiple systems and tools. If the credential is reusable, the organisation may not know what used it, when it was reused, or whether downstream tools propagated it further. That makes the credential itself the control plane, which is a weak position unless secrets governance, policy enforcement, and auditability are linked.

Practical implication: Extend governance beyond authentication to cover credential reuse, propagation, and revocation.

Policy-gated agent access across enterprise systems

The important architectural shift is not just storing secrets centrally, but brokering how an agent exercises that access. Policy controls can restrict an agent to read-only database access, block write operations, limit query rates, or scope permissions by agent or user group. That turns the access path into a governed decision point instead of a hardcoded entitlement. In NHI terms, the issue is not simply possession of a secret, but how the system constrains its use over time and across tools.

Practical implication: Treat agent permissions as policy-driven access paths, not static credentials with broad reuse.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

AI agent access exposes the failure of credential-centric IAM. Traditional access models assume the sensitive identity event happens at login, then the rest is a governed session. That assumption fails when the actor is an agent that retrieves and reuses secrets at runtime across multiple tools, systems, and workflows. The implication is that credential governance now has to account for continuous use, propagation, and revocation, not just initial authentication.

Secret sprawl becomes an agent governance problem the moment runtime execution is allowed. When credentials live in code, configuration files, or internal tools, the organisation no longer controls the point of use. That is not just an operational inconvenience, it is a structural loss of accountability because the same secret can be invoked repeatedly and passed downstream. Practitioners should read this as a sign that NHI governance has moved from storage hygiene to runtime control.

Policy-based agent access is the right direction, but only if policy remains the primary control surface. Read-only database access, write blocking, query limits, and scope-by-user-group controls are meaningful only when they are enforced where the agent acts. A named concept here is runtime credential governance: the discipline of controlling agent access at the moment of use instead of assuming pre-provisioned secrets are sufficient. Teams should treat this as a governance architecture shift, not a feature checklist.

Interoperability now matters as much as secret protection. As agents spread across workflows, the control problem is no longer one vault or one tool, but whether identity, credential storage, policy, and auditability can work together across platforms. That aligns with the direction of OWASP-NHI and Zero Trust thinking, where access is continuously constrained rather than merely issued. Practitioners should expect agent access programmes to fail if control ownership is fragmented across too many systems.

AI agent governance is converging with NHI governance, but the consequences are sharper because the access path is executable. An NHI secret that is merely stored is a risk; an NHI secret that an agent can actively broker, reuse, and pass into downstream systems is a governed execution path. That means IAM, PAM, and NHI teams need to evaluate whether their current programme can describe who or what is using a secret at runtime. If not, the programme is already behind the actor model.

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 Guide to the Secret Sprawl Challenge.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• That pattern is why runtime control matters more than storage alone, as explored in OWASP NHI Top 10.

What this signals

Runtime credential governance is becoming the practical boundary between usable AI agents and unmanaged secret exposure. As more workflows depend on machine-held credentials, teams should expect their existing access review cadences to miss the real risk unless they can trace use at the moment of execution.

The broader signal is that NHI programmes are moving from vault-centric thinking to action-centric governance. If an organisation cannot distinguish stored access from exercised access, the agent will keep operating in a space where identity controls exist on paper but not at runtime.

For practitioners

• Move agent credentials into centralized secret storage Keep shared passwords, API keys, and tokens out of code and configuration files, and require runtime retrieval from a controlled vault before the agent can use them.
• Broaden governance beyond initial login Map where an agent can reuse the same secret across workflows, downstream tools, and service-level access paths, then define revocation and audit requirements for each path.
• Apply policy at the agent interaction point Set read-only, write-blocking, query-rate, and scope-by-group rules where the agent actually reaches the target system, rather than relying on static entitlement design alone.
• Review auditability for propagated credentials Verify that logs can show which agent used which credential, at what runtime context, and whether that secret was passed into another tool or system.
• Use NHI governance as the operating model Align agent credential handling with your NHI governance programme so that storage, rotation, revocation, and access review are managed as one lifecycle.

Key takeaways

• AI agents expose the limits of login-centric IAM because the sensitive action often happens after authentication, through reusable secrets and service-level access paths.
• The governance risk is measurable: once secrets are embedded in code or agent configurations, organisations lose visibility into reuse, propagation, and revocation.
• Practitioners should shift to centralized runtime retrieval, policy enforcement at the interaction point, and auditability that shows which agent used which credential.

Key terms

• Runtime Credential Governance: Runtime credential governance is the practice of controlling secrets at the moment an identity uses them, rather than only when they are created or stored. For AI agents and other NHIs, this means retrieval, scope, and revocation are enforced during execution, when misuse actually occurs.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials, tokens, API keys, and certificates across code, configuration files, chat, and internal tools. It weakens accountability because the same secret can be copied, reused, and forgotten faster than teams can review or revoke it.
• Agent Access Broker: An agent access broker is a control layer that mediates how an AI agent reaches a target system and what it is allowed to do once connected. In practice, it sits between the agent and the service so policy can be applied before access is exercised.

Deepen your knowledge

AI agent credential governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to move from embedded secrets to runtime control, it is a strong fit for your programme design.

This post draws on content published by 1Password: secure AI agent access with Natoma and 1Password. Read the original.