Customers are bringing personal AI agents into their financial lives

A customer asks a personal AI agent—Muse, Dots, Instinct, or whichever comes next—to review a retirement account and rebalance it within agreed limits. The request seems reasonable. It is the customer’s account, after all. Why should the financial institution be concerned?

A valid customer login does not, by itself, communicate the scope of an agent’s delegated authority. The session may permit actions far beyond the customer’s request, such as withdrawing funds or changing beneficiaries. An agent may take those actions even when the customer never intended it to. For the institution, the challenge is identifying the agent, verifying its authority, and enforcing its limits.

Recent reporting from Axios on banks restricting agent access brings that challenge into focus. Institutions have a responsibility to protect accounts against actions beyond the customer’s authorization. But customers also need a supported way to use their chosen assistants to help manage their finances.

When account access exceeds the customer’s intent

Without a dedicated way to delegate access, a customer may give a personal AI assistant their credentials or let it use an existing login session. Automation defenses may block that access. If the agent gets through, however, the session may allow actions beyond what the customer authorized. Blocking alone does not serve the customer’s request; allowing access without task-specific controls may leave the agent’s authority insufficiently bounded.

Delegation to an LLM-based agent adds another challenge: the agent may depart from the customer’s instructions as it interprets new information. Indirect prompt injection can exploit this, steering it toward actions the customer never authorized. Enforceable limits matter even when the customer’s original instruction is clear. Broad session permissions can amplify the impact.

Attribution matters too. When an agent uses a customer’s authenticated session without separate attribution, the institution may struggle to distinguish the agent’s actions from the customer’s own. That ambiguity can complicate the detection and investigation of account takeover.

Reading balances, rebalancing investments, withdrawing funds, changing beneficiaries, and resetting a password carry very different consequences. Authorization for one does not imply authorization for the others.

A supported delegation path can identify the agent, record the customer’s consent, and enforce limits on available actions according to that consent and applicable institutional policy. 

Open banking offers a familiar precedent: dedicated APIs can give institutions greater visibility and control over customer-authorized third-party access. But when those APIs are read-only, they support viewing information rather than taking action. Customers increasingly want their agents to do both. Until permitted actions are supported too, the incentive to seek broader access remains.

Emerging protocols such as the Personal Agent Protocol (PAP) are beginning to define how personal agents identify themselves, establish sessions, and obtain authorized access. That shared foundation matters. Financial institutions still need to provide supported ways for agents to access information and perform permitted actions—and enforce customer consent, account rules, and institutional policy along the way.

This gap between behavior and infrastructure predates personal AI agents 

For decades, consumers have asked financial advisors to help manage accounts whose platforms offer no dedicated route for that relationship. Personal agents introduce a new kind of delegate—and make the need for explicit boundaries more urgent.

Pontera has been working for years to address this challenge within retirement accounts. Historically, advisors have managed these accounts manually, with their clients’ permission and login credentials. 

Pontera was built to enforce guardrails, audits and supervision around this practice. Customers authorize advisors to help manage held-away accounts through a platform that limits the available operations. Advisors can view only the account information needed to support the authorized advisory task and communicate rebalancing instructions. They cannot use Pontera to withdraw or transfer funds or change beneficiaries. They never receive the customer’s credentials, and their activity creates an auditable record.

The advisor supplies the instruction. Pontera’s software carries it out through predefined, programmatic workflows, with access limited to the operations the advisor is authorized to perform. The same principle should govern any future agentic capabilities: customer consent and institutional policy define the boundaries, and controls outside the model enforce them. 

That experience provides a practical foundation for agent delegation: separating what a delegate requests from what the platform permits and executes.

Making delegation explicit and enforceable

The external agent could formulate a request. A controlled access layer would check the requested action and its parameters against customer consent and institutional policy before passing an approved request to a predefined, deterministic execution workflow. 

The agent would have no authority to invent a new operation, expand its permissions, or waive a required approval.

Establishing that boundary begins with registering and verifying the agent, identifying its operator, and connecting it to the customer it represents. Emerging “Know Your Agent” approaches can help establish those relationships. Identifying the agent is only the first step. The customer must explicitly authorize what it may do on their behalf.

“Help manage my finances” is a goal. Authorization must specify the accounts, data, permitted actions, their limits, and the duration of access. Broader access requires renewed customer consent.

A workable delegation model can build on familiar security principles:

1. System and account limits: The access layer enforces which operations are available under applicable account rules and institutional policy, including limits on request rates, transaction amounts, and required approvals. Some operations, such as withdrawals, may be unavailable altogether.

2. Customer-delegated permissions: Within those boundaries, the customer authorizes what a particular agent may access or do, for which accounts, and for how long. Permission to read balances does not authorize a rebalance. Broader permissions require renewed consent, and any required confirmation of a specific action must be obtained before execution.

3. Attributable activity and revocable access: Every request and outcome should be attributable to the agent and the customer it represents, and visible to the institution for monitoring and audit. The customer should be able to revoke delegated access, and the institution should be able to stop activity that exceeds the permitted boundaries. Revocation must stop further access, including through active sessions.

4. Policy enforced outside the AI model: The agent’s behavior may change as it interprets instructions or encounters new information. Independent controls must enforce system limits and customer-delegated permissions whenever an action is requested. The agent cannot expand its own authority or bypass a required approval.

This approach applies established security principles for MCP interfaces to sensitive systems: expose only defined capabilities and enforce authorization whenever they are invoked.

None of this guarantees sound financial judgment. It establishes a boundary around what software is allowed to do and creates evidence for oversight when something goes wrong.

Pontera welcomes collaboration with recordkeepers and financial institutions to extend its delegation model to customers’ personal AI agents. That means combining controlled interfaces, including MCP, with explicit consent, institutional policy, deterministic execution, and visibility into activity.

Financial institutions need a dependable way to say yes to useful delegation—and enforce precisely what that yes allows.

The future is here, we must work collaboratively to address these challenges. 

This agent. For this customer. These actions. Under these policies. Until the authority ends.