Role-Based Access Control in Neo4j
Give every user and AI agent only the access it needs. Use the built-in roles, build your own, and hide sensitive properties in a Neo4j database running in Docker.
In this 45-minute lab, you will learn
Every system that connects to your database, from a reporting dashboard to an AI agent, should be able to read and change only what it uses. Anything more is a risk: a bug, a leaked credential or a prompt-injected agent can only reach what the account is allowed to reach.
In this lab you will apply that principle to a movie recommendation graph running in Docker. The graph holds ratings, movies and genres, but it also holds personal details about the users who left the ratings. A recommendation agent needs the ratings. It does not need to know who the users are.
You will start by looking at the roles that ship with Neo4j and see why the built-in reader role exposes more than the agent needs. You will then create a role of your own that lists exactly what the agent may read, and finish by hiding user details from a second agent with DENY and checking your work with the privilege audit commands.
You should have completed Running Neo4j in Docker and be comfortable reading simple CypherNeo4j's implementation of GQL, the ISO standard query language for graph databases. It is declarative: you describe the pattern to find, and the database decides how to find it. statements. No prior experience with Neo4j security is needed.
Built-in roles
Know what the reader, editor, publisher, architect and admin roles grant, and why most of them give a user or agent more than it needs.
Custom roles
Create a role and grant it traversal and read access to only the labels, relationship types and properties a system uses.
Hiding properties
Hide sensitive properties with an allow-list or a DENY, then audit exactly what each role and user can do.