Shadow AI agents and credential access: what changes for IAM

At a glance

What this is: Bitwarden’s analysis argues that shadow AI agents create credential access risk that traditional password-centric controls do not cover.

Why it matters: IAM and security teams need to treat agent credential access as a governance problem across NHI, autonomous systems, and human approval workflows, not just a secrets-management problem.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Bitwarden's analysis of shadow AI agents and credential access

Context

Shadow AI agents are software systems that can act on behalf of a user or workflow and request credentials or tokens as they move through tasks. The governance gap is that many enterprises still manage those credentials as if the requester were a predictable application, even when the runtime behaviour is more dynamic.

For IAM, PAM, and NHI teams, the issue is not simply secret storage. It is who or what can request access, how long that access lasts, how approval is enforced, and whether the organisation can trace agent activity back to accountable ownership.

Key questions

Q: How should security teams govern credential access for AI agents?

A: Treat agent credential access as a distinct identity path with its own ownership, approval, and revocation rules. Use task-scoped access, separate identities, and audit logging so the organisation can see who approved the request, what the agent received, and when access ended. That is the minimum control set for reducing shadow AI risk.

Q: Why do AI agents complicate traditional NHI controls?

A: Because traditional NHI controls usually assume the access need is known when the identity is provisioned. AI agents can change their action path at runtime, so the scope of access may expand or shift after approval. That makes provisioning-time least privilege incomplete unless it is reinforced by runtime policy and revocation.

Q: What do teams get wrong about just-in-time access for agents?

A: They often assume that temporary access automatically means safe access. In practice, a short-lived credential can still be too broad if it spans multiple systems or survives beyond the task it was meant to support. The real question is whether the credential dies with the workflow, not whether it expires eventually.

Q: Who should be accountable when an AI agent misuses a credential?

A: Accountability should sit with the team that owns the agent workflow, the identity provider, and the approving business owner, because all three influence the access path. A good control model records who authorised the grant, who operated the identity, and who can revoke it before further damage occurs.

Technical breakdown

Why shadow AI agents create a new credential access model

Shadow AI agents change the access pattern because the identity consuming credentials is often created or activated outside standard procurement and onboarding controls. In practice, the agent may inherit human credentials, service account tokens, or API keys and then use them across multiple tools and data sources. That breaks the assumption that credentials map cleanly to a single workload or a stable operator. Once an agent can select actions at runtime, credential exposure is no longer just a storage problem. It becomes a control problem across authentication, authorisation, and session governance.

Practical implication: treat agent credential access as a governed identity path, not as a normal application secret.

Just-in-time access for agents versus standing secrets

Just-in-time access reduces standing privilege by issuing access only when a task requires it, but it does not automatically solve agent trust. The architectural point is that the access grant still needs a policy decision, scope limits, and a revocation path that matches the agent’s runtime behaviour. If the credential can outlive the task, or if the agent can reuse it across unrelated steps, the environment still has persistent privilege in a different form. The control objective is to collapse the usable window of access as tightly as possible around the intended action.

Practical implication: define task-scoped access boundaries and revoke credentials at the end of each bounded agent action.

Human-in-the-loop approvals and end-to-end encryption

Human-in-the-loop approval adds a control point, but it is only effective when the approver understands the scope of the request and the downstream systems the agent may touch. End-to-end encryption protects credential material in transit and at rest, but it does not replace authorisation discipline. Both controls work best when paired with clear ownership, monitoring, and logging that preserve auditability across the agent lifecycle. In other words, the architecture needs both trust minimisation and decision visibility, not one control dressed up as the other.

Practical implication: require approval, encryption, and logging together, then verify that each applies to the full agent workflow.

Threat narrative

Attacker objective: The objective is to turn one agent foothold into broad credential reach that can be reused across systems without tight governance.

1. Entry occurs when a shadow AI agent is introduced into the environment and receives credential access through an informal or partially governed workflow.
2. Escalation occurs when the agent reuses tokens, secrets, or delegated permissions across tasks and tools that were never intended to share the same trust boundary.
3. Impact occurs when that broadened access exposes sensitive systems, data, or downstream identities to actions that were not explicitly authorised.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Shadow AI agent credential access is an identity governance problem before it is an AI problem. The article’s core signal is that credentials given to agents create a governance path that existing application and human IAM models do not fully describe. When access can be requested, reused, and chained by software operating outside traditional approval rhythms, the organisation needs identity controls that follow the actor, not just the application.

Standing secret assumptions break down when the requester can change behaviour at runtime. Static NHI governance assumes the consuming identity and the required access path are knowable at provisioning time. That assumption fails when an AI agent can choose different tools and steps during execution because least privilege is no longer a fixed assignment. The implication is that practitioners must rethink whether provisioning-time access rules can describe runtime agent behaviour at all.

Ephemeral credential trust debt: task-scoped access still creates risk if approval, scope, and revocation are not tied to the full agent workflow. A credential can be short-lived and still overbroad if it is reused across multiple data sources or tools. The field needs to stop treating temporary access as inherently safe and instead measure whether the access path actually ends when the task ends.

The governance boundary now spans human approval, NHI controls, and autonomous execution. A human may authorise the request, an NHI may carry the token, and an agent may decide how to use it. That chain means accountability must be explicit across ownership, revocation, and telemetry. Practitioners should treat this as a cross-domain identity control problem, not a single-product problem.

Agent access patterns will push IAM programmes toward policy that understands intent, not just identity. Traditional identity tools can tell you who authenticated, but they are weaker at describing what an agent was meant to accomplish within the session. That gap is where shadow AI behaviour becomes operationally dangerous. Security teams should expect identity governance to move toward task context, approval provenance, and execution traceability.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• That visibility gap is one reason to review NIST Cybersecurity Framework 2.0 alongside identity lifecycle controls for agent access.

What this signals

Ephemeral access does not remove governance debt if the organisation cannot see every service and agent identity that can request it. The visibility problem matters because the control plane must know where credentials live before it can constrain them. With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the practical task is to shrink privileged paths before agent adoption widens them further.

A useful programme concept here is agent access provenance: the organisation should be able to trace where the request came from, who approved it, what was issued, and when it was revoked. Without that chain, incident review becomes guesswork and access reviews become ceremonial.

Teams that already align identity controls to NIST Cybersecurity Framework 2.0 should use this moment to test whether AI agent workflows are visible in protect, detect, and respond operations. If agents can obtain credentials without leaving a reliable audit trail, the identity programme is not ready for scale.

For practitioners

• Inventory agent credential paths Map every place an AI agent can obtain secrets, tokens, or delegated access, including developer tooling, shared vaults, and pipeline integrations. Classify each path by owner, approval method, and revocation point so you can see where shadow access already exists.
• Bind access to a task scope Issue credentials only for the smallest operational unit the agent needs, and prevent reuse across unrelated tools or sessions. Where possible, pair the grant with explicit expiry and a single approved workflow so access cannot drift beyond the intended action.
• Require approval and logging together Do not treat human approval as sufficient unless the same workflow also records the request, the decision, and the resulting actions. This gives IAM and audit teams a traceable chain from authorisation to execution and supports later review of abnormal agent behaviour.
• Separate agent secrets from human credentials Avoid reusing employee passwords, shared admin tokens, or broad service account access for agent workflows. Use distinct identities and monitored secret issuance so the organisation can revoke agent access without disrupting human access paths.

Key takeaways

• Shadow AI agents turn credential access into a governance issue, because the identity using the secret may be dynamic and hard to inventory.
• Temporary access is not inherently safe if approvals, scope limits, and revocation do not match the full agent workflow.
• IAM teams should separate agent identities from human credentials and insist on task-scoped controls, auditability, and explicit ownership.

Key terms

• Shadow AI: Undiscovered or unmanaged AI agents operating inside an environment without formal approval, inventory, or oversight. In identity terms, shadow AI is dangerous because the organisation cannot reliably answer who owns the agent, what credentials it can reach, or how to revoke its access when behaviour changes.
• Task-scoped access: Access that is issued for a single defined job or workflow and removed when that job ends. For agents and workloads, task-scoped access is only effective when the scope, approval, and revocation points are tied to the actual execution path, not just to a token expiry timer.
• Agent access provenance: The traceable record of where an agent access request came from, who approved it, what identity or secret was issued, and when it was revoked. This is the evidence chain that allows identity teams to investigate misuse and prove whether access stayed inside its intended boundary.
• Standing privilege: Persistent access that remains available without needing a fresh approval each time it is used. In non-human and agent contexts, standing privilege widens the blast radius because the identity can reuse access across tasks, tools, or sessions long after the original need has passed.

What's in the full article

Bitwarden's full blog covers the operational detail this post intentionally leaves for the source:

• The three credential security risks the vendor says come with AI agent adoption, with implementation context for each one.
• The Agent Access SDK workflow and how it is positioned to support least-privilege access patterns for agents.
• Practical examples of just-in-time permissions and human-in-the-loop approval flow for agent credential requests.
• The vendor’s explanation of how end-to-end encryption fits into agent credential access governance.

👉 The full Bitwarden blog covers the Agent Access SDK and the credential security risks behind agent adoption.

Deepen your knowledge

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