Postgres Security and Data Access Hardening

When to use

Invoke when a PostgreSQL deployment must enforce a security architecture and data classification at the engine, when reviewing an existing database for access-control and data-protection gaps before go-live or a security review, or when remediating over-privileged roles, missing tenant isolation, unprotected PII, or weak connection security.

Do not use for: schema modeling or migrations (use postgres-schema-and-migration), query/index performance (use postgres-indexing-and-query-optimization), replication/HA topology (use postgres-replication-and-ha-readiness), or backup/restore/PITR (use postgres-backup-and-operational-readiness).

Inputs

Required:

• The security architecture in scope: trust boundaries, threat model, authorization model, and tenant-isolation requirements, sourced from security-architecture.md where it exists.
• The data classification: which tables/columns are PII, confidential, or regulated, sourced from security-architecture.md / data-architecture.md.
• The deployment substrate: self-managed, managed (RDS/Aurora/Cloud SQL), or Kubernetes operator — this constrains TLS, audit, and TDE options.

Optional: