Treat each AI agent as a privileged user. GLBA safeguards expect access to customer information to be limited to what each user needs, authenticated, logged, monitored and reviewed. An agent qualifies on every count: it needs its own identity, narrow permissions per task, no shared credentials, and records that show what it accessed and why.
What do the GLBA safeguards require?
GLBA requires financial institutions to protect the security and confidentiality of customer information against anticipated threats and unauthorised access that could harm customers. The implementing rules differ by supervisor, but in substance they expect a written information security programme that includes:
- a named person responsible for the programme;
- a written risk assessment covering risks to customer information;
- safeguards designed from that assessment, including access controls, encryption, secure development, multi-factor authentication, secure disposal, change management and monitoring of user activity;
- regular testing of the safeguards;
- staff training;
- oversight of service providers, including contracts requiring them to protect the data;
- an incident response plan;
- regular reporting to the board or senior management.
Access controls sit at the centre. The expectation is that only authorised users can reach customer information, and only the information they need.
Who does it apply to?
US financial institutions under GLBA, whether supervised by the banking agencies or under the separate rule set for non-bank firms. Our article on GLBA and AI agents handling customer financial data covers the privacy side; scoping questions are answered in does GLBA apply to AI agents handling customer data.
What does access control mean when the user is an agent?
Access rules were written with people in mind. Agents strain them in four ways.
Agents are often given service accounts with wide access. It is easier to connect an agent with one broad credential than to scope it. The result is an identity that can read every customer record, used by software that will read whatever it thinks is relevant.
One agent, many jobs. An agent that answers balance questions, drafts dispute letters and updates addresses needs different data for each. If permissions are set per agent rather than per capability, the agent has the union of all of them at all times.
Access is driven by language. A person opens a record because their task requires it. An agent opens a record because its reasoning suggested it. Without a control outside the model, a cleverly worded request can lead the agent to pull data it does not need.
Multi-factor authentication does not map neatly. MFA protects human logins. For agents the equivalent is strong machine identity, short-lived credentials, and authorisation checked on each request rather than once per session.
How do you meet the safeguards for agent access?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Risk assessment covers agents | Each agent and capability assessed for the customer data it touches | Risk assessment entries per agent |
| Least privilege | Permissions set per capability; agent can read only fields the capability needs | Permission map; refused-access logs |
| Unique identity | Each agent has its own identity, never a shared human or system account | Identity register |
| Strong authentication | Short-lived, scoped credentials issued per task; no long-lived keys in configuration | Credential issuance logs |
| Customer authentication before access | Agent receives account data only after the customer is verified by your system | Verification status in each case record |
| Monitoring of activity | Every read and write by the agent logged with the capability and case | Access logs; alerting on unusual volumes |
| Encryption | Data encrypted in transit to the platform and model provider, and at rest in agent stores | Configuration evidence; vendor report |
| Change management | Any change to an agent's access approved through change control | Change tickets with approvals |
| Service provider oversight | Platform contract requires safeguards; controls reviewed periodically | Due diligence file; annual review |
| Testing | Access controls tested, including attempts to make the agent overreach | Test reports |
The testing row is often missed. Testing should include adversarial prompts that try to make the agent read records outside the case in front of it. If the agent can be talked into it, the control is in the model, not around it.
These controls also serve other frameworks. Our guide to mapping AI agent controls to several regulations at once shows how one access control can evidence GLBA, ISO standards and EU rules, and ISO/IEC 42001 controls mapped to AI agents gives the AI management system view.
What will an examiner ask?
- How many agents have access to customer information, and what can each reach?
- Are permissions defined per agent or per capability?
- Show us the identity and credentials an agent uses. How long do they last?
- How would you detect an agent reading far more records than usual?
- When were agent access rights last reviewed, and who signed off?
- How do you test that the agent cannot be persuaded to exceed its access?
What do the safeguards not cover?
They do not decide what the agent may do with data once read; that is a question of the actions it is authorised to take. They do not govern the quality of the agent's outputs. They do not replace sharing restrictions under GLBA's privacy rules. For the wider map of obligations, see AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
In Pryme, access is granted per capability, not per agent. The sources an agent can reach are named in its brief, and every action passes the minimum chain: role scope, certificate, sources, your own limits and the platform guardrails. The verdict names which bound decided and is filed in an append-only record, which gives an examiner the access trail per case.
Questions people ask
Should agent access reviews follow the same cycle as staff access reviews?
At least the same cycle, and also whenever the agent's brief changes. Agent permissions change through configuration, often more often than staff roles, so tie review to change control.
Is reading data the same risk as writing it?
No. Write access lets an agent change records, which can harm customers directly. Separate read and write permissions, and require stronger approval for any capability that writes customer information.
Can we let the agent search across all customers to find a match?
Only if the capability requires it and the search returns only what is needed. A search that returns full records for many customers to resolve one case is excessive. Return identifiers first and let the agent open one record once the match is confirmed.