Key takeaways
- Agentic AI joins reasoning to controlled action.
- Valid authority can still produce a wrong action.
- Approval should vary by decision class.
- Review what an agent can reach and change, when people approve, and how failures are handled.
What does agentic AI in banking do inside a bank?
Agentic AI in banking combines goal-directed reasoning with controlled action. That is the useful distinction. A model can produce an answer, while an agent can carry a task through a sequence of steps and use tools along the way.
The operating loop starts when an AI agent receives a goal. It gathers context, chooses the next step, uses approved tools, and continues until the task is complete or handed to a person. The model handles reasoning inside that loop. The surrounding harness determines which tools are available and where a human handoff belongs. For a closer look at the basic concept, see our definition of agentic AI.
In a banking workflow, those tools can retrieve a transaction, create a dispute case, send a document request, schedule a payment, or update a customer relationship management system. Banks can also use agents to resolve service cases and coordinate work across fragmented systems. These actions are materially different from producing text because they can read from or write to operational systems.
That difference is why the useful question is not simply whether a workflow uses AI. Ask what goal the agent receives, what context it can gather, which tools it can call, and what event ends the loop or sends the work to a person.
How is AI being used in banking now?
Artificial intelligence is already applied across fraud prevention, credit assessment, customer service, and investment advice in financial services. Those categories describe the business area, but they do not reveal how much authority a particular system receives.
Consider customer service. A supervised banking agent can retrieve answers from internal systems during a live support call. In this example, the agent does not speak directly to the customer and does not operate without employee oversight. The application is real, but the authority boundary remains narrow: the agent supplies information while an employee stays in the interaction. The example shows why "customer-service AI" is too broad a label for an approval decision.
JPMorgan Chase offers another view of how a large bank approaches AI more broadly. Its strategy includes learn-by-doing training, rigorous return-on-investment measurement, and preparation of data infrastructure for integration across more than 450 proofs of concept. That figure describes proofs of concept. It does not establish that they are agentic systems or production deployments.
The practical lesson is to move below the application category. Fraud prevention, credit assessment, support, and investment advice can each contain workflows with very different access, action, and approval boundaries.
Use the Banking Delegation Ladder before broadening authority
Before choosing an architecture, write down how much authority the workflow should have. A governed agent workflow can place deterministic controls between reasoning and action: the language model proposes, a rule engine evaluates policy, permissions and approvals decide, and execution is verified afterward. A bank's production review must examine what the agent can reach, what it can change, when approval is required, and how the system responds when the workflow does not go as planned. Fill the matrix with the actual boundaries for one candidate use case.
| Decision class | Reachable data and permitted changes | Approval or policy boundary | Audit evidence, verification, and recovery |
|---|---|---|---|
| Recommendation only | Name the data the agent may read; record that it cannot execute the proposed change | Identify who decides whether to act on the recommendation | Record the requester, allowed access, recommendation, and human disposition; define how a faulty recommendation is contained |
| Mandatory human approval | Name the systems the agent may prepare for action and the exact change awaiting approval | Name the approval event required before execution | Preserve the request, proposed action, approver, execution result, verification step, and recovery behavior |
| Automatic action below a threshold | Name the data, system, action, and use-case-specific threshold | Define what stays automatic and what must be sent for approval | Record the threshold evaluation and result; verify the action and define behavior for partial failure or retry |
| Action with notification | Name the permitted action and the system it can change | Define the policy that permits action and the notification condition | Preserve the action and notification record; verify the result and define recovery behavior |
| Action within a policy boundary | Name every reachable system and permitted change inside the boundary | Specify the policy, permissions, and approvals that decide whether execution proceeds | Record the rule evaluation, permission decision, execution, and post-action verification; define containment and recovery |
| Prohibited automated action | Name the data that may be read, if any, and the change that automation may not execute | Route the decision to a person instead of automated execution | Record the attempted request and handoff; define how the system prevents execution and handles any partial action |
Recovery belongs in the original design. Controllability supports localized, dynamic control during an incident, including containment, eradication, and recovery. The matrix does not prove that an action is safe. It makes the authority and response boundaries visible enough to inspect.
Why can valid authority still produce the wrong action?
Authorization is not a correctness guarantee. An agent can execute an incorrect action while using valid authority. A permission check may therefore succeed even when the proposed action is wrong.
This creates a specific audit problem. Standard logs may not distinguish an action performed by a person from one autonomously initiated by an agent acting on that person's behalf. A record that shows only a valid user credential can hide the source of the decision. The audit trail needs to preserve whether the human or the agent initiated the action.
The ownership question remains after attribution. Human-accountability gaps arise when responsibility for an agent's decisions and autonomous actions is unclear. Preserve whether a human or agent initiated the action. Identify who owns the resulting decision.
Untrusted inputs can redirect an agent
An agent can follow a valid execution path after its reasoning has been redirected by untrusted input. Poorly constrained agents can leak private information or misinterpret instructions in ways that create safety hazards. Malicious prompts or poisoned data sources can also manipulate an agent into bypassing safeguards or behaving unpredictably.
The mechanism matters. Prompt injection arises when a system does not clearly separate trusted internal instructions from untrusted external data. An agent may need external material to complete a task, but that material does not become a trusted instruction merely because the model can read it.
Treat the boundary as part of the harness, not as a wording preference inside one prompt. Identify which instructions define the job, which retrieved material is only data, and which proposed actions still face policy and permission checks. The model's response is only one stage of the path.
This risk is especially important when the agent can act. A misleading input that changes an answer is a content failure. The same input reaching an agent with tools can shape a proposed system change. The decision class still determines whether that proposal remains advice, waits for approval, executes within a boundary, or is prohibited.
Connected systems amplify a compromised action
Tool access expands both useful reach and the path a compromise can travel. AI agents introduce security risks because they operate autonomously and interact with external systems. When agents connect to tools, APIs, and automation pipelines, a compromise can cascade across an organization's systems.
The mechanism can be traced as a chain:
- An agent receives a malicious or misleading input.
- The compromised reasoning shapes a tool or API call.
- The connected system accepts or forwards the action.
- A downstream automated system continues from the changed state.
An error or compromise in one agent can therefore propagate and become amplified through downstream autonomous systems. In banking, an agent can expose account data, make an unauthorized change, or give a customer an incorrect explanation in seconds. These are different consequences, but each begins with an agent whose connected action reaches beyond the model response.
The relevant review surface is the whole execution path. Trace the original request, the agent's available tools, the connected service, and every downstream process that may continue from the result. That path shows where policy evaluation, approval, verification, containment, and recovery have to be specified for the use case.
External-system interaction is what lets an agent coordinate work across systems. It also gives a compromise somewhere to spread. An agent architecture should therefore be read as an authority and state design, not merely as a diagram of model calls.
When is a banking-agent use case ready to pilot?
A candidate is ready to pilot when four things can be specified: its business scope, autonomy level, controls, and success metric. If those points cannot be stated, the candidate remains a demo.
Business scope names the work under consideration. Autonomy level identifies the applicable decision class. Controls define the policy, permission, approval, verification, and recovery boundaries around the action. The success metric gives the pilot an intended objective against which it can be assessed.
"Use an agent for customer support" is not yet a useful pilot boundary. The candidate has to say whether the agent retrieves internal answers, reads customer data, updates a record, or triggers a downstream process. It also has to state whether the agent recommends an action, waits for approval, or acts within a defined policy. Those choices turn a broad application label into a workflow whose reach and autonomy can be reviewed.
The access path then needs its own review. When an agent can read customer data, call internal services, invoke MCP servers, update records, or trigger downstream processes, the bank has to govern the result and the way the agent reaches it. Two systems aimed at the same business outcome can present different operating questions when one only retrieves information and another changes a record.
AI risk management includes deciding whether a system achieves its intended purpose and objectives, and whether its development or deployment should proceed. That decision is easier to inspect when the pilot specification states the workflow and authority boundary plainly. A worked agentic AI example can help expose the loop before tools and permissions are added to it.
Bank AI governance extends beyond model risk
Bank AI governance can place model risk within a wider framework that also covers cyber, IT, legal, and regulatory risk. An agent crosses these domains because its behavior is not confined to a model output. It can handle data, use credentials, call systems, and initiate an operational action.
A coordinated governance model can combine three responsibilities: business ownership, centralized enablement, and independent oversight across the lines of defense. Business ownership keeps the intended purpose and operating decision visible. Centralized enablement supports a common way to build and manage systems. Independent oversight preserves a separate review role.
Third-party dependencies widen the review again. They can introduce data leakage, biased outputs, security vulnerabilities, unclear accountability, and regulatory noncompliance. Those risks belong in the workflow review when an external model, tool, data source, or service sits in the execution path. The dependency is part of the system that acts, even if it is not operated by the bank.
This broader view keeps the model from becoming a stand-in for the whole architecture. The difference between an agentic system and a plain language model becomes important when the design adds tools, state, permissions, and execution. Governance has to follow those additions across the functions responsible for them.
Regulatory exposure follows the use of the system
Regulatory treatment depends on where and how an AI system is used. The EU AI Act sets risk-based rules for developers and deployers regarding specific uses of AI. That is a jurisdiction-specific example, not a universal classification for every banking workflow.
Financial reporting creates another scoped consequence. When AI systems participate in financial reporting, inadequate audit trails can put the associated certification at risk. The relevant fact is the system's participation in that reporting process and the audit trail attached to it.
These examples reinforce the value of a use-case record that names the workflow, authority, accessible systems, accountable owners, and resulting evidence. They do not supply one global approval rule. The applicable legal and compliance review follows the actual use and jurisdiction.
Start with one workflow, not an application category. Write down its goal, the context it may gather, the tools it may use, and the event that completes the task or hands it to a person. Then record the reachable systems, permitted changes, approval boundary, audit evidence, post-action verification, and recovery behavior.
Apply the Banking Delegation Matrix to one candidate workflow before expanding its authority. If the design still treats model output and system action as the same thing, compare agentic AI with a language model, then return to the matrix with the tools and execution path made explicit.