When a team member leaves, what can the AI still access
An internal AI assistant should follow source permissions. Review its access when roles change, and verify removal rather than assuming it.
The short answer
An internal AI assistant should never see more than the person using it is allowed to see in the underlying systems. When someone changes role or leaves, their access to those source systems changes, and the assistant’s access on their behalf should change with it. The risk sits in the gaps: shared service accounts, cached summaries, exported files and old conversation history. Map them, review them on every role change, and test that removal actually worked.
Key points
- The assistant should inherit permissions from the source systems, not hold its own broader set.
- A role change is as important as a departure. People often keep old access when they move.
- Service accounts, cached answers, indexes and chat history can outlive a permission change.
- “Removed” should be verified with a test question, not assumed from a settings screen.
- Name one owner for the assistant’s access map.
Where assistant access usually leaks
An internal assistant may connect to several sources: a document drive, an ERP or property system, a CRM, email, finance reports. There are two common ways to connect them:
-
Per-user access: the assistant queries each source as the person asking. If they cannot open a file directly, the assistant cannot read it for them.
-
Shared access: the assistant uses one powerful account to read everything, then tries to filter answers by role.
Per-user access is easier to reason about. Shared access is common because it is quicker to set up, and it is where problems appear. Even with per-user access, a few things can outlast a permission change:
-
Search indexes built from documents, if they are not refreshed or filtered by current permissions.
-
Cached or saved answers, such as a summary of a confidential report stored in a shared workspace.
-
Conversation history that a person can still scroll back through.
-
Exports and attachments the assistant generated and emailed.
-
Integrations connected using one person’s credentials, which keep working after they move.
We are not claiming any particular setup is secure. These are the places to check.
For a wider view of what internal assistants should and should not do, see our note on the internal AI assistant.
An illustrative example: a revenue manager changes role
An illustrative example, not a real client: consider a hypothetical hotel group in the UAE with four properties. Its internal assistant can answer questions from the property management system, the group’s revenue reports, the contracts folder and the HR policy library.
A revenue manager, with access to rate strategy, corporate contract terms and owner reports, moves to a front-office manager role at one property. Two months later they leave the group.
At the role change, the IT owner removes their revenue reports and contracts permissions in the source systems. Then they check the assistant:
-
Asking the assistant, as that user, for “the negotiated rate for our largest corporate account” now returns “you do not have access to that source”. Good.
-
But the assistant’s search index was last rebuilt weekly. For three days, a question about “Q3 owner report highlights” still surfaced an excerpt. The fix: the index now checks live permissions at query time, not only at build time.
-
The person’s old conversation history still contains a summary of the corporate contract terms they asked for last month. The group decides that, on a role change, conversations touching sources the person can no longer access are archived away from them.
-
A scheduled weekly revenue digest was set up under their name and still emails them. It is reassigned to the new revenue manager.
At departure, their account is disabled in the identity system. The check this time:
-
Test login fails. Assistant access ends with it.
-
One integration, pulling daily pick-up figures into a sheet, had been connected with their credentials. It is reconnected under a service account owned by the revenue team.
-
Exports they generated sit in their mailbox, which is handled under the group’s normal leaver process.
The point is not that each step was hard. It is that nobody would have found the index lag, the history and the integration without checking.
An access review checklist for internal assistants
Run this at least quarterly, and on every role change or departure:
-
List each source the assistant connects to and how: per-user or shared account.
-
For shared accounts, write down what the account can read and who owns it.
-
Confirm the assistant checks the current user’s permissions at the time of each question.
-
Check whether indexes, caches or saved summaries respect permission changes, and how quickly.
-
Decide what happens to conversation history after a role change.
-
Find scheduled reports, digests and integrations created under the person’s name.
-
Ask test questions, as the changed user, that should now be refused. Record the result.
-
Name one owner for the assistant’s access map and the date of the last review.
Where data protection rules or contracts apply, confirm your obligations with your own adviser. This checklist is a practical review, not a compliance guarantee.
Keep the assistant’s scope narrow at first
The simplest way to reduce access risk is to connect fewer sources. Start with one domain, such as operating procedures or one property’s records, get the permission model right, then add the next. A broad assistant over everything is harder to review and harder to trust.
Where SolvTree fits
This maps to our internal AI tools and data capabilities: assistants that respect source permissions, with an access map your team owns and a review routine for role changes. We would start with one assistant role and its sources, and test removal before widening access.
Next step: Book a free 30-minute operational audit and we will review one assistant role and the sources it can access. The report is yours to keep.
Frequently asked questions
- What AI access should be checked when a person changes role?
- Review source permissions, shared accounts, indexes, cached answers, conversation history, exports and scheduled digests. Check integrations tied to that person and name an owner for the access map.
- How can a team verify that AI access was removed?
- Test with the changed user’s access and questions that should now be refused. Check current permissions at query time and verify that retained summaries or scheduled reports do not expose removed sources.