security-and-infrastructure

Kitchen Toolkit — Security & Infrastructure Statement [source: docs/legal/security-and-infrastructure.md]

Last updated: 2026-05-04 [source: docs/legal/security-and-infrastructure.md]

Kitchen Toolkit is a hosted service. The following technical controls are implemented in the codebase. [source: docs/legal/security-and-infrastructure.md]

## Authentication and session protection
- Admin requests require a signed `kt_admin` cookie (HMAC with `ADMIN_COOKIE_SECRET` or `APP_SECRET`), tenant scoping, and a 12-hour max age; CSRF tokens are required for mutating admin actions. [source: lib/auth/session.js][source: lib/auth/csrf.js]
- Non-default tenant restaurant bundles and manifests are additionally protected by a short-lived `kt_content` access cookie or equivalent admin/provisioned-device context, enforced in middleware and supporting APIs. [source: middleware.ts][source: lib/auth/contentAccess.js][source: pages/api/content/access.js]
- Initial account setup and password reset flows use time-limited setup/reset tokens. Password reset links are sent to the tenant contact email, while initial setup links normally go by email and fall back to inline display only if email delivery is unavailable. [source: pages/api/tenant/signup.js][source: pages/api/tenant/requestPasswordReset.js][source: pages/api/tenant/resetPassword.js]
- Device API calls must include `x-device-id`, `x-device-hash`, `x-device-signature`, and `x-device-nonce`; signatures are verified with per-device secrets and timing-safe comparisons, missing nonces are rejected, and replayed nonces are rejected. [source: lib/auth/device.js][source: __tests__/deviceAuth.test.js]
- Admin and device tenant routing is normalized and enforced per request to prevent cross-tenant access. [source: lib/auth/device.js][source: lib/auth/session.js]
- Push subscription registration and removal require admin or signed-device authorization tied to the tenant and, for device requests, to the device ID. [source: pages/api/push/subscribe.js][source: pages/api/push/unsubscribe.js]

## Data protection
- Tenant environment payloads (SMTP credentials, webhook URLs, KV tokens, billing IDs, retention overrides) are encrypted with AES-256-GCM using `TENANT_ENCRYPTION_KEY` (or admin secret) before storage in KV; decryption failures are logged and rejected. [source: lib/tenant/env.js]
- Sensitive fields returned to admins are masked, not plaintext, to avoid accidental disclosure in the UI or exports. [source: pages/api/getTenantEnv.js][source: lib/tenant/env.js][source: pages/admin/settings.js]
- Environment updates are sanitized, merged, and audit-logged (fields changed, IP, timestamp) when KV auditing is configured. [source: pages/api/updateTenantEnv.js][source: lib/tenant/env.js]
- Device and log records include HMACs and tenant-scoped keys (`log:{tenant}:{type}:{device}:{timestamp}`) to keep data isolated per account. [source: pages/api/uploadLog.js][source: pages/api/uploadEquipmentLog.js]

## Infrastructure dependencies and configuration
- Vercel hosts the application from a private GitHub repository; default KV storage uses Upstash (AWS N. Virginia `us-east-1`) unless a tenant supplies its own `storage_kv_url`. [source: docs/reference/data-and-privacy.md][source: lib/tenant/env.js][source: pages/admin/settings.js]
- Required backend environment variables include KV endpoints/tokens, GitHub repo details, and admin password; startup halts if any required variable is missing to avoid misconfigured deployments. [source: lib/ensureEnv.cjs]
- KV operations use bearer tokens supplied via environment variables for both tenant data and audit records. [source: lib/tenant/env.js][source: pages/api/updateTenantEnv.js]
- Git-backed restaurant bundles and manifests are modified through authenticated GitHub API calls; unauthenticated access is not used for content changes. [source: pages/api/deleteRestaurant.js]
- Outbound email may use tenant-configured SMTP settings or KT-managed Gmail/Google-hosted fallback transport, depending on feature and configuration. [source: lib/tenant/mailer.js][source: pages/api/sendLog.js][source: pages/api/uploadEquipmentLog.js][source: pages/api/admin/checkNodeHealth.js]

## Availability, logging, and maintenance
- Log, alert, and live node-presence TTLs are enforced through expiry calls to KV with configurable defaults (`LOG_RETENTION_DAYS`, `ALERT_TTL_DAYS`, `NODE_LAST_SEEN_TTL_DAYS`, `STALE_ALERT_TTL_DAYS`); retained node last-value snapshots (`node:snapshot:*`) persist until node/equipment detach or delete flows remove them. [source: pages/api/uploadEquipmentLog.js][source: pages/api/admin/detachHubNode.js][source: pages/api/updateEquipment.js][source: pages/api/deleteEquipment.js][source: docs/reference/retention-policy.md]
- Admin-triggered data exports rely on the same authenticated KV connections and tenant scoping; responses include masked environment variables. [source: pages/api/exportTenantData.js]
- Failed push, email, and webhook alert deliveries are recorded as server warnings and compact KV evidence records under `alert:deliveryFailure:<tenant>:<channel>:<event>` for later operator inspection. [source: lib/alerts/deliveryEvidence.js][source: pages/api/uploadEquipmentLog.js][source: pages/api/hubHeartbeat.js][source: pages/api/admin/checkNodeHealth.js][source: pages/api/push/send.js]
- KT does not maintain separate backups of tenant KV data; deletes and TTL expiry on the configured KV endpoints are not recoverable from backups. [source: docs/reference/data-and-privacy.md]
- If KT infrastructure is suspected compromised, operators may temporarily take down the Vercel deployment and apply patches before restoring service. [source: docs/legal/terms-of-service.md]

## Customer responsibilities
- Customers must secure their devices, networks, and any connected third-party services (SMTP, webhooks, KV endpoints) and rotate credentials if compromise is suspected. [source: lib/tenant/env.js][source: pages/admin/settings.js]
- Platform access is provided “as is” and “as available”; customers remain responsible for endpoint hardening and for ensuring connected services comply with their policies. [source: docs/legal/terms-of-service.md]
- KT does not monitor customer secrets or passwords; hygiene (rotation, revocation, and device authorization) is customer-driven using the provided admin and reset flows. [source: lib/tenant/env.js][source: pages/api/tenant/requestPasswordReset.js][source: pages/api/tenant/resetPassword.js]
- If KT infrastructure is suspected compromised, service may be taken offline from Vercel while patches are applied; contact liam@liambendix.com for coordination. [source: docs/legal/terms-of-service.md]

## Open items
- Hosting locations and default KV region are documented (Vercel + Upstash us-east-1); security incidents will be emailed to tenant contacts without undue delay after KT confirms or reasonably suspects unauthorized access, in accordance with applicable law and law-enforcement constraints. [source: docs/reference/data-and-privacy.md][source: docs/legal/terms-of-service.md]