Every enterprise AI discussion eventually reaches the same diagnosis: the data is not ready.
Sometimes that is true. Records are incomplete, documents conflict, and ownership is unclear.
But many banks do not have only a data problem. They have a more difficult problem hiding underneath it.
They do not know how to give an AI system enough access to be useful without giving it enough access to become dangerous.
The next bottleneck in banking AI is not retrieval. It is permission.
Access turns a demo into a product
A demo works with a prepared set of documents. A production assistant needs live context.
An advisor-support tool may need client holdings, risk profile, previous meeting notes, approved research, product restrictions, and current policy. A service agent may need account status, transaction history, identity information, open complaints, and communications. A compliance agent may need to connect behavior across customers, entities, payments, and jurisdictions.
Without access, the system gives generic answers. With broad access, it may reveal information the user is not entitled to see or take an action the user is not authorized to request.
This is why the model is the cheapest part of enterprise AI. The expensive work is connecting context while preserving the rules that make it safe.
The problem becomes more serious with agents. A human employee usually navigates systems one screen and one case at a time. An agent can search thousands of records, combine previously separate data, call several tools, and act at machine speed. A permission that looked acceptable for occasional human use can become excessive when exercised continuously and autonomously.
Role-based access is necessary and insufficient
Banks already have access controls. They assign roles, groups, entitlements, and approval levels. Why not reuse them?
They should, but the existing model has gaps.
First, employee roles are often broad. Entitlements accumulate, shared accounts persist, and temporary exceptions become permanent.
Second, AI creates information through combination. Two data points may be harmless separately and sensitive together. A model can infer relationships, vulnerabilities, or intent that no source system stored explicitly.
Third, an agent acts on behalf of someone. The institution must distinguish the user's identity, the agent's identity, the delegated purpose, and the permissions of every tool called along the way. A shared API key cannot explain that chain.
NIST's agent identity and authorization guidance makes the risk explicit: weak identity and authorization expose organizations to data leakage, compliance failure, prompt injection, and unpredictable behavior. NIST recommends treating agents as first-class identities rather than letting them borrow user credentials.
An agent needs its own badge. It also needs to show whose instructions it is carrying.
Five permissions every AI workflow must define
The usual question is, “Can the model access this data?” That is too binary.
I would require five dimensions of permission.
1. Principal
Who is requesting the work, and on whose behalf is the agent acting?
The system should preserve the chain from human or business process to agent to downstream tool. Every action should be attributable. Shared credentials destroy that evidence.
2. Purpose
Why is the information being used?
Access to prepare a scheduled client review does not automatically authorize training a model, prospecting, employee monitoring, or marketing. Purpose should be enforced as part of the workflow, not written only in a privacy notice.
3. Scope
Which customers, documents, fields, time periods, and systems are included?
“Read access to the CRM” is not a safe scope. A wealth advisor's agent may need specific client records but not every client in the institution. A policy assistant may need approved documents but not draft legal advice or investigation files.
4. Action
What may the system do with the information?
Reading, summarizing, comparing, recommending, updating, sending, and executing are different permissions. Retrieval access should not silently become transaction authority.
5. Duration
How long does the permission last?
Agents should favor short-lived, task-specific credentials over standing access. When the case closes, the delegated authority should expire. When the user's role changes, the agent's effective scope should change with it.
These five dimensions turn access from a static entitlement into a controlled delegation.
The control must follow the source
A common architecture copies documents into a vector database and lets an assistant search them. That can improve retrieval. It can also detach content from the source system's permission model.
If a confidential document becomes an embedding without its classification, owner, geography, retention rule, and access list, the AI layer has created a second information system with weaker controls than the first.
The safer pattern is permission-aware retrieval: evaluate access at query time, filter before content reaches the model, preserve source entitlements, and cite the material used. Outputs should inherit restrictions from their sources.
DBS provides a practical signal in its 2025 reporting. The bank says DBS-GPT gives employees role-based access to more than four million policies and content items. The value is not simply that the system knows four million things. It is that access is connected to role.
That is the difference between enterprise search and governed institutional intelligence.
Separate permission to think from permission to act
An AI system may be allowed to analyze information without being allowed to change anything.
This separation should be deliberate. A research agent can prepare a recommendation. Another control can validate the request, check policy, confirm the user's authority, and approve an action. High-impact steps can require a person or a deterministic rule outside the model.
OWASP calls the failure to maintain these boundaries “excessive agency”. Its examples include read-only tasks connected through identities that also have update and delete rights, or agents using a generic privileged account rather than the permissions of the individual user. The recommended response is least functionality, least privilege, user-context execution, and explicit approval for high-impact actions.
Policy should constrain capability before model reasoning begins.
Why “more data” can make the system worse
The Bank of England and FCA survey found that four of the five most frequently cited current AI risks were related to data: privacy, quality, security, and bias or representativeness. It also found that 46% of respondent firms had only a partial understanding of the AI technologies they used, compared with 34% reporting complete understanding. Third-party models were a major reason for the gap.
Adding more sources to a system increases context. It also increases the number of owners, classifications, retention policies, jurisdictions, vendors, and failure paths.
This is where the instinct to centralize everything becomes dangerous. The objective is not to create one giant pool that every model can search. It is to make governed data available for defined work under observable policy.
The first valuable AI systems will often be narrow for this reason. As discussed in The First Banking AI Winners Will Be Invisible, a controlled workflow with a specific queue can create more value than a universal assistant with vague authority.
Measure permission quality
Permission architecture needs operating metrics, not just an annual access certification.
I would monitor:
- requests denied correctly and incorrectly;
- attempts to reach data outside task scope;
- use of standing versus short-lived credentials;
- high-privilege tool calls;
- human approvals and reversals;
- outputs containing restricted information;
- orphaned agent identities and unused entitlements;
- time required to revoke an agent across every connected system.
These signals reveal whether controls enable work or force workarounds. A system denied too often will not be adopted. A system never denied may not be controlled.
Make permission part of product design
Banks frequently involve security and compliance after selecting the AI product. That creates a predictable result: the vendor demonstrates broad capability, the control functions narrow access late, and the final tool becomes too restricted to solve the original problem.
Permission design should begin with the job. Which data is necessary? Which fields are unnecessary? Which action is the system expected to complete? What is the lowest authority that still produces value? How will the institution prove who saw what and why?
Late permission design also produces the ceremonial approvals described in “Human in the Loop” Is Not a Governance Model. The tool is purchased before the organization resolves the authority required to operate it.
The answer is not unrestricted access. It is precise access.
The banks that solve this will not merely have cleaner data. They will be able to turn institutional knowledge into useful action without losing control of who can know, infer, or do what.
That is the real data advantage.
Sources
• NIST — Why Agentic AI Needs a Strong Identity Foundation
• DBS Annual Report 2025 — CEO reflections
• Bank of England and FCA — Artificial intelligence in UK financial services 2024
