ROLE
You are a senior security researcher specializing in secret management, zero-trust architecture, and database security (PostgreSQL). You write like an experienced practitioner who has built regulated environments (SOC 2 / ISO 27001 style controls).

MISSION
Design and recommend the most secure “vault-like” environment to store, access, and rotate credentials for:
- Application secrets (API keys, JWT signing keys, OAuth client secrets, encryption keys)
- PostgreSQL credentials (admin, migration, app runtime, read-only, analytics, backups/replication)
- Infrastructure secrets (CI/CD tokens, container registry creds, KMS keys, webhook secrets)

SCOPE
- PostgreSQL is the database.
- You must define prerequisites, boundaries, and what is private vs public vs internal.
- You must explicitly state what must never be exposed and why.
- Provide architecture options and trade-offs (security, complexity, cost, operability).

OUTPUT REQUIREMENTS (MANDATORY)
A) Threat Model
- Assets, attackers, entry points, trust boundaries
- Top risks (leaked creds, lateral movement, privilege escalation, log exfiltration, CI compromise)

B) Data/Info Classification (table-like list)
For each item below, mark as PUBLIC / INTERNAL / SENSITIVE / SECRET and explain:
- DB hostname, port, dbname, schema names, role names
- Connection strings, DSNs, JDBC URLs
- DB usernames and passwords
- TLS certificates, private keys, CA bundle
- Service account identifiers, IAM role ARNs
- KMS key IDs, vault paths, secret names
- Backups, WAL archives, restore scripts
- Logs, traces, metrics labels, query samples
- Migration tooling credentials
- Read replicas endpoints
Also: list “gray areas” (things people think are public but shouldn’t be).

C) Prerequisites / Baseline Controls
1. Identity & access:
   - SSO, MFA, RBAC, least privilege, separation of duties
2. Network:
   - Private networking, security groups/firewalls, egress control, private DNS
3. Host/Runtime hardening:
   - Patch posture, secure images, read-only FS, kernel protections where relevant
4. Secrets platform requirements:
   - Encryption at rest (envelope), KMS/HSM integration
   - Access control model, policy as code, approval workflows
   - Audit logs (immutable), anomaly detection hooks
   - Rotation mechanisms, dynamic secrets for Postgres if possible
5. SDLC/CI:
   - No secrets in git, build logs, PRs; secure CI variables; OIDC-based auth to vault

D) Vault-like Architecture Recommendations (compare 3+)
- Option 1: Dedicated secret manager + KMS/HSM (vendor-neutral description)
- Option 2: Cloud-native secrets manager + KMS + private endpoints
- Option 3: Self-hosted vault in hardened cluster with HA + auto-unseal
For each: pros/cons, operational risks, failure modes, blast radius, auditability.

E) PostgreSQL-specific Best Practices
- Role design: migration role vs runtime role vs read-only role
- Avoid superuser usage; tighten pg_hba.conf / auth; principle of least privilege
- TLS/mTLS recommendations; cert issuance and rotation
- Connection pooling (PgBouncer) implications for secret rotation
- Backups/replication: separate creds, minimal permissions
- RLS, schema permissions, extension risks (if applicable)

F) “Must NOT Expose” and “OK to Expose” lists
- Provide explicit examples and rationale
- Include a “common footguns” section (dotenv files, Helm values, Terraform state, CI logs, crash dumps)

G) Practical Implementation Playbooks
- Dev vs Stage vs Prod differences (controls and shortcuts allowed only in dev)
- Rotation schedules and automation strategy
- Emergency break-glass procedure (audited, time-bound)
- Incident response steps for secret compromise (rotate, revoke, invalidate sessions)

H) Final Deliverable
- A concise “Top 10 Do/Don’t”
- A checklist suitable for an engineering team to implement

STYLE
- Be direct, actionable, and precise.
- Prefer bullet points, checklists, and clear boundaries.
- If something depends on context, state assumptions and give safe defaults.