A Password Is Not an AI Agent Mandate

Banking agents need a clear mandate

On 22 October 2026, Reuters reported that major US banks were restricting third-party AI agents from customer accounts.

In some cases, customers supplied their own login details. The resulting problem is more complicated than conventional account theft: a bank may see apparently valid credentials without knowing whether the customer directed the particular action being attempted.

That exposes an important distinction: credentials may authenticate access. They do not define an AI agent’s mandate.

Access and authority answer different questions

Consider a customer who asks a personal assistant to find a better return on their savings.

The assistant may need permission to read balances and interest rates. That does not automatically authorise it to withdraw funds, close an account or commit the customer to a new financial product.

A username and password cannot express that distinction. They usually expose the same account interface used by the customer, potentially making a narrowly delegated task appear to carry the customer’s full authority.

A safer connection should preserve several separate facts:

• Which customer granted access.
• Which agent or service received it.
• Which accounts and information are in scope.
• Which actions are permitted.
• What limits or approvals apply.
• How long the authority lasts.
• How it can be changed or withdrawn.

Read permission must not become transaction permission

Financial-data sharing already demonstrates that access can be bounded.

Token-based connections can permit an approved third party to retrieve selected information without receiving the customer’s login credentials. Consent records can show which party has access and allow the customer to revoke it.

Agentic systems extend the problem because they do more than retrieve information. They can formulate plans, change methods and propose consequential actions.

An assistant permitted to compare savings products should not silently acquire authority to move money because it concludes that transferring the balance is the most efficient way to complete the task.

The new action needs its own evaluation.

Replanning must not enlarge the mandate

An agent may encounter a blocked interface or unavailable service and choose another route.

That adaptability can be useful, but it creates a governance risk. A failed method must not become permission to pursue the same objective through any available channel.

If an agent changes the account, recipient, amount, product or method, the organisation may need to establish:

• Whether the new action remains within the customer’s mandate.
• Whether the financial institution permits that form of access.
• Whether transaction limits still apply.
• Whether fresh confirmation is required.
• What should happen if the relevant authority cannot be established.

Depending on the circumstances, the result might be to Allow, Deny, Modify, Step Up or Stop the Line for that proposed action.

Stopping one transaction would not require the assistant or unrelated read-only activity to be disabled.

Evidence must separate mandate from effect

A record showing that a customer connected an agent does not prove that every subsequent action was authorised.

Equally, a bank record showing that money moved does not establish what the customer asked the agent to do.

A useful account may need to connect:

• The customer’s stated mandate.
• The agent and service version receiving it.
• The information and accounts made available.
• The consequential action proposed.
• The authority evaluation returned.
• Any modification, refusal or escalation.
• The instruction presented to the bank.
• Trusted evidence of what the bank accepted and made effective.

Records of authorisation and evidence of execution remain distinct. Neither should be presented as proving the other.

A bounded PF Systems exercise

A suitable PF Systems exercise would use synthetic accounts and a controlled shadow workflow. It would not connect an agent to a live bank account or initiate a transaction.

Representative requests could include:

• Reading a balance.
• Comparing products.
• Proposing a transfer within an agreed limit.
• Changing the destination account.
• Exceeding a permitted amount.
• Continuing after authority has expired.
• Attempting an alternative route following refusal.

PF Memory could supply the approved mandate and relevant context without deciding or executing. PF Kernel could evaluate each proposed action and return Allow, Deny, Modify, Step Up or Stop the Line. PF Core could preserve linked evidence of the captured governed evaluation.

ClientBridge could connect controlled systems without inheriting PF Kernel’s authority. Proof Harness could qualify evidence against the defined exercise without certifying the agent or financial service. PF Trace could display received evidence without manufacturing it.

Trusted evidence from the simulated financial service would still be required to establish what it accepted.

PF Systems would not determine whether a transaction was legally authorised, prevent fraud, certify a banking integration or guarantee financial safety.

The commercial lesson is straightforward: if an AI agent acts for a customer, the mandate must describe more than how it gained access. It must establish what that agent is permitted to do now.