Should financial organisations use the same controls for customers and agents?

No. Customers, human delegates, and software agents represent different risk profiles and should not receive the same approval path. Human logins can rely more on identity verification, while agents need delegated authority limits, per-action policy checks, and stronger confirmation for transactions that change funds, ownership, or access.

The practical difference is not just who is acting, but what authority is being exercised. Customers usually move through identity verification and consumer-facing controls, while agents can execute repeated, programmable actions at machine speed. That changes how you should gate approvals, because the control has to limit delegated authority, not just confirm a person’s identity.

For a financial organisation, the main design question is whether the request is a one-time human decision or an ongoing permission to act. A customer journey can tolerate a simpler approval path when the action is low risk; an agent path should assume the request may be replayed, chained, or expanded unless the authority is tightly scoped.

That is why the control objective shifts from “who logged in” to “what this principal may do right now.” For agents, the relevant control surface is per-action authorisation, not a broad account-level approval that stays valid after the original context has changed.

What changes when the actor is a human delegate instead of a software agent

Human delegates still need stronger verification than ordinary customers when they are acting on someone else’s behalf, but they remain bounded by human interaction, attention, and a limited transaction pace. Software agents are different because they can be persistent, delegated, and integrated with tools, which means the organisation must bound the authority itself rather than rely on the operator’s intentions.

The key difference is that agent controls have to account for delegated authority, session reuse, and automated follow-on actions. An agent that can initiate payments, alter ownership, or change access should be treated as a high-consequence principal, especially when it can act through long-lived credentials or an already authenticated session.

That is why financial firms should separate customer identity proofing from agent governance. A useful reference point is how AI agents get, use and lose identities, because the lifecycle of a delegated agent matters as much as the original login event.

Where the control boundary should be strongest

The strongest boundary is at actions that move money, transfer ownership, or expand access. Those are the cases where organisations should require explicit, contextual confirmation and policy checks at the point of action, not just at sign-in time. If the request changes a beneficiary, authorisation scope, or account control, the approval should be evaluated against current policy and current risk, not a stale grant.

That principle also applies to agent-to-agent or agent-to-tool interactions inside a financial workflow. Once an agent can fan out to multiple systems, the risk is no longer just a single approval mistake, but a chain of authorised actions that may be hard to unwind. Multi-agent delegation and containment become relevant when one principal can trigger other principals or services on its behalf.

For high-impact changes, the best practice is to verify the action, the scope, and the blast radius together. That means the approval should ask whether this specific principal, at this specific moment, can perform this specific transaction and nothing more.

Risk and Threat Considerations

Using the same controls for customers and agents creates over-permissioning risk, approval drift, and weak attribution. If agent access is handled like a standard customer login, a compromised or overbroad agent can move from convenience to direct financial loss very quickly.

Failure mechanism: A generic approval path grants a broad session or standing authority, then the agent reuses that authority for actions outside the original intent, including transfers, ownership changes, or privilege expansion.

Impact: The organisation can lose money, expose customer accounts, and struggle to prove whether a human, an agent, or an integrated tool actually caused the transaction.

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-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agents need scoped authority and stronger approval boundaries for high-impact actions.
	ASI02 — Tool Misuse	Agents can overreach through connected tools and workflows after login.
Recommendation — Limit agent authority per action and require fresh approval for sensitive transactions. Constrain tool access and validate each requested operation before execution.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Different principals need different authority limits, especially for agentic actions.
	IA-5 — Authenticator Management	Agents may rely on credentials that need lifecycle controls beyond customer sign-in.
	IA-9 — Service Identification and Authentication	Software agents acting as services require distinct authentication handling from human users.
Recommendation — Grant only the minimum permissions needed for the current task and revoke excess access. Manage credential issuance, storage, rotation, and revocation for agent access. Authenticate non-human principals with controls suited to service-to-service trust.
OWASP ASVS	V8 — Authorization	Per-action policy checks and scoped permissions are central to the question.
Recommendation — Enforce authorization at the action level, not just at login.

Practitioner Guidance

What to prioritise: Separate the control model by actor type before you tune transaction thresholds. If the principal is a software agent, build the workflow around delegated scope, per-action checks, and explicit expiry rather than customer-style sign-in assurance.

What to verify: Confirm that high-risk actions require fresh policy evaluation at the moment of execution, especially for payments, access changes, and ownership changes. If the approval is reusable across multiple actions, it is probably too broad for an agent.

Practitioner takeaway: The safest pattern is not “stricter customer controls,” but a different control model altogether, one that measures and limits delegated authority at the point where the action can actually cause harm.