No, not as a standing permission. A bank's AI agent should read the accounts relevant to the case in front of it: the authenticated customer it is serving, or the accounts named in the investigation it was assigned. Bank-wide read access turns one agent into a single point of exposure, and data protection law expects access to match purpose.
Why is "read only" not the same as "safe"?
Reading looks harmless because nothing changes. But an agent with broad read access can disclose what it reads. A customer-facing agent tricked into looking up another person's balance, a summary that pulls in a joint account holder's transactions, a prompt injection hidden in a document that asks for "all accounts with this surname": each is a disclosure, and each is possible only because the access existed.
Under GDPR and UK GDPR, the principles in Article 5 include data minimisation and purpose limitation. An agent that can see every customer to answer one customer's question is hard to square with either.
What should decide the agent's access?
The task, the customer and the moment. Access should be granted per case, not per agent.
| Agent's job | What it should read | What it should not |
|---|---|---|
| Customer service in an authenticated session | That customer's accounts and products | Any other customer, including family members, unless a mandate applies |
| Fee refund handling | The account and fees in the request | The customer's other products, unless policy requires it |
| Fraud or money mule investigation | Accounts linked to the case by payments or identifiers | Unlinked accounts, browsed speculatively |
| Complaint drafting | The complainant's records for the period in dispute | Unrelated history |
| Portfolio reporting | Aggregated or pseudonymised data | Named customer records |
The tighter scoping for transaction data is covered in whether an AI agent can read a customer's transaction history.
How is case-scoped access enforced?
Not by telling the agent to look only at the right customer. By making other customers unreachable.
- Session-bound tokens. In a customer channel, the agent's tools accept only the authenticated customer's identifiers. A request for any other account fails at the tool.
- Case-bound scope. For back-office work, the case defines which accounts may be read. Widening the scope, for example adding a linked account to an investigation, is an action that is recorded and, above a threshold, approved by a person.
- No free search. The agent should not have a tool that lists customers by name, postcode or balance.
- Aggregates for analysis. Questions about the portfolio go to a reporting layer with pseudonymised data, not to live customer records; see how to give an AI agent read access to your data warehouse.
What stays with a person?
- Granting access outside the current case, such as a review across many customers.
- Deciding that a linked account belongs in a financial crime investigation, when the link is weak.
- Approving any bulk extract of customer data.
- Reviewing the access record when something looks wrong.
An illustrative example
Take a retail bank using an agent to handle fee refund requests from customers in its app. A customer asks why they were charged an overdraft fee and whether it can be refunded.
The agent's session token covers that customer's current account and nothing else. It reads the fee, the balance history for the days around it and the bank's refund policy. It finds a salary payment arrived a day late, drafts a refund within the policy limit, and processes it at depth 3. The process is set out in how to handle fee refund requests on bank accounts with an AI agent.
Halfway through, the customer asks the agent to check whether their partner's account was charged too. The agent cannot. The tool refuses because the partner's account is outside the session, and the verdict is filed. The agent explains that the partner needs to ask from their own login.
What about internal agents with broad roles?
Some internal roles do range widely, such as a financial crime analyst. Even then, the agent should work case by case, with each widening of scope recorded. Business banking has a parallel question about a company's own accounts, covered in whether a finance agent should have access to the company's bank accounts. The bank-wide limits are in AI agents in banking: what they may and may not do.
Where Pryme fits
In Pryme, read access is a capability like any other, bounded by role scope and the bank's own limits at the moment of action. Facts arrive stamped with their source, so the record shows not just that the agent read an account but which system it came from and under which case.
Questions people ask
Does pseudonymisation make bank-wide access acceptable?
For analysis, often yes, because the agent is not handling named individuals. It does not help a customer-facing agent, which needs real records for the customer in front of it.
How should the bank audit agent access?
Sample the record of reads, check each against the case or session that justified it, and investigate any read without a matching reason.
What if a staff member asks the agent about another customer?
The agent should apply the same rules it would for the staff member's own system access. If the staff member is entitled to that record for that purpose, the case should say so.