Trust & security

Security, risk, and legal overview for Kitchen Toolkit customers.

This page gives a plain-language overview of how Kitchen Toolkit approaches security, risk, and legal topics, without requiring you to dig into internal documentation.

Read the user manual Help desk Legal docs Security & compliance Contact support

Sales, pilots, and tenant access are handled for business, institutional, and professional kitchen operators. Current hardware deployments may include pilot, evaluation, or pre-certification units for supervised indoor use until released otherwise in writing.

At a glance

Hosted SaaS only: Kitchen Toolkit is operated by our team and is not licensed for self-hosting.
Admin access uses HMAC-signed session cookies (12-hour max age) plus CSRF protection for changes.
Device uploads use per-device HMAC signatures; optional nonces help reduce tampering and replay risk.
Secrets are encrypted at rest with AES-256-GCM and masked in the UI and exports; passwords are PBKDF2 hashed.
Hosted on Vercel with default KV storage in Upstash (AWS us-east-1) or your own KV endpoint.
The public Help desk may route questions and attachments through configured AI providers, temporary Upstash-backed support caches, and short-lived support image URLs.
Non-default tenant bundles require authenticated admin or provisioned-device context; the default demo tenant remains public.
Exports and deletion are controlled in the admin console, but Git history and customer-managed provider backups may persist outside Kitchen Toolkit control.
Security incidents are communicated to tenant contacts without undue delay after we become aware, in line with applicable law.
Kitchen Toolkit is assistive software and hardware; it does not replace manual food-safety programs, human review, or emergency response.

Account access and device integrity

Kitchen Toolkit combines account-level authentication with device-level signatures to reduce the risk of unauthorized access or tampering.

Admin sessions use HMAC-signed cookies with a 12-hour max age, and non-default tenant content also requires a short-lived access cookie or equivalent admin/provisioned-device context.
CSRF tokens are required for admin actions that change data or settings.
Device uploads include a per-device HMAC signature; optional nonces are used and replayed nonces are rejected.
Tenant scoping is enforced for admin, device, push-subscription, and protected content requests to reduce cross-tenant access risk.
Passwords are stored as PBKDF2 hashes; password resets use 15-minute links sent to the tenant contact email, and initial setup links normally go by email with an inline fallback only if email delivery is unavailable.

Encryption and secret handling

We encrypt sensitive configuration data and avoid exposing secrets in the UI or exports.

Hosted admin, API, and device-to-cloud traffic use HTTPS/TLS; hubs use a temporary HTTP captive-setup page only on their password-protected maintenance AP, while the full local hub admin surface remains self-signed HTTPS on trusted local networks and should not be internet-exposed.
Tenant environment settings (SMTP, webhooks, KV tokens, billing IDs, retention overrides) are encrypted at rest with AES-256-GCM before storage.
Customer-managed webhook URLs are encrypted at rest, and the current product accepts either HTTP or HTTPS targets; use HTTPS unless you intentionally operate an internal-only endpoint.
Secrets are masked in admin views and exports so unchanged values stay hidden.
Settings updates are sanitized and can be audit logged with timestamp and IP when auditing is configured.
Kitchen Toolkit cannot view plaintext passwords and does not expose secrets in exports.

Data ownership and storage

You retain ownership of Customer Data. We process it only to provide, secure, support, and improve the service.

Customer data is stored in tenant-scoped namespaces, and non-default tenant bundles/manifests require admin or provisioned-device context.
Log records include timestamps, device IDs, timezones, IP addresses, and HMAC signatures for auditability.
Kitchen Toolkit does not sell or share Customer Data beyond operating the service you request.
By default, the platform runs on Vercel with KV storage in Upstash (AWS us-east-1).
You can point telemetry to your own KV endpoint from admin settings if preferred.
Restaurant content is stored as Git-backed bundles; deletion removes active content, but Git history and customer-managed providers may keep backups or archives outside Kitchen Toolkit control.

Retention, exports, and deletion

You control how long data is retained and can export or delete from the admin console.

Retention windows for logs and alerts are configurable per tenant in admin settings.
Admins can export logs, equipment data, alerts, tenant profiles, and masked environment settings.
Exports reflect the data stored in the configured KV endpoint.
Deletes and retention changes apply to the live product-side stores Kitchen Toolkit targets, including tenant-configured storage KV and platform KV records covered by the delete flow.
Git history and customer-managed provider backups or archives may persist outside Kitchen Toolkit control.
Some records do not auto-expire and require manual deletion when needed.

Subprocessors and data transfer

Kitchen Toolkit relies on established providers to operate the hosted service.

Hosting and routing: Vercel. KV storage: Upstash (AWS us-east-1) or your configured KV endpoint.
Source and content systems: GitHub. Billing: Stripe. Messaging: customer-selected SMTP/webhook providers plus Kitchen Toolkit-managed Google/Gmail-hosted fallback or platform mail delivery for some account, security, operational, and export messages.
If you use the public Help desk, questions and attachments may also be processed through the configured AI provider stack (currently Groq, OpenAI, and/or OpenRouter, depending on runtime configuration) with temporary Upstash-backed caching and short-lived support-image URLs for visual analysis.
Data may be processed in Canada and the United States or in your configured KV endpoint.
Material subprocessor changes are communicated at least 30 days in advance when practical.

Incident response and availability

We communicate quickly when issues arise and may suspend service to protect customer data.

Security incidents are communicated to tenant contacts without undue delay after we become aware, in line with applicable law.
If infrastructure compromise is suspected, service may be temporarily taken offline while patches are applied.
Service is provided as-is; no uptime SLA or service credits apply unless agreed in writing.

Customer responsibilities and acceptable use

Security is a shared responsibility between Kitchen Toolkit and each customer account.

Secure your devices, networks, and connected third-party services; rotate credentials if compromise is suspected.
Keep admin and billing contacts current and manage access for invited users.
Do not upload sensitive categories of data that are not requested (e.g., payment cards or identity documents).
If you assign devices or accounts to named staff, or use KT records for accountability workflows, handle any employee/workplace notices your deployment requires.
Use Kitchen Toolkit email, push, and export features only for operational or customer-directed messages you are authorized to send; they are not offered as a general-purpose bulk marketing service.
Use the service for internal business purposes unless a separate agreement allows otherwise.

Legal baseline and policy access

This page is a plain-language summary and does not replace the Terms of Service or Privacy Notice.

Full legal terms, privacy notice, and data export/deletion policy are published under /docs/legal and linked during sign-up.
Governing law is Ontario, Canada with venue in Kitchener-Waterloo.
Standard DPA, transfer-addendum / SCC, and subprocessor-schedule templates are published under /docs/legal; customer-specific signatures and redlines still run through the legal contact path.
Lawful requests will be honored and tenants will be notified unless legally prohibited; passwords and secrets are stored encrypted or hashed and cannot be provided in plaintext.