How should banks implement authorization controls for AI agents that act inside existing workflows?

Banks should treat agents as controlled actors, not as extensions of the human user. The practical baseline is explicit authorization, least privilege, task-scoped access, and a distinct agent identity. Teams should preserve delegation context, log the chain of authority, and require human approval for high-impact actions. The goal is not only to know that an agent acted, but to prove what it was allowed to do.

How banks should think about agent authorization inside existing workflows

Banks should treat an AI agent as a bounded actor with its own permissions, not as a proxy for the person who triggered it. That means the authorization model has to express what the agent may do, where it may do it, and under what escalation rules, instead of inheriting broad user entitlements by default.

The practical design goal is to keep the agent useful without collapsing human context, application context, and delegated authority into one indistinct permission set. In regulated workflows, that separation is what makes approval chains, audit trails, and exception handling defensible.

When a bank lets an agent operate inside a workflow, the first control question is whether the agent is allowed to act on the same basis as the user, or whether it needs narrower, task-scoped authority. In most cases, the safer answer is narrower authority with explicit delegation, because workflow automation tends to expand faster than the control model if permissions are inherited casually.

What good authorization looks like in practice

Good implementation starts with a distinct agent identity, explicit scopes, and a clear mapping between workflow step and allowed action. If an agent can only draft, fetch, classify, or prepare a recommendation, its access should stop there; if it can submit, approve, or release something, that higher-impact step should be separately authorised and reviewable.

That model works best when the bank preserves delegation context through the entire transaction path. The system should be able to answer who initiated the workflow, which agent acted, what authority it used, what policy granted that authority, and whether the action was completed under direct human oversight or a pre-approved exception path.

For bank operations, least privilege should be applied to both data and action. An agent may need read access to a case file, but not export rights; it may need to create a payment proposal, but not execute the payment; it may need to assemble evidence, but not alter the decision record. The more the agent can change money movement, customer impact, or control evidence, the more tightly the authorization boundary should be drawn.

Where a workflow already has strong manual checkpoints, the agent should fit into those checkpoints instead of bypassing them. That usually means explicit permission to prepare or recommend, combined with separate approval for release actions, with the approval decision anchored in the bank’s existing control environment rather than in the agent interface alone.

Why banks should separate delegation, approval, and execution

A common failure mode is treating an agent action as simply another user action because it was launched by a human. That shortcut hides the real risk, which is that the agent may chain multiple tool calls, reuse context across steps, or reach outcomes the human did not directly review. The authorization model needs to reflect the full action path, not just the starting prompt.

Banks also need to be careful with standing delegation. If an agent is allowed to operate broadly for convenience, permissions can outlive the business need that justified them. That is especially dangerous in high-volume operations, where the same workflow runs thousands of times and exceptions become normalised.

A better pattern is time-bounded, task-bounded authority with explicit limits on sensitive actions. In practice, that means the agent can act for this case, in this environment, for this objective, and only until the task is completed or the approval window expires. Anything outside those bounds should fail closed and require reauthorisation.

Risk and Threat Considerations

The main risk is privilege inflation through workflow convenience: once an agent is treated like the user, it can accumulate access that exceeds the task, the system, or the reviewer’s intent. In a bank, that can turn a helpful automation layer into a high-blast-radius control path.

Failure mechanism: The bank grants the agent broad inherited access, weakly scoped delegation, or reusable approval context, then the agent uses that authority across more data, more tools, or more transaction steps than intended.

Impact: A compromised or misdirected agent can create unauthorized transactions, expose sensitive records, distort audit evidence, or execute actions that are difficult to unwind because they appear to have been performed under legitimate workflow authority.

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 surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agent authorization is centrally about preventing overbroad delegated privilege.
Recommendation — Bind each agent to explicit scopes and separate human approval from agent execution.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Banks need task-scoped access so agent permissions stay narrower than user entitlements.
	IA-9 — Service Identification and Authentication	An agent acting inside workflows needs a distinct machine or service identity for controlled access.
	AU-2 — Event Logging	Authorization decisions and delegated actions must be auditable in regulated bank workflows.
Recommendation — Enforce least privilege for each workflow step and deny broad inherited access. Authenticate the agent with a distinct identity before allowing workflow actions. Log the delegating user, granted scope, and each agent action for auditability.
NIST CSF 2.0	PR.AA-05 — Managed Access Control	The subject is about governing who or what can perform actions in a workflow.
Recommendation — Apply managed access controls that separate agent authority from the initiating user.
ISO/IEC 27001:2022	A.5.15 — Access control	Banks need formal access control rules for agent actions inside production workflows.
Recommendation — Define and enforce access rules that limit each agent to approved workflow actions.

Practitioner Guidance

What to prioritise: Anchor the control design on the highest-impact action the agent can reach, not on the low-risk steps it performs most often. If a workflow has one step that can move money, change customer outcomes, or alter records, that step should get the strictest approval and logging treatment.

What to verify: Confirm that every agent action can be traced to a specific policy grant, a specific workflow state, and a specific approval path. If the bank cannot reconstruct those three elements after the fact, the authorization design is too loose for regulated operations.

Decision rule: If the agent is acting only as a recommender, keep the authority narrow and read-oriented; if it can execute or commit state, require separate delegated permission and human review for the commit step. Do not let “the user started it” become the sole justification for downstream authority.

Practitioner takeaway: The safest bank pattern is not to make agents more trusted, but to make their trust boundaries more explicit, narrower, and easier to prove after the workflow has completed.