Why do borrowed sessions and shared service accounts create agent security risk?

Because they destroy identity boundaries. When multiple agents or users share one credential, you lose the ability to answer who acted, what was allowed, and how to revoke one actor without breaking others. That makes incident response and access governance much harder, especially when the agent can call external tools.

Why This Matters for Security Teams

Borrowed sessions and shared service accounts are dangerous because they erase the boundary between an identity and a task. Once an agent can reuse a session or operate under a common account, security teams lose reliable attribution, cannot scope privilege to one workflow, and struggle to revoke access without collateral impact. That is especially risky for autonomous systems that can chain tools, pivot across APIs, and act faster than manual review can keep up.

This is why the problem shows up so often in agentic environments discussed in the OWASP NHI Top 10 and the NIST AI Risk Management Framework: the session, not just the account, becomes the security boundary. NHIMG research has also shown that 72% of organisations have experienced or suspect a breach of non-human identities, which underscores how often identity reuse becomes an operational failure rather than a theoretical concern. In practice, many security teams encounter the blast radius only after an investigation reveals one shared credential was used across multiple agents, environments, and toolchains.

How It Works in Practice

Security teams should treat each agent, workload, or automation path as a distinct non-human identity, even when the underlying software is similar. A borrowed session is risky because it lets one actor inherit another actor’s authenticated context, including whatever scopes, claims, and approvals were attached to that session at the time. A shared service account is equally problematic because it turns access governance into guesswork: there is no clean mapping from action to actor, and no safe way to revoke one participant without breaking the rest.

For agentic systems, current guidance suggests shifting from static, shared credentials toward short-lived, task-bound access. That usually means:

• Issuing just-in-time credentials per workflow, then revoking them automatically when the task ends.
• Using workload identity as the primary identity primitive, so the system proves what it is rather than relying on a reused login.
• Evaluating policy at request time, not only at provisioning time, so the authorization decision can reflect the agent’s intent, destination tool, and current risk context.
• Segmenting access by tool and environment so a compromise in one path does not inherit trust across all paths.

That pattern aligns with the agent-focused threat models in CSA MAESTRO agentic AI threat modeling framework and the control emphasis in NHIMG’s OWASP Agentic Applications Top 10, where identity reuse is treated as an exposure multiplier. These controls tend to break down in legacy batch jobs, long-running integrations, and vendor-managed automations because the systems were built to preserve continuity, not to terminate access cleanly after each task.

Common Variations and Edge Cases

Tighter session control often increases operational overhead, requiring organisations to balance containment against throughput, debugging, and service continuity. That tradeoff becomes visible when an agent needs repeated access to the same API, when a workflow spans multiple microservices, or when human operators temporarily “borrow” an agent session during troubleshooting.

There is no universal standard for this yet, but best practice is evolving toward ephemeral delegation rather than shared standing access. A short maintenance window may justify a controlled break-glass process, but it should be time-bound, logged, and separately approved. Likewise, some legacy platforms still require shared technical accounts; in those cases, the compensating control is aggressive rotation, scoped network placement, and strong logging around every use.

NHIMG’s analysis of agentic risks shows why this matters in real deployments: identity misuse often travels alongside tooling misuse, not separately. For examples of how shared access and weak boundaries become breach multipliers, see Moltbook AI agent keys breach and the broader patterns in Top 10 NHI Issues. Shared sessions can still be tolerated in isolated lab environments, but they are a poor fit for production agents that touch customer data, external tools, or privileged administration paths.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• When do service accounts become a higher risk than ordinary user accounts?
• How should security teams govern Active Directory service accounts?
• Why do stale service accounts create such a large security risk?