SuperAPI AI Directory
Partner with us中文AI newsFavorites
All toolsAI codingdatabase-sentinel

database-sentinel

Read-only security audit for Supabase. Four tools surface RLS gaps, permissive policies, exposed functions and grants; an audit prompt returns scored findings with fix SQL.

Open website

About this tool

Overview

Database Sentinel provides security auditing capabilities for database backends. To describe the experience in one sentence: ask "audit my database" and get a scored report with precise remediation code. It can be used as a Claude Skill (supporting Supabase, MongoDB), a read-only MCP server for any AI client, or a CLI agent using its own model (both support Supabase).

Three Usage Forms

  • Claude Skill: Load SKILL.md in Claude Code. Only SKILL.md (about 2K tokens) and core/* are preloaded; files for each backend are loaded only when that backend is detected.
  • Read-only MCP server: Works with any MCP client. Provides four read-only Supabase tools, one audit prompt, and a schema catalog as a resource. Analysis is performed by the user's own LLM, so it is free.
  • CLI agent (sentinel-audit): Based on a LangGraph pipeline, it can be used with any OpenAI-compatible model, such as OpenRouter, OpenAI, or local Ollama.

Main Capabilities

  • Detect RLS misconfigurations, exposed keys, and high-risk functions.
  • Return scored reports and generate precise remediation SQL.
  • Read-only first: only reads system catalogs; the MCP server and agent cannot write, delete, or drop anything.
  • Does not read users' row data: the audit role has no access to table data; repository scans report only files and line numbers, never key values.
  • Writes and network probes require explicit opt-in (Skill form only).
  • Verification step: probe as anonymous (anon) to confirm exploitable findings.
  • --fix only prints remediation SQL for selected findings, and never executes it.
  • Cost reporting: tokens, dollar cost, and tool call count per audit.
  • Continuous monitoring: provides github-action-supabase.yml and github-action-mongodb.yml templates that can run on migrations, policy or IaC changes, weekly, or manually, comment on PRs, and fail the build when critical issues are found.

Usage

Claude Code one-time installation of the audit skill and MCP server (requires uv): Supabase users first create a read-only login (step 1), then run in Claude Code /plugin configure database-sentinel@database-sentinel, then ask "Audit my database". For other MCP clients and full setup, see the MCP guide. When using only the skill, Claude Code will recognize it automatically. The CLI agent (Supabase, bring your own model) can be installed via pipx:pipx install "database-sentinel[agent] @ git+…"; the MCP server can be installed via uvx --from git+… sentinel-mcp . Available sentinel-mcp --role-sql prints the read-only role setup SQL. Version pinning: use git+https://github.com/Farenhytee/database-sentinel@v1.0.0in any uvx / pipx command. The Claude Code plugin automatically pins the version.

By default, the CLI audits with one prompt plus anonymous probe verification, about $0.0007 and about 15 seconds each. --deep switches to a tool-calling agent, with the same accuracy on our benchmark but about 5 times the cost.

Skill Audit Process

  1. Detect the backend. 2. Scan the code for exposed credentials. 3. Introspect the schema, policies, and configuration. 4. Match against the anti-pattern catalog. 5. Safe probing (opt-in). 6. Score and report. 7. Generate remediation code.

Security Details

  • Supabase write probes use Prefer: tx=rollback, therefore no data is modified.
  • The MongoDB write probe uses session + abortTransaction() on replica sets; on standalone deployments it uses a canary insert plus delete (opt-in).
  • The MongoBleed network probe requires double opt-in; some monitoring tools will alert on the 42-byte probe packet.
  • The authentication probe uses the .invalid email domain (RFC 6761).
  • Credentials reside in memory only during the audit and are redacted in reports.
  • The MCP server has five independent layers of read-only protection.

Benchmarks and Evaluation

bench/cases/ holds annotated Supabase schemas, applied to a local Supabase. evals/ scores three systems by precision, recall, and F1: R0 (rules, no LLM), B0 (single-shot prompt), and A (agent). The test set is frozen and never used for tuning. Test set (10 blind locked cases, deepseek-v4-flash, each run 3 times): agent F1 0.782, single-shot prompt 0.766, rules 0.559 (v0.2.0 results); v0.2.1 fixed crashes and timeouts, agent F1 rose to 0.831, single-shot prompt rose to 0.849, v0.2.0 remains the blind-test number. The difference between A and B0 is within the noise range. The agent is more precise, has fewer false positives on clean projects, and discovers via anonymous authentication, but costs about 5 times as much. The MCP flow was also benchmarked: the model drives the real server via stdio, testing F1 0.865, precision 0.905, critical recall 1.0.

Version Update Highlights

  • v1.0.1 (2026-10-01): Fix — UPDATE policies without WITH CHECK are no longer reported as allowing users to reassign row ownership (Postgres reuses USING as the check). Added development case 027.
  • v1.0.0 (2026-09-30): MCP server released. Four read-only Supabase tools, one audit prompt, and directory resources. Verified on hosted Supabase: session pooler, read-only role with BYPASSRLS, all 20 queries. Q1 now checks API authorization: when RLS is off but anon / authenticated are revoked, it is no longer reported as exposed. Audit menIndicates that SECURITY INVOKER functions have only caller privileges. Standard auditing becomes the CLI default.
  • v0.2.1 (2026-09-30): Fixed bad tool parameters no longer terminating the audit; OpenRouter calls routed to the fastest provider; the agent's final discovery step no longer lists rejected candidates.
  • v0.2.0 (2026-09-29): Released test results; added MCP server, lightweight agent, benchmarks and evaluations; fixed six Supabase audit queries (Q8 never matched, Q16 and Q19 missed rows, Q6/Q13/Q14 had incorrect conditions).

Detectable Patterns and Research Sources

See Appendix A for the detailed table. The MongoBleed probe (mongobleed-probe.md) is a single-packet read-only detector, validated on mongo:7.0.20 (vulnerable) and 7.0.28 (patched), and runs only after two opt-in confirmations. Research sources include CVE-2025-48757, Escape.tech, Veracode, CMU SusVibes, ModernPentest, Supabase Splinter lints, CVE-2025-14847 MongoBleed, Mongoose CVE-2024-53900 / CVE-2025-23061, CIS MongoDB 7 Benchmark, etc.

Applicable Scenarios

Suitable for developers using Supabase or MongoDB, authors of vibe-coding projects, and teams that want a low-barrier, low-cost way to continuously check database security configurations (RLS, policies, key exposure, high-risk functions) and obtain remediation SQL. Also suitable for integration into CI as a security regression gate (the rules version is free).

Limitations and Notes

  • Read-only by default, does not read table data; writes and network probes are only available in the Skill form and require explicit opt-in.
  • Remediation SQL is never executed automatically and must be applied by the user.
  • Partial backend support: Supabase supports Skill, MCP server, and CLI agent; MongoDB is supported in the Skill form.
  • Pricing, charges, and the specific pricing of the hosted version Locksoup are not yet provided.
  • License: MIT; exceptions: database_sentinel/agent/, database_sentinel/mcp_server/, and database_sentinel/kb/ are AGPL-3.0, and contributing to AGPL directories requires a CLA.
  • Naming history: Supabase Sentinel (v1) → Database Sentinel (v3, multi-backend). The supabase-sentinel name is still available via compat/supabase-sentinel/.

Related Links

  • Repository:https://github.com/Farenhytee/database-sentinel
  • See the documentation in the repository for MCP server setup and usage guide
  • Hosted version: Locksoup (provides Supabase security auditing, scheduled rechecks, and alerts)

Related tools

Browse category