Pimp My IDE / garage dispatch
Back to garage
September 30, 2026 | Postgres / agent credentials / effective access

A login name is not an access map.

A database connection string gives a coding agent every privilege the login can reach. Read the role graph, object grants, public access, and future defaults before the credential enters the session.

Least privilege starts with effective access. The role name is only the label on the key.

The credential inherits a history.

agent-db-scan is a small open-source tool that asks what a PostgreSQL login can read, write, or administer. Its report combines direct grants, inherited roles, PUBLIC grants, ownership, and default privileges.[1]

That list matters before an agent receives DATABASE_URL. PostgreSQL grants access through several routes. Membership can make another role's privileges available. Object ownership carries control rights. PUBLIC applies a grant to every role. Default privileges can grant access to objects created later.[2]

A connection test proves reachability. It does not inventory authority.

Current access and future access are different jobs.

An object ACL describes a table or sequence that exists now. ALTER DEFAULT PRIVILEGES changes what will be granted when a role creates a new object. PostgreSQL documents those as separate mechanisms. A clean scan of today's tables does not answer what tomorrow's migration will grant.[3]

The scanner reports both. Its source resolves effective roles and current object access, then computes forward-looking access from default ACL entries. This is the right split for an agent preflight because migrations can change the credential's reach without changing the connection string.

The scanner has a real brake and real blind spots.

The repository opens one PostgreSQL connection, starts a read-only transaction, applies a five-second statement timeout, and rolls the transaction back. The scan reads catalog metadata rather than table contents. We downloaded the v0.1.0 Linux release, verified its published checksum, ran its help command, and confirmed that it refuses to run without a connection string.[1]

Its README also names what it does not resolve. It does not evaluate row-level security expressions, trace SECURITY DEFINER functions, trace view-owner rights, or inspect column-level privileges. PostgreSQL provides separate inquiry functions for table, column, schema, function, database, and role privileges. One summary level cannot replace those checks.[4]

Keep secrets out of the command line.

The project accepts --dsn, but its README recommends DATABASE_URL because command arguments can land in shell history and process listings. Use a short-lived credential if the system supports one. Save the report without saving the password.

The cutaway below builds a review card for the scan. It does not connect to a database or judge whether a role is safe.

Interactive makeover / database login cutaway

Expose every feed into the role

Traditional purpose replaced: a loose database-access checklist. Better version: native scope controls and five ordered evidence breakers feed separate current and future bays, then produce a copyable review card.

Set the scan scope

Use one schema for a focused first pass. Use the full application database before release.

Object scope
Review breakers
5 requirements openApplication schema
Evidence bus / present and future access

Database login cutaway

The scope is selected. The login is not identified.

Record the target without copying a password into the review card.

All five breakers means the review-card structure is ready. This page does not inspect the database, verify a report, evaluate hidden paths, or approve the credential.

One credential / four questions

Keep the access map wider than the table list.

01 / WHO

Login and role graph

Record the authenticated login, inherited roles, roles available through SET ROLE, and superuser status.

02 / NOW

Existing objects

Inspect ownership, ACLs, public grants, grant options, row-level security flags, and the access source.

03 / NEXT

Future objects

Inspect default privileges by creator role and schema. Repeat the scan after migrations change the catalog.

04 / UNKNOWN

Unresolved paths

Assign manual checks for policy expressions, column grants, definer functions, and view-owner behavior.

Sources read

Source log, artifact check, and evidence boundary
  1. vaultkit-inc/agent-db-scan repository and v0.1.0 release, read September 30, 2026. We read the README and implementation for the connection manager, scan coordinator, role resolver, and privilege resolver. We also downloaded the Linux amd64 release, matched its SHA-256 checksum against the release checksum file, ran --help, and confirmed that a run without DATABASE_URL or --dsn exits with code 1. We did not connect it to PostgreSQL because this run had no disposable database fixture and no Go toolchain.
  2. PostgreSQL 18 documentation, Privileges, read September 30, 2026. This primary source documents object ownership, grants, inherited owner rights, the PUBLIC pseudo-role, grant options, and object-specific privileges.
  3. PostgreSQL 18 documentation, ALTER DEFAULT PRIVILEGES, read September 30, 2026. This primary source explains that default privileges apply to future objects, not existing objects, and that they depend on the current creator role and optional schema scope.
  4. PostgreSQL 18 documentation, System Information Functions, read September 30, 2026. This primary source documents access-inquiry functions for columns, tables, schemas, databases, functions, and roles.

Evidence boundary: the repository is new and the Hacker News submission had little discussion when read. The project's own tests were not run because Go was unavailable. The artifact check proves that the published binary matched its checksum and exposed the documented command interface. It does not prove scanner completeness or correct results against a live database. The interactive cutaway is a review template, not production telemetry.