An error message that echoes a row can expose the very data your access rules protect. The --pii pass looks where nobody writes a test.
Every error and RAISE path exercised
Output inspected for personal data
Findings in their own report, with JSON alongside
Runs on your side, no telemetry
Run it
The database URL goes in the DATABASE_URL environment variable. There is no command-line flag for it.
export DATABASE_URL=postgresql://user:pass@host:5432/mydb
unitautogen pii --schema public
On Windows PowerShell, set it with $env:DATABASE_URL="postgresql://user:pass@host:5432/mydb". The standard PG* variables work too. Connecting →
It picks up your Enterprise licence file automatically. On Supabase, run unitautogen --supabase pii --schema public from your project. It connects to the local Supabase database itself.
The PII audit report
Each finding names the routine, the path, and the personal data it exposed
Written to <out>/pii_tests/pii_report.html, its own module in the output
pii_findings.json alongside, for CI
Run it with --pii next to your security coverage run
Recognises PHI by column name too, such as medical record numbers, diagnosis codes and medication
Declare columns it does not recognise in the config file
Why it is its own check
Access control asks who can reach a row; this asks what the code says back
A leak here needs no multi-tenancy. One customer's data in an error is still exposure
Maps to data-minimisation, distinct from the access controls seccover covers
We would like to log your visit to see how the site is used. That records the page, the site you came from, your IP address and browser, and a random id for this tab. We delete it once we no longer need it.
