RBAC Privilege Update Propagation: Do Active Neo4j Sessions Reflect Changes Immediately?

Do active Neo4j sessions see privilege changes right away?

Short answer: yes, for any new query issued after the role is modified, Neo4j will honor the updated privileges immediately. A running transaction that began before the change is not retroactively revoked; it can continue until the point where the new policy would be violated, typically at commit time.

How Neo4j evaluates permissions

• Access rights are checked at the start of each query execution, not when a session is opened.
• The server keeps a lightweight privilege cache that is refreshed automatically whenever a role definition is altered.
• There is no documented driver‑side command to force a cache flush on a per‑session basis; the system‑wide refresh is implicit.
• Neo4j 5.x and later apply changes instantly across all running sessions. Earlier 4.x releases may exhibit a very short, sub‑millisecond staleness window.

What stays the same after a change

• Transactions that were already started before the privilege revocation will keep running until they hit a point where the new restriction applies (often at COMMIT or the next query in the transaction).
• If the transaction has already performed an operation that is now disallowed, the commit will fail with an AUTHORIZATION_FAILURE.
• Any new session or new query issued after the change will immediately enforce the updated policy.

Practical verification steps

1. Create a role with read access to a specific label:

   CREATE ROLE read_label_role;
   GRANT READ ON :LabelName TO read_label_role;
   CREATE USER alice SET PASSWORD 'pass' USER ROLE read_label_role;

2. Open a driver session as alice and run a MATCH query to confirm success.
3. Revoke the read privilege:

   REVOKE READ ON :LabelName FROM read_label_role;

4. Immediately issue another MATCH in the same session; you should receive an AUTHORIZATION_FAILURE.
5. Start a multi‑statement transaction before revoking:

   BEGIN;
   MATCH (n:LabelName) RETURN n;
   REVOKE READ ON :LabelName FROM read_label_role;
   MATCH (m:LabelName) RETURN m;
   COMMIT;

   The second MATCH will fail, and the COMMIT will raise an authorization error.
6. Repeat the test on a 5.x cluster to confirm instant propagation; on a 4.x cluster you may observe a negligible delay (a few milliseconds) before the new policy is enforced.

When a session restart is required?

Under normal circumstances, a session restart is not required for privilege changes to take effect. The only scenario where a restart might be considered is if you suspect a stale driver‑side cache in a long‑lived connection pool; in that case, closing all connections or restarting the driver application will clear any cached session state.

Missing diagnostic detail

To tailor this guidance to your environment, could you confirm which Neo4j major version you are running (4.x or 5.x)? That will help narrow down the exact timing of the cache refresh.