Encrypting individual sensitive columns before they hit the database, on top of disk-level encryption.
Field-level PII encryption is the practice of encrypting personally identifiable information (PII) at the application layer with keys the database itself does not hold. Customer names, phone numbers, and street addresses are encrypted before they are written to the database and decrypted only when the application reads them back.
The application holds an encryption key (in a key management service or environment-protected secret) and uses it to encrypt PII fields before the INSERT statement runs. The database stores ciphertext. On read, the application decrypts the ciphertext on the way back to the user. Anyone with database access alone — an attacker with a leaked credential, a misconfigured backup, an over-permissioned analyst — sees encrypted bytes instead of plaintext names and numbers.
A common implementation uses Fernet (a symmetric authenticated encryption format defined by the Python cryptography library) for individual fields, with a single application key rotated periodically.
Disk-level encryption protects against someone walking off with the physical hard drive. It does not protect against the more common attack: a credential leak, a vendor with too much access, a backup file exposed via a misconfigured bucket. Field-level encryption raises the bar significantly: even with full database access, an attacker has only ciphertext and no key.
Night Watch encrypts caller name, phone number, address, and other PII fields with Fernet before writing them to Postgres on Supabase. Keys are held in the application’s secret store, not in the database. Recording files in Supabase Storage are similarly protected with row-level security and access tokens that the application gates per request. Nothing in this pipeline is shared with third parties or used to train external AI models.