Security & Trust

Every table in the Gungnir database that holds firm data is protected by Row-Level Security (RLS) — a database-native enforcement layer, not application code. This means that even if our application had a bug that passed the wrong tenant ID, the database itself would reject the query and return zero rows.

The isolation check on every query is:

-- Applied to every SELECT, INSERT, UPDATE, DELETE
USING (tenant_id = auth_tenant_id())

There are 57+ tables with this policy. None of them can be bypassed by application code. The only bypass is the database service role key — which is never exposed to the frontend, never used in client-side code, and covered by our Data Processing Agreement.

Every matter document you upload to Gungnir is encrypted before it reaches storage using AES-256-GCM, a standard authenticated encryption algorithm.

How it works:

1. When you upload a matter document, Gungnir generates a unique data encryption key (DEK) for your firm.
2. The file is encrypted with your DEK before it is written to storage. What reaches the storage layer is ciphertext.
3. Your DEK is itself encrypted with a master key that only Gungnir holds, and stored alongside your tenant record.
4. When you download a document, Gungnir decrypts the file in memory and streams the plaintext to your browser over TLS. The plaintext is never written to disk on our servers.

What this means for you: Even if someone extracted the raw storage bucket, they would get encrypted blobs that are unreadable without your firm's DEK.

Every action on your firm's data — document upload, AI draft, billing entry, login, approval decision — creates a timestamped record in an append-only audit log.

The audit log is enforced at the database level: there are no UPDATE or DELETE policies on the audit log table for any role, including platform administrators. Once an entry is written, it cannot be changed or removed by anyone.

You can view your firm's complete audit trail at any time from Settings → Audit trail. Each entry shows the action, the user who performed it, the IP address, the timestamp, and a SHA-256 payload hash so you can verify the entry has not been tampered with.

We want to be honest about what is technically possible versus what is contractually and operationally prevented.

What is technically possible: A Gungnir engineer with access to the Supabase service role key could bypass RLS at the database layer. This is true of every SaaS platform.

What prevents this:

• Matter document encryption — even with database access, matter documents are ciphertext. The DEK is required to decrypt.
• Data Processing Agreement — Gungnir is legally bound as a data processor under R.A. 10173. Unauthorised access is a breach of contract and a violation of Philippine law.
• Audit log — any application-layer access to your data is logged. You can audit what has been accessed at any time.
• Access controls — production infrastructure access is restricted to a small number of authorised engineers and logged.

Gungnir runs daily automatic backups of all firm data. Point-in-time recovery allows restoration to any moment within the retention window. Before Supabase Pro activation, the standard retention window applies. After Supabase Pro upgrade (before 50 tenants), retention extends to 7 days. Backups are stored in Supabase's Seoul, South Korea region (AWS ap-northeast-2).

Gungnir runs on serverless infrastructure (Vercel for the web application, Railway for the AI service). There is no single server to attack or take down. DDoS protection is built into the platform layer. All environment variables and secrets are encrypted at the infrastructure level and are never in source code.

In the event of a personal data breach affecting your firm, Gungnir will notify you within 72 hours of becoming aware of the breach, as required under R.A. 10173 and NPC Breach Reporting requirements. We will provide a description of the nature of the breach, the categories of data affected, and the measures taken or proposed to address it.