On a Tuesday morning the operational risk committee at Fynbos Capital Bank, a fictional South African bank, was handed a one-page paper with a single question on it: should staff outside technology still be allowed to use the coding assistant? Over six months, a few hundred people in markets, credit and finance had used it to write spreadsheet macros, small Python scripts and, in a handful of cases, internal web tools that colleagues now relied on. Some of that work was excellent. Some of it nobody could explain.
The committee spent forty minutes debating yes or no. Neither answer survived the discussion. "Yes" meant accepting tools nobody owned, built against data nobody had classified. "No" meant cutting off the people who had found the most useful applications, and pushing the next round of experiments onto personal laptops. The question was framed wrongly. It was never whether staff may use AI. It was what each of them was authorised to do with it.
This series follows Fynbos Capital Bank through what came next: an interim rule, a redesign of access around entitlements, and finally a narrowing of access rather than a ban. Everything about the bank, its people, its systems and its figures is invented. The mechanisms are not.
Why the question is current
On 2 November 2026, Bloomberg reported that Goldman Sachs had restricted advanced AI coding tools, which the report named as Anthropic's Claude Code and Microsoft's GitHub tools, to engineering staff under internal guidance updated in October, after bankers and traders had been allowed to use them for months. According to the report, the bank weighed productivity and risk, and the restriction did not apply to "strats", staff who work across trading, quantitative research and software engineering. That is a report of one firm's internal policy. It does not show that the tools are safe or unsafe, and we draw no conclusion about the firm's reasons beyond what was reported.
What the report does show is that a large, regulated firm drew a line by role and by tool type, not across "AI" as a whole. That is the right instinct. This series argues it can be taken further: the line should be drawn by what a person may do, with which data, in which environment, and with whose review.
Blanket answers fail in both directions
A blanket yes treats an AI tool like a word processor. The tool is licensed, single sign-on is switched on, and everyone with an account may use it for anything the acceptable-use policy does not forbid. The policy then carries the whole load. It has to anticipate every combination of person, data and action, and it is read once at onboarding.
A blanket no treats every use as equally risky. It is simple to state and impossible to sustain. People keep the problem the tool was solving, so they solve it elsewhere. Our article on shadow AI as a governance design problem explains why careful professionals end up on the ambiguous path when the permitted one is unclear or slow.
Both answers share the same flaw: they decide at the level of the tool. But the risk of an AI tool is not a property of the tool alone. Summarising a public annual report and rewriting a credit-limit calculation in a production system can be done with the same product. They are not the same act.
Four capabilities, not one tool
Fynbos started by describing what its staff actually needed, rather than which products they had asked for. The answer came out as four distinct capabilities:
- A general assistant over approved internal knowledge. Drafting, summarising and answering questions from policies, procedures and product documents. No tools that write to any system.
- A sandboxed coding assistant. Writing and testing code in an isolated development environment, against synthetic or masked data, with no route to production credentials.
- A governed analytics copilot. Querying curated, read-only data products for analysis, with masking applied to personal information and outputs that stay inside the analytics workspace.
- A restricted change agent. Preparing changes to production systems through the normal delivery pipeline, with named approval before anything takes effect.
The four are not a maturity ladder. Most staff will only ever need the first. Some need the third. Very few need the fourth, and those that do need it for a narrow set of systems. Separating them made the committee's original question answerable: the coding assistant was not one thing to allow or ban, but capability two, and a very small slice of capability four, that had been handed out as if they were capability one.
The capability-and-authority matrix
The tool for making these decisions is a matrix, not a list. Rows are roles. Columns are capabilities. Each cell states what that role is authorised to do with that capability, and under what conditions.
Three things make the matrix work in practice.
First, the cells are not yes or no. They are conditions: "read-only over the markets data product, masked client identifiers, outputs stay in the workspace" is a cell. A cell marked "Not entitled" means exactly that: no default access for the role, though an individual may still request it with a use case. A cell that reads "yes" without conditions is usually a sign that nobody has thought about it yet.
Second, roles are the starting point, not the answer. The matrix sets a default per role, and individual entitlements can add to it through a request with a stated use case. The hardest cases, people whose work straddles business and engineering, get their own treatment in part 5 of this series.
Third, the matrix is about people's entitlements, not the authority of an agent once it is running. How much a deployed agent may do on each action is a separate design question, covered in Agent capability is not agent authority. The matrix decides who may operate which capability in the first place.
What a single entitlement records
A cell in the matrix becomes real when it is granted to a person. Fynbos defined an entitlement as a record with eight fields, held in its identity governance system alongside other access rights.
- Who. The named person and their role, taken from the HR system so that a move or a departure changes the entitlement automatically.
- Use case. The approved purpose in one sentence. "Build and test pricing scripts for the rates desk", not "coding". Because those scripts feed client quotes, part 5 of this series treats them as business-critical, which is why the review field below is independent.
- Data class. The highest classification of information the person may use with the capability. Fynbos uses four classes: public, internal, confidential and restricted.
- Environment. Where the capability runs: the managed browser, a local development sandbox, an ephemeral cloud workspace, the analytics workspace or the production pipeline.
- Action authority. What the capability may do on the person's behalf: answer, draft, run code in the sandbox, query, or prepare a change.
- Review. Who checks the output before it is relied on, and when. For anything leaving the person's own workspace, a named second person.
- Evidence. What is logged and retained, which part 7 covers in detail.
- Expiry. A date on which the entitlement lapses unless it is reviewed. Nothing is granted indefinitely.
The eight fields do the work that a policy document cannot. They are specific enough to enforce, they attach to one person and one purpose, and they can be revoked without affecting anyone else.
They are not the same thing as the eight parts of approval in Shadow AI is a governance design problem. Those are questions a person answers about one use before deciding. The entitlement is the enforceable identity record the organisation keeps once the answer is yes.
Where the controls sit
Entitlements are only useful if something checks them. At Fynbos the checks are spread across four places, each doing what it is good at.
Identity. Every capability sits behind single sign-on, and access is granted through groups that map to entitlements. The principle is the one set out in Identity before intelligence: the system must know who is asking before it decides what they may do.
The gateway. Model calls from the general assistant and the analytics copilot pass through a gateway that applies data-class rules, routes to approved models and records usage against the entitlement.
The environment. The coding sandbox and the production pipeline enforce their own boundaries: which networks, which credentials, which branches. Part 3 explains why a coding agent should be treated as an execution environment, not as a chat window.
The workflow. Review and approval live in the systems people already use for change and risk decisions, not in a separate AI process.
None of these is new technology, and much of it is the platform work described in From personal AI tools to a governed team toolchain. The new work is deciding, for each capability, which control enforces which field of the entitlement.
The South African frame
For a South African bank, several pieces of law and regulation shape this design, and neither was written specifically for AI. The Protection of Personal Information Act requires a responsible party to secure the integrity and confidentiality of personal information through "appropriate, reasonable technical and organisational measures" (section 19), and to ensure by written contract that an operator processing information on its behalf maintains those measures (section 21). An AI tool provider processing customer information on a bank's behalf will usually be such an operator. Because many model providers process information outside South Africa, section 72 on transfers of personal information to a third party in a foreign country also applies: it permits such transfers only under stated conditions, such as the recipient being bound by law, binding corporate rules or an agreement giving substantially similar protection. POPIA does not say your data must stay in South Africa explains what that means in practice.
The Prudential Authority and the Financial Sector Conduct Authority issued Joint Standard 2 of 2024, Cybersecurity and Cyber Resilience Requirements, which applies to banks among other financial institutions. Joint Notice 1 of 2024 set its commencement date as 1 June 2025. The standard includes requirements on identity and access management. In their first joint report on artificial intelligence in the South African financial sector (24 November 2025), the same regulators surveyed adoption across the sector.
An entitlement model does not by itself satisfy any of these. It does give a bank a way to show, person by person, that access to AI capabilities is deliberate, limited and recorded. This is general information, not legal advice: each institution should take its own advice on how the obligations apply.
A starting checklist
| Question | A crude answer | An entitlement answer |
|---|---|---|
| Who may use the tool? | Everyone, or nobody | Roles by default, individuals by request with a use case |
| With which data? | "No confidential data" in the policy | A data class per entitlement, enforced at the gateway |
| Where does it run? | Wherever it is installed | A named environment per capability |
| What may it do? | Whatever the product can do | Answer, draft, run in sandbox, query or prepare a change |
| Who checks the output? | The user, implicitly | A named reviewer when output leaves the person's workspace |
| How long does access last? | Until someone notices | An expiry date and a review |
If most of your answers sit in the middle column, you have a tool list. The right-hand column is an access model.
Key points
- The useful question is not whether staff may use AI, but what each person is authorised to do with it, on which data, in which environment and with whose review.
- Blanket access and blanket bans both decide at the level of the tool. Risk sits in the combination of person, data and action.
- Describe the capabilities staff need before choosing products. Fynbos found four, and most people need only the first.
- Replace the tool list with a capability-and-authority matrix whose cells are conditions, not yes or no.
- Grant each cell as an entitlement with eight fields, ending in an expiry date, and decide which control enforces each field.
Next: Part 2, An approved model is not an approved use case. All parts are on the series page.
How CloudNala can help
CloudNala runs AI access reviews for regulated organisations. We inventory the AI capabilities your staff actually use, separate them into distinct capabilities, draft the capability-and-authority matrix with your risk, security and privacy teams, and specify the entitlement record and the control that enforces each field, so that the next committee paper asks which cell to change rather than whether to ban a tool.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Access Review or write to us at consult@cloudnala.co.za