just-vibeDatabases · inspect by default
/db-access
Audit roles, tenant filtering, and row-level policies where supported
Use for grants, connection roles and row policies; backend-permissions checks application enforcement.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select db-access from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv db-access, /just-vibe db-access and /jv:db-access in Claude. See shortcut setup and context examples.
/just-vibe:db-access Audit tenant policies and service-role bypass paths from supplied metadata./just-vibe:db-access Review row policies where reads are scoped but inserts permit another tenant ID./just-vibe:db-access Inspect policy definitions without probing real tenant data or changing grants.What the agent does
- Trace the actual runtime role, grants, execution identities and ownership or bypass privileges.
- Inspect read and write policy predicates with positive and cross-tenant negative access cases; run read-only probes against an isolated target in scope, and leave write-policy probes to a separately scoped apply run.
Inputs
- roles, tenant model, policies, engine, and representative access matrix.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Database privileges, tenant predicates, row-level policies, and bypass paths.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. db-migrate applies an accepted grant or policy change.
- Mode
- Inspect; roles, tenant model, policies, engine, and representative access matrix.
- Prerequisites
- Actual engine/version, schema/migrations, query workload, and explicitly identified environment. Prefer supplied plans, metadata, and isolated fixtures. Even a SELECT can lock, call mutating functions, or overload a database; inspect semantics before execution. Executing an analyzed query is distinct from reading its plan.
Expected output
- Role/resource/action matrix with policy paths, verified and unknown isolation checks, and remediation or test proposals.
How the work is checked
- A tenant cannot read/update another tenant's rows; privileged service roles are recognized as potential policy bypasses.
When to stop or clarify
- No grant/policy changes or real tenant-data probing by default. Unknown execution roles block confident isolation claims.
Handling missing context
- Infer
- Read engine/version, ORM/runner, schema and migration history from project artifacts before choosing SQL.
- Assume
- Prepare local SQL and isolated fixtures without assuming production size, locks or recovery guarantees.
- Ask
- Ask for environment, downtime or recovery constraints before live/destructive execution when missing; unavailable production access does not block migration files.
Technical guidance
- Evidence
- Read actual connection roles, grants, RLS read/write predicates, owner/bypass privileges and tenant context setup/reset.
- Method
- Test using the application role and transaction/pool lifecycle; distinguish row visibility from INSERT/UPDATE policy enforcement.
- Pitfall
- Table owners or bypass roles can make policy tests pass incorrectly; pooled session tenant state can leak into the next request.
- Check
- Alternate tenants on reused connections and test select/insert/update/delete plus indirect views/functions under the intended role.
Situational decisions
When tests run as an elevated owner/service role: Do not infer ordinary-user isolation from those results; test the intended execution identity.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.