What breaks when agents rely on shared credentials or borrowed user identities?

Why This Matters for Security Teams

Shared credentials and borrowed user identities create a control failure that is easy to miss during normal operations: authentication still works, but the organisation loses the ability to tie actions to a specific non-human actor. That breaks audit trails, weakens approvals, and makes incident response far slower because investigators cannot distinguish legitimate automation from misuse. It also undermines segmentation, because a borrowed human identity inherits access patterns that were never designed for autonomous execution.

This is exactly why NHI governance treats workload identity as the primitive, not convenience logins or shared service accounts. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST AI Risk Management Framework both point toward explicit accountability, least privilege, and identity separation for machine actors. NHIMG’s research shows the maturity gap is still wide: 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM, which helps explain why shared secrets persist even in teams that know better.

In practice, many security teams discover the blast radius of shared identities only after an investigation cannot prove who actually used the account, rather than through intentional identity design.

How It Works in Practice

The cleanest model is to stop treating agents like human users and instead issue them workload identities with tightly scoped, short-lived credentials. That means each agent, service, or pipeline gets its own cryptographic identity, such as an OIDC-backed token or a SPIFFE/SPIRE workload identity, and access is evaluated at request time based on task context, not a standing role. For agentic systems, this is where static IAM fails: an agent can chain tools, call APIs in new orders, and expand its own effective reach in ways a fixed role never anticipated.

Best practice is evolving toward just-in-time credential issuance, ephemeral secrets, and policy-as-code enforcement. A policy engine can decide whether a given action is allowed based on the agent’s identity, target resource, environment, and current task. That is the practical difference between “the account is permitted” and “this specific action is permitted right now.” It also supports faster revocation when a task ends or an anomaly appears.

• Issue one identity per agent or workload, not one shared account across a fleet.
• Use short TTLs and auto-revocation for tokens, certificates, and API keys.
• Bind access decisions to runtime context, not only to a pre-set RBAC role.
• Log the workload identity, task context, and policy decision for every privileged action.

NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because it explains why dynamic secrets reduce exposure windows compared with long-lived shared material. The implementation lesson is simple: when an agent can act autonomously, identity and privilege must be as short-lived and attributable as the action itself. These controls tend to break down in legacy job schedulers, shared CI runners, and environments that still depend on a single service account for many different automations because the resulting identity collision destroys attribution.

Common Variations and Edge Cases

Tighter identity separation often increases operational overhead, requiring organisations to balance stronger attribution against deployment complexity and token management burden. That tradeoff becomes sharper in multi-tenant platforms, batch systems, and older automation stacks where per-task identity issuance was never designed into the workflow.

There is no universal standard for every agent pattern yet. Some environments can support strict workload identity from day one, while others need a transitional model that replaces only the most privileged shared accounts first. Guidance from CSA MAESTRO agentic AI threat modeling framework and the OWASP Agentic AI Top 10 suggests that shared credentials are especially risky when tools can be chained, prompts can steer behaviour, or agents can reach across trust boundaries without human confirmation.

Borrowed user identities also create governance ambiguity. A human account may be acceptable for attended workflows, but once autonomous execution is introduced, that same account can mask which tool, agent, or process actually initiated the action. In those cases, current guidance suggests moving to dedicated non-human identities rather than extending human entitlements to software. The strongest warning signs are reused admin accounts, opaque service ownership, and any environment where recertification depends on remembering which person “covers” which bot.

Related resources from NHI Mgmt Group

• What breaks when agents use long-lived API keys or shared credentials?
• What breaks when AI agents are connected through personal accounts or shared credentials?
• What breaks when AI agents rely on shared service accounts or API keys?
• What breaks when user access reviews are the main identity control?