AI agents complicate authentication because a successfully authenticated session can still be unsafe if the agent is allowed to perform the wrong action. Banks may accept an agent for read-only tasks but not for transfers or profile changes. The governance problem is permissioning inside the session, not simply proving identity at entry.
Why banks have to separate authentication from authorization for AI agents
AI agents change the old assumption that a successful login means the session is safe to use for any action. A bank can authenticate the customer correctly and still end up with an unsafe request path if the agent is allowed to initiate transfers, alter profile data, or approve steps the customer never intended. The bank has to decide what the session is allowed to do, not just who entered it.
This is why the control point shifts from entry checks to per-action permissioning. An agent may be acceptable for low-risk servicing, but the same session should not inherit full customer authority by default. That distinction matters because the agent can chain requests quickly, reuse context, and turn a legitimate session into an execution path with a much larger blast radius than a human would normally create.
For a practical model of this problem, banks need to think in terms of delegated authority, scoped access, and action-level approval. A useful reference point is AI Agent Authorisation Guide, which frames the problem as least privilege for agent actions rather than a one-time login decision. That framing fits banking because the risk is not merely account access, but what the authenticated entity can do once it is inside the session.
Where customer authentication breaks down in an agentic flow
Traditional customer authentication was designed for a person making a bounded decision at the keyboard. AI agents blur that model because they can act continuously, follow tool prompts, and combine multiple permitted steps into one harmful outcome. The bank may still trust the customer’s initial identity proofing, but it cannot assume every downstream action remains within the customer’s intent or the original risk tolerance.
That creates several practical failure modes. Read-only access can become write access through poor transaction design, a low-risk support task can drift into sensitive profile changes, and an apparently valid session can be used to trigger transfers, beneficiary updates, or account recovery actions. Banks also have to consider that an agent can operate faster than a human can notice, so weak action boundaries become an amplification mechanism rather than a convenience feature.
A broader banking context is covered in the Customer IAM (CIAM) Guide, especially where customer authentication, recovery, delegated access, and consent management intersect. For readers comparing how agents change the model, AI Agents vs Agentic AI helps separate a simple assistant from a system that can accumulate enough autonomy to require stronger controls.
What banks should treat as the real security boundary
The real boundary is not “authenticated versus unauthenticated,” it is “what is this authenticated session permitted to execute.” That means banks should separate viewing, initiating, approving, and changing functions, and treat each as a different trust level. If an agent is permitted to help with servicing, the bank still needs explicit guardrails before it can reach payment, beneficiary, device enrollment, or profile-change functions.
This is also where verification has to become contextual. The bank should test whether the session can be constrained to a specific purpose, whether step-up approval is required for sensitive actions, and whether the system can distinguish a human request from agent-driven automation when the same account is being used. Zero Trust for AI Agents is useful here because it treats each request as something to verify, not something to inherit from a prior login.
Risk and Threat Considerations
AI agents increase the chance that a legitimate customer session is turned into an overpowered execution path. The exposure is not limited to account takeover, it also includes misuse of valid access, mistaken consent, and high-speed abuse of actions that a human would have been less likely to chain together. In banking, that can turn a normal service interaction into a fraud or account-change event.
Failure mechanism: The bank authenticates the customer once, but the agent inherits broader authority than the customer intended, then uses that authority to perform sensitive actions within an otherwise valid session.
Impact: Transfers, profile changes, recovery abuse, and other high-risk actions can occur without a fresh trust decision, increasing fraud exposure and making incident scoping harder.
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 addresses the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents can overreach customer-authorised actions after login. |
| ASI09 — Human-Agent Trust Exploitation | Banks must stop agents from converting trust into unintended sensitive actions. | |
| Recommendation — Enforce per-action authorization for agent requests and limit delegated privileges. Require step-up approval before high-risk agent actions. | ||
| NIST SP 800-63 | AAL — Authenticator Assurance Level | Customer authentication strength matters, but it does not by itself authorise risky post-login actions. |
| Recommendation — Use stronger authentication for sensitive banking sessions and step-up events. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Agent and customer sessions depend on credential lifecycle and safe session handling. |
| AC-6 — Least Privilege | The core issue is limiting what an authenticated agent may do within the session. | |
| Recommendation — Rotate and protect authenticators and revoke them promptly when exposure is suspected. Grant only the minimum rights needed for each customer action. | ||
Practitioner Guidance
What to prioritise: Banks should classify customer-facing agent use by action type, not by login status. Read-only servicing, low-risk account lookup, and payment initiation should not share the same permission envelope.
What to verify: Confirm that the customer session, the agent’s delegated rights, and any step-up approval are separately enforced and independently logged. If those three collapse into one control, the bank has not really constrained agent authority.
Decision rule: If an action can move money, change recovery details, or alter account identity data, treat it as a high-risk operation that needs explicit policy and stronger confirmation before execution.
Practitioner takeaway: The key design mistake is treating authentication as the finish line; for AI agents, the security decision must continue inside the session, where permissions, intent, and action scope determine whether the bank is actually safe.