Neo4j Protocol
The neo4j protocol uses Bolt or HTTP to send Cypher queries and return graph data. Teams set up client drivers to talk to the graph server over TCP ports. Many teams share one broad database role across developers and apps to move fast. Broad roles let any user run heavy writes or read sensitive nodes by mistake. How the neo4j protocol handles graph sessions Neo4j supports two main ways to move data between clients and the database server. The first option is Bolt, a binary protocol built for
Model Context Protocol (MCP) Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The neo4j protocol uses Bolt or HTTP to send Cypher queries and return graph data. Teams set up client drivers to talk to the graph server over TCP ports. Many teams share one broad database role across developers and apps to move fast. Broad roles let any user run heavy writes or read sensitive nodes by mistake.
How the neo4j protocol handles graph sessions
Neo4j supports two main ways to move data between clients and the database server. The first option is Bolt, a binary protocol built for fast graph queries. Bolt keeps TCP sockets open so apps can reuse sessions without extra network handshakes. It packs nodes, links, and paths into compact binary messages to save bandwidth.
The second option is the HTTP API, which sends JSON messages over standard web ports. Web tools and simple scripts often use HTTP when they cannot load a Bolt driver. Both methods require the client to log in with a username, password, or token. After login, the server checks the assigned role before running any Cypher statement.
In a cluster, routing rules direct read queries to follower nodes and writes to leaders. The client driver fetches a routing table from the cluster during the initial handshake. This design keeps graph reads fast and prevents write conflicts across the cluster. Teams should turn on TLS encryption so passwords and graph data stay private on the wire.
How native roles work in graph databases
Native roles in the graph database control which labels and properties a user can read. Admins create roles and grant read, write, or schema rights to specific database users. When a session starts, the server loads these rules and checks every Cypher query. This setup blocks unauthorized users from dropping indexes or reading restricted node labels.
Teams also connect the database to an external directory to manage user groups in one place. When an engineer leaves the team, removing their directory group revokes their database role. Native audit logs can record who logged in and which statements ran on the server. These built-in tools give teams a solid base for basic user management.
Model Context Protocol (MCP) Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Where native graph roles fall short
Native roles decide who can log in, not whether a live query is safe. A developer with write access for one bug fix holds that power all day. One bad Cypher query can delete millions of edges before anyone notices the mistake. Static roles cannot pause a dangerous delete statement and ask a lead for approval.
Shared service passwords also create blind spots in the native database audit logs. When five engineers use one admin account, the log shows the same user name. Teams cannot tell which person ran a slow query or exported customer data. Also, native property rules return all or nothing instead of masking sensitive fields in flight.
If a node stores emails, phone numbers, card numbers, or national IDs, raw values appear. Masking rewrites matched fields in results so analysts can test queries with safe strings. Without query-level checks, teams must choose between blocking developers or risking raw data leaks.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between Bolt and HTTP in Neo4j?
Bolt uses compact binary messages over persistent TCP connections for fast, stateful graph transactions. HTTP sends text-based JSON payloads, which works well for simple scripts without native drivers.
How does routing work in the neo4j protocol?
Routing drivers ask the cluster for a map of leader and follower servers first. The driver then sends write queries to the leader and read queries to followers.
Why are static database roles risky for production graphs?
Static roles stay active all day and do not check individual Cypher statements for safety. A user with valid write rights can still run an unapproved delete or read raw PII.