AI access control for firms: what should carry over
6 minutes read
An AI tool that ignores your firm's existing permissions is a new access problem, not a productivity win. What should carry over, and how to check.
A firm spends years building access rules: who can open which client folder, who can see which financial model, who loses access the day they leave. Connect an AI tool without carrying those rules over, and it can quietly undo all of that. AI access control for firms is not a new category of permission to design from scratch. It is the same rules your firm already runs, applied to a new user of your data.
What access control means once AI is in the mix
An AI tool should never see more than the person using it is already allowed to see. That is the whole rule. If a junior analyst cannot open a partner's pricing model, an assistant working on that analyst's behalf cannot pull from it either, no matter how convenient a shared knowledge base would be.
Firms get this wrong in a specific, common way: they connect an AI tool to "the firm's knowledge" as one undifferentiated pool, because building a shared source library feels like the whole point of connecting AI to internal data. But a pool with no boundaries is not a knowledge base. It is every permission the firm has ever set, flattened into one open drawer.
Where the boundary actually breaks
The failure rarely looks like a hack. It looks like a workflow.
- A shared assistant with broader reach than any one user. Someone configures an assistant against "all of drive" or "all of the client workspace" because scoping it felt like extra setup, and now everyone who can talk to the assistant can retrieve documents they were never granted direct access to.
- An integration that authenticates once, at admin level, for everyone. The connection to the firm's document store gets set up with an admin's credentials, and after that every user of the AI tool inherits the admin's reach rather than their own.
- A departed employee's access outliving their employment. Offboarding checklists cover email and the CRM. An AI tool with a standing connection to client folders is easy to forget, and a live connection is still a live connection after someone leaves.
- Client material moving into a general workspace. A document a client shared for one engagement gets used to answer a question on an unrelated one, because nothing in the tool distinguishes which client the material belongs to.
None of these require anyone to do something wrong on purpose. They are what happens when a tool is easier to set up broad than scoped, and nobody revisits the setup once it works.
What should carry over, mapped
The permissions a firm already has should apply the same way inside an AI tool as they do everywhere else. This is the check to run against any tool before client data goes near it.
| Existing access rule | What should happen inside the AI tool |
|---|---|
| A user can only open documents in their own workspace | The AI tool respects that scope when retrieving sources, not "all connected documents" |
| A client's material is restricted to the engagement team | AI-generated drafts for that client draw only from material scoped to that engagement |
| A role has read-only access to a system | AI access through that connection is also read-only, not elevated by the integration |
| An employee's access is revoked on their last day | The AI tool's access to their sessions, keys, and connected sources is revoked on the same day |
| Actions in core systems are logged | AI usage against those same systems is logged with the same level of detail |
If a vendor cannot map their tool to a row in this table, that gap is the finding, not a detail to sort out later.
Questions to ask before connecting AI to your stack
Ask these before an integration goes live, not after a client asks who could see their material.
- Does the AI tool inherit the permissions of the person using it, or the permissions of whoever set up the connection?
- Can access be scoped per client, per engagement, or per document, or is the connection all-or-nothing?
- When someone's access to a source system is revoked, does the AI tool's access to that source revoke automatically, or does someone have to remember to do it separately?
- Is there a record of what the AI tool retrieved and when, in enough detail to answer a client's question about their own material?
A vendor that answers all four with specifics is describing an access model. A vendor that answers with "it's flexible" is describing the opposite.
Access boundaries and offboarding
The offboarding gap is worth calling out on its own, because it is the one that turns a design question into a live risk. A person leaves, their laptop gets collected, their email gets disabled, and their access to the CRM gets pulled. An AI assistant they had connected to a client workspace six months earlier, on the other hand, often keeps running on a token nobody remembers issuing. As covered in AI security and trust for client work, that connection needs the same offboarding step as everything else on the checklist: a named owner, checked on the day someone leaves, not discovered during a security review.
How this fits together with connected knowledge
This is the other half of connecting your firm's stack to AI. Connecting sources makes drafts better because they come from real, current material instead of what an assistant already knows. But that same connection is where access boundaries either hold or quietly stop applying. The two decisions, what to connect and what should still be off-limits once it is connected, have to be made together. Treating the second one as an afterthought is how a productivity project turns into an access incident.
Hebno's access model is built to be the second answer, not the first: connections inherit the permissions your firm already runs, activity is logged with enough detail to answer a client's question about it, and revoking someone's access closes the AI connection along with everything else. See the security page for the full detail, or book a demo to walk through how access boundaries hold up against your firm's specific setup.
