Why does impersonation create risk in financial services AI workflows?

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.

Related resources from NHI Mgmt Group

• Why do borrowed human credentials create risk in AI workflows?
• Why do AI agents create new risk in non-human identity management?
• When does AI agent access create more risk than it reduces?
• When do AI agent credentials create more risk than they reduce?