Announcing Seizu, a security-focused dashboard for graph databases with MCP

TL;DR: Seizu is an operational layer for security graph databases: dashboards for humans, scheduled queries for automation, and permission-controlled MCP tools for agents. Though it’s primarily targeted at security tooling, it’s also usable as a general Neo4j dashboarding tool.

A while back I worked at PayPay Japan, leading their product security org. Like most startups, they had a number of disparate tools to handle their security needs, but needed a cohesive strategy on improving their security processes across their engineering teams.

PayPay operated with a DevSecOps model and wanted security to primarily fit into that same ownership structure, rather than sit outside it as a separate review gate. This meant teams needed to be empowered to own their security, which meant first they needed to know what issues applied to their services.

The problem was that critical security context was spread across many systems. Findings were not always tied cleanly to teams or services, and giving everyone direct access to every SaaS tool meant paying for more seats than we really needed.

Pulling disparate data, and mapping it together

As a first step we took to simplify this for teams was to use CNCF’s Cartography product to pull data into a Neo4j graph from their cloud provider, IDP, system vulnerability SaaS, vulnerability scanner SaaS, CVE datasets, Kubernetes, internal deployment system, and other sources. Then, we added some Cartography analysis jobs to add relationships for data that weren’t automatically handled by default in Cartography.

This provided a single location that not only had up-to-date information from all tooling and infrastructure, but also gave us an end-to-end view of teams, services, services’ transitive dependencies, containers, associated infrastructure, access from endpoints throughout a service’s resources, and more.

Finding a needle in a haystack

Pulling data into a graph database means you have the data you need, and that you can query it quickly, but it doesn’t solve the problem. You also need some way to make that data digestible by teams in a straightforward way.

This is where Seizu comes in.

I wrote Seizu to make it easy to provide per-team reports, outlining what needed to be focused on, as well as how to action outstanding issues. We also used it to provide reporting cross-team/org so that security teams, and leadership, could ensure efforts were being directed where it was needed, and that OKRs were being hit.

Trial by fire

While developing Seizu, and building out the Cartography graph, we had a first major test in using our tooling for emergency incident response: Log4Shell.

Seizu and Cartography were instrumental in an incredibly fast response, that was also highly effective in prioritizing the most important targets, and then working down all targets until every service was known safe.

The hard part of Log4Shell was not just finding directly exposed services, but also finding internal services could also be reachable through paths from exposed systems. Prioritization depended on understanding the graph of services, dependencies, containers, and network exposure.

Within hours of Log4Shell, Cartography community members were sharing queries with how to find Log4j dependencies, as well as queries to find vulnerable paths. We had reports written, both per-team and cross-org, that identified critical paths that should be targeted first. We were able to isolate non-critical services, and were able to patch critical services in a very short time period in a way we could confidently verify.

Initial response isn’t everything, though. Part of vulnerability management is ensuring regressions don’t occur. Services occasionally need to roll back, developers deploy old images to qa/staging, and development nodes run old branches. The repo may have a patched main branch, but other branches, and old container images may still be vulnerable.

Scheduled queries and alerts

We added the ability to run scheduled queries, outputting query results to a queue that we consumed in a pipeline to find and scan container images that were running in Kubernetes that hadn’t yet been scanned for Log4Shell regressions.

We also extended the scheduled queries to alert teams in Slack when a new regression popped up, so they could undo the action that led to the regression. Along with this, we added StatsD output to hook into stats alerting for teams, which could be used to page teams for critical services.

Fork and refactor

As mentioned earlier, I wrote this years ago. Though Seizu was open sourced, I had left PayPay, and hence couldn’t continue as the maintainer. Since then the original release has been closed.

Cartography was recently donated to CNCF, and that rekindled my interest in investing in the general ecosystem. I’ve made a fork of the original OSS release and have made considerable improvements to the tooling. Here’s a short-list of improvements:

Queries and Neo4j access are now fully controlled by Seizu

Neo4j Community Edition is not designed for fine-grained, direct end-user access control. Neo4j Enterprise Edition is prohibitively expensive for small organizations and testing out new tooling. By having Seizu run queries, rather than giving users direct Neo4j access, we can:

• Ensure read-only access to Neo4j Community Edition, by validating queries
• Log actions, including queries
• Have reports written by users with full read access, but shared to users with only access to the data exposed by the reports
• Provide agents read-only access to the graph, or subsets of the graph

Seizu validates Cypher before execution, blocks write queries and admin actions, guards against common exfiltration patterns such as LOAD CSV and APOC-based outbound calls, and can surface schema/property warnings to help users write better graph queries.

Query validation alone shouldn’t be your sole defense. Seizu’s documentation has guidance for hardening Neo4j for defense in depth. We also have a Neo4j plugin to better enforce read-only access and to disable admin actions, directly in the Neo4j layer.

Access to Seizu (and thus Neo4j) goes through your IDP, with fine-grained permissions and roles

Seizu defers authentication to your identity provider and supports two complementary paths that resolve to the same identity and permissions:

• In the browser: Seizu uses a backend-for-frontend (BFF) flow. The Seizu backend, rather than the SPA, performs the OIDC Authorization Code + PKCE exchange, so the IDP refresh token never touches JavaScript. It lives only inside an AES-256-GCM-encrypted, HttpOnly, Secure, SameSite=Strict session cookie, while the short-lived access token is held in memory by the React app and never written to local storage. The SPA silently renews it against the backend before it expires.
• For everything programmatic: the CLI, the MCP endpoint, and direct REST API calls authenticate with Bearer JWTs, validated against your IDP’s JWKS (with optional RFC 7662 token introspection for opaque tokens).

Seizu has fine-grained permissions; those permissions are grouped into built-in roles and can also back user-defined roles. A role claim in the token (configurable, seizu_role by default) maps the groups/roles from your IDP to roles in Seizu, with a configurable default role for tokens that carry no claim.

The built-in roles make it easy to get started:

• seizu-viewer: read reports, run approved tools, render skills, and view scheduled-query metadata. No ad-hoc query console access.
• seizu-editor: all viewer capabilities, plus create/edit/delete/pin reports, set the default dashboard, and use the ad-hoc query console (validated read-only Cypher) with query history.
• seizu-admin: all editor capabilities, plus manage toolsets, tools, skillsets, skills, scheduled queries, and user-defined roles.

The MCP endpoint uses the same authentication and permission model as the UI, CLI, and REST API. When configured, Seizu also exposes OAuth discovery metadata for MCP clients, so compatible clients can discover the authorization and token endpoints and authenticate through the organization’s existing OIDC provider rather than relying on manually copied bearer tokens.

MCP toolsets and skillsets, both built-in and user-defined, are included

Seizu supports both tools and skills. Tools are callable MCP actions, while skills are delivered to agents as MCP prompts. Both are grouped as toolsets and skillsets, and both can be enabled or disabled individually or as groups.

A number of built-in tools are provided out of the box, like the ability to query the graph, or introspect the defined schema, but you can also create your own tools (or have an agent define them for you), to provide subsets of the graph for lower token usage or for security.

Skills can define trigger phrases, typed parameters, required tools, and prompt templates. In Claude Code, they can be exposed as slash commands such as /seizu:<skill_name>; in Codex, they can be invoked by name.

Agents are first class citizens

All features are accessible to agents, via MCP. Agents can write reports, create scheduled queries, add tools, define skills, and help investigate graph data. Because MCP requests resolve to the same Seizu user and permission set as the UI/API, agents only see and execute the tools, prompts, and administrative actions their identity is allowed to use.

The most powerful use case is investigation. An agent can help find vulnerable paths or secure a service because it has access to highly relevant infrastructure context in a pre-connected graph.

All features are database-backed, and editable via UI, CLI, API and MCP

Choose your preferred method of editing. You can edit directly through the UI, you can use the CLI, an API, or you can have an agent make changes on your behalf.

Reports are grid-based, resizable, and support a basic set of panels (count, progress, bar, pie, table, markdown, etc). Markdown uses Stripe’s Markdoc, and has support for basic templating, with plans to fully incorporate query data in markdown panels for more powerful templating.

An ad-hoc query console and graph explorer are included

The basics of what are most commonly used in Neo4j’s console can be done in Seizu directly. Query the graph, visualize it, and see the data in table or raw form. See the schema (nodes, relationships, properties), with quick-actions to query example data from the schema.

Query history is saved per-user, in the database, so you don’t lose your query history if you move across browsers.

Scheduled queries

Scheduled queries can be defined, with a pluggable output. Current outputs are: stats, sqs, slack, log, but you can define your own if you need a custom output, or want to have more logic in the query.

The queries are either run on a specific schedule (every x minutes), or can be driven by changes in the graph (a new Cartography sync that updates the data, for example).

Versioning

Security tooling needs an audit trail. Reports, scheduled queries, toolsets, tools, skillsets, skills, and roles in Seizu are database-backed and versioned, so important operational changes aren’t just overwritten in place.

This matters more once humans and agents are both making changes. A report can be updated as an investigation evolves. A scheduled query can be tuned as a detection matures. A tool or skill can be refined as an agent workflow becomes more useful. A role can be changed as access requirements shift. In each case, Seizu keeps prior versions available so teams can review what changed, understand who changed it, and restore earlier definitions when needed.

Versioning also makes Seizu safer to use as an agent-facing system. Agents can help create reports, scheduled queries, tools, and skills, but those changes remain visible and reviewable through the same UI, CLI, API, and MCP surfaces used by humans.

Try it out and get in touch

You can try out Seizu, with some basic data, preconfigured reports, tools, and skills in the quickstart.

If you’d like to chat, open a discussion in GitHub, or if you’ve found a bug or want to make improvements, open an issue.