Impersonation creates risk because it hides the true actor behind a human account, which weakens accountability, non-repudiation and incident reconstruction. When an autonomous system uses a borrowed identity, the organisation may be unable to prove whether a person or machine made the decision that triggered the action.
Why This Matters for Security Teams
In financial services, impersonation turns AI from a governed workload into a trust problem. When an agent acts through a human account, normal controls like role review, user attestation, and audit trails can all point to the wrong actor. That weakens non-repudiation, complicates regulatory evidence, and makes it difficult to separate approved automation from abuse. Guidance in the NIST Cybersecurity Framework 2.0 emphasises accountable identity and traceability, but impersonation erodes both if the system boundary is unclear.
The risk is not limited to fraud. A borrowed identity can give an AI workflow access to payment systems, customer records, trading tools, or privileged back-office applications that were never intended for autonomous use. That creates a direct path from model output to operational harm, especially when approvals are cached, sessions persist, or secrets are reused across tasks. NHIMG research on the Ultimate Guide to NHIs — Why NHI Security Matters Now shows why hidden machine activity has become a core governance issue, not a niche technical concern. In practice, many security teams only discover impersonation after a suspicious transfer, model-driven account misuse, or an audit request that cannot prove who actually acted.
How It Works in Practice
Impersonation risk emerges when an AI agent uses a person’s login, session cookie, API token, or delegated approval path instead of a distinct machine identity. In that pattern, the workflow may look legitimate to downstream systems because it inherits the human account’s trust. The result is false attribution: logs show a named employee, while the actual decision and execution path came from an autonomous process. That is especially dangerous in financial services, where approval chains, segregation of duties, and evidentiary controls matter as much as access itself.
Current guidance suggests separating user identity from workload identity so the agent can be authenticated as a distinct non-human actor. Practical implementations often combine short-lived credentials, runtime policy checks, and strong provenance signals. NIST identity guidance such as NIST SP 800-63 Digital Identity Guidelines is useful for assurance thinking, but AI workflows usually need more than login strength. They need per-task authorisation, not durable standing access. NHIMG’s OWASP NHI Top 10 is a useful lens for mapping this risk to agentic application failures.
- Issue the agent a workload identity, not a borrowed human session.
- Use JIT credentials with short TTLs and automatic revocation after task completion.
- Require policy-as-code evaluation at request time, not only during provisioning.
- Log both the human sponsor and the machine actor so audit evidence can distinguish intent from execution.
These controls tend to break down when legacy banking platforms only accept human SSO sessions because the workflow cannot present a separate workload identity without redesign.
Common Variations and Edge Cases
Tighter impersonation controls often increase integration overhead, requiring organisations to balance stronger attribution against legacy compatibility and operational speed. That tradeoff is real in financial services, where some workflows still depend on service accounts, delegated tokens, or step-up approvals that were built before agentic AI existed.
There is no universal standard for this yet, but best practice is evolving toward explicit machine-to-human delegation records, short-lived secrets, and context-aware approval boundaries. A low-risk internal assistant may only need read access and full provenance logging, while a payments agent may need stronger constraints, dual approval, and event-level replayability. The important distinction is that the agent must never disappear inside a human identity just to make integration easier.
NHIMG’s Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks both reinforce the same operational point: impersonation is not just an access problem, it is a trust-boundary problem. Where organisations rely on shared credentials, long-lived sessions, or generic “automation” accounts, attribution failure becomes likely because the system can no longer prove whether a person or a machine initiated the action.
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 | Impersonation often stems from shared or over-privileged non-human access. |
| OWASP Agentic AI Top 10 | A-03 | Agentic workflows need distinct identity and action attribution to prevent misuse. |
| NIST AI RMF | AI RMF governance addresses accountability, traceability, and human oversight gaps. |
Establish governance that preserves provenance, accountability, and escalation paths for AI actions.
