Banks and credit unions already know how to delegate authority. The harder part is enforcing it at the moment an AI agent’s request becomes an action.
Every bank and credit union already runs on delegated authority. A teller can process routine transactions, but a larger withdrawal may need a supervisor’s approval. A contact center representative can reverse some fees, but not all of them.
Nobody sees this as a lack of trust. It’s how institutions let people act quickly while keeping the actions that matter within bounds.
AI agents now need the same discipline around delegated authority. The shift is already underway. Deloitte points to banks such as Wells Fargo and PNC already building AI agents into how they operate and serve customers.
As these agents move from answering questions to initiating actions, the question shifts from what they can do to what the institution authorizes them to do.
That doesn’t mean giving an AI agent a teller’s limits. An institution may reasonably set tighter or different ones, including stricter verification.
What carries over is the discipline: deciding in advance what can be done independently, what needs a check, and what needs a person.
Banks Already Know How to Grant Authority
Delegated authority is one of the oldest controls in banking. Tellers work within transaction limits, and loan officers work within approval thresholds. Segregation of duties keeps the person who initiates a transaction from being the only one who approves it.
Dual control requires two people for certain actions. None of these practices assume staff is careless. They exist because the consequence of an action, not the competence of the person taking it, determines how much control the action needs.
The same structure carries into the contact center. A representative can update contact preferences or explain a charge on their own. Other requests, such as waiving a larger fee, changing the address on an account, or releasing a hold, may require additional verification, a supervisor’s approval, or a handoff to another team.
Each institution draws these lines in its own way. Representatives know where the lines are because the systems they work in enforce them.
This is the part of the analogy that matters most for AI. The AI agents banks and credit unions are bringing into the contact center don’t sit behind a teller window.
They handle the same calls, chats, and requests representatives handle. They face the same decisions about when to act, when to verify, and when to escalate.
Capability Doesn’t Confer Authority
Today’s AI agents can understand what a customer or member is asking, retrieve account information, reason through a multistep request, and initiate actions in the systems behind the conversation. That capability is what makes them valuable.
But capability and authority are different things. Capability determines what an agent can potentially do. Authority determines what the institution permits it to do.
Banks and credit unions already make this distinction with people. An experienced representative may be fully able to handle a complex account change and still need approval above a certain limit. Their skill doesn’t expand their authority. The institution’s decision does.
The same holds for AI agents. A more capable agent can take on more of the conversation, resolve more requests, and handle more complexity. That doesn’t mean it should be permitted to initiate every action it can technically perform.
That decision belongs to the institution, and it should be made deliberately, not inherited from whatever systems the agent happens to be connected to.
Deloitte makes a related point in its analysis of agentic AI risk in banking, arguing that banks should treat AI agents as “accountable actors,” in the same way they treat employees. Accountability starts with authority. An institution can’t hold an agent to boundaries it never defined, and defining them is what lets a capable agent do real work.
Authority also has two layers: defining it and enforcing it. Defining it is familiar ground for any bank or credit union. Enforcing it when an AI agent’s request becomes an action is where the problem changes.
Setting Authority Tiers for AI-Initiated Actions
If authority is the principle, tiers are how it becomes practical. Rather than approving or blocking an AI agent as a whole, an institution can define what each kind of action requires before it executes.
The factors interact. A large funds transfer and a phone number change look nothing alike on amount. But a changed phone number can redirect the one-time passcodes an institution uses to verify the member later, so a zero-dollar action can carry more consequence than its amount suggests. Amount alone can’t set the tier.
Each institution combines these factors into its own tiers, and each tier determines what an action needs in order to proceed. A reversible action under a set amount might proceed after standard verification. A larger or hard-to-reverse action might require additional verification or a second approval before it proceeds.
This is a mental model, not a standard classification. Two credit unions may tier the same action differently, depending on their members, products, and risk appetite. What matters is that the tiers are explicit and set by the institution in advance.
Per-action limits aren’t enough on their own, though. A single large request can be split into smaller actions that each stay below an individual threshold. Deloitte describes a related risk in multi-agent systems that it calls approval-threshold arbitrage: an unintended pathway in which each step appears policy-compliant on its own, while the overall pattern increases compliance, audit, and fraud risk.
Authority tiers should consider cumulative activity, such as total fee waivers on one account over a period, not just each request in isolation.
Where the Limits Are Enforced
Defining authority is half the job. The other half is making sure it holds when an action executes.
Policy defines the authority. Execution controls enforce it. A policy can state that an AI agent may not waive fees without approval, but it can’t stop the agent from requesting one.
What stops the waiver is a control at the point of execution, one that checks the requested action against the institution’s configured authority before anything changes.
That distinction matters more for AI than for people. A representative who is unsure about a limit can pause and ask. An AI agent handles requests at speed and at volume, often across several channels at once.
Its boundaries have to be enforced consistently at the moment of execution, not remembered.
Consider a member who asks an AI agent to waive an overdraft fee. The agent understands the request and determines that a waiver is appropriate. Before anything changes in the core, the request is checked: Is this action within the agent’s authority? Has the member been verified to the level it requires?
Does the institution’s policy require approval for this waiver? If the action is within the agent’s authority, the member has completed the required verification, and the waiver does not require approval, it executes. If more verification is needed, the member completes it first. If the policy requires approval, the request goes to a representative, with the context attached.
The AI agent decides what to request. The institution decides what is permitted. Something has to enforce that boundary when the action executes.
For banks and credit unions, that is where CCIP fits. CCIP sits between the AI agent, the CCaaS platform, and systems of record. It governs each requested action against the institution’s configured controls, checking it against the authority the institution has defined, the verification it requires, and any approval it calls for.
Each action available to an agent through CCIP can carry a risk tag and a flag for whether it needs human approval before CCIP executes it. Every tool call is logged, giving the institution an execution record it can shape to its own audit requirements.
Connectivity moves data. CCIP controls execution.
When the Agent Reaches Its Limit
Limits only work if reaching one is handled well. When a requested action falls outside the configured authority, the institution’s controls don’t permit it, so CCIP doesn’t execute it. What happens next depends on the tier. If the configured control requires additional verification, the action can proceed once the customer or member completes it.
Otherwise, the agent escalates to a person with the full context of the interaction. Either way, the agent tells the customer or member what happens next. For a closer look at these handoffs, see the questions to answer before an AI agent writes to the core.
Who Changes the Limits
Authority doesn’t end at deployment. Products change, fraud patterns shift, and agents take on new tasks. Each AI agent’s authority boundaries need a named owner, regular review, and changes approved through the same change management process the institution uses for its other controls.
Without a clear owner, limits set at launch drift out of step with how the agent is actually used. Ongoing governance keeps delegated authority meaningful over time.
The updated interagency model risk guidance issued in April 2026 excludes generative and agentic AI models from its scope. Federal Reserve Vice Chair for Supervision Michelle Bowman has said the agencies expect banks’ other risk management and governance practices to support adoption of these models.
AI agents don’t need arbitrary restrictions. They need explicit authority boundaries that reflect what the institution is prepared to authorize, and controls that enforce those boundaries when actions execute. Banks and credit unions already know how to do this. They’ve done it for tellers and representatives for decades.
CCIP brings that discipline to AI-initiated actions across systems of record, including Jack Henry, Fiserv, and FIS. It already supports 1.2B+ governed enterprise executions annually.
