Can an AI support agent access customer account data?

Yes, but only the slice the conversation needs. An AI support agent can read a verified customer's account data relevant to why they got in touch, through read-only access scoped field by field. It should not have standing access to every record, to internal fraud or financial crime notes, or to data about other people on the account.

What conditions decide how much it sees?

Four conditions, all of which must hold at once.

The customer is verified. Before verification, the agent sees nothing about the account beyond what it needs to run the check. After it, access opens to the level that check allows. A one-factor pass might allow balance and recent orders; changing anything needs more. How to sequence this is set out in verifying a customer's identity before discussing an account.

The data fits the contact reason. A customer asking about a delivery does not need the agent reading their payment history. Data minimisation is a principle of data protection law, under Article 5 of the GDPR and its equivalents, and it maps directly onto agent design: retrieve per question, not per customer.

The field is in the agent's scope. Access is granted per field group, not per database. Contact details, orders, balances and case history can be in scope for a support agent. Internal risk scores, investigation notes and special category data such as health information normally are not.

The access is logged. Every read is filed with the conversation it served. If a customer later asks who looked at their data and why, you can answer.

What may the agent see, and what stays with a person?

• May read after verification: contact details on file (partly masked when read back), order and service history, balances and recent transactions, open cases and their status, communication preferences.
• May read but not repeat: internal notes written for staff. The agent can use them for context but should not quote them, because they were not written for the customer.
• May not read: fraud and financial crime flags and notes, credit scoring detail, health or other special category data, and details of joint holders or authorised users beyond what the verified customer is entitled to see.
• Stays with a person: any request that needs those closed fields, such as why an account is restricted, plus subject access requests, which have their own process and deadline.

Joint accounts deserve their own line. Two people share the account but not necessarily every detail: one holder's separate contact details or individual notes should not be read out to the other. Scope access by the person verified, not just by the account number.

An illustrative example

Take an energy supplier's chat agent. A verified customer asks why their latest bill is higher than usual.

The agent reads the last six bills, the meter readings behind them and the tariff on record. It explains that the bill used an estimated reading because no actual reading was submitted, and offers to take one now. It does not open the customer's debt collection notes, though they exist, because the question did not need them.

Later the customer asks why they were refused a payment plan the previous winter. The reason sits in notes outside the agent's scope. The agent says it cannot see that decision, records the question, and routes it under the escalation matrix for customer support agents.

What controls make it safe?

• Scoped credentials. The agent's connection to each system returns only the permitted fields. The restriction is in the integration, not in the prompt.
• Session binding. Access is tied to the verified customer in this conversation. The agent cannot look up a different customer mid-chat because someone asks it to.
• Masking on read-back. Email addresses and phone numbers are partly masked when spoken or shown, so a shoulder-surfer gains little.
• Read-only by default. Writes are separate capabilities, each with their own checks, such as changing a customer's name on an account or deleting an account.
• Access record. Each retrieval is filed with field names, time and purpose.

Recovery of an account the customer can no longer access is the one case where the agent may see slightly more before full verification, to match details, and it is covered in handling account recovery requests.

Where Pryme fits

In Pryme, account data reaches the agent through the Pryme Context Protocol, field by field, each stamped with its source. Scope is set per capability, so a billing agent and a delivery agent see different slices of the same customer. More is in the AI support agent that knows when to say no.