A borrowed user session makes the agent look like the human, which blurs accountability and complicates revocation when the session ends. An agent acting under its own identity keeps the acting subject separate from the delegating authority, so downstream systems can verify who did the work and on whose authority. That separation is the basis for clean audit trails and constrained delegation.
Why Borrowed Sessions and Self-Identity Are Not the Same Thing
A borrowed user session collapses the agent’s actions into the human’s account context, which is convenient but weakens attribution and makes delegation harder to reason about. An agent acting under its own identity preserves a distinct actor for logs, policy, and revocation. That difference matters because the security question is not only whether the action was allowed, but whether the system can later prove who acted, under what authority, and with what bounds.
For agentic workloads, that separation is also what keeps permissions from becoming permanently tied to a person’s login state. If the session is used as the control plane, the agent inherits whatever that session can reach, and the scope is often broader than the task really needs. Current guidance for agentic systems increasingly treats identity separation as a prerequisite for accountability rather than a nice-to-have design choice.
Borrowed sessions can still be acceptable for tightly supervised, low-risk actions, but they become fragile as soon as the agent can chain calls, retry work, or touch multiple systems. In practice, many teams discover the accountability problem only after a session has expired, been reused, or been assumed to represent the wrong actor.
How the Two Identity Models Work in Practice
Under a borrowed session model, the agent operates inside an already authenticated human context. Downstream systems typically see the human principal, the human’s session token, or a token derived from that session. This can be useful when the task is short-lived and the human is directly supervising each step, but it also means the agent’s authority is coupled to the lifespan and reach of the user session.
Under an agent-owned identity model, the agent authenticates as a separate workload or application principal. The delegating human may still approve the task, but the agent’s calls are made through its own credentials, policy, and audit trail. That makes it possible to bind permissions to the task, the environment, or the service path instead of to a human’s interactive login.
- Borrowed session: faster to start, but harder to constrain, revoke cleanly, or distinguish in logs.
- Owned identity: better for traceability, least privilege, and automated policy enforcement.
- Borrowed session: usually inherits human entitlements unless additional guardrails are built around it.
- Owned identity: can be paired with short-lived credentials, explicit approval, and narrower scopes.
This is why many agent deployments are moving toward just-in-time delegation, ephemeral credentials, and real-time policy checks rather than static role assumptions. The identity primitive changes the control model: one is “act as the human,” the other is “act on behalf of the human, but remain separately addressable.” The distinction becomes especially important when a workflow spans multiple systems, because the audit question changes from “which user was logged in?” to “which agent performed which action under which delegated authority?” For more background on machine identity governance, see the Ultimate Guide to NHIs and the OWASP Agentic AI Top 10.
These models tend to break down when a single human session is reused across long-running, multi-step automations because the delegated authority no longer matches the actual acting subject.
Where the Boundary Breaks Down, and What Practitioners Should Watch
Tighter separation often increases orchestration overhead, so teams have to balance auditability against implementation complexity and user convenience. That trade-off becomes visible when organisations want both “one-click approval” and strong traceability, because those goals are not fully compatible once the agent can act autonomously.
A common edge case is partial delegation: the human initiates the task, but the agent later continues after the user session has expired. In that case, the borrowed-session model creates ambiguous ownership, while the owned-identity model can keep operating as long as its delegated grant is still valid. Best practice is evolving toward short-lived delegation with explicit expiry and scope limits, but there is no universal standard for every workflow yet.
Another edge case is exception handling. If an agent needs to escalate, retry, or recover from failure, the system should not silently fall back to the human’s session just because it is available. That shortcut can turn a bounded workflow into an unconstrained one, especially if the session has access to production data or administrative tools. The safer pattern is to treat the agent’s identity as the default and reserve human re-authentication for exceptional approval points.
For teams building controls around this distinction, the important question is not only “can the agent do the task?” but “can the organisation later revoke, inspect, and explain the task without depending on a person’s login history?”
Risk and Threat Considerations
Borrowed sessions create identity ambiguity, privilege spillover, and revocation risk. They also make abuse harder to detect because malicious or unsafe actions can blend into normal human activity if the agent is operating inside the user’s authenticated context.
Failure mechanism: the agent inherits a session that outlives the original intent, carries broader permissions than the task requires, or is reused across steps without fresh policy evaluation. That can enable overreach, persistence within a live session, and weak forensic separation between human and machine action.
Impact: logs become less trustworthy, revocation becomes less precise, and downstream systems may be unable to distinguish delegated automation from direct human action. In a compromise scenario, that can widen blast radius and delay response because the session appears legitimate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 — Identity and Access | Compares agent-owned versus borrowed authority and delegation boundaries. |
| Recommendation — Use separate agent identity and scoped delegation for autonomous actions. | ||
| CSA MAESTRO | IAC — Identity and Access Control | Covers workload identity and delegated access for agentic systems. |
| Recommendation — Bind agents to distinct identities with least-privilege access grants. | ||
| NIST AI RMF | MAP — Measure and Manage | Supports governance of accountable AI action and delegated responsibility. |
| Recommendation — Document who authorises agent actions and how accountability is retained. | ||
| NIST CSF 2.0 | PR.AC-1 — Identities and Credentials Managed | Applies to managing the credentials behind human and agent access. |
| Recommendation — Manage agent credentials separately from user sessions and rotate them routinely. | ||
| CIS Controls v8 | 6 — Access Control Management | Addresses access scope, revocation, and least privilege for delegated access. |
| Recommendation — Restrict delegated access and revoke agent permissions when tasks end. | ||
Practitioner Guidance
What to prioritise: Use a borrowed session only when the task is tightly scoped, directly supervised, and short-lived. If the agent may retry, chain actions, or continue after the user steps away, give it a separate identity and treat the human as the delegator, not the actor.
What to verify: Confirm that revocation actually stops the agent’s access path, not just the human’s browser session. Also verify that logs preserve both the human approver and the agent principal, because attribution fails if either side is missing.
Decision rule: If the agent can touch production data, administrative functions, or multiple downstream systems, do not rely on a borrowed session as the primary identity model. Keep the agent separately addressable and bound it with explicit scope and expiry.
Practitioner takeaway: The safest design is the one that lets the organisation remove, audit, or constrain the agent without having to guess which human session it happened to be borrowing.
Related resources from NHI Mgmt Group
- What is the difference between human identity governance and AI agent governance?
- What is the difference between workload identity and API keys for AI agents?
- What is the difference between governing human access and governing AI agent access?
- What is the difference between acting as an agent and on behalf of a user?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
