Back to home

Security at Pantrifuge

Your kitchen says a lot about your life — what you buy, what you eat, who you live with. We treat that as private by default. This page explains exactly what we do to protect it, in plain words first and in technical detail further down.

Last reviewed: September 20, 2026

In plain words

Your pantry is yours

What you add to Pantrifuge is tied to your account. We don't sell your data, and we don't share it with advertisers.

Only you and the people you invite

Nobody else can see your items, receipts, photos or meals. Household members only see what your household shares.

Locked at the source

Access rules live in the database itself, not just in the app. Even a mistake in the app can't hand your rows to someone else.

You can leave with your data

Export everything you've stored, or delete your account, from your settings at any time.

Your data, your account

Every item, receipt, photo, meal and shopping list you create is stored against your account. Our database refuses to return another person's rows to you, and refuses to return yours to them — that rule is enforced below the application, so it holds even if a page or button has a bug.

Households. When you invite someone into a household, you are deliberately sharing that household's pantry, shopping list and planning with them. They do not get access to your profile email, your private notes, your payment details or any other household you belong to. You can remove a member at any time.

Sharing and the marketplace. Items you choose to share or list are visible only in the way you chose — to a specific person, or as a listing. Addresses on store listings are masked until a pickup is arranged, and pickup codes are generated server-side with a cryptographically secure random source.

Staff and stores. Business accounts are isolated by organisation. Staff see only their own store's inventory and orders.

Our own team. Internal tools are limited to a small number of administrators, require two-factor authentication, and are used for support, safety and billing — not for browsing your pantry.

How we protect it

Encrypted in transit and at rest

Every connection uses HTTPS/TLS. The database, file storage and backups are encrypted at rest by our managed cloud platform.

Sign-in and two-factor

Passwords are hashed by our managed authentication service — we never see or store them. Two-factor authentication (authenticator app) is available to every account, and is mandatory for all internal admin areas. On supported phones you can add Face ID or fingerprint unlock.

Per-row access rules

Row-level security is switched on for every table in our database, with policies scoped to the signed-in account. Reads and writes are filtered by the database before the app ever sees them.

Private file storage

Receipts, fridge photos, waste images, resumes and signed documents live in private buckets with per-owner rules, size limits and short-lived signed links. Only genuinely public imagery — blog, recipe and marketplace pictures — is publicly readable.

Secrets stay on the server

API keys and service credentials are stored in a managed secret store and used only inside server-side functions. They are never bundled into the app you download or the pages you load.

Payments handled by Stripe

Card details are entered directly with Stripe, a PCI-DSS Level 1 provider. Pantrifuge never receives, processes or stores card numbers.

Keeping it running

Backups. Our managed cloud platform takes automated backups of the database and supports point-in-time recovery, so we can roll the data back to a specific moment rather than only to last night. File storage is redundantly stored by the same platform.

An independent off-site copy. Since September 2026 a nightly job copies the entire database and every stored file into separate cloud storage held in our own account, outside the platform that runs the service. Each night produces a dated restore point with a manifest describing the exact file set; unchanged files are stored once and referenced rather than copied again. We keep roughly 30 daily and 12 monthly restore points, and a stored file is never removed while a retained restore point still references it. Failures alert us by email the same morning.

Rebuildable from source. All application code and every change to it are version-controlled. Secrets live outside the codebase, so credentials can be rotated without touching the code, and the entire service can be rebuilt from a known-good commit.

If something happened anyway. Our response sequence is: contain (cut off the affected path and suspend affected sessions), rotate (replace keys, tokens and credentials), assess (determine what was reached, using append-only audit and usage records that an intruder cannot quietly edit), restore (recover to a verified clean point in time), verify (re-run our security checks before reopening), and notify (tell affected customers and any regulator we are required to inform, with what we know and what we're doing).

On ransomware specifically. The database and file storage are managed services rather than servers we keep on a network share, which removes the most common ransomware path. Point-in-time recovery means encrypted or destroyed data can be rolled back. In addition, the nightly off-site copy described above lives in storage we control, separate from the running service, so a compromise of the platform does not take the backups with it. On September 20, 2026 we performed a full restore rehearsal from the previous night's off-site copy into an isolated, throwaway environment — production was never touched. The complete database (169 tables, 52,720 rows) rebuilt in 22 seconds and all 6,044 stored files (9.6 GB of photos, receipts and documents) restored in 7 minutes, with no failures and byte-for-byte totals matching the snapshot index. Data recovery is therefore a matter of minutes; a realistic end-to-end return to service, including deciding which restore point to use and provisioning a clean environment, is 2–4 hours. We repeat this rehearsal quarterly and after any change to the backup format.

For security reviewers

Database access control
PostgreSQL row-level security enabled on every application table; policies scoped to auth.uid() or an explicit membership/role check.
Privilege escalation
Roles are held in a dedicated table and evaluated through a SECURITY DEFINER function — never read from a user-editable profile field.
Admin surface
Admin and internal routes require an admin role plus a completed second factor (AAL2) at the session level.
Server logic
Privileged work runs in isolated edge functions with validated input, output sanitisation and least-privilege database access.
Append-only records
Sensitive ledgers (usage and cost events, audit logs) are append-only: update and delete privileges are revoked and guard triggers enforce it.
Input handling
User input is schema-validated, length-capped and escaped before display or email rendering; CSV exports neutralise spreadsheet formula injection.
Transport & browser
HTTPS only, a content security policy, and a frame guard on authentication and invitation pages.
Monitoring
Automated code, dependency and database security scans run continuously; findings are triaged, fixed and recorded with the change that closed them.

Penetration testing

Planned

We run continuous automated scanning today and fix findings on a tracked schedule. A third-party penetration test has not yet been performed; when one is completed we will publish the date, scope and remediation status here, and make a summary letter available to partners and investors on request. We would rather be accurate than impressive.

What we deliberately don't claim

  • We are not SOC 2 or ISO 27001 certified. We are building toward those controls.
  • We do not use end-to-end encryption; your data is encrypted in transit and at rest, but is readable by the service in order to work (expiry tracking, meal ideas, search).
  • No system is unbreakable. Our goal is a small attack surface, early detection, and a fast, honest recovery.

Report a security issue

Found something? Please tell us before telling the internet. Email pantrifugeai@gmail.com with the steps to reproduce, the affected URL or screen, and what you were able to access.

  • We aim to acknowledge reports within 2 business days.
  • We will keep you updated until the issue is resolved, and credit you if you'd like.
  • We will not pursue legal action against good-faith researchers who avoid privacy violations, data destruction and service disruption, and who give us reasonable time to fix the issue before disclosure.
  • Please test only against your own account and data.

See also our Privacy Policy and Terms of Use.