What is RBAC for enterprise AI, and why should you care?

The campaign ended in March. The agency guest is still in the room in June. Nobody meant to leave them there. The invite was a courtesy, the workstream was busy, and the login looked harmless because the model was only supposed to summarise. Then a member pasted a CRM export into the thread so the assistant could “just take a look.” The guest never needed a production password. They inherited a session that could already see customer rows. When security asks who could see the file, the honest answer is a display name and a date that nobody reviewed.

That is the enterprise AI access problem in one room. Role-based access control — RBAC — is who is allowed to do what. For people it is familiar: guests, members, admins; remove the contractor when the project ends. For a model, the “who” is the session acting with someone’s credentials — reading files those credentials can reach, and sometimes proposing a change to a live system. A fluent answer can still be the wrong change in the wrong place.

What is AI governance is the parent definition. RBAC is the people-and-tools half. This essay is not a claim that one product has solved it. It is why the noun exists, what fails when a chatbot login is treated as the whole answer, and a way to start this quarter.

Why the noun exists

Classic RBAC, described by Ferraiolo and Kuhn in a NIST paper in 1992, assigns permissions to roles, then roles to people. The point was never elegance. It was that individual user-to-permission maps rot the moment headcount moves. A role is a job you can revoke.

Enterprise AI adds three questions the 1992 paper did not have to ask:

• Which jobs and files can this person — and this model, in this session — see?
• Which tools can it call?
• If it can change a live system, who must approve, and is that approval stored?

A chatbot login answers a fourth, narrower question: may this person talk to the bot? That is necessary. It is not the same as answering the three above. The login is a door. RBAC is the floor plan.

NIST’s AI Risk Management Framework puts the same idea in public language: govern, map, measure, manage. You cannot measure a write you cannot attribute. SP 800-207 on zero trust is the companion: do not assume a session is trusted because it signed in. A model that inherited a sales manager’s token is still a session, not a person you can walk to a desk.

Guests, members, and admins are who is on the job. The model side is which tools that session may call. Both belong in RBAC.

McKinsey’s State of AI keeps finding the same organisational pattern: use is ordinary, and operating redesign is not. Eighty-eight percent of respondents say their organisations use AI in at least one function; nearly two-thirds remain in experimentation or piloting. Programmes that scale a model into every function without scaling roles onto every job will discover the guest-and-paste problem as an incident, not as a design review.

The hidden failure

The failure is not usually a Hollywood breach. It is a customer record changed without a name next to the change, or a contractor who still sees a workstream after the project ended.

IBM’s Cost of a Data Breach research found that one in five organisations studied reported a breach involving shadow AI, and that high levels of shadow AI were associated with about $670,000 in higher average breach costs. Only 37 percent had policies to manage AI or detect unsanctioned use. You do not need those numbers to justify RBAC. You need one guest who outlived the job, or one unofficial tool that never received a role at all.

Microsoft and LinkedIn’s Work Trend Index found that 78 percent of AI users bring their own tools. That is shadow AI: useful, and outside the roles you think you assigned. The official RBAC matrix on the sanctioned chatbot does not cover the personal account on the phone. A board that has never seen the unofficial path is not conservative. It is uninformed.

Three failures follow when the login is treated as the control.

Inherited sight. A member pastes a file the guest should never have seen. The model summarises it for everyone in the room. Revoking the guest login later does not un-see the export. Roles that follow the job — not only the person — are how you close that gap. Roles that follow only the seat leave the file in the history.

Unsigned writes. Write-back means the AI changes a live system. Fail-closed means if nobody approves, nothing happens. A prompt that says “ask first” is not fail-closed. If the model can post because the connector was on for retrieval, you have given a session the rights of a clerk without giving it the duties of a clerk. Write-back governance is the checklist for that path.

Orphaned access. The campaign ends. The guest remains. The shared password remains. The “temporary” API key remains. Offboarding that disables a human account and leaves the model’s tool grants untouched is half an offboarding.

If AI only summarises public wiki pages, the stakes are lower. You can still use roles so the wiki is not everyone’s dump of customer data. You should care if you have guests on a job, if AI can write to CRM or finance systems, or if someone might later ask who approved a machine-initiated change.

Where Article 14 of the EU AI Act applies, human oversight is not a footer. People must be able to interpret the output and interrupt or refuse the system. A role that can open the chat but cannot refuse the write is not that oversight. You do not have to be in scope of the Act for the operational question to be useful. Customers and boards will ask it in other words.

How to apply it when AI can change records

Write-back means the AI changes a live system. A payload is the exact change, shown before it goes out. A signer is a person whose role owns that class of change — not “the channel,” not “the bot user.”

A practical sequence:

1. Keep the model from writing until you can name the object class and the signer. Write-back governance is the checklist. Read-only by default is the honest starting state, not a temporary embarrassment.
2. For each write class, name the approver role. Finance on a journal. The account owner on a discount. Legal on a clause that will be sent. If you cannot name the role, the class is not ready.
3. Store the payload and the decision so you can reopen them. What auditors are asking for is the evidence pack: a named person, a frozen change, a stored yes or no.
4. When someone leaves the job, remove them from the roster the same week. Review guest access on a cadence, not when security asks.
5. List the unofficial tools. Shadow AI is what happens when the unofficial path never got those roles. A ban without a usable sanctioned path moves the work to a phone.

Decision History — a log of actor, tier, and timestamp — can show who signed a proposal. It is not the statutory archive, the ledger, or the customer file the company already keeps. Do not buy a trail and retire the system of record. Counsel names where the books live. The product trail is how you walk a single change without reconstructing a chat.

What to ask a vendor

A short list of demo questions lives in what auditors are asking for. In one sentence: can they show who could see a job, which tool ran, and who approved a write — without a screenshot hunt?

Ask the concrete version. Pick a guest; show the files that session can reach; remove them and show the next run cannot. Name one connector; show it read-only; attempt a write and show the failure. Propose a change; refuse it; show the stored no. Ask whether Sales can see a payroll connector. “The workspace” is not an answer.

The EU AI Act and ISO/IEC 42001 are why those questions show up in procurement. You do not have to implement every clause on day one. You do need an answer you could give an auditor. ISO 42001 is a management system. It does not replace a named person on a payload. You can be on a certification path and still have an admin token on a model.

How to start this quarter

You need one job, one roster, and one write class that stays off until the signer is named.

This month, pick a cross-team job that already has guests. Write down who is on it and why. Remove anyone whose reason is “they were copied in.” Attach the two files the job needs. Keep connectors read-only.

Next month, name the first write class you might enable and the role that may sign it. Run one refusal in a sandbox. Walk what auditors are asking for against that change. Fill blanks as findings.

Then list unofficial tools that touch customer files, unpublished figures, or source code. You will not eliminate shadow AI with a memo. You will learn which sanctioned path is too slow — people leave the role system you designed because it cannot finish the job.

Score any product as an access review: named roster, named tools, write off until a signer exists, a stored no you can reopen. If the demo starts by sharing a password into a consumer model, you are scoring a chat seat.

How this shows up in Nimbus

Nimbus is a Collaborative AI operating system: humans and agent teams on the same workstream, with roles on the job rather than only on a chat login. Connectors default to read-only. Writes wait for a named approval. The platform reaches 2,000+ business tools; a connection is not permission to mutate the source. Governance is the product surface. Security states the compliance lines as they stand: GDPR today; ISO 27001 and SOC 2 Type 1 independent audits underway — not certificates for a slide.

Decision History logs actor, tier, and timestamp. It is a trail you can filter, not the statutory books-and-records store. Hugh Woods Ballard at Day Webster wanted specialists and people in the same place, and a way to see who approved what. Andy at Digby Fine English wanted humans still in the loop before anything commits. That is RBAC as a daily habit, not a policy PDF.

For how teams share the job once access is clear, see what is collaborative AI. For where the decision should live after the thread ends, see search is not memory.

Related reading

• What is AI governance
• What is write-back governance
• What auditors are asking for
• What is shadow AI
• What is collaborative AI

References

• Ferraiolo and Kuhn, Role-Based Access Controls, NIST, 1992
• NIST AI Risk Management Framework
• NIST SP 800-207, Zero Trust Architecture
• McKinsey, The State of AI
• IBM, Cost of a Data Breach research release, 30 July 2025
• Microsoft and LinkedIn, 2024 Work Trend Index
• EU AI Act, Article 14, human oversight
• EU AI Act, Regulation (EU) 2024/1689
• ISO/IEC 42001