What breaks is attribution. When an assistant operates inside a human session, activity may be legitimate but still hard to separate from the employee’s own actions. That creates audit ambiguity, weakens accountability, and can let sensitive actions disappear inside ordinary user behaviour unless session monitoring and approval rules are explicit.
Why This Matters for Security Teams
Borrowed human sessions and tokens collapse the boundary between a person and a machine that is acting on the person’s behalf. That matters because audit logs, approvals, and incident response all depend on attribution. When an AI assistant inherits an authenticated browser session, OAuth token, or API bearer token, the activity can look fully legitimate while still exceeding what the human intended. NIST Cybersecurity Framework 2.0 frames this as an identity and access control problem, but in practice it becomes a governance problem as well. The same ambiguity shows up in incidents such as the Salesloft OAuth token breach, where token misuse turns trusted access into a hidden path for data access.
Security teams often miss the difference between authentication and authority. A valid session does not prove the action was appropriate, especially when an assistant can chain tools, replay requests, or continue operating after the employee has stopped supervising. Guidance from NIST and current NHI practice both point toward stronger session isolation, shorter-lived credentials, and explicit approval boundaries. In the field, this usually fails only after an assistant has already made a change that appears to belong to the user.
How It Works in Practice
The practical fix is to stop treating the assistant as a transparent passenger inside the employee’s identity. Current guidance suggests separate workload identity for the assistant, explicit mapping between the human request and the machine action, and short-lived credentials issued only for the task at hand. That means using JIT access, not shared sessions, whenever the assistant needs to reach production systems, data stores, or SaaS tools.
Security teams should think in terms of runtime authorization rather than one-time login. A useful pattern is: authenticate the human, authenticate the assistant as a distinct workload, then evaluate whether the requested action is allowed in that specific context. Policy engines can approve or deny based on task, data sensitivity, time, tool, and environment. In agentic systems, this is closer to intent-based control than classic RBAC.
- Use a separate workload identity for the assistant, rather than reusing the employee’s browser or API session.
- Issue ephemeral tokens with narrow scope and a short TTL, then revoke them automatically when the task ends.
- Require explicit approval for high-risk actions such as export, delete, share, privilege change, or credential creation.
- Log both the human origin and the assistant execution path so audit teams can distinguish intent from automation.
NHIMG research on the 2025 State of NHIs and Secrets in Cybersecurity shows how quickly token exposure becomes operational risk, especially when secrets are duplicated or overused. The related Guide to the Secret Sprawl Challenge is a useful reference for understanding why borrowed credentials are so hard to contain once they spread across apps and teams. These controls tend to break down when assistants are embedded in shared browsers, legacy SaaS integrations, or long-lived service accounts because the environment itself cannot preserve clean identity separation.
Common Variations and Edge Cases
Tighter session isolation often increases user friction, so organisations have to balance usability against the risk of invisible machine activity. There is no universal standard for this yet, and best practice is evolving. Some teams allow read-only inheritance from a human session but require separate approval and fresh credentials for write actions. Others ban session sharing entirely and force every assistant action through a broker or gateway.
Edge cases matter. In customer support, finance, and admin workflows, a borrowed token may seem convenient because it preserves context across tools. But convenience can hide privilege escalation, especially if the assistant can act after the employee has closed the app or left the desk. Best practice is to treat shared refresh tokens, persistent cookies, and browser profile reuse as high-risk patterns, not shortcuts.
Where identity sprawl is already present, borrowed sessions become harder to govern because multiple apps may trust the same bearer token. That is exactly the kind of trust concentration highlighted by the Secret Sprawl Challenge and the Dropbox Sign breach, where token handling and downstream access paths can outlive the original user action. In practice, borrowed sessions fail most often in long-lived SaaS sessions and automation-heavy environments because the organisation cannot tell when the human stopped and the assistant began.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Shared sessions blur human and machine identity, increasing NHI attribution risk. |
| OWASP Agentic AI Top 10 | A-03 | Agent actions must be constrained when they operate with human-derived tokens. |
| NIST AI RMF | AI RMF governs accountability and traceability for autonomous assistant actions. |
Use separate NHI identities and short-lived credentials instead of borrowing human sessions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
