Security & Data Protection 🛡️

Is the data of the families you serve safe with us? Yes.

Access is restricted to accounts you approve, the data is encrypted so no one else can read it, and each pantry's records are isolated.

How we protect your data

PantryInsight stores personal information about the families you serve, including names, addresses, and household composition. The safeguards below apply to all of it.

☁️

Audited cloud hosting

Your data is hosted on Google Cloud and TiDB Cloud, both independently certified to ISO 27001 and SOC 2.

🔐

Encrypted in transit & at rest

Data is encrypted while moving over the network and while stored, so it can't be read in between.

🔑

Passwords never in plaintext

Passwords are stored as one-way hashes, not the original value. We cannot read them either.

Approved-only access

Every page requires a login, and new accounts must be approved by an admin before they work.

🚫

Never sold or shared

Your data is used only for your dashboard. You own it and can export or delete it at any time.

🏠

Per-pantry isolation

Each pantry's records are stored in a separate database, never mixed with another organization's.

🤖

Read-only AI

The built-in assistant can read data to answer questions but cannot modify it, and it never receives individual records.

Summary and technical detail for each safeguard

Each topic below opens with a summary. The toggle beneath it contains the technical detail required for IT review or grant reporting.

Where your data lives

Your data is hosted on two independently audited cloud platforms. Google Cloud runs the application and TiDB Cloud stores the database. They provide the physical security, backups, and uptime, certified to standards including ISO 27001 and SOC 2.

Technical detail: certifications (ISO 27001, SOC 2, FedRAMP)
  • Google Cloud Platform (GCP) runs the application and holds independent certifications including ISO/IEC 27001, 27017, 27018, SOC 1/2/3, and FedRAMP authorization for U.S. government workloads.
  • TiDB Cloud hosts the database with its own SOC 2 Type II and ISO/IEC 27001 compliance, running on top of major cloud providers.

Scope: these certifications apply to our infrastructure providers. PantryInsight is not separately certified under ISO, PCI, or FISMA. We do not process or store payment card data, so PCI requirements do not apply.

Encryption

Encryption converts data into an unreadable form that only authorized systems can decode. We apply it in two places: while data moves over the network, and while it is stored in the database. Passwords are stored only as one-way hashes, never in their original form, so they cannot be recovered, including by us.

Technical detail: TLS, AES-256, PBKDF2
  • In transit: everything moves over HTTPS (TLS). App-to-database connections are encrypted too, and we verify the database server's certificate and hostname on every connection, so no one can impersonate it.
  • At rest: all stored data and backups are encrypted with AES-256 by our infrastructure providers.
  • Passwords: hashed one-way with a salted PBKDF2 before they touch the database. Reset links are single-use, signed, and expire after 6 hours.
  • Secrets: API keys, database credentials, and signing keys are loaded from a secret store at deploy time. They are not hard-coded or committed to version control.

Access control

Access is not automatic. No record is visible without logging in. New accounts must be approved by an admin before they work, and admin tools are restricted so a standard user cannot reach them, even by entering the URL directly.

Technical detail: sessions, CSRF, rate limits
  • Login required everywhere: every page and API endpoint checks for a valid session first; unauthenticated requests are redirected (APIs get a clean 401). Only a minimal allow-list of public routes (login, sign-up, reset, OAuth callback) is reachable without one.
  • Allow-listed sign-up: new accounts, whether created with Google or email, must match an approved address or organization domain. This requires human approval before access is granted.
  • Separated admin: admin views and actions are restricted to a configured allow-list.
  • Hardened sessions: the login cookie is signed, HttpOnly, Secure, SameSite, and has a bounded lifetime.
  • CSRF protection: every state-changing request must echo a per-session X-CSRF-Token, or it's rejected with 403.
  • Rate limiting: login, sign-up, reset, and the AI endpoint are throttled per client; going over returns 429 until you wait.

The AI assistant

PantryInsight includes an assistant you can query in plain language. It can only read your data; it cannot change or delete anything. It never receives individual records. It uses the structure of your data to answer a question, and names and addresses are never sent to it.

Technical detail: read-only account, query validator, data handling

It can only read:

  • Runs on a dedicated read-only database account (SELECT only).
  • Every generated query passes a read-only validator that blocks write keywords, file-write clauses, and SQL comments.
  • Queries run behind an EXPLAIN pre-check, a hard row cap, and a timeout, so nothing can exhaust the database or dump unbounded data.

What it sees:

  • To understand a question it gets only the database structure (table and column names), not the contents of your tables.
  • For direct look-ups, the query runs on our server and the result is filled in after the AI has finished; the rows never reach the model.
  • For trend analysis, a small capped sample is shared, but names, address, email, phone, and date of birth are removed first. Only totals, dates, program, and county remain.
  • Each request is independent and stateless: one user's question cannot surface in another's answer.
Training policy. The assistant can run on a paid AI tier (Google's paid Gemini / Vertex AI), where prompts are contractually not used to train the model. Regardless of tier, direct identifiers are removed before any data reaches the model, so individual identities are never exposed to the AI.

Tenant isolation

Each pantry's data is stored in its own database. There is no shared table where one organization's records sit alongside another's. This removes the most common cause of cross-tenant data leaks and makes data residency straightforward: a region's data stays in that region.

Technical detail: multi-tenant architecture

The product is multi-tenant by separation: each tenant has its own database (and, initially, its own deployment), driven by per-tenant configuration. There is no shared table requiring a tenant_id filter, which eliminates the most common multi-tenant leak and makes data residency (e.g. keeping an EU pantry's data in the EU) straightforward.

Backups & monitoring

Your data is backed up automatically and stored redundantly, so a single server failure won't lose it. We maintain logs and alerts so issues are detected quickly. You own your data and can export it in full at any time.

Technical detail: backups, logging, monitoring
  • The database runs on TiDB Cloud with automated backups, point-in-time recovery, and redundant storage across availability zones.
  • Application requests, sync jobs, and AI queries are logged for monitoring and after-the-fact review.
  • A stale-data monitor alerts admins if the data pipeline stops refreshing, so issues surface quickly instead of silently.

Last updated: June 22, 2026.

Have a security question? 🛡️

Contact us for board evaluation, grant reporting, or to report a vulnerability.

📅 Book an Intro Call Contact us