A pattern where an AI assistant operates under a human user’s permissions during a session. It hides the agent’s activity inside the person’s legitimate access, which makes review, detection, and accountability difficult because the identity boundary is blurred.
What Borrowed Access Really Means in Practice
Borrowed access is not just “sharing a login.” It is a runtime condition where an assistant inherits a user’s permission boundary for the duration of a session, so the assistant’s actions appear to come from the person rather than from a separately governed actor.
That distinction matters because the access path is not merely technical. The human account becomes the visible carrier of activity, which means the organisation often loses a clean line between user intent, automated execution, and accountable control.
How Borrowed Access Blurs Identity Boundaries
The core problem is that the assistant is operating inside an already trusted identity context. Instead of presenting its own identity, it uses the user’s authenticated session, tokens, or interactive access path, which can make the assistant look indistinguishable from normal user behaviour.
This creates an attribution gap. Reviewers may see a valid session and assume ordinary human action, even when the actual sequence of clicks, prompts, tool calls, or data access was produced by an autonomous or semi-autonomous system.
Why Borrowed Access Changes Accountability and Review
When actions are executed under a person’s permissions, accountability can become ambiguous even if the underlying access was technically legitimate. The issue is not only who was logged in, but who decided, initiated, and benefited from the action.
That ambiguity complicates audit trails, incident review, and policy enforcement because the access record reflects the human principal, while the operational behaviour may reflect an assistant with a different intent, workflow, or error profile.
Where Borrowed Access Fits in Security Design
Borrowed access is best understood as a control boundary problem. It sits at the intersection of authentication, authorization, session handling, and delegated action, because the system is trusting one identity while another actor is effectively using that trust.
It becomes especially important in environments where assistants can read data, trigger tools, send messages, or make changes on behalf of a person. A session that is acceptable for human work can become much harder to govern once non-human behaviour is operating inside it.
Risk and Threat Considerations
Borrowed access raises a real exposure issue because a compromised or over-permissioned session can let an assistant exercise the full reach of a user’s account while masking the true source of activity. That can weaken detection, complicate containment, and make misuse harder to distinguish from legitimate work.
Failure mechanism: the assistant inherits an already-authorised session or token, then performs actions that are logged as the human user, which blurs intent, ownership, and behavioural baselines.
Impact: organisations may miss abnormal tool use, overreach data exposure, or delayed containment because the observed identity looks valid even when the activity path is not what reviewers expected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Borrowed access depends on session material and credential handling for the acting user |
| AC-6 — Least Privilege | The assistant operates under user permissions, so excess user privilege becomes assistant reach | |
| AU-2 — Event Logging | Borrowed access complicates attribution, so the activity needs stronger audit detail | |
| Recommendation — Tighten authenticator lifecycle rules so borrowed sessions cannot persist longer than intended. Limit user permissions so inherited access cannot exceed the minimum needed. Log actor context and session provenance so assistant-driven actions remain reviewable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Borrowed access is an access-control boundary issue created by inherited user permissions |
| A.8.5 — Secure authentication | The pattern relies on a valid authenticated session that the assistant can operate within | |
| A.8.15 — Logging | Borrowed access needs auditability because the visible user may not be the effective actor | |
| Recommendation — Set access-control rules that distinguish human use from delegated assistant use. Bind authentication to the intended actor and session context before granting action rights. Record session and action context needed to reconstruct assistant activity accurately. | ||
| OWASP ASVS | V7 — Session Management | Borrowed access is fundamentally a session-bound behaviour that can outlive the intended user action |
| V8 — Authorization | The assistant executes inside the user’s granted permissions, making authorisation boundaries central | |
| Recommendation — Treat assistant use as a distinct session state and constrain session reuse accordingly. Authorize delegated assistant actions separately from the human user’s baseline rights. | ||
Practitioner Guidance
Why practitioners should care: borrowed access is a governance problem as much as a technical one, because teams need to know whether they are authorising a person, an assistant, or both. If those boundaries are not explicit, access reviews and incident investigations can produce false confidence.
Common misunderstanding: a valid user session does not automatically mean the resulting activity is fully human. Treating assistant-driven actions as ordinary user behaviour can hide privilege misuse, policy drift, or weak supervision.
Practitioner takeaway: define where the human session ends and where assistant authority begins, then make that boundary visible in logs, review processes, and operating policy.