It matters because shared sessions hide who actually took the action. When an agent rebooks travel, moves money, or changes records under a customer login, the business loses the ability to separate human intent from machine execution. That weakens auditability, complicates dispute handling, and makes it harder to prove who approved the action when regulators or investigators ask.
Why delegated agent identity changes the fraud picture
Fraud controls depend on being able to distinguish who initiated an action, who executed it, and whether execution stayed within authorised bounds. When an agent acts inside a shared customer or employee session, that separation collapses. The result is not just a technical ambiguity, it is a material control gap that affects approval, repudiation handling, and post-transaction investigation.
That matters most in high-impact flows such as travel rebooking, refunds, funds movement, account changes, and records updates. In those cases, the issue is not whether automation was involved, but whether the system can prove which actor exercised the authority and under what delegated scope.
Why disputes and chargebacks become harder to resolve
Disputes usually turn on evidence. A business may need to show that the customer authorised the change, that the agent stayed within policy, or that the action was an expected outcome of the service. If the only record is a shared login, the evidence trail weakens and the company may be left arguing from inference instead of attribution.
Delegated identity gives the business a way to preserve action provenance across the transaction lifecycle. That includes session lineage, bounded permissions, and logs that show whether the request came from a human, an agent operating on behalf of the human, or an automated workflow taking a tool action.
Why accountability now depends on explicit agent identity
Accountability is shifting because more business actions are now executed through AI agents that can trigger tools, call APIs, or complete workflows with real-world consequences. Without a distinct agent identity, organisations cannot cleanly assign responsibility, enforce least privilege, or answer basic questions such as which policy decision was human-approved and which step was machine-executed.
This is why delegated identity is becoming a governance requirement rather than a nice-to-have design choice. It supports clearer audit trails, tighter approval boundaries, and more credible explanations when regulators, customers, or internal investigators ask why a state change occurred.
Risk and Threat Considerations
The core risk is accountability collapse: once human and machine actions share the same session or credential path, a fraudulent or harmful action can look like legitimate customer activity. That creates exposure in dispute handling, makes abuse harder to detect, and can let an attacker hide behind normal business automation.
Failure mechanism: Shared authentication and broad delegated permissions erase the distinction between initiation, execution, and approval, so a compromised or overreaching agent can perform actions that appear user-authorised.
Impact: Organisations can lose evidentiary clarity, mis-handle chargebacks or complaints, and face stronger regulatory scrutiny when they cannot prove who did what, when, and under what authority.
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 SP 800-53 Rev 5, OWASP ASVS and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Shared sessions blur human and machine actions in delegated flows. |
| NHI-05 — Overprivileged NHI | Delegated agents need bounded authority to avoid unauthorized actions. | |
| NHI-09 — NHI Reuse | Reused customer sessions obscure attribution and weaken accountability. | |
| Recommendation — Separate human approval from agent execution and log both identities. Constrain agent permissions to the smallest task-scoped access. Avoid reusing one session across human and agent actions. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Delegated agents can misuse borrowed authority for fraudulent actions. |
| Recommendation — Bind agent identities to explicit privileges and audit every delegated action. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | External customer-facing agent flows need distinct identity and auth handling. |
| AU-2 — Event Logging | Disputes and accountability depend on action provenance and traceability. | |
| AC-6 — Least Privilege | Delegated agents should only receive the authority needed for the task. | |
| Recommendation — Authenticate delegated actors separately from the end user session. Log the initiating user, agent, tool, and outcome for each delegated action. Limit each agent to task-specific permissions and revoke excess access. | ||
| OWASP ASVS | V8 — Authorization | Delegated execution must preserve who may perform a sensitive business action. |
| Recommendation — Verify that every agent action is authorised against the original request scope. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Delegation and attribution depend on strong identity proofing and authenticators. |
| Recommendation — Use phishing-resistant authenticators and preserve identity assertions across delegation. | ||
Practitioner Guidance
What to verify: Confirm that every agent action has a distinct actor identity, a bounded delegation scope, and logs that preserve the original human request separately from downstream machine execution. If those three elements are not all present, the control is not strong enough for fraud-sensitive workflows.
Decision rule: If the action can move money, change records, or affect a customer outcome, treat shared-session execution as a high-risk exception and require explicit provenance before production use.
What good looks like: The business can answer, from logs alone, which human approved the request, which agent executed it, which tools were used, and whether the action stayed within policy and scope.
Practitioner takeaway: The key design choice is not whether agents are allowed to act, but whether their actions remain separately attributable enough to survive a fraud review, dispute, or regulatory challenge.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
