AI agent credentials need runtime governance, not embedded secrets

At a glance

What this is: This is a 1Password article arguing that AI agent access should be governed at runtime, not embedded in code or configuration, because shared credentials and secrets are otherwise difficult to control.

Why it matters: It matters to IAM and NHI teams because agent access now sits in the same control plane as human and machine access, but traditional login-centric IAM does not govern runtime secret use well enough.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.

Context

AI agent credentials are shared secrets, tokens, API keys, and passwords that let a non-human system reach databases, APIs, SaaS tools, and internal infrastructure. The governance problem is not simple connectivity. It is whether those credentials are controlled at the moment an agent uses them, rather than buried in code, configuration files, or workflow glue.

Traditional IAM was built to secure human access at login, then hand off ongoing access to downstream systems. That model does not govern repeated secret use, service-level access paths, or the way an agent can reuse the same credential across workflows. For AI agent programmes, the control question shifts from who signs in to how runtime access is issued, observed, and revoked.

Once credentials are embedded into agent logic, security teams lose the ability to distinguish legitimate use from uncontrolled reuse. That is why runtime governance has become the practical boundary between scalable agent deployment and secret sprawl.

Key questions

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: Why do monolithic AI agents create higher credential risk?

A: Monolithic agents combine reasoning, execution and credential storage in one process, so a compromise in one part can expose the rest. That increases the chance that prompt injection or execution abuse turns directly into credential theft or unauthorised service access.

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: What should teams do when an AI agent credential is no longer needed?

A: Revoke the secret at the source and remove any downstream references that allow the agent to keep using it. If the same credential remains valid across multiple tools or workflows, the access model has turned into secret sprawl and should be redesigned.

Technical breakdown

Why embedded secrets break runtime governance

Embedded secrets create an unmanaged trust path between the agent and the target system. If a password, API key, or token sits in code or configuration, the secret becomes part of the workflow itself rather than a governed access decision. That means the credential can be copied, reused, passed to downstream tools, or left behind after the original use case changes. In practice, the security problem is not only exposure but also loss of control over where the secret is exercised. Runtime governance keeps the credential outside the static workflow so access can be mediated when the agent actually needs it.

Practical implication: Treat any credential stored in code or configuration as an unmanaged access path, not a governed control.

How runtime retrieval changes the control point

Runtime retrieval moves the security decision from deployment time to use time. The credential remains centrally stored, while the agent receives access only when a broker or policy layer authorises the request. That matters because the access can be scoped to the specific task, system, or session rather than assumed to be persistently valid. This is especially important for AI agents, which may invoke the same tool repeatedly across a workflow and create access reuse that human IAM never had to model. The runtime model does not remove privilege. It relocates the decision point so access can be managed with greater precision.

Practical implication: Issue secrets through a runtime broker so each agent interaction is mediated at the point of use.

Why service-level access paths need policy, not just authentication

AI agents often operate through service accounts, tokens, or other non-human credentials that authenticate the workload rather than the person behind it. Authentication alone does not say what the agent may do after entry. Policy must govern read-only access, write restrictions, table scope, query limits, and similar constraints that shape behaviour inside the target system. Without that layer, a valid credential can still be overbroad or reused beyond the intended purpose. For AI agents, the relevant control is therefore both identity and authorisation at runtime, with the broker enforcing how the access is exercised.

Practical implication: Pair machine authentication with explicit runtime policy that limits what each agent credential can do.

Threat narrative

Attacker objective: The objective is persistent, hard-to-audit access to enterprise systems through credentials that outlive the intended workflow.

1. Entry occurs when an AI agent is provisioned with shared secrets, API keys, or tokens that were embedded in code or configuration.
2. Escalation happens when the agent reuses the same credential across multiple workflows or hands it to downstream tools beyond the original scope.
3. Impact follows when lingering access cannot be cleanly scoped, monitored, or revoked, leaving sensitive enterprise systems exposed to uncontrolled runtime use.

Breaches seen in the wild

• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime governance is the real control plane for AI agent access: AI agents do not fit a login-only IAM model because their access is exercised inside workflows, not just at session start. When credentials are embedded in code or configuration, governance shifts from policy to residue. The practitioner takeaway is that control has to exist where the secret is used, not where the agent was deployed.

Embedded secrets create access that is technically valid but operationally ungoverned: A shared API key or token can still authenticate successfully while escaping visibility, scoping, and revocation discipline. That is a governance failure, not just a hygiene issue. The field should treat runtime retrieval and brokered use as the minimum condition for governable AI agent access.

Access review assumptions break when agents reuse credentials continuously: Access review processes were designed for access that persists long enough to be observed and certified. AI agents that fetch and exercise credentials inside task execution make that assumption unreliable, because the access may be created, used, and discarded inside a single workflow. The implication is that review must move toward issuance and policy enforcement, not retrospective certification alone.

Secret sprawl becomes identity sprawl when AI agents scale across systems: Each additional database, SaaS tool, or internal service connection increases the number of credential paths that must be governed. That is why runtime control, auditability, and scoped authorisation matter more than simple connectivity. Practitioners should expect agent programmes to stress the same NHI controls that already struggle with service accounts and API keys.

Ephemeral credential trust debt: The article points to a growing mismatch between how quickly AI agents are adopted and how slowly credential governance adapts. Teams borrow old assumptions about static access, but agent workflows produce repeated, machine-paced secret use. The practical conclusion is to reframe agent access as a governed lifecycle, not a one-time integration.

From our research library:

• 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
• Read next: AI Agent Authorisation Guide

What this signals

Runtime access governance is now the dividing line for AI agent programmes: teams that keep credentials in static files will struggle to explain who or what used them, because the access path is no longer bounded by the deployment boundary. Moving secret retrieval to runtime makes the control observable enough to audit and revoke.

Secret sprawl becomes a lifecycle problem, not just a storage problem: once an agent can touch databases, APIs, and SaaS tools, every additional integration multiplies the number of credentials that must be issued, monitored, and retired. That means agent governance has to absorb NHI lifecycle discipline, not just IAM integration.

For practitioners

• Centralise AI agent secrets Keep passwords, API keys, and tokens in a controlled vault rather than embedding them in code, configuration files, or internal tools.
• Broker runtime secret retrieval Require a runtime access layer to retrieve or reference credentials only when an agent needs them, so the secret is not persistently exposed to the workflow.
• Scope agent permissions by task Limit each agent to read-only access, specific tables, or constrained write actions so the credential cannot exceed the workflow it was issued for.
• Track repeated credential use Monitor when the same credential is invoked across multiple workflows or services, because reuse is the signal that static storage is creating governance debt.
• Separate human approval from machine execution Define where human approval ends and agent execution begins so access policy can be enforced consistently across service-level access paths.

Key takeaways

• AI agent access becomes hard to govern when passwords, API keys, and tokens are embedded in code or configuration instead of being managed at runtime.
• The article’s core message is that centralised secret storage plus runtime brokering creates a controllable access path for agents.
• For practitioners, the immediate issue is not connectivity but whether agent credentials can be observed, scoped, and revoked consistently across workflows.

Key terms

• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
• Embedded Secret: An embedded secret is a credential, token, API key, or certificate that has been placed inside an image, file, or configuration bundle. Once exposed, it can outlive the original control that created it, so revocation and rebuilds become necessary even if the underlying system is later patched.
• Context Retrieval: Context retrieval is the process of supplying an AI system with the files, records, or project state it needs to act effectively. It becomes an identity concern when retrieval scope shapes what the agent can decide, access, and change, making data exposure part of the authorization boundary.
• Service-Level Access Path: A service-level access path is a machine-to-machine route that allows an application, workload, or AI agent to reach a target system using non-human credentials. These paths are usually authenticated by shared secrets or tokens, so they need lifecycle and authorisation controls, not just login controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.