Why do borrowed sessions create risk for AI agents?

Why This Matters for Security Teams

Borrowed sessions are risky because they turn an AI agent into a temporary stand-in for a human account instead of a bounded workload. That means the agent inherits broad entitlements, hidden approval chains, and access paths the task never needed. In autonomous systems, that is especially dangerous because the agent can chain tools, pivot across systems, and act faster than a human can intervene. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework points toward tighter runtime controls, but borrowed sessions still remain common because they are convenient.

That convenience hides the real failure mode: a session was created for a person, yet the agent uses it as if it were its own identity. NHIMG research shows this pattern is not theoretical. In the AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope. In practice, many security teams encounter borrowed-session abuse only after an over-permissioned agent has already touched data it was never meant to see.

How It Works in Practice

The safer model is to treat the agent as a distinct workload identity, not as a user session with a keyboard attached. That usually means combining workload identity, policy-as-code, and just-in-time credential issuance so the agent receives only the access needed for a single task, for a short time, and under explicit runtime policy. Best practice is evolving, but the direction is consistent across CSA MAESTRO agentic AI threat modeling framework, OWASP Top 10 for Agentic Applications 2026, and NIST AI guidance.

In practical terms, borrowed sessions fail because they carry too much static privilege and too much implicit trust. A more defensible pattern is:

• Issue ephemeral secrets per task, not long-lived credentials that survive beyond the workflow.
• Use workload identity, such as SPIFFE/SPIRE or OIDC-backed service identity, to prove what the agent is.
• Evaluate intent-based authorisation at request time, so access depends on the action being attempted, not only on a preassigned role.
• Revoke access automatically when the task ends or when the agent strays outside the approved context.

That design aligns with the threat patterns described in NHIMG’s OWASP NHI Top 10 and the broader attack-surface concerns in the AI LLM hijack breach analysis. These controls tend to break down in legacy environments where the agent can only authenticate by reusing a human session cookie or VPN-backed account.

Common Variations and Edge Cases

Tighter control often increases integration overhead, requiring organisations to balance operational speed against containment. That tradeoff is real in multi-step workflows, where an agent may need several tools in sequence and a fresh authorisation decision for each step. There is no universal standard for this yet, so current guidance suggests keeping sessions narrow, revocable, and task-scoped rather than trying to make borrowed human sessions “safe.”

One common edge case is delegated support automation, where a human intentionally authorises the agent to act on their behalf. Even there, the safer pattern is not a borrowed full session but a constrained delegation token with explicit scope, expiry, and auditability. Another edge case is emergency access. If a team relies on borrowed sessions for break-glass response, that access should be tightly logged, separately approved, and time-boxed, because the same credentials that help with recovery also create an attractive escalation path.

NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both reinforce the same practical lesson: once a session is broad enough to act like a user, it is also broad enough to be abused like one.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk in non-human identity management?
• Why do AI agents create more risk when they reuse existing credentials?
• Why do AI agents create more IAM risk than ordinary developer tools?
• Why do AI agents create a different access-risk profile than traditional applications?