The audit trail becomes ambiguous, access reviews lose meaning, and accountability shifts from a specific actor to a generic human account. That makes it hard to determine whether access was justified, whether it should still exist, and who is responsible when an action goes wrong.
Why This Matters for Security Teams
When AI agents borrow employee logins, the identity model stops reflecting the actual actor. A human account may appear to be driving normal activity while an autonomous system is chaining tools, moving data, and making decisions at machine speed. That breaks the basic assumptions behind access reviews, segmentation, and incident response because the account no longer maps cleanly to a single person, purpose, or approval.
This is not just a logging problem. It turns governance into guesswork: reviewers cannot tell whether access was granted for the employee, the agent, or both, and revocation becomes risky because it may interrupt legitimate human work. The issue shows up quickly in environments that rely on shared browser sessions, delegated OAuth grants, or long-lived SSO tokens. NHI Management Group has documented how agent misuse can expand beyond intended scope in the field, including AI Agents: The New Attack Surface report, where 80% of organisations said agents had already acted beyond scope. In practice, many security teams encounter the breakage only after an agent has already accessed systems no one expected it to reach.
How It Works in Practice
The failure starts when an agent inherits a human identity instead of using its own workload identity. Once that happens, the organization loses the ability to distinguish agent actions from employee actions at the authentication layer, in the audit trail, and in authorization decisions. Static role-based access control is a poor fit here because the agent’s behavior is goal-driven and dynamic, not a fixed set of pre-approved tasks. Current guidance suggests treating the agent as a separate workload with its own identity, policy, and lifecycle, rather than as a proxy for the employee who launched it.
In practice, stronger patterns include:
- Workload identity for the agent, such as OIDC-based service identity or SPIFFE-style cryptographic identity, so the system can prove what the agent is.
- Just-in-time, short-lived credentials issued per task, not reused human tokens that outlive the session.
- Real-time authorization checks, using policy-as-code, so the decision is based on the request context, tool, and data sensitivity.
- Separation of human approval from machine execution, so the employee authorizes intent without lending their login.
This is also where agent-specific threat research matters. NHIMG’s OWASP NHI Top 10 and the broader OWASP Agentic AI Top 10 both reflect the same operational point: autonomous systems need identities and controls that match machine-scale behavior, not human convenience. For risk governance, the NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework both support separating identity, privilege, and accountability across agent lifecycle stages. These controls tend to break down when an agent is embedded inside a single sign-on session because the session token still looks like the employee, even after the employee has stopped directing the action.
Common Variations and Edge Cases
Tighter identity controls often increase integration overhead, requiring organisations to balance governance against developer speed and operational simplicity. That tradeoff is real, especially in early deployments where teams use browser automation, RPA, or managed SaaS copilots that were never designed to carry a distinct machine identity. Best practice is evolving, and there is no universal standard for every agent pattern yet.
Some edge cases are especially difficult. Shared service accounts may look efficient but usually destroy attribution. Delegated access can be acceptable for narrow workflows, but only if the delegation is explicit, time-bound, and separately logged. Human-in-the-loop review does not fix the problem if the agent can continue acting after approval expires. The most dangerous pattern is when a “temporary” borrowed login quietly becomes the agent’s permanent identity, because then revocation, incident response, and access review all point to the wrong subject.
Recent NHIMG reporting on agent behavior shows why this matters operationally, not just theoretically, in AI Agents: The New Attack Surface report and related research such as CoPhish OAuth Token Theft via Copilot Studio. The practical takeaway is simple: if the agent can borrow the employee’s login, it can also borrow the employee’s blame. That becomes unacceptable as soon as the agent can touch sensitive data, trigger financial actions, or chain tools across environments.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Borrowed logins create agent identity confusion and authorization abuse. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Human-account reuse defeats non-human identity attribution and lifecycle control. |
| CSA MAESTRO | IAM-02 | MAESTRO emphasizes distinct identity and authorization for autonomous workloads. |
| NIST AI RMF | AI RMF addresses accountability and monitoring for autonomous system behavior. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access breaks when agents inherit broad human permissions. |
Assign each agent its own NHI, then bind access, rotation, and revocation to that identity.
